Attendees

Agenda

Recap

Identifier issue

From R&S 1.3

where shared user identifier is a persistent, non-reassigned, non-targeted identifier defined to be either of the following:

  1. eduPersonPrincipalName (if non-reassigned)
  2. eduPersonPrincipalName + eduPersonTargetedID

From the eduPerson (202001)

NOTE: eduPersonTargetedID is DEPRECATED and will be marked as obsolete in a future version of this specification. Its equivalent definition in SAML 2.0 has been replaced by a new specification for standard Subject Identifier attributes [https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html], one of which ("urn:oasis:names:tc:SAML:attribute:pairwise-id") is a direct replacement for this identifier with a simpler syntax and safer comparison rules. Existing use of this attribute in SAML 1.1 or SAML 2.0 should be phased out in favor of the new Subject Identifier attributes."



Issues Raised on Previous Calls

  1. One of the reasons R&S supports ePPN and ePTID is that it was targeting applications that were broken because they only allow for a single identifier to identify an individual (the “one field for everything” approach). That’s why ePPN was the chosen identifier, because it was traditionally a user-friendly identifier and so suitable for the one-size-fits-all use case, as long as you ignore reassignment. ePTID was added to address reassignment. Those applications failed miserably if they only had ePTID.

    Is this still an issue? Do we still need to support the one-size-fits-all approach? If we can chose a common, opaque identifier, with an understanding that you want the additional personalization, we can do that.

  2. Providing a migration path for changes in R&S


Notes

If the requirement is to have an single identifier that is user friendly and able to route email, then there are no changes we can make here, and we need to convince people to not reassign it. There is also concerns that it will be too difficult to change this because of existing implementations, because implementations will need to re-key. If we are going to change it, we do have a clear target to move to.

Note that we are also seeing a number of services moving to OIDC, and they are relying on "sub". We can make a similar change to rely on a subject ID.

Poll one: replacing both ePPN and ePTID with a common, opaque identifier: 57%, yes; 36%, no; 7%, more info

If we focus on the "ePPN+ePTID" can we change that to a SAML subject identifier?

What can our migration path look like?

Targeted vs non-targeted


Poll two: R&S 2.0 should offer ePPN if not reassigned as one option, and SAML subject-id as the second option: 71%, yes; 29% no

Poll three: subject id should be listed as the new identifier, but the spec would include migration requirement where ePPN would be passed, regardless of reassignment status: 69%, yes; 15%, no; 15% need more info

Action item

For our next call: