Page History

...

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.
1. There is disagreement about the definition of R&S; the table captures some of the questions that have been posted about questions re: "Commercial", "Management, etc. We should be making positive statements about what should be included, not focus on what should be excluded.
2. One comment - do not want to have normative text in examples (which is something done in the second paragraph of the definition)
3. Focusing on the word "Commercial" - does this need to be relevant to the spec? We don't have a clear way to distinguish "commercial" from "academic". If GEANT buys a service from someone else for use by the GEANT community, is that a commercial service? What if the platform is used both by obvious 'commercial' entities (e.g., Oracle) and non-commercial entities (e.g., GEANT).
  1. What are we trying to preserve by restricting who gets into R&S? attribute release of name, email, affiliation, non-targetedID. InCommon is considering requiring this for all participants. That may not meet the EU use cases.
  2. Coming back to why 'commercial' is a problem - is it because they make money off of secondary use of identities? Nominally, they shouldn't be doing that anyway, but we are assuming there are greater protections or something in place with R&S-qualifying entities. Could we include a statement just to that effect, that this data won't be used for any other purposes. "These won't be used outside of R&S space". But we shouldn't write what should be legally binding anyway.
  3. We're making R&S not about the service but about the organization. We're saying the organization must have some R&S-type characteristics, but we have no definition for that. Attempts to define "academia" have already failed a few times.
  4. Commercial was viewed as a problem because we were trying to soothe people's concerns that information would be released to bad actors, and by restricting it to our community would lessen the risk of bad actors. Also, the centrality of contracts - R&S was for those entities that did NOT require a contract. If there is a contract in place for the party releasing attributes, then any question of attribute release should be dealt with that way. R&S is about ad hoc federation.
  5. There is a growing trend of getting services under contract that are not necessarily for just the campus users, but also apply to individuals outside the specific organization.
  6. What we want to do is release basic profile information - historically, we are comfortable doing that within the R&S community. After so much time, maybe the level of comfort has changed and expanded. Maybe we don't need to limit this to just the one community of interest. Let the fed op make the determination re: what their local community is comfortable with.
  7. Given the original definition, we were explicit about e-journals. What was the basic reasoning? You shouldn't need PII to authenticate to a publisher; they shouldn't need to know who the user is.
  8. This is about establishing a trust relationship with entities that legitimately need this bundle.
  9. Could this be alleviated by definition about what the SP is allowed to do with the data? e.g., "Only for the purposes for the R&S service involved". There will always be some subjective consideration for trust.
  10. Hearing two things 1) strengthen saying how you can use the data and 2) strengthen the language around the federation must prove that the SP needs the data.
  11. Is R&S still necessary? It may be time to retire it entirely and just say this is the standard bundle to release. It could be a collaboration bundle and not targeted to R&S.
  12. Poll: Should we retire the term R&S in favor of a collaboration bundle? (Thus retiring the issue of defining what is research and scholarship) - Yes, 29%; No, 21%, Need more info, 50%
    1. This introduces a marketing problem; people are familiar with the term R&S
    2. Note that R&S 1.3 will stay, so we're introducing something of a new name regardless
  13. Where is the implied trust here? on the IdP side, or on the SP side
  14. Looking at the list of SPs currently tagged with R&S, it seems half 10% are test entities.
  15. We need to work on this more, and make the trust model explicit. Is this basically bringing in aspects of CoCo?
  16. R&S has always been different because it requires the fed ops to do something. Is that where we need to do more work, not in the spec itself?
  17. Next steps: Heather and Nicole will work on some proposals, noting that there is work needed both on guidance for fed ops, and there is work to consider a radical rewrite.
4. Note: the definition of "organizational attributes" differs between the Pseudonymous Entity Category and the R&S Entity Category. This will need to be addressed.
Discussion of subject-id as source for origin organization (if not resolved on the list)
Solicitation of volunteers to focus on supporting documentation

Child pages

Versions Compared

Old Version 4

New Version Current

Key