Versions Compared

Old Version 2

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: meeting notes

Attendees


V/C Info

Topic: R&S 2.0 WG
Time: Jul 1, 2021 09:00 AM Pacific Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/83548142348?pwd=N0VZY05McnZobG5DOUgwUk1jQ3BrUT09

Meeting ID: 835 4814 2348
Passcode: 452429
One tap mobile
+12532158782,,83548142348#,,,,*452429# US (Tacoma)
+13462487799,,83548142348#,,,,*452429# 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 312 626 6799 US (Chicago)
+1 929 205 6099 US (New York)
+1 301 715 8592 US (Washington DC)
Meeting ID: 835 4814 2348
Passcode: 452429
Find your local number: https://us02web.zoom.us/u/kcUGYPBFqI

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

Pre-Reading

Working Draft

Agenda

  1. Recap of consensus so far - note that all changes will need to be validated via the consultation process
    1. The FAQ will be revised to offer clarity on the term "affiliation" (see Research and Scholarship FAQ) and editorial changes made to the spec to make it more clear (see new draft spec for updated structure)
    2. eduPersonScopedAffiliation will become a required value
    3. R&S will require privacy statements
    4. subject-id should be listed as the new identifier
    5. R&S 1.3 and R&S 2.0 can co-exist; no migration detail will be included in the spec itself.
    6. ePPN and targeted ID to both be removed from R&S 2.0
    7. Information on OIDC requirements will be moved to R&S 2.1 (after the OIDF OIDCre working group has formal documentation in this space)
    8. eduPersonAssurance will be required, RAF recommended
    9. We'll resolve the need for information on the origin organization by adding guidance for the use for eduPersonScopedAffiliation
    10. DisplayName and Given/SN are required
  2. Normalizing organizational attributes between R&S, Anonymous, Pseudonymous Entity Categories
    1. Homework: working group members need to read through the other entity categories so we can discuss them in conjunction with Personalized Authorization. If we want to propose changes to those specs in favor of the work done in this working group, that's ok.

  3. Discussion of subject-id as source for origin organization (if not resolved on the list)

    1. postponing pending coverage of Personalized Authorization and the other entity categories

Notes

  1. Normalizing organizational attributes between R&S, Anonymous, Pseudonymous Entity Categories
    1. Nicole has created a comparison of attribute release information between each entity category
    2. Why is OrgDN included at all? It's not clear what's actually required. Do we have to express home org in all cases? If the SP needs to know what organization a user is coming from because of a subscription model, then they really should be using the entitlement data and not the organization. Still under debate: should entitlement require registration? The original concern was that a free-for-all of support for entitlement was too hard to support. Alternatively, though, these are generally pairwise. Suggest we limit the scope regarding the interoperability of the entity category.
    3. If home org is required in all cases, we should be clear as to why that information should be used and how it is not an entitlement. Maybe "if schacHomeOrg is present, then it's the value to be used; if not present, eduPersonScopedAffiliation should be used."
    4. eduPersonOrgDN is an X.509 structure; the value in the directory is formally defined, whereas the scope we use are domains. If you put the scope in the OrgDN, then you have a broken OrgDN.
    5. If we normalize on schacHomeOrg, that can just be a string passed as per config in the IdP; it does not have to be set in a directory
      1. Poll: Should we default to schacHomeOrg for all three entity categories? Yes 75% (6); No 13% (1); Need More Info 13% (1)
      2. No - if we require schacHomeOrg exclusively, will limit adoption. ScopedAffiliation is so much more commonly supported.
      3. Consensus: if schacHomeOrg is present, then it's the value to be used; if not present, eduPersonScopedAffiliation should be used.
    6. If we remove entitlements from the attribute bundle, are SPs even allowed to ask for an entitlement attribute given "Service Providers SHOULD limit their data requirements to the bundle of attributes defined in Section 4."? The purpose of this is to say that the IdP is not guaranteed to give you anything else, not that you can't ask for anything else. Entitlement needs to be described better; even limiting to common-lib-terms is not sufficient for all cases. eduPersonEntitlement may also be more than one value….. that sentence reads like it can only be one
      1. Need to write up language in the new proposal that would transfer across to the other, minus the entitlement part.
      2. Poll: Should we adopt the text from R&S 1.3 "Service Providers SHOULD limit their data requirements to the bundle of attributes defined in Section 5, but MAY negotiate for additional data as required via mechanisms that are outside the scope of this specification." Yes for all three 63% (5); Yes for Pseudonymous and Personalized only 25% (2); No, too open 13% (1)
        1. It's not clear enough to say that this is the minimal bundle, but you might be able to get more.
        2. The general principle is that if you want to have a frictionless interoperable experience and to meet minimization standards, don't do anything outside this bundle. But if your business needs require more, that's up to you and your responsibility.
        3. If we're encouraging entitlement and not affiliation, then we should make sure that entitlement is in there.
        4. The authorization story should be more consistent. We should also be consistent with what we say affiliation is for.
    7. The entitlements registry is only for globally recognized values, not any and all values possible
    8. The categories are mutually exclusive; an SP can't publish in metadata that they want all three. They'll have to pick what works for the majority of their use cases, and otherwise negotiate for additional attributes where needed.
    9. Only Personalized requires a third-party review (similar to as R&S is today). The other entity categories can remain self-asserted since the risk is minimal.
    10. The specs need to be consistent as they talk about how the attributes like affiliation and entitlement should be used.
    11. The language around user identifiers for Pseudonymous and Personalized needs to be made consistent; those are the correct attributes, but the description needs to be made more clear.
  2. Next step
    1. Heather will draft changes to the personalized entity category, highlighting where we think that language should be used in the other entity categories

  3. Discussion of subject-id as source for origin organization (if not resolved on the list)

    1. postponing pending coverage of Personalized Authorization and the other entity categories

Definition Statement for R&S

Problem statement: the current definition of who can be tagged with R&S ("Candidates for the Research and Scholarship (R&S) Category are Service Providers that are operated for the purpose of supporting research and scholarship interaction, collaboration or management, at least in part.") is being interpreted differently by different groups.  Requirements that are not specifically in the specification are being applied by federations, creating an uneven use of the specification.

...