Attendees:

Agenda

  1. Because this was an unconference session, there was no formal agenda. An ad hoc discussion suggested the following topics:
    1. Direction
    2. Status of Schema & Attribtues
    3. Work plan?

Notes

The notes from the ACAMP session are available here. Because a quorum was reached (5/7 current Schema Board Members attended) this session was declared an official Schema Board meeting, and the notes from the session are copied herein.

Topic 1: Direction → Not many requests.

  • There’s a lack of organizational regularity to the schema board right now.
  • Albert is willing to step up and help; considers what this group does as core / important; 
  • Get board back into a monthly / bi-monthly cadence (after holidays)
    • Do this before TIIME (i.e. in January)
  • Some logistics to do on getting Albert involved (wiki access, etc).

Topic 2: Status

  • The schema board looks after several schemas - eduPerson, SHAC, VoPerson - there’s a bunch, some not even used anymore but still referenced
  • e.g. no demand for new version of eduPerson; 
    • Big directory of values in eduPerson that aren’t used any more; can we clean some of this up? 
    • Is it time for eppn
  • Albert: as we begin the journey of requiring standard attributes, “how to use”, “here they are” - some confusing things: 
    • multiple schemas; 
    • some attributes not yet included
    • binding various protocols - some agnostic, and then specific protocol delivery
  • Would be great if schema board took these problems on
  • Schema board doesn’t need to set the MUST and MUST NOT, but can be enforced by implementer (I2) 
  • Would like to document from a protocol-specific lens; no ambiguity; 
  • Probably need a pure semantic description of elements, e.g. schema.org-like description of the elements
  • Separating attribute definitions from schema definitions: there is a start on this already
  • Deployers may not deal with abstraction very well. 
  • Behind the scenes, an abstraction may be helpful;
    • Some disagreement here - esoteric concept may not be helpful; others believe the underpinnings need this. 
    • eduPerson as an example of the problem space
    • Some agreement on identifiers, but that is thin; names? These are semantic: preferred name, legal name, etc - these are not protocol specific; they are a construct.
    • Agreement met on what this means when understood that concepts need to be represented in data. e.g. defining what “Legal Name” means. → have come to “violent agreement” then.
    • Note - this is required for automatic protocol translations.
    • Example of problem space: OIDC claim email
    • include in the schema how claims are intended to be used

  • We don’t want these schemas to organically evolve - we want to guide this.
  • Mapping exercise important / helpful, and where things pre-exist, don’t re-invent the wheel.
  • OpenID space: we want to include mappings already in use to encourage adoption
  • eduPerson essentially becomes the ldap-specific implementation
  • What’s the prospect of merging the three specs?
    • Usually these conversations result in “the less we touch them the better”
    • Socially there are different communities - this is someone independent of different protocols, but you tend to get a different protocol in a different community
    • There’s still some notion that eduPerson is US thing, SHAC is European thing
    • Branding is important (i.e. communicating what’s happening, what these are)
    • REFEDS data schema, REFEDS attribute registry (protocol specific)
    • The public facing things are all protocol specific
    • Is “name” an insoluble problem? 
      • Perhaps only “name” is the most difficult
      • Many others seem reasonable to accept what exists?
    • Some requests for new “name” values, but then when asked back what those were, no one responded for clarification …
    • Values registry: there will be a need, but perhaps next gen
    • Help guiding important e.g. from affiliation -> entitlement 
      • Discussion of library space
  • Multi-protocol → moving from SHAC to OpenID, need strong definitions; 
    • Allow for transforms
    • Applications should handle localization
  • Note: if we deprecate eppn, we deprecate R&S
  • Interrelationships between specs and profiles: they depend on each other
  • Much of this is about perception and organized change.
  • So who is stewarding the migration - on a global level.
  • REFEDS, eduGain …

Topic 3: next steps

  • Albert / Ben → Flywheel; structural work
  • Meeting in January
  • TIIME, meetings
  • Resources
    • mailing list
    • EduGain Slack
    • REFEDS wiki
  • (Slack? but not accessible)
  • No labels