New OAuth 2-wg – Multi-Party Federation
Session Topic: New OAuth2-WG: Multi-Party Federation!
Tuesday 2J
Convener: Mike Schwartz
Notes-taker: Mike Schwartz
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Topic: OAuth2 Working Group? Multi-Party Federations
Moderator: Michael Schwartz
A multi-party federation enables a group of autonomous entities to drive down the cost of security by agreeing to a common set of business policies, technical schema and protocols. An example of a federation is InCommon, which has over 400 university participants, and over 150 websites. The list of InCommon participants can be found at http://www.incommon.org/participants, the Agreements for a participant to join can be found onhttp://www.incommon.org/join.html , and an example of mulit-party federation metatdata in SAML can be found at :https://spaces.internet2.edu/display/InCFederation/Metadata+Aggregates
Given the success of federations using SAML, it seems only natural that existing and new federations could benefit from using the same strategy to drive down the cost of OAuth2 based applications. Originally, Gluu had proposed such an approach for OpenID Connect: http://ox.gluu.org/doku.php?id=oxauth:federation&s[]=federations
However, on further consideration, it became apparent that other profiles of OAuth2, especially UMA, could be incorporated. At the InCommon Advanced Camp held last year, it was suggested that instead of the OpenID Foundation, that perhaps such an effort would be better suited as a working group of OAuth2.
OAuth2 brings new schema that needs to defined, including OpenID Connect scopes and UMA scopes. Some of the requirements are being uncovered by Gluu as a result of one of its involvement in the formation of the first OAuth2 based federation for a K12 project in Texas. The schema for that federation has already been published at :https://idp.texaspass.org/tech-info
In addition to schema and metadata, endpoints would need to be defined to publish federation metadata and to enable entities to join federations. An idea of these are alos proposed on the above mentioned OX Wiki page on the "Design for OpenID Connect Multi-Party Federations" mentioned above.
While much work on this topic is being done by Gluu, Mike pointed out that he really needs help to move this forward. It would be a great chance for someone who wants to get involved in standards development to get involved (hint - hint).
This work is critically needed by many ecosystems. If OpenID Connect becomes a ubiquitous federation protocol, better trust models will be needed. The federation provides an efficient way to distribute public certificates. If a Heartbleed-like vulnerability were to afflict OpenID Connect or UMA AS's, re-keying would be a nightmare. In addition to the cost savings associated with federations, they would reduce the impact of such a nightmare.
