Keith Hazelton – UWisc
TIER work growing out of CIFER – Not just RESTful APIs. The goal is to make identity infrastructure developer and integrator friendly.
Considering use of RAML API designer and raml.org tools for API design and documentation.
Data structures – the win is to get a canonical representation that can be shared across vertical silos. Looking at messaging approaches. Want to make sure that messaging and API approaches are using the same representations. Looking at JSON space.
DSAWG – the TiER Data Structures and APIs Working Group – just forming, not yet officially launched. Will be openly announced.
Ben Oshrin, Spherical Cow
CIFER APIs – Quite a few proposed, some more mature than others.
More Mature: (Core schema – attributes that show up across multiple APIs); ID Match (creates a representation for asking “do I know this person already, and do I have an identifier?”); SOR to Registry (create a new role for a person); Authorization (standard ways of representing authorization queries).
Less mature: Registry extraction (way to pull or push data from registry – overlap with provisioning); Credential management (do we really need to have multiple password reset apps?)’
Not even itemized: Management APIs; Monitoring APIs. Have come up in TIER discussions.
Non CIFER APIs / Protocols of interest: CAS, LDAP, OAuth, OIDC, ORCID, SAML2, SCIM, VOOT2
- Intra-component: e.g. person registry queries group registry for authorization; group registry receives person subject records from person registry.
- Enterprise to component: System or Record provisions student or employee data in Person Registry
- Enterprise APIs: Homw grown person registry exposes person data to campus apps.
API Docs; Implementations