Attendees:

Agenda

  1. Administrivia
    1. SEB nominations
  2. Open PRs and Issues
    1. https://github.com/REFEDS/eduperson
    2. https://github.com/voperson/voperson
  3. Subcommittee status
    1. only "active" subcommittee is voPerson
  4. SCHAC
    1. Malaysia SCHAC assignments
    2. we also have a question from  Matthew Economou to answer, relating to his schacProjectMembership registration request (programme/org details given but no program name, etc)[and he also has a schema modification proposal in the form of usingOID/URI as well as names for the schacProjectMembership andschacProjectRole attributes....]
  5. Splitting out protocol profiles from schema - status?
  6. AOB

Notes

  1. Administrivia
    1. SEB nominations
  2. Open PRs and Issues
    1. https://github.com/REFEDS/eduperson
      1. https://github.com/REFEDS/eduperson/pull/17 - 389 is a directory run by RedHat; slightly different to LDAP. PR has been accepted and closed.
      2. https://github.com/REFEDS/eduperson/issues/5 - need to rename the current file, dropping the date, and then tag the current version (v4.4.0). Heather and Benn will meet to determine how much history we have to work with, then Heather will drop a note to the schema-discuss list advising of the change in filename and tagging releases; Heather and Benn will make the actual changes later.
      3. https://github.com/REFEDS/eduperson/issues/7 - closed with "The spec contains the following: "It consists of a set of data elements or attributes about individuals within higher education, along with recommendations on the syntax and semantics of the data that may be assigned to those attributes""
      4. https://github.com/REFEDS/eduperson/issues/8 - this may be a result of different LDAP services; Alan Buxey to do research for this
    2. https://github.com/voperson/voperson - these issues are really just documenting potential future items or other things that don't have much energy behind them. Progress will happen when people have a use case that needs to be solved.
      1. There may be interest from EOSC, but it hasn't been clear how to indicate that interest. PRs are a good start or, alternatively, updates to the issues indicating areas of interest.
  3. Subcommittee status
    1. only "active" subcommittee is voPerson - community hasn't put further time into this after the 2.0 release. This may change as EOSC offers input.
  4. SCHAC
    1. Malaysia SCHAC assignments
    2. we also have a question from  Matthew Economou to answer, relating to his schacProjectMembership registration request (programme/org details given but no program name, etc)[and he also has a schema modification proposal in the form of usingOID/URI as well as names for the schacProjectMembership andschacProjectRole attributes....]
      1. The request to add a note on how to register is purely an editorial change; the other part of his request is more a breaking change ("I don't understand why these attributes' values cannot be essentially free form. I recommend expanding the definitions of schacProjectMembership and schacProjectRole to include OID URNs and HTTP URLs as valid project and project role names (respectively), e.g., urn:oid:1.3.6.1.4.1.0.123 might represent a project and urn:oid:1.3.6.1.4.1.0.123.456 might represent a role within that project, as might https://example.com/project and https://example.com/project/role.").
        1. The spec says that values should be registered, but there is nothing on record in the registry. Why are these values registered at all? Can we assign a namespace? Unclear if that's what's being asked for.
        2. Does he have a working implementation using OIDs?
        3. Should we be assigning namespaces with OIDs? Need to also stop conflating URL with URN and URI. Need to ask the REFEDS list. It will be quite a bit of work to add this; need to know if it has value.
  5. Splitting out protocol profiles from schema - status?
    1. Any of the protocols that we would hope to pick this up have already created a reference to the eduPerson spec. Splitting that out to get rid of the LDAP-specific things, but that would create docs that wouldn't actually be useful for voPerson or OIDC info claims, JSON web tokens, etc. Given all that, is what we've done so far by creating the attribute dictionary sufficient? There isn't a driving need to do this; voPerson started with this as an assumption, but it's not actually critical for anything else.
    2. 2018 white paper from the OIDCre working group: https://docs.google.com/document/d/1b-Mlet3Lq7qKLEf1BnHJ4nL1fq-vMe7fzpXyrq2wp08/edit 
    3. One benefit of the LDAP schema is that it does offer very strict value formats. That said, there is divergence in how different protocols are implementing it. If LDAP is your integration protocol, this makes sense, but what's happening in practice is that integration protocols are now OIDC, SAML, etc, not directly through LDAP.
      1. Informal poll of SEB members says there is not enough energy to fully split the protocols from the schema, but we are uncertain about expanding the attribute dictionary
  6. AOB