OTTO = Open Trust Taxonomy OAuthz / Session
OTTO = Open Trust Taxonomy for OAuth2
Wednesday 4I
Convener: Mike S.
Notes-taker(s): Mike S.
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Mike gave an overview of multi-party SAML federations, like InCommon http://www.incommon.org
These federations provide a central authority that vets participants (either IDPs or SPs), and publish metadata in XML to distribute key material and attributes of the entities. For example, see and look at some of the entries (like http://www.okstate.edu) http://md.incommon.org/InCommon/InCommon-metadata.xml
In addition to publishing metadata, federations standardize the legal and technical policies and procedures to drive down the cost of integration. For example, InCommon has standardized on the eduPerson schema for user attributes.
No such standard exists to centralize trust management for OAuth2 entities. And in addition there are more types of entities in OAuth2. Where SAML just had IDPs and SPs, OAuth2 has OpenID Connect OPs, OpenID Connect Clients, UMA Authorization Servers, UMA Resource Servers, and UMA Clients.
OAuth2 also has more schema: in addition to user claims, there are scopes (both OpenID Connect and UMA). And the opportunities exists to also standardize ACRs for authentication and perhaps other technical schema.
Gluu had published an early implementation of OAuth2 federation, which can be found at: http://ox.gluu.org/doku.php?id=oxauth:federation After discussing this with the higher education federation in Ireland, they expressed some interest to extend their Jagger federation tool to support OAuth2. See Jagger website at: http://www.gluu.co/jag
Mike had presented this idea previously at IIW in the fall 2014, and after talking about it for a few years, it seems like the time is right to start a working group at Kantara to start work.
The conversation then turned to the scope of the standard. What would be the metadata, endpoints, schema seemed clearly in scope. Perhaps also what mechanisms would be in place for distribution or replication of the metadata.
With regard to endpoints, Roland expressed some concern about the size of federation metadata in SAML, and suggested endpoints that enabled querying the federation metadata by providing the entityid. Perhaps an endpoint that allowed querying the metadata by type (for example, return a list of all the OPs)? An endpoint for "Join"? "discovery" (webfinger? .well-known/otto-configuration) and to get a list of federations hosted by the federation provider.
To form the Kantara Working Group, we need to submit the Charter, and get support from three or more Kantara members. Roland and Judy may be interested to get support from their organizations.
