Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Open Actions
    1. For the LDIF files, see eduPerson LDIF Files - still need additional pointers to other LDIF files as appropriate. Board should send those to Keith or update that page.
    2. For 6338bis, see AOB
    3. SimpleSAMLphp - are all the tools ready to deal with the SAML identifiers (Subject-ID and Pairwise-ID)? yes, this is fine, no issue
  2. Administrivia
    1. Board nominations - nominations will open in March; the seats below will move to 2-year terms. We need at least two nominations, no more than four.
      1. David Banz (U. Alaska) (2019-2020)
      2. Scott Koranda (LIGO/SCG) (2019-2020)
      3. Miro Milinovic (SRCE) (2019-2020)
      4. Catarina Ribeiro (University of Porto) (2019-2020)
        •  Benjamin Oshrinwill post a suggestion to the board list on how to handle the situation of receiving more nominations than seats open for the board
  3. Status of schema
    1. eduCourse
      1. eduCourse was designed with an eye towards what IMS Global was specifying for course rosters. The current new standard is OneRoster 1.1 (see Keith's comment). Someone needs to review that document to see if the information it contains what is needed. We may need to profile what's in there. 
    2. voPerson
      1. The subcommittee is trying to work out the SAML representation of the voPerson attributes.
      2. v2 of the schema is having some challenges - some new information will be added (see Blocked on getting OIDs assigned. (Does this need a registry update as well?) Explore the idea of having a Schema Board branch so we can add more schema as needed; leave SCHAC as grandfathered in with its own top-level domain
  4. Next steps for eduPerson
    1. decoupling the protocols are a likely place to start, and may end up suggesting other changes to the spec.
    2. Are we talking about stripping out the LDIF examples? Having the expected value styles is helpful, but it does influence specific protocols (e.g., LDAP). Alternatively, we could dilute the protocol specificity by adding more protocol examples. What would be most useful to the community? Given we're still waiting for the OIDC Federation, we're not sure exactly what will be most useful. Consensus is leaning towards having eduPerson as a complete with multiple examples and changing the markup to make it easier to extract the examples into a protocol appropriate set. Discuss on the next call; start going through the spec to determine where we could make changes to be more clear re: the protocols.
    3. What about focusing on expanding attribute values? Check for some possible notes from Internet2's Tech Ex 2019. Affiliations, in particular, could use potential expansion (though maybe groups are a better way to handle the many variances of affiliation possibilities). This is something we should explore with the community to figure out what they need us to do. Some federations have done this on a federation-specific level. Let's reach out and figure out what they are doing and why. Discuss on the next call how to phrase the questions and how to reach out.
    4. Let's also discuss adding AcademicID to a schema (the way we have ORCID). Maybe this belongs in SCHAC?
  5. AOB
    1. Updating RFC 6338 - should we broadly replace "TERENA" with "GEANT"? Perhaps change the intro to include "Management of the schema has been transitioned to REFEDS, an entity supported via secretarial services by GEANT."