Page History

The existing identifier complexity is maddening. Possibly push for adoption of the Subject-ID spec everywhere an identifier is needed, to reduce complexity for all involved going forward. Replaces eduPersonTargetedID, SAML 2.0 persistent NameID, eduPersonUniqueID and (partially) eduPersonPrincipalName. Might help align with private/public identifiers in OIDC.

• Consider creating R&S 2.0 as a result, replacing ePPN or ePPN+ePTID as standard identifier(s).
• CoCo v2 also has a section on attributes (use of "least privacy-invasive" attribute when alternatives exist) and I think that section could use more concrete and more complete guidance (which in turn would make Art.29WP/Art.68WP happier).
• We could also make this into a Best Practices piece for eduGAIN, to replace the deprecated/old Attribute Profile. Has the least prescriptive power but the widest audience.
• What ever happened to REFEDS Attribute Registry? Since Subject-ID uses different signalling (yet again: RequestedAttribute, NameIDFormat and now EntityAttribute) is the meta-attribute approach relevant (again)?

Content-wise this could say something: For SPs, signal/use subject-id if you require a shared/public identifier, if not available also accept ePUID (if not available also accept ePPN?). Signal/Use pairwise-id if you don't require correlation between multiple SPs, if not available also accept persistent NameIDs (in the Assertion's Subject), if not available also accept eduPersonTargetedId. For IDPs, have them all available, but release in the given precedence if multiple ones are signalled by the SP. I.e., provide strong guidance on what to use when (achieve consistency, lessen complexity mid-term), but help with interop today (and possibly improve privacy and data protection compliance) by giving precendece lists for alternative attributes.

Nick Roy, InCommon

Judith Bush, OCLC