Attendees

Pre-reading


WG Consensus

  • The Anonymous Access, Pseudonymous Access, and Personalized Access Entity Categories shall be harmonized based on the decisions made around Personalized Access.
  • Authorization guidance shall be split out into a separate, descriptive paper and not be part of any of the entity categories.
  • The names should be "Access Entity Category" not "Authorization Entity Category" - 10 January 2022
  • We will not include assurance requirements to the Anonymous Access Entity Category - 10 January 2022
  • We will take out wording in Anonymous that Section 4 that requires proof while leaving in wording that requires documentation for Registration Requirements - 24 January 2022

Agenda

  • Verify WG Consensus items
  • Review proposed changes to Anonymous and Pseudonymous ECs 
    • Pål to match up Pseudonymous and Personalized EC's based on changes made to Anonymous
  • Review initial draft for authorization (Scott C's action item from last call) - Federated Authorization Best Practices
    • "I think it's important that a service that requires only the former but can do the latter be able to assert both. We should take care to author the changes to both of them to ensure that's sensible. It shouldn't worded so strictly that you have to pick only one."

Notes

  • Verify WG Consensus items
  • Review proposed changes to Anonymous and Pseudonymous ECs 
    • Pål to match up Pseudonymous and Personalized EC's based on changes made to Anonymous
    • Note that we need to make sure to add a section on authorization that will point to the Federated Authorization Best Practices; a to-do currently noted in Section 6 of AA
    • We do still have authorization in the ECs and attributes outside the scope of these specs. That needs to be addressed.
    • Significant discussion on whether Anonymous needs registration criteria at all. Is that valid for authentication only? As is, it implies processing personalized data where no personalized data exists.
    • "So we don’t want to keep the first 4.1 - the need for this information ?  use of this EC is to get org/affil value returned… why do they need those and not just a blank attribute bundle ?" that would be very hard to document and prove, and since it's not PII, is it even necessary to ask?
    • Since Anonymous was originally intended to help SPs avoid getting user data they did not want, let's explicitly state that that's what this EC is about.
  • Review initial draft for authorization (Scott C's action item from last call) - Federated Authorization Best Practices
    • "I think it's important that a service that requires only the former but can do the latter be able to assert both. We should take care to author the changes to both of them to ensure that's sensible. It shouldn't worded so strictly that you have to pick only one."
    • Ran out of time: Will come back to this on a future call