Introducing OIDC Credential Provider
OpenID Connect (OIDC) is a hugely popular user authentication and identity protocol on the web today. It enables relying parties to verify the identity of their users and obtain basic profile information about them in order to create an authenticated user experience.
In typical deployments of OpenID Connect today, in order for a user to be able to exercise the identity they have with a relying party, the relying party must be in direct contact with what’s known as the OpenID Provider (OP). OpenID Providers are responsible for performing end-user authentication and issuing end-user identities to relying parties. This effectively means that an OpenID Provider is the Identity Provider (IdP) of the user.
It’s the reason we often see buttons that say “Login with Google” or “Login with Facebook” during the login journey in an application or service. The website or application you want to use must first authenticate who you are with a provider like Google or Facebook which controls and manages that identity on your behalf. In this context we can think of the IdP as the “man in the middle.” This relationship prevents users from having a portable digital identity which they can use across different contexts and denies users any practical control over their identity. It also makes it incredibly easy for IdPs like Google or Facebook to track what users are doing, because the “man in the middle” can gather metadata about user behavior with little agency over how this identity data is shared and used.
In order to allow users to have practical control over their identity, we need a new approach.
Introducing OpenID Connect Credential Provider, an extension to OpenID Connect which enables the end-user to request credentials from an OpenID Provider and manage their own credentials in a digital wallet. This specification defines how an OpenID Provider can be extended beyond being the provider of simple identity assertions into being the provider of credentials, effectively turning these Identity Providers into Credential Providers.
To maximize the reuse of existing infrastructure that’s deployed today, OIDC Credential Provider extends the core OpenID Connect protocol, maintaining the original design and intent of OIDC while enhancing it without breaking any of its assumptions or requirements.
Instead of using OIDC to provide simple identity assertions directly to the relying party, we can leverage OIDC to offer a Verifiable Credential (VC) which is cryptographically bound to a digital wallet of the end-users choice. The digital wallet plays the role of the OpenID Client application which is responsible for interacting with the OpenID Provider and manages the cryptographic key material (both public and private keys) used to prove ownership of the credential. The credentials issued to the wallet are re-provable and reusable for the purposes of authentication. This helps to decouple the issuance of identity-related information by providers and the presentation of that information by a user, introducing the user-controlled “wallet” layer between issuers and relying parties.
Essentially, a wallet makes a request to an OpenID provider in order to obtain a credential, and then receives the credential back into their wallet so they can later use it to prove their identity to relying parties. The interaction consists of three main steps:
- The Client sends a signed credential request to the OpenID Provider with their public key
- The OpenID Provider authenticates and authorizes the End-User to access the credential
- The OpenID Provider responds to the Client with the issued VC
In this new flow, the credential request extends the typical OpenID Connect request in that it expresses the intent to ask for something beyond the identity token of a typical OIDC flow. Practically, what this means is that the client uses a newly defined scope to indicate the intent of the request. The Client also extends the standard OIDC Request object to add cryptographic key material and proof of possession of that key material so that the credential can be bound to the wallet requesting it. Though the credential can be bound to a public key by default, it can also support different binding mechanisms, e.g. the credential can optionally be bound to a Decentralized Identifer (DID). In binding to a DID, the subject of the credential is able to maintain ownership of the credential on a longer life cycle due to their ability to manage and rotate keys while maintaining a consistent identifier. This eases the burden on data authorities to re-issue credentials when keys change and allows relying parties to verify that the credential is always being validated against the current public key of the end-user.
The request can also indicate the format of the requested credential and even ask for specific claims present within the credential. This is designed to allow multiple credential formats to be used within the OIDC flow.
On the provider side, OpenID Connect Providers are able to advertise which capabilities they support within the OIDC ecosystem using OpenID Connect Provider Metadata. This approach extends the metadata to support additional fields that express support for binding to DIDs, for issuing VCs, and advertising which DID methods, credential formats, credentials, and claims they are offering. This information can be utilized by the end-user’s digital wallet to help the user understand whether or not they wish to proceed with a credential request.
In order to create a way for the wallet or client to connect to the OpenID Provider, the spec also defines a URL which functions as a Credential Offer that the client can invoke in order to retrieve and understand the types of credential being offered by the provider. The client registers the ‘openid’ URI scheme in order to be able to understand and render the offer to the user so they can make an informed decision.
The sum of these changes means that OpenID Connect can allow users to have a portable digital identity credential that’s actually under their control, creating an opportunity for greater agency in digital interactions as well as preventing identity providers from being able to easily track user behavior. The OpenID Connect Credential Provider specification is in the process of being contributed to the OpenID Foundation (OIDF) as a work item at the A/B Working Group, where it will continue to be developed by the community behind OpenID Connect.
MATTR is pleased to announce that our OIDC Bridge Platform Extension now uses OIDC Credential Provider under the hood to facilitate issuing credentials with OpenID Connect. OIDC Bridge hides the complexity associated with setting up infrastructure for credential issuance and simply requires configuration of a standard OpenID Provider. We also simplify the process of verifying credentials issued over OIDC Credential Provider by allowing the wallet to respond to requests, present credentials, and prove ownership and integrity of their credentials via OIDC.
This new set of capabilities allows OpenID Providers greater flexibility around which claims end up in a credential, and allows for the support of many different credential types with a straight-forward authentication journey for end-users.
Our Mobile Wallet supports the ability to invoke credential offers using OIDC Credential Provider as well as creating credential requests and receiving credentials from an OpenID Provider.
To find out more, check out our tutorials on MATTR Learn, read the spec, or watch a recording of our presentation on this spec from the recent Internet Identity Workshop.