3J/ OTTO Schema
OTTO Schema
Wednesday 3J
Convener: Michael Schwartz and Judith Bush
Notes-taker(s): Darin McAdams
Tags for the session - technology discussed/ideas considered: OTTO, FastFed
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Both the OTTO and FastFed working groups wish to enable groups of actors to agree on a shared schema and communicate that agreement as part of their federation metadata. This session reviewed the OTTO proposal for modeling these schemas. The vocabulary builds upon schema.org and is available at https://rawgit.com/KantaraInitiative/wg-otto/master/html/otto-vocab-1.0.html
In addition, there was general discussion about single-sign-on federation in the commercial sector and how that differs from other sectors, such as education/government. One difference is that in the educational/government sectors, there is often a need to know/trust the identity provider or service provider, know they comply with certain policies, and agree on attribute meaning. A single organization can provide many services. Certification can occur at the top-level organization and be reflected in each service they offer. The OTTO schema handles this case. The OIDC federation specification also addresses this circumstance: https://openid.net/specs/openid-connect-federation-1_0.html
The OTTO schema also enables users to describe the bindings into other protocols such as OIDC and SAML via a "sameAs" attribute. This describes the links between the different data representations.
Additional notes from Mike Schwatz
Federations like InCommon are a good place to publish schema, like what user claims (attribute) should be used to enhance interoperability.
One of the goals of the Kantara OTTO working group was to create a machine readible way to describe such supported schema.
To this end, it was decided to use JSON-LD to describe schema. Schema.org provides a useful baseline: see https://schema.org
OTTO has two current specs relevant to schema:
In the "vocab" spec, you should look at the schema object. Other objects, like a federation or entity, can use the "supports" property to reference schema that they support.
The base schema class can be subclassed to make it more specific. For example, in the "openid" spec, we define the Scope class, which adds a property called userClaim, which links to the associated userClaim for that scope.
Another interesting challenge solved was "catagory"--for example what if you only want to get back the OpenID scopes supported by a federation. Category is a subclass of Enumeration.
We patterned after https://schema.org/DayOfWeek.
Another interesting feature of OTTO schema is that we could use "sameAs" to link certain schema. For example, an OpenID Connect userclaim called "given_name" might be linked to an
LDAP attribute called "givenName".
One idea that was posited was to create a spec to define SCIM schema.
Also, there was some question as to whether OTTO could be used for 1:1 sso, to perhaps align with requirements for FastFed. Maybe... not sure.
