Refeds


Subject Re: eduPersonSubjectIDGUID
From Nick Roy <nroy@xxxxxxxxxxxxx>
Date Thu, 22 Oct 2015 19:48:07 +0000

Makes sense.  It's a centralized solution, and hyperbolically so.  I've been back-channeling with Nate on his "Dogma" - which is the other end of the central/not central spectrum, and probably has less dire security problems than my "give everyone a permanent single ID" pitch.

Has anyone who is interested in this conversation on either of these lists, and wants to solve this problem, not gotten a chance to look at Nate's "Dogma," or couldn't understand it?  It took me a while to understand it (not sure I still fully do).  It's worth a read and a sleep-on-it (or in my case, several dozen sleeps-on-it) if you haven't.

Trying to find a middle-ground path between these endpoints, I was trying to think about this problem along the axes of types of identifying secrets and their relative merits and problems.  I thought about:

1) Private keys that are not escrowed
-These are a huge problem because they're a pain in the butt to teach people how to use; have provisioning, revocation and other management problems...etc.

2) Passwords that a person knows and a verifier stores a hash of
-These are a problem for all the reasons we all know

3) Private keys that are escrowed
-Less manageability problems, but problems around proof of possession/"giant honeypot in the sky"

Then I thought, "what if there were some combination of these things that would allow sharing of identifiers using policy and key sharding so that a user always had to be involved in the sharing of their secrets, but IAM systems and relying parties could be involved in certain aspects of provisioning/management without user involvement"?

Hashicorp Vault's use of key sharding and policy to perform varying actions with varying numbers of shards present is pretty interesting:


Nick

From: "Jones, Mark B" <Mark.B.Jones@xxxxxxxxxxx>
Date: Thursday, October 22, 2015 at 12:19 PM
To: Nick Roy <nroy@xxxxxxxxxxxxx>, "mace-dir@xxxxxxxxxxxxx" <mace-dir@xxxxxxxxxxxxx>, "refeds@xxxxxxxxxx" <refeds@xxxxxxxxxx>
Subject: RE: eduPersonSubjectIDGUID

If eduGAIN is to be the central organizing entity then eduGAIN should generate and assign the identifier.

 

From: Nick Roy [mailto:nroy@xxxxxxxxxxxxx]
Sent: Thursday, October 22, 2015 1:16 PM
To: Jones, Mark B <Mark.B.Jones@xxxxxxxxxxx>; mace-dir@xxxxxxxxxxxxx; refeds@xxxxxxxxxx
Subject: Re: eduPersonSubjectIDGUID

 

cf.

 

From: Nick Roy <nroy@xxxxxxxxxxxxx>
Date: Thursday, October 22, 2015 at 11:02 AM
To: "refeds@xxxxxxxxxx" <refeds@xxxxxxxxxx>, "mace-dir@xxxxxxxxxxxxx" <mace-dir@xxxxxxxxxxxxx>
Subject: Re: [refeds] Re: [MACE-Dir] eduPersonSubjectIDGUID

 

As an adjunct to this, the eduGAIN-published portability service could also be a long-lived and community-supported IdP of last resort, since a person would need to log into it anyways to hook up their old value to their new account.

 

Nick

 

From: "Jones, Mark B" <Mark.B.Jones@xxxxxxxxxxx>
Date: Thursday, October 22, 2015 at 12:14 PM
To: Nick Roy <nroy@xxxxxxxxxxxxx>, "mace-dir@xxxxxxxxxxxxx" <mace-dir@xxxxxxxxxxxxx>
Subject: RE: eduPersonSubjectIDGUID

 

I don’t see how global portability works without a central organizing entity.

Without that central entity to tell you which UUID belongs to who the UUID is meaningless.

 

I don’t see ‘portability’ as being useful.  When a person moves from one institution to another they don’t pick up their identity and take it with them.  The identity at the old institution remains and gains some form of ‘inactive’ attribute, and a new identity is established at the new institution.  I don’t think ‘portability’ is what is needed.  It may or may not be desirable to link one or more current identities to one or more old identities.  i.e.  I am mark@xxxxxxxxxxx, I am mark@xxxxxxxxxxxxx, and I am also mark@xxxxxxx.

 

 

From: Nick Roy [mailto:nroy@xxxxxxxxxxxxx]
Sent: Thursday, October 22, 2015 1:01 PM
To: Jones, Mark B <Mark.B.Jones@xxxxxxxxxxx>; mace-dir@xxxxxxxxxxxxx
Subject: Re: eduPersonSubjectIDGUID

 

Global portability across institutions, and across things like IdPs of Last Resort which may go out of business.

 

Nick

 

From: "Jones, Mark B" <Mark.B.Jones@xxxxxxxxxxx>
Date: Thursday, October 22, 2015 at 11:58 AM
To: Nick Roy <
nroy@xxxxxxxxxxxxx>, "mace-dir@xxxxxxxxxxxxx" <mace-dir@xxxxxxxxxxxxx>
Subject: RE: eduPersonSubjectIDGUID

 

I don’t think an identifier has any value without a scope/context.

 

What is the use case?

 

 

 

From: mace-dir-request@xxxxxxxxxxxxx [mailto:mace-dir-request@xxxxxxxxxxxxx] On Behalf Of Nick Roy
Sent: Thursday, October 22, 2015 11:27 AM
To:
mace-dir@xxxxxxxxxxxxx
Subject: [MACE-Dir] eduPersonSubjectIDGUID

 

Hello,

 

I've seen the subject of type 4 (https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_.28random.29) UUIDs or GUIDs as a way to create a globally unique (with no need for scoping) identifier across systems without any kind of coordination or state sharing between them crop up recently.

 

With all the talk of nameIDs that can change/be reassigned, and targetedIDs not providing the type of valuable "collusion" (I prefer the word "coordination" in this positive context) that VOs need, and scoped IDs being hard for a lot of systems to deal with, I would like to ask this group:

 

Is it time for a new eduPerson attribute along the lines of "eduPersonSubjectIDGUID" (or whatever you want to call it) which is just a permanent-per-person, portable, non-reassignable, globally unique and non-scoped type 4 UUID?  This would allow it to be created for a person at their home institution at the time the home institution adopts this schema extension in their IAM system.  It could be used as a persistent ID and asserted to "everyone" "by default."  A clearinghouse of these values could be set up in eduGAIN and provide global account linking.  It could then become standard practice when someone leaves an institution to tell them to access this service with their account before they leave, and immediately access it with their new account when they get to their new institution.  When they access the service at the new institution, it could send them an email containing information about how to tell their local IAM people their existing value.  If an IAM system registers for messages from this service, it could get these values auto-provisioned.

 

Thoughts?

 

Thank you,

 

Nick