Versions Compared

Old Version 1

changes.mady.by.user Heather Flanagan

Saved on

compared with

New Version Current

changes.mady.by.user Heather Flanagan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added notes

Attendees

V/C Info

Topic: R&S 2.0 WG call
Time: Dec 9, 2021 09:00 AM Pacific Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/86330064875?pwd=YjE3S2FrM24zelI3SGZiVUpVQnlNQT09

Meeting ID: 863 3006 4875
Passcode: 337622
One tap mobile
+12532158782,,86330064875#,,,,*337622# US (Tacoma)
+16699006833,,86330064875#,,,,*337622# US (San Jose)

Dial by your location
        +1 253 215 8782 US (Tacoma)
        +1 669 900 6833 US (San Jose)
        +1 346 248 7799 US (Houston)
        +1 312 626 6799 US (Chicago)
        +1 929 205 6099 US (New York)
        +1 301 715 8592 US (Washington DC)
Meeting ID: 863 3006 4875
Passcode: 337622
Find your local number: https://us02web.zoom.us/u/kcAu6M3dv6

...

Pre-reading


Agenda

  • Feedback from SeamlessAccess Contract Language WG on the Anonymous and Pseudonymous ECs
  • Discussing potential changes to harmonize with the Personalized Access EC


Notes

  • Feedback from the SeamlessAccess Contract Language group has been added in a box in each draft.
  • If we work against the assumption that these should be harmonized, need to make sure we have consensus on which direction the harmonization should run. If we re-write according to the same rules, rather than adjust piecemeal, that might be more effective.
  • One big difference in the doc is how they handle organization. There was a lot of discussion, and Personalized did something different because it does not require affiliation.
  • An entity category sets rules for attribute release; allowing several alternatives for any specific use defeats the purpose of standardization.
  • The way entitlement is referred to, if we make it consistent with Personalized, will also result in changes. Entitlement is not in personalized at all.
  • Should affiliation be required in Anonymous if it uses affiliation and organization?
  • These are not authorization specs; they are authentication and identification specs. If we are talking about authorization, we need to be consistent across all three ECs.
  • If you want to require eduPersonEntitlement for use with authorization, you need to be more specific about values.
    • Should not bake the registry into the document
    • Entitlement has a security implication; entitlement is a general concept; releasing entitlement cannot be done per SP, it would be general and released to all SPs
    • Image Added
  • For anonymous, the default identification is organization-wide. Whether that's sufficient for authorization is dependent on the service. In a sense, this ends up being just a replacement for IP address authorization. We already decided that we won't prevent people from using affiliation for authorization decisions, though we will tell them they shouldn't. The goal is to be consistent across all three ECs, so we should stick with what we decided in Personalized.
  • If we take away authorization from the ECs, we need to provide guidance for how to do authorization properly
    • Should this be prescriptive guidance or descriptive guidance? Prescriptive would be something like how to specifically use common-lib-terms; Descriptive would have the library/common-lib-term as an example
    • It will often be a business problem to get entitlement populated with whatever values the SP might expect to see. Authorization may require SP-specific knowledge, sometimes it may be IdP-specific knowledge.
    • Given the range of possibilities, the document must be descriptive because it will need to talk about when and why IdP specific authorization would work (e.g., common-lib-terms) and when and why it wouldn't and SP-specific authorization should happen. Current thought is to have this be a living doc that may refer to the registry and be updated as we learn more about existing and valid use cases for how authorization is handled in the world. There are entitlements that are highly generic; there are others that are highly specific. Here's where to find highly generic that you should use when general interop is required. If you have other use cases, consider adding to the registry. (Don't reinvent wheels.)
  • Action items:
    •  Scott Cantor to take a first pass at writing up a descriptive doc for entitlement
    •  Pål Axelsson to take a first pass at updating the anonymous and pseudonymous specs with what we have in personalized