Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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
    8. Information on OIDC requirements will be moved to R&S 2.1 (after the OIDF OIDCre working group has formal documentation in this space)
  2. eduPersonAssurance and RAF (Jule Ziegler)

    1. Relevant notes from 17 December call
      1. Should R&S encourage the release of eduPersonAssurance as a "SHOULD" value, in support of REFEDS Assurance Framework?
      2. Value of "no assurance" would have to be include
      3. 31% Yes; 6% No; 38% Optional is bogus; require it or leave it out; 25% Need more info
        1. Perhaps go back to this Assurance with how to indicate no value; it can't be required if it doesn't exist
        2. For the "No" vote, because it will massively reduce the number of IdPs that can/will release R&S as defined in 2.0
        3. General input is that this would be nice to have, but not MUST have to make decisions on their side; note that the NIH and other SPs are starting to require this information
        4. Assurance does imply liability, which may also complicate matters
    2. What would need to happen for institutions that do not (yet) support eduPersonAssurance or the RAF? There are values defined in the REFEDS doc that are appropriate for campuses not able to do assurance (e.g., reassignment policies, local-enterprise). Could say if you use one of these values, you must include it. If you don't, then that will be its own signal.
    3. Are we talking about eduPersonAssurance, or are we talking about supporting everything in RAF? R&S 2.0 can leave this open-ended and let the decision about what's required in it to be up to the SP. The RAF indicates there are values that can be used, but it doesn't require any particular practices.
    4. Is Assurance orthogonal to Research and Scholarship? If IdPs are free not to say anything, how does it actually support use cases in R&S? Are we using this attribute as a vehicle to solve a variety of problems because we have no better or more appropriate way to do it? Perhaps say that Assurance should be a required attribute in eduGAIN's baseline and not a requirement for R&S.
    5. We need more clarity on what the expected behavior is if this value is empty.
    6. Getting back to the entire purpose of an entity category - a good entity category should have one purpose, not several. R&S is about releasing attributes, not about improving security profiles. If we include assurance, it's introducing a second signal. We'd need to include more details that brings this all together.
    7. Should eduPersonAssurance be required by R&S 2.0?
      1. yes, required with no restrictions: 33% (4); yes, required with RAF value: 25% (3); not required by R&S: 25% (3); required by eduGAIN: 8% (1); need more info: 8% (1)
      2. if we exclude values outside of RAF, then that's it's own problem as well
    8. Is the right question to ask: is this valuable to research and scholarship? If we do add it, then we need to change the definition of R&S. R&S is defined as an attribute release profile; if we introduce security requirements, then the definition of R&S changes.
    9. Next steps
      •  Scott Cantorwill add suggested text to the draft spec so we can consider specific language around adding eduPersonAssurance
  3. Home Organization use case (Andrew Morgan and Christos Kanellopoulos )

    1. This item may be moved to the next call
  4. Proposal to require DisplayName (Petersen )
    1. This item may be moved to the next call