Pre-reading

Attendees



Agenda

Proposed work structure - Focus on the issues of R&S 1.3 in the following order, with each agenda coming to the next on the list

  1. eduPersonAffiliation vs eduPersonScopedAffiliation
    1. "and where affiliation is defined to be the eduPersonScopedAffiliation attribute." (see section 5 of the R&S spec)- How can we make the spec clearer? Is the release of scoped affiliation mandatory or not? What if the IdP doesn’t actually have that value recorded?
  2. Identifier issue
    1. One of the reasons R&S supports ePPN and ePTID is that it was targeting applications that were broken because they only allow for a single identifier to identify an individual (the “one field for everything” approach). That’s why ePPN was the chosen identifier, because it was traditionally a user-friendly identifier and so suitable for the one-size-fits-all use case, as long as you ignore reassignment. ePTID was added to address reassignment. Those applications failed miserably if they only had ePTID.

      Is this still an issue? Do we still need to support the one-size-fits-all approach? If we can chose a common, opaque identifier, with an understanding that you want the additional personalization, we can do that.

      • One opinion: time is right to do this, and R&S is the right place to do this first.
      • Second opinion: this is a question for the SP. Are they ready for R&S to move to a more opaque identifier? There’s no incentive for an IdP to make their identifier better unless there’s a demand by the SPs.
        • Based on the responses from the SPOG list, SPs do not handle identifier reassignment in any standardized manner. The level of automation in responding to this seems to depend entirely on the size of the SP and how big their IT budget is.
  3. Privacy Statements
    1. Should R&S require privacy statements?
  4. eduPersonASsurance
    1. Should R&S encourage the release of eduPersonAssurance as a "SHOULD" value, in support of REFEDS Assurance Framework
  5. Administrative involvement
    1. How to be clearer about “Without administrative involvement"

    2. How to be clearer that the campus does have control regarding what population they should release information about (e.g., whole campus? other?)

  6. R&S as it relates to CoCo


Notes

  1. eduPersonAffiliation vs eduPersonScopedAffiliation
    1. "and where affiliation is defined to be the eduPersonScopedAffiliation attribute." (see section 5 of the R&S spec)- How can we make the spec clearer? Is the release of scoped affiliation mandatory or not? What if the IdP doesn’t actually have that value recorded?
      1. Because the attribute is optional, it's not always released. But because, again, it's optional so not adding it is still in compliance with the spec.
      2. Suggest that it should remain optional (and not SHOULD, as SHOULD implies the attribute is recommended)
      3. Perhaps we need to change the language of "where affiliation" since 'affiliation' may be confused with eduPersonAffiliation.
      4. Across eduGAIN, the number of R&S SPs asking for eduPersonScopedAffiliation in RequestedAttribute elements in their metadata is fewer than the ones requesting DisplayName, etc.
      5. Suggest we leave the specification as is, but add something to the supporting documentation (e.g., Research and Scholarship FAQ) if it doesn't have something already
        1. Another suggestion: If you need it, use it via the Requested Attribute mechanism - though that may weaken the message that R&S signals attribute requirements solely via the entity category, not RequestedAttribute elements.
          Also as long as the attribute remains optional even requesting it specifically via RequestedAttribute elements may not get IDPs to release it, so probably not worth the effort.
      6. One group of services that may offer a good argument for requiring eduPersonScopedAffiliation (that would still qualify for R&S) are those as part of Erasmus+ and/or the European Student Card Initiative (cf. MyAcademicID)
      7. Given that affiliation is not at all PII, would it hurt to just go ahead and require it? There are mismatches in understanding of the definitions, and this is unlikely to solve any problems and may in fact increase confusion.
      8. What about creating an entire second category for R&S use cases that would require affiliation? There is difficulty in adoption of entity categories, would another (for the sole purpose of "R&S plus ePSA-required") actually help?
      9. Consider subsections to help clarify intent (if we decide we need to go that route).
      10. Action items: (tick) Peter to offer revised draft text for the FAQ, Heather and Andrew/Alan to work on editorial changes to the spec.
  2. Identifier issue
    1. One of the reasons R&S supports ePPN and ePTID is that it was targeting applications that were broken because they only allow for a single identifier to identify an individual (the “one field for everything” approach). That’s why ePPN was the chosen identifier, because it was traditionally a user-friendly identifier and so suitable for the one-size-fits-all use case, as long as you ignore reassignment. ePTID was added to address reassignment. Those applications failed miserably if they only had ePTID.

      Is this still an issue? Do we still need to support the one-size-fits-all approach? If we can chose a common, opaque identifier, with an understanding that you want the additional personalization, we can do that.

      • One opinion: time is right to do this, and R&S is the right place to do this first.
      • Second opinion: this is a question for the SP. Are they ready for R&S to move to a more opaque identifier? There’s no incentive for an IdP to make their identifier better unless there’s a demand by the SPs.
        • Based on the responses from the SPOG list, SPs do not handle identifier reassignment in any standardized manner. The level of automation in responding to this seems to depend entirely on the size of the SP and how big their IT budget is.
  3. Privacy Statements
    1. Should R&S require privacy statements?
  4. eduPersonASsurance
    1. Should R&S encourage the release of eduPersonAssurance as a "SHOULD" value, in support of REFEDS Assurance Framework
  5. Administrative involvement
    1. How to be clearer about “Without administrative involvement"

    2. How to be clearer that the campus does have control regarding what population they should release information about (e.g., whole campus? other?)

  6. R&S as it relates to CoCo