Federations have a crucial role to play in our digital infrastructure.
In our non-cyber world (i.e. real life), we look to central authorities to help us know who we can trust, and who plays by our rules. For example, health insurance companies in the U.S. list which doctors are in the network. We know that these providers have signed certain agreements (i.e. that they will accept payment from our insurer). Like a federation, health insurers provide the tools (websites and technical
infrastructure) and rules (legal agreements) that enable us to efficiently receive care (sometimes!).
The Kantara OTTO working group was started about a year ago, to develop a standard to be used by federation operators to address new requirements arising from OAuth2 profiles for authentication and authorization. The group has developed a set of REST API’s and a JSON-LD data structure. The group found that JSON-LD combines the simplicity of JSON and the ability to reference data via the Web. Using links to express federation membership enables data about a service to be managed in one place. Links are also an interesting way to represent inter-federation agreements, while reducing data replication.
OTTO defines three key actors in the federation ecosystem:
- Registration Authority (RA)—the operator of a technical infrastructure that can host multiple federations.
- Federation Operator (FO)—the party responsible for making the policy and procedures for the ecosystem, approving participants, and filtering data.
- Participants—the organizations that want to join the federation.
The API’s are all published by the RA—one RA can host multiple federations. This multi-tenant approach was influenced by the work of the Jagger federation software, which already supports the management of multiple federations. Independently operated RA’s can also reduce the technical barriers needed to host a federation, freeing the people behind the federation to focus on the hard part—the legal agreements and community consensus building.
OTTO has defined a compact search query syntax to enable the identification of services offered by a federation. Previously, the Metadata Query Protocol offered a solution to search by primary key—in SAML the entityID XML attribute. OTTO goes further, enabling queries to be expressed based on the properties of the participants’ services. For example, find all the websites that are in the “research” category.
In the last year, OAuth2 and OpenID Connect have introduced solutions aimed at shoring up the ability of federation operators to add trust.
In the scenario defined in the OpenID Connect federation draft, the federation operator publishes only its public key, and validates and then signs requests from OpenID Providers and Relying Parties. In the process, this draft also defines several new features which will be useful to OTTO, including a way for an OpenID Provider to publish signing keys, and a Relying Party to register signing keys. A signing key is a rotated less frequently (or never). This is in contrast to OpenID Connect keys used for signing responses, which are rotated frequently (normally every two days).
Using the working draft specification, Gluu has implemented an open source OTTO server in Node. You can see the API documentation for this server at http://otto-test.gluu.org/swagger Gluu has also published a test OTTO data generator: http://otto-test.gluu.org:8080.
The current draft specification can be found as the README page of the OTTO Github home page: https://github.com/KantaraInitiative/wg-otto.
Although the project has been moving forward, more contributors are needed—especially people who might want to help draft the specification. If you’re interested, you can join at: