OpenID Federation and the trust chain explained

The new OpenID protocol defines a clever JWT architecture for establishing trust at Internet scale. It was chosen in 2022 for the national eID in Italy to federate a dozen IdPs catering to thousands of applications. Presently, advocates of the protocol and its "trust chain" are pursuing its adoption in other areas, like the EUDI wallet, a project of the EU for a citizen's digital wallet, and in OpenID GAIN, a globally interoperable profile for verified identity provisioning.

1. What is OpenID Federation good for?

The automated:

• determination whether an OpenID relying party (RP) and an OpenID provider (OP) can trust one another, given one or more shared trust anchors;

• discovery, policing and updating of RP and OP metadata, federation wide;

• registration of RPs as clients at OPs, saving costly human administration.

As a protocol for trust establishment OpenID Federation 1.0 is not bound to OpenID Connect and OAuth 2.0 uses cases only. Thanks to its generic nature it can work equally well in other domains, for instance in the IoT and the wallet / verifiable credentials space.

2. The need to establish trust between clients and IdPs

A relying party, whether in OpenID Connect or SAML, cannot send a user to authenticate with an IdP, unless the RP has been registered there as client. In OpenID Connect the client registration is necessary so that the RP is provisioned with a client_id and has its redirect_uri recorded at the IdP. For an RP which is a confidential client the registration also establishes an authenticating credential. This is the minimum data an OpenID provider must have on record for every RP, in order for the OAuth flows to work and the RP to be able to log in a user.

Identity providers traditionally put up an online portal for developers to register their applications. Occasionally an IdP may also expose a web API, secured by means of a key or token. The OpenID Connect working group devised a standard API for client registration, which the Connect2id server has duly implemented. However, the standard is silent on how the client registration requests are to be pre-authorised, an aspect left to implementers to figure out for themselves. Managing access to the registration API is crucial for security, in order to prevent phishing attacks by malicious applications seeking to get at and exploit user identities.

The developer portal method for registering clients becomes impractical with tens, hundreds, or more IdPs. A proper solution must be readily programmable and require minimum human interaction. This calls for the following:

1. A protocol for RPs and OPs to find out whether a counterparty can (still) be trusted.

2. A method for authenticated client registration, once mutual trust is established.

Prior to the advent of OpenID Federation 1.0 there have been several approaches to manage the establishment of trust between entities and the process of client registration in a federation. Two notable examples:

• In Open Banking UK all entities must enroll in a central directory. RPs are still required to explicitly register at each server they intend to use, by making a customised dynamic client registration request with a software statement, signed with a key tied to a certificate.

• The eduGAIN federation, a “super federation” spanning 80 ecosystems in research and education, and totaling over 4500 SAML IdPs, approaches the problem by generating and distributing lists of the authorised entities, together with their latest metadata, to all participants.

The OpenID Federation 1.0 protocol was originally motivated to enable a next-level eduGAIN, comprised of OpenID Connect relying parties and IdPs (instead of SAML) and assisted by a clever JWT architecture for resolving trust. The federation protocol further evolved to address new use cases, such as the new Italian eID, to reach its present form, with official publication expected in 2023.

3. The six tenets of OpenID Federation

What are the principles that govern the OpenID federation protocol?

Tenet 1: Enroll once, scale without limits

Once an entity enrolls with a trust anchor or intermediary it immediately becomes recognisable as ratified by all members in the federation. Due to the bottom-up trust chain resolution process this occurs without delay, as opposed to protocols, such as the DNS, which require time for new records to propagate.

There is no fixed limit on the number of entities that can be enrolled in a federation.

An entity is free to enroll with other federations, reusing its entity ID (URL) and credentials (one or more public keys).

Should the authority where the entity was originally enrolled become part of some super federation, for intance by joining an international eID scheme, the trust from the super level will extend transitively to it.

Tenet 2: Trust topology for evolving needs

The simplest federation topology is a single trust anchor directly enrolling all OPs and RPs.

Delegation of enrollment is made possible by adding intermediate authorities beneath the trust anchor. Member organisations can thus be entrusted to manage the enrollment of their own IdPs and RP applications. The trust anchor (and intermediates) can formulate a policy to constrain further delegation and the types of accepted leaf entities.

A federation can be seamlessly expanded to span multiple trust anchors (multilateral federation). A trust anchor can also seamlessly join a super federation, by becoming an intermediary relative to the super federation’s trust anchor.

Tenet 3: Entity type agnostic

The protocol is capable of resolving trust and metadata for entities of any type. The original use case was to enable the federation of entities that are OpenID relying parties and providers. The protocol is generic enough to cater for other use cases, such as OAuth 2.0 clients and servers, or wallet and verifiable credential providers.

Tenet 4: Built-in metadata discovery, assertion and policing

OpenID Connect and OAuth 2.0 have the concept of entity metadata, a standard JSON document describing the endpoints, keys, cryptographic capabilities and other details particular to the entity type. The metadata makes it possible for the entities to setup communication, algorithms and keys to be established, UIs localised, etc.

The ability to deal with the natural metadata requirements of entities, whatever their type and role, is a function that integrates neatly into the federation protocol:

• Every federation entity is able to publish typed metadata about itself, making it discoverable by other members. For example, an RP can publish its metadata with its redirect_uris and other details required for an OpenID Connect client registration.

• Authorities are able to assert selected metadata parameters about their direct subordinates. For example, an organisation may choose to assert the official names, logos and terms & conditions for all RPs and IdPs in its jurisdiction.

• Authorities can also formulate metadata policies for their subordinates. The purpose of policies is to ensure interoperability between entities and a baseline of security. For example, a trust anchor may create a policy that requires all RPs and OPs to support the authorization_code OAuth 2.0 grant and ID tokens signed with PS256.

• The metadata and its dynamic resolution is secured by the same JWT architecture that protects the trust chain.

Integrating entity metadata into the federation protocol and trust chains has the effect that whenever the trust for a given entity is positively resolved, the entity’s effective metadata is automatically resolved as well, incorporating all metadata assertions and policies along the trust chain.

Tenet 5: Automatic authenticated client registration

A federated RP can send end-users to authenticate with their IdPs directly, as if the RP was already registered with it as a client application, using a standard OAuth 2.0 flow and existing OpenID Connect library code.

The RP needs only two things:

• Set the client_id in the OpenID authentication request to its federation entity URL.

• Authenticate the request with a public key based method supported by the IdP:

  • By either passing a signed request object, or
  • By using the pushed authorisation request (PAR) endpoint, with private_key_jwt or self_signed_tls_client_auth client authentication.

Example signed authentication request from an RP with client_id set to an https://rp.example.com URL:

https://demo.c2id.com/login?
response_type=code
&client_id=https%3A%2F%rp.example.com
&scope=openid+profile+email
&request=eyJraWQiOiJLLVFLM0JTY0NWYTZXY2wzRHFDZXg3amQ0VFBMV1dhRkFXbnNiQnNU...

Example pushed request with private_key_jwt authentication, using the same client_id to identify the RP as a federation entity:

POST /par HTTP/1.1
Host: demo.c2id.com
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=https%3A%2F%rp.example.com
&scope=openid%20profile%20email
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Frp.example.org%2Fcb
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIno.eyJpc3Mi...

The elimination of the traditional and usually manual client registration step is made possible by the properties of the federation protocol explained above:

• The trust check on the client_id will determine whether it represents a valid federated RP entity.

• The trust check will simultaneously produce the discovered RP metadata, shaped by any applicable assertions and policies from federation authorities in the trust chain.

A federation aware OpenID provider does the trust check in the background, creating an internal client registration for the RP on success. The OpenID authentication request is expected to be signed (request object or PAR) to guarantee it originates from the claimed entity in the client_id and not some other party. No prior client registration, registration specific client-side state or administrator involvement is thus required for RPs to call at IdPs in a federation.

For RPs that for some reason cannot use signed requests or PAR, OpenID Connect Federation 1.0 allows for explicit registration at the OP, where the RP can be provisioned with a regular client_id and a client_secret for basic authentication. This type of registration can be easily scripted, so no administrator involvement is required either.

Tenet 6: Standard, autonomous JWT-based security

The statements that compose the trust chains in a federation are signed JSON Web Tokens (JWTs). The default signature algorithm is RS256 (RSA with SHA-256). A federation can use a different JSON Web Signature (JWS) algorithm or a mix of algorithms should its needs dictate so.

The signature (JWS) gives the statements the properties of integrity, authenticity and non-repudiation. The statements thus do not need rely on the underlying transport layer or additional protocols for their security. This makes them suitable in zero-trust environments.

4. The entity statement

The entity statement, a signed JWT, is the basic unit that makes up the trust chains in OpenID Connect Federation 1.0.

There are three statement variants, which have a common structure:

• Entity configuration (EC): Lets a federation entity create a self-issued (iss = sub) statement about itself - with its entity ID, public federation signing keys and entity type specific metadata.

  An entity with a web server can publish it at a well-known location, using the /.well-known/openid-federation path.

• Entity statement (ES): Lets authorities (trust anchors and intermediates) issue signed statements about their subordinates, asserting the subject’s public keys and optionally specifying metadata policies and trust chain constraints.

  Authorities return those statements at a web endpoint in response to queries from other federation participants.

• Explicit registration statements: For RPs that choose to use the explicit registration method with a federated OpenID provider. This variant is for OpenID Connect use only.

The following table outlines the JWT claims that go into Entity Configurations (EC) and Entity Statements (ES). The iss, sub, iat and exp are standard JWT (RFC 7519) claims. The remaining claims are defined in the federation spec.

Key: ✔ required; ∼conditional or optional

Example of an Entity Configuration (EC)

This is an example JWT for the EC of an OpenID relying party (RP).

JWT header

The JWT header identifies the signing algorithm (alg) and the optional key ID (kid). The explicit typing (typ) is to prevent confusion between JWTs that may have a similar claims structure.

{
  "alg" : "RSA",
  "kid" : "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
  "typ" : "entity-statement+jwt"
}

JWT claims

The iss and sub claims are identical, since the EC is self-issued.

The standard iat and exp claims establish the time validity of the EC and can be used as a hint when caching it.

The jwks claim is where the entity publishes its federation signing key(s) in standard JWK set format. The EC is self-signed, to let the RP prove that it’s in possession of its key.

The authority_hints contains a reference to the federation authorities where this entity is enrolled. In this example there is only one, and it is the federation’s trust anchor.

The included metadata is standard for an OpenID relying party that uses public key authentication with a JWT. Note that the signing key for OAuth 2.0 / OpenID Connect specific uses must be different from the one the entity uses to sign its Entity Configuration! To illustrate this point the example below contains a different key type (Elliptic Curve instead of RSA) in its OpenID RP metadata.

{
  "iss" : "https://rp.example.com",
  "sub" : "https://rp.example.com",
  "iat" : 1684920387,
  "exp" : 1684923987,
  "jwks" : {
      "keys" : [
          {
             "kty" : "RSA",
             "alg" : "RS256",
             "use" : "sig",
             "kid" : "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
             "e" : "AQAB",
             "n" : "nechoo7aelaelo3diegai7ie5Pu7koh4..."
          }
      ]
  },
  "authority_hints" : [ "https://ta.example.com" ],
  "metadata" : {
      "openid_relying_party" : {
          "client_registration_types" : [ "automatic" ],
          "grant_types" : [ "authorization_code" ],
          "response_types" : [ "code" ],
          "redirect_uris" : [ "https://rp.example.com/cb" ],
          "jwks" : {
              "keys" : [
                  {
                     "kty" : "EC",
                     "crv" : "P-256",
                     "alg" : "ES256",
                     "use" : "sig",
                     "kid" : "1",
                     "x" : "gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
                     "y" : "SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
                  }
              ]
          },
          "request_object_signing_alg" : "ES256",
          "token_endpoint_auth_method" : "private_key_jwt",
          "token_endpoint_auth_signing_alg" : "ES256"
      }
  }
}

Example of an Entity Statement (ES)

This is an example JWT for an ES issued from a trust anchor about the OpenID RP from the above example of an EC.

JWT header

The JWT header identifies the signing algorithm (alg) and the optional ID (kid) of the trust anchor’s public federation key. The JWT must be explicitly typed (typ) too.

{
  "alg" : "RSA",
  "kid" : "moor1arahC0ahM1Jaezeecei2yoh2Iet2Xa5shoM1nah",
  "typ" : "entity-statement+jwt"
}

JWT claims

The subject (sub) is set to the entity ID (URL) of the OpenID relying party.

The ES also has a validity time window, established by the standard iat and exp JWT claims.

The jwks claim is the public JWK set that the RP has registered with the trust anchor, and is essentially a repeat of the jwks in the RP’s own EC above. If the RP is the process of rolling over to a new federation public key the two jwkss may differ and include more than one key. The key that an entity uses to sign statements issued by it (whether an EC or ES) must however always be registered with its authority. Failure to do so will result in invalid trust chains.

The ES also contains metadata assertions and policies that apply to the subject entity as an OpenID relying party.

The asserted metadata.openid_relying_party here contains the legal name under which the RP is registered with the trust anchor. Also, the RP’s policy and terms of service documents which the trust anchor operator has approved as being compliant with the federation’s policy and has them hosted on behalf of the RP.

Finally, the metadata_policy.openid_relying_party sets the general OAuth 2.0 client / OpenID Connect RP metadata policies that have been put in place to ensure protocol interoperability between the RPs and the OPs in the federation.

{
  "iss" : "https://ta.example.com",
  "sub" : "https://rp.example.com",
  "iat" : 1684920387,
  "exp" : 1684923987,
  "jwks" : {
      "keys" : [
          {
             "kty" : "RSA",
             "alg" : "RS256",
             "use" : "sig",
             "kid" : "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
             "e" : "AQAB",
             "n" : "nechoo7aelaelo3diegai7ie5Pu7koh4..."
          }
      ]
  },
  "metadata" : {
      "openid_relying_party" : {
          "organization_name" : "Blackhex Boildrip Ltd.",
          "client_name" : "The Sureshot Tantrum App",
          "logo_uri" : "https://ta.example.com/hosted/AA4H/logo.png",
          "client_uri" : "https://rp.example.com/",
          "policy_uri" : "https://ta.example.com/hosted/AA4H/policy.html",
          "tos_uri" : "https://ta.example.com/hosted/AA4H/tos.html"
      }
  },
  "metadata_policy" : {
      "openid_relying_party" : {
          "grant_types" : {
              "default" : [ "authorization_code" ],
              "superset_of" : [ "authorization_code" ]
          },
          "token_endpoint_auth_method" : {
              "default" : [ "private_key_jwt" ],
              "one_of" : [ "private_key_jwt", "self_signed_tls_client_auth" ]
          },
          "token_endpoint_auth_signing_alg" : {
              "one_of" : [ "RS256", "ES256" ]
          },
          "id_token_signed_response_alg" : {
              "default" : "RS256",
              "one_of" : [ "RS256", "ES256" ]
          }
      }
  }
}

5. The trust chain

The OpenID Federation 1.0 trust chain is composed of two or more signed entity statement JWTs.

The minimal trust chain

In the most simple case, a federation where all OPs and RPs are enrolled directly with the trust anchor, the trust chain for every leaf (OP or RP) contains exactly two statement JWTs, in the following order:

1. An Entity Statement (ES) issued by the trust anchor about its subordinate (leaf OP or RP).

   The ES contains the entity ID of the subject and asserts its public signing federation key(s). It may additionally assert metadata parameters, such as organization_name, about the subject. The trust anchor in its ES JWTs may also specify metadata policies for its subordinates, for example OAuth grant types and ID token algorithms that must be supported.

2. An Entity Configuration (EC) issued by the leaf (OP or RP) about itself.

   The EC asserts the entity’s own ID and public signing federation key(s). Depending on its type (OP or RP) it will also include appropriate metadata, for example an authorization_endpoint for an OP, or a redirect_uris for an RP.

Trust chain with intermediaries

In federations where the trust anchor has delegated enrollment to one or more subordinate authorities the trust chains will include an additional Entity Statement, that of the intermediary. The statement JWT order will thus be:

1. An Entity Statement (ES) issued by the trust anchor about its subordinate intermediary.

2. An Entity Statement (ES) issued by the intermediary about its subordinate (leaf OP or RP).

3. An Entity Configuration (EC) issued by the leaf (OP or RP) about itself.

If multiple levels of delegation are allowed these will be represented by additional intermediate ES JWTs in the trust chain.

There is no hard protocol limit on the number of intermediate authorities in a trust chain. A federation policy governing the max level of delegation can be established, by setting a max_path_length constraint.

6. How is trust resolved?

The process of resolving trust between two entities is a mutual, two-step process.

Why resolve trust mutually?

In OpenID Connect the OP and the RP must trust one another before user authentication is safe to proceed:

• The OP must trust that the RP is safe to access the end-user identity and any consented profile information.

• The RP must trust that the OP is able to authenticate the end-user, at the required level of assurance.

This means that in order for an OpenID authentication request to proceed, both OP and RP must have positively established that they can trust one another. If not there is risk of a private data leak or identity impersonation.

The requirement of mutual trust typically holds for entities that perform transactions or transmit private data. In scenarios that don’t exhibit these characteristics unilateral trust may be sufficient.

The trust resolution process

The two steps of the trust resolution are these:

Step 1. Obtaining the trust chain

An entity’s trust chain can be obtained in three ways:

• Pull method – This method requires the entity ID, which is a URL. Appending the /.well-known/openid-federation path to it produces the URL where the Entity’s Configuration (EC) can be retrieved. Following the authority_hints in the EC (and any subsequent statements from authorities) a chain of statements can be retrieved, eventually reaching the trust anchor to obtain the complete trust chain.

In the case of an OpenID authentication request the entity ID is communicated via the existing standard client_id parameter.

Once retrieved, the trust chain can be cached locally, to save future network calls. The recommended strategy is to cache the trust chain for the remaining lifetime of its nearest expiring statement (set by the exp JWT claim).

• Push method – The entire trust chain is passed as part of the request.

In the case of an OpenID authentication request the trust chain can be passed in a trust_chain request parameter. When a request object (JWT) is utilised the trust chain can alternatively be passed in a JWS trust_chain header parameter.

The push method is indispensable in cases where the entity cannot host a web endpoint at the well-known path for its Entity Configuration (EC). For the validating entity it also has the advantage that it doesn’t require outbound network calls to retrieve the statements to compose the trust chain. Finally, passing the trust chain in requests ensures the validating entity has the most recent metadata of its counterparty, instead of relying on caches that may become stale.

• Hybrid push / pull method – With this method only the Entity Configuration (EC) is passed as part of the request. The remaining Entity Statements (ES) are fetched with network calls. This method is used by the explicit client registration of OpenID relying parties and OAuth 2.0 clients.

Step 2. Validating the trust chain

Validation of trust chains requires the trust anchor’s public singing keys. They can be obtained from the well-known Entity Configuration HTTPS endpoint of the trust anchor, or by some suitably secured key distribution mechanism agreed within the federation.

The trust anchor’s signing keys are used to verify the chain of digital signatures, starting from the trust anchor issued Entity Statement until the last Entity Statement (if intermediate authorities were involved).

The final statement in the trust chain is the Entity Configuration, which is self-signed. Verifying its signature proves that the entity possesses its signing key.

The trust chain must also be traversed to validate the JWT claims in each entity statement (ES or EC):

• That there is a logical iss (issuer) -> sub (subject) chain from the trust chain ES to the EC.

• That the signing key used by an entity to issue its statement has been registered with its authority, by checking the key is present in the jwks claim of the ES issued by the authority. This check doesn’t apply to the trust anchor’s statement since it is the ultimate authority.

• That the current time is within the time window bound by the iat (issued-at time) and exp (expiration time) JWT claims.

• That entity metadata complies with any metadata policies set by the trust anchor and any other intermediate authorities.

• That any included trust marks recognised within the federation are valid.

• That the ES and EC JWTs are otherwise syntactically correct.

The exact procedure to validate trust chains is described in the OpenID Federation 1.0 specification.

The resolve facility

To help entities with the process of trust chain resolution an authority, such as the trust anchor, may offer a resolve endpoint. The endpoint returns resolved entity metadata ready to be used by applications within the federation. Internally the endpoint will perform the requisite trust resolution by fetching the statements to build a trust chain and then validating it.

The resolve endpoint is optional in federations and chiefly intended as a convenience for participating entities, giving them the choice of calling this endpoint instead of implementing the trust resolution in their own software.

The responses from the resolve endpoint are signed with the resolver’s federation key, to ensure their integrity, authenticity and non-repudiation.

7. The trust chain vs the X.509 certificate chain

The OpenID Federation 1.0 trust chain can be regarded as an X.509 certificate chain on steroids.

Both types of chains can be used to assert and verify that a named entity owns a given public key, by defining a data structure for authorities to sign the public keys of subjects. X.509 thus enabled the creation of public key infrastructure, to secure communications over the Internet. Crucial cryptographic protocols, like TLS, use X.509 certificate chains to validate the public keys of servers or clients.

The public key infrastructure evolves into trust infrastructure

The X.509 certificate is a binary (ASN.1/DER) data structure that essentially contains an issuer name, a subject name, a public key, an expiration date, with the content being digitally signed. Its format was designed for efficiency and doesn’t allow for easy inclusion of additional data that may be required at higher protocol layers or the application layer.

The JWT format defined in OpenID Federation 1.0 has now arrived to fill this significant gap. Protocols and applications receive the ability to define and plug metadata and metadata policies about entities into the same vehicle that asserts an entity’s public key. The basic key infrastructure can thus evolve into a more complete security infrastructure – a trust infrastructure.

What kind of metadata may entities put in their EC JWTs?

• Metadata describing the capabilities of the client or server;
• Metadata listing API endpoints;
• Accreditations / trust marks.

What kind of metadata policies may authorities (trust anchors) put in their ES JWTs?

• Minimum required protocols to ensure interoperability between clients and servers;
• Minimum required security;
• Privacy and compliance requirements.

Rich choice of standard web APIs to aid trust decisions

X.509 became standard in 1988, the era before the WWW and HTTP. The profound implication is X.509 has no standard web APIs to query a Certificate Authority (CA) or the subject (recipient) of a certificate.

The OpenID Federation 1.0 spec doesn’t suffer from this deficiency. Architects and developers can find a set of useful web APIs:

The majority of those APIs are optional. Leaf entities are not required to implement any.

Push, pull and hybrid methods for obtaining the trust chain

The X.509 certificate and certificate chains usually get passed as part of a handshake request or response. At the time of the X.509 invention the concept or well-known URLs didn’t exist. LDAP servers were supposed to become directories where clients would go to search for and retrieve certificates, but this idea did not pick up to any significant degree.

The definition of standard endpoints for retrieving entity configurations (EC) and entity statements (ES) gives architects a choice of methods – pull, push and hybrid – to obtain a trust chain, as explained in the section about trust resolution.

Architects are thus able to choose an optimal method for their particular protocol or application. The push method for instance minimises the number of outbound network calls, the pull method the effective revocation time.

Designed for real world trust topologies

The X.509 design envisioned an Internet and relationships that are relatively static and single dimensional. The digital entities of today often need to be more fluid and can have complex relationships, which can be driven by business, organisational or regulatory needs. A protocol for establishing trust must be able to accommodate this richer, dynamic world.

One notable aspect of OpenID Federation 1.0 is it’s explicit design to cater for entities partaking in more than one federation, which is sometimes called multilateral federations. This means that an entity may be configured with more than one trust anchor (i.e. more than one ultimate authority), while using an identical ID in all places.

The individual federations that compose a multilateral federation can have different sets of policies. When resolving the trust and the metadata for a given entity, one can choose which policies are to apply by explicitly selecting the federation’s trust anchor for the process. The resulting metadata will then automatically reflect the applicable policies for the federation.

Another aspect is the support for trust marks, which gives architects the ability to devise supplementary trust relationships, in the form of accreditations and attestations, independent from the public key assertion of the trust anchor (and intermediate authorities).

A feature that may not be obvious is that trust anchors can transparently become intermediates (for example when the current federation joins a super federation), without requiring entities to update the trust anchor keys or otherwise reconfigure themselves.

Summary comparison

8. How to explore further and get started

To dive deeper into OpenID Federation 1.0 read the most recent published draft.

Are you contemplating the use of trust chains in a project or ecosystem? Get in touch with us to find out how we can assist you. We can put you in touch with experts who have worked on the development of the standard or its implementation.

Core functionality, like the trust chain validation and metadata resolution, is available as part of the open source OAuth 2.0 / OpenID Connect SDK that we maintain. If you intend to use the SDK in your project, have feedback or ideas how to contribute to its federation functionality, feel free to write to our technical team.

The Connect2id server has had built-in support for OpenID Connect Federation 1.0 since v10.0, released in August 2020. In 2022 the support was updated to match the most recent spec developments which resulted from its adoption in the Italian eID federation as well as feedback in the OpenID Connect WG.

Presentations