V/C info

Topic: REFEDS R&S 2.0 call
Time: May 11, 2021 08:00 AM Pacific Time (US and Canada), 15:00 UTC

Join Zoom Meeting
https://us02web.zoom.us/j/82438710780?pwd=MC93Slh3VlZ5eE1nZUlJbTVGcldpZz09

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

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

Google Calendar link

Working Draft

Draft spec for R&S 2.0

Agenda

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
Definition Statement for R&S.
Review of final changes to the draft spec

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.

Areas questioned	Potential issues
Is R&S focused on the requirements of the service or the organisational type	Issues with not having a definition of an R&S / R&E organisation and the fact that most organisations have business arms to R&E structure
Should "commercial" services be allowed	No way to distinguish the nuance in commercial vs paid for
Should services that are contracted be allowed	Contracts are paid for things like collaborative wikis, having a contract does nothing to help the
Should "management" be dropped from the definition statement
Is this about translation of real world trust (need to collaborate with other humans) into the spec
Should services that are "operated for" IdPs be allowed (e.g. cloud infrastructure - geant.altassian.com vs wiki.geant.org)	Who is registering the entity, which challenges are there with registering cloud entities, how do you determine the difference between a private / community based approach vs just having an account in a commercial environment
Problem of only calling out e-journals in the existing spec	Better phrased as something like "Service Provider MUST be able to prove that it has a legitimate need for the personal data in the attribute bundle." (positive rather than negative entry requirement).