Child pages
  • 2021-01-22 R&S 2.0 Notes
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

V/C Info

Topic: R&Sv2 - January call
Time: Jan 22, 2021 07:00 AM Pacific Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/87835414714?pwd=bDN6bGV4Ty9HSWZpdXNiRklNb2hYUT09

Meeting ID: 878 3541 4714
Passcode: 121039
One tap mobile
+12532158782,,87835414714#,,,,*121039# US (Tacoma)
+13462487799,,87835414714#,,,,*121039# US (Houston)

Dial by your location
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 6833 US (San Jose)
+1 929 205 6099 US (New York)
+1 301 715 8592 US (Washington D.C)
+1 312 626 6799 US (Chicago)
Meeting ID: 878 3541 4714
Passcode: 121039
Find your local number: https://us02web.zoom.us/u/kebqYGgRyb

Join by Skype for Business
https://us02web.zoom.us/skype/87835414714


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.

    • One opinion: time is right to do this, and R&S is the right place to do this first.
    • Second opinion: this is a question for the SP. Are they ready for R&S to move to a more opaque identifier? There’s no incentive for an IdP to make their identifier better unless there’s a demand by the SPs.
      • Based on the responses from the SPOG list, SPs do not handle identifier reassignment in any standardized manner. The level of automation in responding to this seems to depend entirely on the size of the SP and how big their IT budget is.
  2. Providing a migration path for changes in R&S
  • No labels