OpenID logoThe OpenID Connect working group recently adopted three new specifications that build upon and provide new capabilities to OpenID Federation. But I’m not only happy about these because of the engineering benefits they bring.

I’m particularly happy because they bring new active contributors to the work, specifically Michael Fraser and Łukasz Jaromin, as well as continuing the strong work by Giuseppe De Marco, who’s become a leader in the space. They’re also supported by a few veterans: Roland Hedberg, John Bradley, and yours truly, plus now the full OpenID Connect working group.

Here’s the three new specifications, along with an abstract for each of them:

1. OpenID Federation Extended Subordinate Listing

This specification acts as an extension to OpenID Federation 1.0. It outlines methods to interact with a given Federation with a potentially large number of registered Entities, as well as mechanisms to retrieve multiple entity statements along with associated details in a single request.

2. OpenID Federation Wallet Architectures

As digital wallets become increasingly deployed for managing identity credentials, establishing an architecture for trusted communication is required to allow each participant in the ecosystem to evaluate other participants’ compliance with mutual trust frameworks and accomplish secure and trusted transactions.

This specification defines how to use OpenID Federation 1.0 to enhance the security and interoperability of wallet ecosystems, facilitating trust establishment among the parties and enabling secure metadata exchange and policy application across large scale deployments. It outlines the general architecture of a federated trust infrastructure for wallet ecosystems, identifying participant roles and describing the use of those roles.

3. OpenID Connect Relying Party Metadata Choices

This specification extends the OpenID Connect Dynamic Client Registration 1.0 specification to enable RPs to express a set of supported values for some RP metadata parameters, rather than just single values. This functionality is particularly useful when Automatic Registration, as defined in OpenID Federation 1.0, is used, since there is no registration response from the OP to tell the RP what choices were made by the OP. This gives the OP the information that it needs to make choices about how to interact with the RP in ways that work for both parties.

Thanks to the members of the OpenID Connect working group who helped refine them before adoption, and are now working on progressing them in the working group.