Attendees

Pre-reading

Specifies a person ́s home organization using the domain name of the organization.Issuers of schacHomeOrganization attribute values via SAML are strongly encouraged to publish matching shibmd:Scope elements as part of their IDP's SAML metadata.Relaying Parties recieving schacHomeOrganization values via SAML are stronglyencouraged to check attribute values against the Issuer's published shibmd:Scope elements in SAML metadata, and may discard any non-matching values.

Agenda

  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, but the spec would include migration requirement where ePPN would be passed, regardless of reassignment status

    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

  2. Focus on the OIDC section

  3. Come back to the need for organization info (scope? schacHomeOrganization?) if not resolve on the list

  4. Proposal to require DisplayName


Notes

  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

  2. Focus on the OIDC section

    1. Heather suggested on list that we remove this section until there is a standard to point to; standardizing that information should not happen in this working group
    2. Marcus (from OIDF OIDCre) sees not having the OIDC mapping in this spec as a missed opportunity. Can we express similar things in the protocols, rather than have a full mapping? There would be some issue about what to name these things; Shibboleth will be doing one thing, but that might not match what other efforts.
    3. The discussion we're having here has revived the OIDF OIDCre working group. It would make sense in R&S2.0 to make it clear what the expectations are from the RPs and IdPs, and set a goal for a 2.1 that will can follow up with information on OIDC
    4. Poll: Should we add a section on OIDC in the R&S spec? Yes, in 2.0 = 13%; Yes, in 2.1 = 75%, No = 6%, Need more info = 6% (question re: timing of the expected outputs of the OIDF OIDCre working group)
    5. Proposal: move all protocol-specific information into an Appendix? One consideration is that this is too important to the overall spec; moving it into an Appendix doesn't offer anything, unless we're saying the information is not normative (which would be a bad thing)
      • Heather Flanagan will spin REFEDS OIDCre working group for those people that cannot participate in the OIDF group due to IPR constraints
    6. Suggest that R&S2.1 may not change the SAML section; the changes would only be for OIDC information; question about what this means if we want to add eduPersonAssurance? this could help us resolve some concerns around verified email and be responsive to more apps that are starting to require Assurance

  3. Come back to the need for organization info (scope? schacHomeOrganization?) if not resolve on the list

    1. Is there anything that exists that includes organization information to the granularity we need? Not globally; limited regionally.
    2. this is driven by the requirements for student mobility; in Europe, it's common for students to transfer for one semester to another university. It becomes critical to know which university the student is originating from. ScopedAffiliation was investigated, but thinking it always denotes the student's organization is not correct. schacHomeOrganization has been used in Europe to capture this; that makes sHO a required attribute for the student mobility program, which primarily impacts Europe but also involves students around the world. All this becomes even more complicated with virtual student mobility.
    3. Limiting/defining scopes is entirely a policy issue. That implies flexibility but also increases complexity.
    4. At this point, we either have to re-define an existing attribute and what's required in it (which may invalidate other, existing uses of that attribute) or we have to define an entirely new attribute that clearly states what is needed and what use case its solving.
      • Andrew Morgan and Christos Kanellopoulos will work together to document the requirement so we can determine if an existing attribute can meet the need, or if we should consider generating a proposal for an entirely new attribute
  4. Proposal to require DisplayName
    1. Moved to a future call