Attendees:

Agenda

  1. Administrivia
    1. SEB nominations
  2. Subcommittee status
    1. voPerson
    2. VC
  3. MFA status indicator 
  4. REFEDS Work Plan item overlap
  5. SAML Subject Identifiers
    1. SAML V2.0 Subject Identifier Attributes Profile Version 1.0
  6. Open PRs and Issues
    1. eduPerson
    2. SAML-profile
  7. AOB
    1. eduMember definition doc and proposed eduPerson page updates

Notes

  1. Administrivia
    1. SEB nominations - note that several members have had their terms expires. We need to refresh the 2024 membership. Note that Mark and David are willing to extend their terms. 
      • Heather Flanagan  to send out a call for nominations for the next term for three positions
  2. Subcommittee status
    1. voPerson - there may be an errata release, but the subcommittee is otherwise not working on anything.
      1. Note there are open issues and PRs for the group to consider
      2. There is a group in InCommon TAC to promote the new entity categories and the persistant/pair-wise SAML attributes. They are also working on clarifying language for eduPersonUniqueID.
    2. VC - group is very active; group may meet at TIIME. Does not expect to have anything ready for consultation until maybe TNC25.
  3. SAML Subject Identifiers

    1. SAML V2.0 Subject Identifier Attributes Profile Version 1.0 - On behalf of the Chairs of the InCommon Community Trust and Assurance Board (CTAB) and Technical Advisory Committee (TAC), please consider these informal requests arising from work of the SAML Subject Identifiers Deployment Guidance Working Group:
      Add formal schema definitions of the SAML Subject Identifiers to the eduPerson schema.
      Consider how the definitions of the Subject Identifiers and eduPerson attributes may be abstracted or generalized from dependence on SAML and LDAP - for example, for uses in federations relying on OIDC.

    2. Why bring this into the eduPerson schema, rather than leave it stand-alone? There is a lot of comparison with the new identifiers (e.g., eduPersonTargetedID) so it would be convenient to have them all in one place. Also, we might be advocating for best practice guidelines to use eduPerson schema as a whole, rather than to focus on one attribute or another. Having subject identifiers in SAML rather than eduPerson is that it doesn't carry the 'baggage' of an education-based specification. From a vendor perspective, there was a hope that it would be treated more sector-agnostically. Alternatively, we could refer to it in the eduPerson schema. There was a lot of work that went into UniqueID semantically and syntactically 'pure'. How much of that is in the SubjectID document? Were the constraints put on UniqueID also put on SubjectID? Consider not adopting this at the meeting but letting this group to review the text. Another concern re: moving it is the existing URN is well established in urn:oasis. Reminder that this is tied to the entity categories. 
      • Keith Hazelton will review the document and offer feedback re: the Subject Identifiers document then either offer feedback to the working group or come back.  to the SEB with a recommendation
  4. MFA status indicator - Benn sent this to the list a month ago. It would have been helpful for their to be a standard attribute early on, but it seems like people have done it every possible way (e.g., local attribute, group membership, entitlements). Do we want to dive in and add another way (or recommend an existing approach)? The idea is to add MFA status to a person. 
    1. Have there been other endpoint security policy requirements handled in a like way (e.g., attestation that a workstation someone is logging in from meets minimal security requirements)? Something we could build on? Not aware of anything at the schema level. 
    2. If someone is authenticating and during that process, the response is "this person can/must do MFA", can SAML deal with that after the authentication bit? Normally the request for MFA happens in the initial set up. This is an IdP-centric attribute. There is potential work at the SP/Federation level re: better functionality, but for now, this is specifically about internal-to-IdP work. Might be worse having a work item to discuss further, though no guarantee for a new attribute. Suggest meeting at TIIME to discuss what the charter would look like. 
  5. REFEDS Work Plan item overlap
    1. For the name pronunciation proposal, unclear what the definition would look like. If they really want audio, then we need a whole new spec because #audio doesn't support enough files. OK to charter a subcommittee
    2. For the ROR, interesting proposal.
    3. For the SeamlessAccess one, that one may be difficult. 
  6. Open PRs and Issues
    1. eduPerson
    2. SAML-profile
  7. AOB
    1. eduMember definition doc and proposed eduPerson page updates
    2. review a proposed operational practice doc re: eduPersonUniqueID - Keith will send to the list for discussion