- Jiří Pavlík
- Alan Buxey
- Heather Flanagan
- Scott Cantor
- Miroslav Milinović
- Alex Stuart
- David St Pierre Bantz
- Jens Jensen
- Meshna Koren
- Anonymous Authorization
- Pseudonymous Authorization
- comparison of attribute release information between each entity category
- Recap of consensus so far - note that all changes will need to be validated via the consultation process
- 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)
- eduPersonScopedAffiliation will become a required value
- R&S will require privacy statements
- subject-id should be listed as the new identifier
- R&S 1.3 and R&S 2.0 can co-exist; no migration detail will be included in the spec itself.
- ePPN and targeted ID to both be removed from R&S 2.0
- Information on OIDC requirements will be moved to R&S 2.1 (after the OIDF OIDCre working group has formal documentation in this space)
- eduPersonAssurance will be required, RAF recommended
- We'll resolve the need for information on the origin organization by adding guidance for the use for eduPersonScopedAffiliation
- DisplayName and Given/SN are required
- Recap of consensus specific to the Personalized Authorization spec
- if schacHomeOrg is present, then it's the value to be used; if not present, eduPersonScopedAffiliation should be used.
- We will adopt the following 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."
- The entity categories (Anonymous Authorization, Pseudonymous, and Personalized) are mutually exclusive
- Reviewing the draft spec
- Next call to pick up on the question of subject-ID vs pairwiseID
Discussion of subject-id as source for origin organization (if not resolved on the list)
- postponing pending coverage of Personalized Authorization and the other entity categories
Reviewing the draft spec
- subject-id vs pairwise-id
Reasons for subject-id:
some use-cases need a non-targeted identifier, and this category is one way they can get it.
'optional personalization' refers to the user, not to the IdP. If the IdP doesn't release the attributes then a user doesn't have the options.
the added protection by /not/ sending an opaque identifier may not actually achieve all that much even assuming bad intentions/actions at the SP. [if the concern is tracking users]
There are also many laws and regulations in most regions too (e.g. GDPR immediately comes to mind!). The data cant be used for anything other than the service access (authn/authz decision).
the original R&S spec did not use ePTID. That was never true. It used EPPN. ePTID was there to address EPPN changes/reassignment, not to be the actual identifier used in practice. [if subject-id is not ever reassigned, then it is an improvement over ePPN and we don't need a fall back]
Reasons for pairwise-id
make tracking of individual users more difficult
People take issue that people can learn other's subject-id; pairwise-id can be generated randomly.
- Poll: Should Personalised Authorization use subject-id or pairwise-id? subject-id = 78% (7); need more information = 22% (2)
- After discussion, both "need more information" have switched to "subject-id"; add this to the consensus list.
- Should we add Nickname? Poll: yes (1), no (7), I don't care (1). Will leave out and revisit if it comes up during consultation
- Next call
- come back to whether the title of the category should use "Authorization"; maybe "Personalized Access" or "Personalized Entity Category"?
- Start with section 6 of the draft; note this touches on the consensus we reached on an earlier call "We will adopt the following 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."
Updated consensus specific to the Personalized Authorization spec
- if schacHomeOrg is present, then it's the value to be used; if not present, eduPersonScopedAffiliation should be used. (See 2021-07-01 R&S 2.0 Notes)
- We will adopt the following 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." (See 2021-07-01 R&S 2.0 Notes)
- The entity categories (Anonymous Authorization, Pseudonymous, and Personalized) are mutually exclusive (See 2021-07-01 R&S 2.0 Notes)
- We will use subject-id for this specification. (See 2021-08-10 R&S 2.0 Notes)
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 IdP administrator formulate an attribute release policy|
|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).|