Versions Compared

Key

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

Attendees

  • David St Pierre Bantz
  • Björn Mattsson
  • Alan Buxey
  • Andrew Jason Morgan
  • Uros Stevanovic
  • Pål Axelsson
  • Maarten Kremers
  • Jiri Pavlik
  • Bas Zoetekouw
  • Mischa Salle
  • Marcus Hardt
  • Scott Cantor
  • Nicolas Liampotis
  • Alex Stuart
  • Hannah Short
  • Licia Florio
  • Heather Flanagan

V/C info

Topic: REFEDS R&S 2.0
Time: Mar 2, 2021 08:00 AM Pacific Time (US and Canada) / 16.00 UTC / 17.00 CET

Join Zoom Meeting
https://us02web.zoom.us/j/83742805453?pwd=NUZ2SkNzS3V1RG9kbHlMMTJJZUxUdz09

Meeting ID: 837 4280 5453
Passcode: 256764
One tap mobile
+12532158782,,83742805453#,,,,*256764# US (Tacoma)
+16699006833,,83742805453#,,,,*256764# 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 929 205 6099 US (New York)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
Meeting ID: 837 4280 5453
Passcode: 256764
Find your local number: https://us02web.zoom.us/u/kxuVBq6G4

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

Calendar link HERE

Pre-reading

...

...

Agenda

  1. Recap of consensus so far
    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 https://docs.google.com/document/d/1xXMvMV2_tYZBcejfVrItLlABprC7TkkTu9sRcpY22jg/editnew draft spec for updated structure)

    2. eduPersonScopedAffiliation will become a required value

    3. R&S will require privacy statements

    4. Encouraging the use of eduPersonAssurance requires further discussion with the Assurance Working group

    5. 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

    6. R&S 1.3 and R&S 2.0 can co-exist; no migration detail will be included in the spec itself.
    7. ePPN and targeted ID to both be removed from R&S 2.0
  2. Focus on the OIDC section

  3. Come back to the need for organization info (scope? schacHomeOrganization?) if not resolve on the list

  4. Proposal to require DisplayName


Notes

  1. Recap of consensus so far
    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. Encouraging the use of eduPersonAssurance requires further discussion with the Assurance Working group

    5. subject-id should be listed as the new identifier

    6. R&S 1.3 and R&S 2.0 can co-exist; no migration detail will be included in the spec itself.
    7. ePPN and targeted ID to both be removed from R&S 2.0
  2. Focus on the OIDC section

    1. Heather suggested on list that we remove this section until there is a standard to point to; standardizing that information should not happen in this working group
    2. Marcus (from OIDF OIDCre) sees not having the OIDC mapping in this spec as a missed opportunity. Can we express similar things in the protocols, rather than have a full mapping? There would be some issue about what to name these things; Shibboleth will be doing one thing, but that might not match what other efforts.
    3. The discussion we're having here has revived the OIDF OIDCre working group. It would make sense in R&S2.0 to make it clear what the expectations are from the RPs and IdPs, and set a goal for a 2.1 that will can follow up with information on OIDC
    4. Poll: Should we add a section on OIDC in the R&S spec? Yes, in 2.0 = 13%; Yes, in 2.1 = 75%, No = 6%, Need more info = 6% (question re: timing of the expected outputs of the OIDF OIDCre working group)
    5. Proposal: move all protocol-specific information into an Appendix? One consideration is that this is too important to the overall spec; moving it into an Appendix doesn't offer anything, unless we're saying the information is not normative (which would be a bad thing)
      •  Heather Flanagan will spin REFEDS OIDCre working group for those people that cannot participate in the OIDF group due to IPR constraints
    6. Suggest that R&S2.1 may not change the SAML section; the changes would only be for OIDC information; question about what this means if we want to add eduPersonAssurance? this could help us resolve some concerns around verified email and be responsive to more apps that are starting to require Assurance
  3. Come back to the need for organization info (scope? schacHomeOrganization?) if not resolve on the list

    1. Is there anything that exists that includes organization information to the granularity we need? Not globally; limited regionally.
    2. this is driven by the requirements for student mobility; in Europe, it's common for students to transfer for one semester to another university. It becomes critical to know which university the student is originating from. ScopedAffiliation was investigated, but thinking it always denotes the student's organization is not correct. schacHomeOrganization has been used in Europe to capture this; that makes sHO a required attribute for the student mobility program, which primarily impacts Europe but also involves students around the world. All this becomes even more complicated with virtual student mobility.
    3. Limiting/defining scopes is entirely a policy issue. That implies flexibility but also increases complexity.
    4. At this point, we either have to re-define an existing attribute and what's required in it (which may invalidate other, existing uses of that attribute) or we have to define an entirely new attribute that clearly states what is needed and what use case its solving.
      •  Andrew Morgan and Christos Kanellopoulos will work together to document the requirement so we can determine if an existing attribute can meet the need, or if we should consider generating a proposal for an entirely new attribute
  4. Proposal to require DisplayName
    1. Moved to a future call