You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Pre-reading

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. In the UKAF, the number of SPs asking for eduPersonScopedAffiliation 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 - but that might not work because of CoCo.
      6. One service that may offer a good argument for requiring eduPersonScopedAffiliation (that would still qualify for R&S) is ERASMUS.
      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 actually help?
      9. Consider subsections to help clarify intent (if we decide we need to go that route).
      10. Action items: Peter Schober to offer revised draft text for the FAQ, Heather and 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
  • No labels