Swedish OpenID Federation Deployment and Interoperability Profile 1.0

	swedish-openid-federation-profile	October 2026
Lindström & Santesson	Standards Track	[Page]

Abstract

This document defines a deployment and interoperability profile for OpenID Federation [OpenID.Federation]. The profile introduces a constrained and implementation-focused subset of the OpenID Federation specification, designed to simplify deployment and promote interoperability across federations.¶

It provides clarifications and extensions that enable entities with protocol roles, such as OpenID Providers, OpenID Connect Relying Parties, OAuth 2.0 Authorization Servers, Clients, and Protected Resources, to join and use an OpenID Federation with minimal effort. The profile also describes mechanisms that allow legacy systems to participate without being fully OpenID Federation-compliant.¶

2. Structuring Federation Deployments

The OpenID Federation standard [OpenID.Federation], is generic and imposes few restrictions on how a federation may be structured. This section introduces a set of requirements and recommendations intended to make OpenID Federation deployments straightforward and easy to maintain.¶

2.1. Responsibilities of a Federation Operator

This section describes the responsibilities of a Federation Operator, as manifested by a Trust Anchor, when establishing and operating a federation.¶

A Federation Operator MUST define Federation Rules that govern the operation of the federation and the conduct of its members. These rules encompass both technical requirements and non-technical processes. The following requirements apply to Federation Rules:¶

The Federation Rules MUST define rules and requirements for joining the federation. It is RECOMMENDED that Registration Policies be defined; see Section 3.2.¶
Federation Rules SHOULD define protocol-specific requirements, including which underlying standards and profiles federation members are required to comply with. This includes interoperability requirements such as regulated algorithm support and requirements for Entity metadata. See Section 7, Adapting OAuth 2.0 and OpenID Connect for OpenID Federation.¶
The Federation Rules SHOULD define and maintain a Trust Mark Policy. See Section 5.1.¶
It is RECOMMENDED that the Federation Rules define federation-wide security requirements, such as minimum key lengths, key rollover frequency, and client authentication requirements.¶
Federation Rules SHOULD define recommended validity periods for Entity Statements in order to promote predictable behaviour and operational stability; see Section 2.4.1.¶
The Federation Rules SHOULD define a base URL, or domain, for the federation. This base URL SHOULD be used when defining collision-resistant URLs within the federation context, such as Trust Mark type identifiers.¶

Some of the above rules are enforced through metadata policies or constraints, while others are enforced by operational means such as audits and controls.¶

2.2. Federation Entity Types

[OpenID.Federation] does not restrict how federation roles may be combined by a Federation Entity operating under a single Entity Identifier. However, combining the role of an Intermediate Entity with that of a Federation Protocol Entity, such as an OpenID Provider, can introduce challenges and unnecessary complexity. Most importantly, it may lead to conflicts between the contents of the metadata Claim and the metadata_policy Claim in subordinate Entity Statements, see Section 2.5.¶

Therefore, implementers of this profile MUST NOT combine the role of a Trust Anchor, Intermediate Entity, Trust Mark Issuer, or Federation Resolver with that of a Federation Protocol Entity under the same Entity Identifier.¶

This requirement implies that a Federation Protocol Entity is always a Leaf Entity and that its Entity Configuration MUST NOT include metadata of type federation_entity.¶

2.3. Federation Resolvers

Section 10 of [OpenID.Federation] specifies requirements for how an Entity resolves the Trust Chain and metadata of another Entity with which it wishes to establish trust. This process includes fetching Entity Statements, applying metadata policies and constraints, validating Trust Chains, and handling caching. The procedure is complex and may be difficult for all Federation Protocol Entities within the federation to implement.¶

Also, this algorithm relies on all participants publishing their Entity Configuration information at a well-known location, as specified in Section 9 of [OpenID.Federation]. However, this profile references an alternative way of publishing Entity Configuration (see Section 2.4.2 below), that requires a Trust Chain building algorithm starting at the Trust Anchor instead of the bottom-up approach specified in Section 10 of [OpenID.Federation].¶

Therefore, it is RECOMMENDED that Entities compliant with this profile use a Federation Resolver in order to resolve metadata and trust for peer Entities. A Federation Resolver is a Federation Service Entity within the federation that provides a federation_resolve_endpoint as specified in Sections 5.1.1 and 8.3 of [OpenID.Federation].¶

A Trust Anchor adhering to this profile MUST ensure the availability of at least one Federation Resolver compliant with the requirements stated in this profile. This resolver MUST support resolving for the given Trust Anchor. It is RECOMMENDED that the resolver is provided as part of the Trust Anchor itself.¶

Section 4, Resolving Metadata and Trust Marks, specifies further requirements for Federation Resolver usage and implementation.¶

2.4. Entity Statements

This section defines requirements and recommendations for Entity Statements defined in Section 3 of [OpenID.Federation].¶

2.4.1. Entity Statement Validity

The validity period of an Entity Statement is controlled by the exp Claim. Setting a short validity period undermines effective caching and places a burden on the issuing Entity to continuously update and sign the Entity Statement. Conversely, setting long validity periods for Entity Configurations may delay the propagation of metadata changes, as older versions may remain cached.¶

Federation rules SHOULD define recommended validity periods for Entity Statements in order to promote predictable behaviour and operational stability. In particular, Federation Operators are responsible for establishing guidance on appropriate validity intervals for Entities within their federation, see Section 2.1.¶

An Entity MUST publish updated Entity Configurations at intervals shorter than the validity period indicated by the exp Claim. This ensures that a fresh Entity Configuration is available before the previously issued one expires, thereby increasing resilience in case of temporary outages, signing key rollover, or operational disruptions. Entities SHOULD publish updated Entity Configurations with sufficient margin to account for caching behaviour and clock skew. It is RECOMMENDED that a new Entity Configuration be published when half of the lifetime of the current one, as given by its iat and exp Claims, has elapsed.¶

2.4.2. Hosted Entity Configurations

The specification for the extension "OpenID Federation Entity Configuration Hosting" [OpenID.Federation.Hosting] defines the Entity Statement extension Claim ec_location. The primary purpose of this Claim is to enable hosting of a Leaf Entity's Entity Configuration data at a location other than the one specified in Section 9 of [OpenID.Federation].¶

Using this Claim, an OpenID Federation deployment can allow Entities that do not support the [OpenID.Federation] specification, or that for other reasons cannot meet its requirements for publishing their Entity Configuration at a well-known location, to participate in the federation.¶

Deployments adhering to this profile MAY support the ec_location extension Claim. It is RECOMMENDED that Superior Entities supporting the Claim include the Claim in all published Entity Statements, even when the subject's Entity Configuration is published at the well-known location as specified in [OpenID.Federation]. This gives resolvers a uniform way to locate the subject's Entity Configuration.¶

Note that [OpenID.Federation.Hosting] is an extension to [OpenID.Federation], and an Entity can be fully compliant with this profile without supporting it.¶

2.5. Controlling Metadata for Subordinates

An Entity declares its own metadata, that is, the parameters describing its capabilities and preferences, in the metadata Claim of its Entity Configuration. A Superior Entity can change the resolved metadata of a Subordinate Entity in two ways:¶

By declaring metadata values in the metadata Claim of the Subordinate Statement it issues for the Entity. These values apply only to the subject of the statement and override identically named parameters declared by the Entity.¶
By including a metadata policy, using the metadata_policy Claim as defined in Section 6.1 of [OpenID.Federation], in the Subordinate Statement. The policy applies to all Entities that are Subordinates of the Entity that sets the policy.¶

Since any Entity in a Trust Chain that issues Subordinate Statements may define metadata policies, the resolved metadata of an Entity is the result of merging all applicable policies along the chain. This can cause two problems:¶

If a policy introduces parameter values that were not declared by the Entity, the resolved metadata may include capabilities or preferences that the Entity does not support. This can lead to unpredictable or invalid configurations.¶
The policies along a chain may not be possible to merge. For example, if an Intermediate Entity uses the value operator to set token_endpoint_auth_signing_alg to RS256, and the Trust Anchor uses the same operator to set it to ES256, the policies cannot be merged, see Section 6.1.3.1.1 of [OpenID.Federation]. Such a merge conflict makes it impossible to validate the Entity's metadata through that Trust Chain. The risk of conflicts increases when complex policies are defined by lower-level Entities in the chain, and when an Entity is reachable through Trust Chains ending at different Trust Anchors.¶

To prevent these problems, this profile specifies requirements based on two categories of metadata parameters:¶

Descriptive parameters that characterise the Entity, such as display name, logotype, and organizational affiliation.¶
Protocol parameters that define security and functional settings, such as keys, algorithms, and endpoint URLs.¶

The following requirements apply:¶

Adding metadata parameter values to an Entity's metadata SHOULD be limited to the Entity itself and its Immediate Superior Entity responsible for registering the Entity in the federation.¶
An Immediate Superior Entity that needs to add metadata parameter values to an Entity's resolved metadata SHOULD declare these values directly in the metadata Claim of the Entity Statement issued for the Entity, and SHOULD NOT use metadata policy operators for this purpose.¶
Metadata policies SHOULD be used to constrain, filter, or refine metadata values declared by the Entity, and SHOULD NOT be used to introduce capabilities or preferences that are unknown to the Entity.¶
Deployments compliant with this profile SHOULD concentrate metadata policies that control protocol parameters at Trust Anchors.¶

Together with the requirement in Section 2.6.1 that Federation Protocol Entities are not Immediate Subordinates of a Trust Anchor, the last requirement makes it possible to build alternative Trust Chains towards other Trust Anchors without applying the metadata policies of more than one Trust Anchor. This reduces the risk of merge conflicts caused by incompatible policies.¶

2.6. Federation Hierarchy Requirements and Recommendations

[OpenID.Federation] defines an infrastructure in which an Entity can belong to more than one federation context and therefore be reachable via different Trust Chains, each ending at a different Trust Anchor. Each federation context is anchored by a Trust Anchor. A Trust Anchor defines a policy that all its Subordinates must satisfy in order for their metadata to be validated through that Trust Anchor.¶

A Federation Protocol Entity or Federation Service Entity may have paths to more than one Trust Anchor. A path to a Trust Anchor does not, however, guarantee a valid Trust Chain. The Trust Chain is valid only if the Entity's metadata conforms to the combined metadata policies of all Entities in the Trust Chain up to and including the Trust Anchor, see Section 6.1.4 of [OpenID.Federation].¶

It is therefore important to structure the hierarchy of Federation Service Entities and their metadata policies carefully. The aim is to enforce essential rules while avoiding the unintended blocking of legitimate services due to incompatible policy applications.¶

This section contains sub-sections with requirements and recommendations for structuring a federation hierarchy in order to avoid unnecessary complexity and pitfalls.¶

2.6.1. Hierarchy Models

Federation Protocol Entities SHOULD NOT be Immediate Subordinates of a Trust Anchor. Instead, their Immediate Superior SHOULD be an Intermediate Entity that is an Immediate Subordinate of the Trust Anchor. This requirement reduces the risk of metadata policy conflicts when a Federation Protocol Entity also has paths to other Trust Anchors.¶

It is also RECOMMENDED that Federation Protocol Entities that need to be available under a common Trust Anchor have a common Intermediate Entity as their Immediate Superior. This makes it easier for that Trust Anchor to include a group of Federation Protocol Entities, since it only needs to issue a single Subordinate Statement about the common Intermediate Entity.¶

A Trust Anchor SHOULD NOT issue a Subordinate Statement about another Trust Anchor, in order to minimise the risk of merge conflicts between Trust Anchor metadata policies.¶

2.6.2. Trust Anchor and Trust Mark Issuer Roles

Trust Anchors may apply different metadata policies to the same Entity. That is, one Trust Anchor may restrict the set of metadata preferences in one way, while another imposes a different and potentially incompatible set of restrictions. When these policies cannot be reconciled into a single combined policy, a Trust Anchor that wants to support Entities recognized by another Trust Anchor needs to issue a Subordinate Statement directly about a Subordinate Entity of that other Trust Anchor, rather than about the other Trust Anchor itself. See Section 2.6.1 above.¶

However, this approach is no longer viable when the other Trust Anchor also operates as a Trust Mark Issuer whose Trust Marks are required to be understood by all Entities. Issuing a Subordinate Statement about a Subordinate Entity bypasses the Trust Anchor role and therefore excludes trust in the Trust Mark Issuer. Attempting to resolve this by issuing a Subordinate Statement directly about the Trust Mark Issuer is also problematic, because it implicitly creates an additional path through the other Trust Anchor, resulting in two possible trust paths, one of which may fail due to policy conflicts.¶

These issues are inherently difficult to resolve and introduce ambiguity and inconsistency in the trust path evaluation process. Therefore, deployments compliant with this profile SHOULD NOT allow Trust Anchors to also function as Trust Mark Issuers.¶

3. Entity Registration

"OpenID Connect Dynamic Client Registration" [OpenID.Registration] and "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] specify how a Client registers at an OpenID Provider or an OAuth 2.0 Authorization Server. Such registrations are performed in a peer-to-peer manner, where a Client is registered with a single service. A given Client's registration at another service may differ in naming, metadata, and security mechanisms.¶

When a Client joins a federation, it registers, not at a specific service, but to the federation itself. This fact implies that the registration data for a Client joining the federation MUST be generic in a sense that the registration does not presuppose a particular peer service. This also applies for other Entity types other than OAuth 2.0 Clients and OpenID Relying Parties.¶

Consequently, an OpenID Provider or an OAuth 2.0 Authorization Server compliant with this profile MUST be prepared to accept, and incorporate the metadata of an already registered Client, to its service configuration.¶

3.1. Role of the Federation Registration Entity

A Federation Registration Entity is a Superior Entity within the federation with which a Federation Protocol Entity (for example, an OpenID Connect Relying Party) registers to join the federation.¶

How the registration is initiated is out of scope for this profile, but one example is that the Federation Registration Entity provides an application to which Entity administrators log in and request registration for their Entity.¶

The Federation Registration Entity registers an Entity by creating and signing a Subordinate Statement for this Entity. Thus, the following aspects of an Entity being registered are vouched for by its Immediate Superior Entity:¶

The binding of a federation key to an Entity Identifier.¶
That the Entity holding the federation key is the legitimate Entity representing this Entity Identifier.¶
That the Entity holding the federation key is a legitimate member of the community implied by membership within a particular federation and can be trusted as such.¶

The registration is performed according to a Registration Policy, and in order for other participants within a federation to trust a registered Entity, they must trust and accept the policy under which the Entity joined the federation. See Section 3.2 below.¶

If the Federation Registration Entity declares metadata values in Subordinate Statements, these values SHOULD be limited to fixating descriptive Entity metadata that was controlled during registration. Typically, such values include display names or organizational affiliation. Constraining other metadata values is the responsibility of the Trust Anchor, see Section 2.5.¶

An Intermediate Entity acting as a Federation Registration Entity and compliant with this profile MUST expose a subordinate listing endpoint as defined in Section 8.2 of [OpenID.Federation].¶

3.2. Use of Registration Policies

A Federation Registration Entity that creates a Subordinate Statement for an Entity follows a set of rules, described by a Registration Policy, during the registration process. Such rules may comprise:¶

Checks to ensure that the organization behind the Entity has entered into the required agreements necessary for federation membership.¶
Checks to ensure that the individual requesting that the Entity be added to the federation is authorized to do so, for example by validating that the person is authorized to represent the organization that owns the Entity. This may also involve requirements on the authentication strength for the Entity administrator.¶
Checks to determine the ownership of domains. This is especially important when Entity Configuration Hosting is supported, see Section 4.1 of [OpenID.Federation.Hosting].¶
Assertions that Entity informational metadata parameters such as organization_name and display_name contain values that correspond to the organization behind the Entity.¶

Federation deployments compliant with this profile MAY support the extension specification "OpenID Federation Registration Policy 1.0" [OpenID.Federation.RegPolicy], define Registration Policy URIs for the policies used when registering Entities, and have Federation Registration Entities include the registration_policy extension Claim in Subordinate Statements.¶

Note that [OpenID.Federation.RegPolicy] is an extension to [OpenID.Federation], and an Entity can be fully compliant with this profile without supporting it.¶

Note: A Trust Mark could in theory be used to represent that a certain policy was applied during registration of an Entity to the federation. However, there is an important distinction between Registration Policies and Trust Marks. Whether an Entity holds a particular Trust Mark is typically checked by other Entities after its metadata and Trust Marks have been resolved and validated. Registration Policies, on the other hand, operate as part of the Trust Chain building process and are enforced through constraints defined by the federation.¶

4. Resolving Metadata and Trust Marks

As described in Section 2.3, this profile recommends the use of Federation Resolvers to resolve peer metadata and Trust Marks. This section defines requirements and recommendations for both Entities implementing a Federation Resolver and Entities using a Federation Resolver.¶

4.1. Federation Resolver Requirements

A Trust Anchor or an Intermediate Entity that provides a federation_resolve_endpoint takes on the role of a Federation Resolver.¶

This section extends the requirements specified in Section 8.3 of [OpenID.Federation] with the following statements:¶

A Federation Resolver MAY include Trust Marks that are not present in an Entity's Entity Configuration. It can do so by communicating directly with a Trust Mark Issuer. This functionality may be useful in cases when Trust Marks are being used as a control mechanism within the federation and Entities within the federation are unaware of a particular Trust Mark type. See Section 5.3.¶

The requirements for the resolve response exp Claim given in Section 8.3.2 of [OpenID.Federation] state that the validity of the response must not exceed the validity of the underlying Trust Chain and of the included Trust Marks. If a Trust Mark instance for the Entity being resolved is either expired or has a validity that is shorter than the validity of the Trust Chain, a Federation Resolver MAY obtain a new Trust Mark instance for the Entity by calling the Trust Mark endpoint at the Trust Mark Issuer. By doing so, the Federation Resolver avoids issuing resolve responses with unnecessarily short validity periods. This reduces the frequency of resolve requests, as longer-lived responses are more amenable to caching by consuming parties.¶

4.2. Using a Federation Resolver

The resolve endpoint, request and response formats are defined in Section 8.3 of [OpenID.Federation].¶

4.2.1. Sending a Resolve Request

An Entity wishing to obtain the resolved metadata and Trust Marks of a peer Entity sends a resolve request to the federation_resolve_endpoint of a trusted Federation Resolver, as described in Section 8.3.1 of [OpenID.Federation].¶

If the caller has prior knowledge of the Trust Anchor under which the subject Entity is registered, it MUST include only that Trust Anchor in the trust_anchor parameter. Including additional Trust Anchor values when the correct one is already known introduces unnecessary ambiguity and SHOULD NOT be done. The trust_anchor parameter may be specified multiple times only when the caller genuinely does not know under which Trust Anchor the subject is registered and wishes to delegate that determination to the resolver.¶

4.2.2. Processing the Resolve Response

If the Federation Resolver is not implemented by the Trust Anchor itself, the caller may need to explicitly configure trust in the resolver. See Section 2.3 for requirements on how Trust Anchors ensure resolver availability and on configuring trust for resolvers that are not hosted by a Trust Anchor.¶

A consumer MUST NOT use a resolve response beyond its validity period as indicated by the exp Claim of the response JWT. The exp value reflects the shortest validity among the underlying Trust Chain and any included Trust Marks.¶

Implementations SHOULD implement caching of resolve responses. A cached response MAY be reused for subsequent requests for the same subject and trust context, that is, the same combination of subject Entity Identifier and Trust Anchor, provided the response has not yet expired. This reduces the frequency of calls to the Federation Resolver and improves overall federation performance. However, it is RECOMMENDED that implementations refresh cached responses before the time indicated by the exp Claim, in order to remain resilient against resolvers being temporarily unavailable and to ensure that metadata changes are propagated more quickly.¶

Although the resolve response includes the Trust Chain in the trust_chain Claim as required by Section 8.3.2 of [OpenID.Federation], most consumers resolving peer metadata for the purpose of establishing protocol-level trust do not need to process or validate the Trust Chain themselves, as the Federation Resolver has already performed this validation. Such consumers MAY ignore the trust_chain Claim in the resolve response.¶

Note: Depending on the federation's Trust Mark Policy, see Section 5.1, the trust_marks Claim of the resolve response might not contain instances for all Trust Marks held by the Entity, see Section 5.3. An Entity consuming resolve responses is expected to be aware of the federation's policy for Trust Marks.¶

5. Trust Marks

5.1. Trust Mark Policy

A Federation Operator SHOULD define a Trust Mark Policy for the federation. Such a Trust Mark Policy SHOULD define:¶

Rules and processes for designating which actors may act as federation-accredited Trust Mark Issuers.¶
Rules and requirements applicable to federation-accredited Trust Mark Issuers. The requirements stated in Section 5.2 apply, but the policy may define additional requirements, such as the authorization criteria that determine whether a Trust Mark can be issued to a given Entity.¶
Rules and processes for defining Trust Mark types recognized by the federation, including which Trust Mark Issuer(s) may issue each Trust Mark type.¶
Rules for Trust Mark type URL identifiers recognized within the federation, ensuring that they are collision-resistant across multiple federations (see Section 7.1 of [OpenID.Federation]).¶
Whether Trust Mark Issuers may issue Trust Mark types that are not recognized federation-wide, for example Trust Marks intended for specific purposes or specific Entity audiences.¶
Whether the policy requires Entities to include held Trust Mark instances in their Entity Configurations and be responsible for keeping them up to date, or whether peer Entities (or resolvers) may obtain Trust Mark instances for specific Entities. Typically, a peer obtains such a Trust Mark instance when it needs to check whether a specific Trust Mark is held by its peer. See Section 5.3, Obtaining and Maintaining Trust Marks.¶

A Trust Mark Policy MAY also define rules or recommendations for the validation of Trust Marks, see Section 7.3 of [OpenID.Federation]. If validation rules are defined, it is RECOMMENDED that these also cover requirements for Trust Mark status checking.¶

Note: Only a federation-accredited Trust Mark Issuer is allowed to issue Trust Mark types that are recognized by the federation. A Trust Mark Issuer is considered federation-accredited when it appears in the trust_mark_issuers Claim of the Trust Anchor's Entity Configuration, as defined in Section 7 of [OpenID.Federation]. This Claim also identifies which Trust Mark types are recognized by the federation, and which Trust Mark Issuers are authorized to issue each type.¶

5.2. Requirements on Trust Mark Issuers

A Federation Service Entity that exposes a Trust Mark endpoint as defined in Section 8.6 of [OpenID.Federation], is a Trust Mark Issuer.¶

For a Trust Mark to be recognized within the federation, the Trust Mark Issuer and the Federation Operator (Trust Anchor) SHOULD establish a bilateral agreement covering both the issuance of the Trust Mark type and its inclusion in the Trust Anchor's trust_mark_issuers Entity Configuration Claim. As part of this agreement, the Federation Operator defines the Trust Mark type identifier to be used.¶

The Trust Mark Issuer is responsible for maintaining a repository of the Entities that are entitled to specific Trust Mark types, including the authorizations and limitations that apply to them. The procedures by which an Entity applies for a Trust Mark, and the procedures used to determine whether a Trust Mark is granted, are outside the scope of this profile.¶

If short-lived Trust Mark instances, that is, JWTs with an exp Claim set to a near-term time, are issued and the federation deployment requires Leaf Entities to include held Trust Mark instances in their Entity Configurations, this has practical consequences, including the following:¶

Leaf Entities have to obtain new Trust Mark instances frequently and update and re-sign their Entity Configurations accordingly.¶
Federation Resolvers will be required to issue resolve responses with short validity periods, since a resolve response cannot exceed the validity of the artefacts it contains, see Section 8.3.2 of [OpenID.Federation]. This limits the ability to cache resolve responses within the federation and increases the number of invocations to Federation Resolvers.¶

Also, in federation deployments where Trust Mark instances are not distributed via Entity Configurations, short-lived instances lead to potentially frequent calls to the Trust Mark endpoint, since cached instances expire quickly.¶

Therefore, the following requirements apply to Trust Mark Issuers that are compliant with this profile:¶

The validity period of a Trust Mark JWT SHOULD be aligned with the validity of the underlying authorization that determines the Entity’s entitlement to the Trust Mark. If that authorization is not time-limited, the Trust Mark Issuer SHOULD NOT include an exp Claim in the Trust Mark JWT.¶
If a Trust Mark Issuer issues Trust Marks without an expiration time, the Trust Mark Issuer MUST expose a Trust Mark Status endpoint, as defined in Section 8.4 of [OpenID.Federation].¶

5.3. Obtaining and Maintaining Trust Marks

An Entity's Entity Configuration MAY contain the Trust Mark instances held by the Entity. An Entity wanting to check whether another Entity holds a specific Trust Mark can either use a resolver, where the peer's resolved metadata and verified Trust Mark instances are delivered in the resolve response, see Section 8.3.2 of [OpenID.Federation], or validate the Trust Mark of its peer according to Section 7.3 of [OpenID.Federation] after building the peer's Trust Chain (see Section 10 of [OpenID.Federation]).¶

The former of the methods above for checking whether a peer Entity possesses a specific Trust Mark, and in some cases also the latter, depends on the Entity including a valid Trust Mark instance in its Entity Configuration.¶

Requiring Entities to keep the Trust Mark instances in their Entity Configurations up to date may be too demanding for some deployments. Every Entity has to obtain a new instance before the current one expires, and then update and re-sign its Entity Configuration.¶

Some Trust Marks may also be of no interest to the Entities themselves. Where Trust Marks are used as a control mechanism within the federation, and the Entities holding them have no knowledge of the Trust Mark type in question, those Entities should not have to maintain the instances themselves.¶

Therefore, this profile also allows for other mechanisms for obtaining Trust Marks:¶

An Entity MAY invoke the Trust Mark endpoint at the Trust Mark Issuer to obtain a Trust Mark instance for a peer Entity whose possession of that Trust Mark it wants to check.¶
A resolver MAY invoke the Trust Mark endpoint at the Trust Mark Issuer to obtain an Entity's Trust Marks and include them in a resolve response.¶

In both scenarios above, the Entities obtaining Trust Marks for other Entities SHOULD use caching to minimize the number of calls to the Trust Mark Issuer's endpoint.¶

For Entities that include long-lived Trust Marks, or Trust Marks with no expiration, in their Entity Configurations, it is RECOMMENDED that such Trust Marks are periodically renewed or have their status checked. The reason for this recommendation is to account for possible changes of signing keys at the Trust Mark Issuer.¶

A federation's Trust Mark Policy, see Section 5.1, SHOULD include rules for how Trust Marks are distributed and obtained. Such a policy MAY allow some Trust Marks to be obtained by peers, while requiring others to be maintained by the Entities that hold them.¶

7. Adapting OAuth 2.0 and OpenID Connect for OpenID Federation

This document is a profile for OpenID Federation and should refrain from introducing protocol-specific requirements for the use of OAuth 2.0 and OpenID Connect. Such requirements should be addressed in protocol-specific standards and profiles.¶

However, OAuth 2.0 and OpenID Connect predate the introduction of OpenID Federation, and some concepts of these protocols do not mix naturally with a federated environment.¶

Both OAuth 2.0 and OpenID Connect assume that there is a registration phase in which the client (an OAuth 2.0 Client or OpenID Connect Relying Party) registers at the server (an OAuth 2.0 Authorization Server or OpenID Connect OpenID Provider), and the parameters needed for future protocol exchanges are negotiated based on the server's capabilities and policies and the client's requirements. The client metadata returned in a registration response therefore reflects what has been approved by the Authorization Server or OpenID Provider.¶

In an OpenID Federation context, the client instead presents its metadata to the federation, and the server consumes that metadata after resolving the client's Entity Statement. While Section 12 of [OpenID.Federation] defines methods for registering a Relying Party at an OpenID Provider, the metadata made available to the federation still needs to be generic, since it will presumably be consumed by multiple OpenID Providers and Authorization Servers.¶

"OpenID Connect Relying Party Metadata Choices 1.0" [OpenID.RP.Choices] addresses the above issues for OpenID Connect, and to some extent also for OAuth 2.0: a Relying Party can declare all the choices it supports for metadata parameters, allowing the OpenID Provider to use these values during client registration.¶

For federation deployments based on this profile, it is RECOMMENDED that support for the parameters defined in [OpenID.RP.Choices] be mandatory for federation participants.¶

A federation deployment that does not mandate support for [OpenID.RP.Choices] SHOULD at least address the following areas in its federation rules:¶

Mandatory Algorithm Support

In both OAuth 2.0 and OpenID Connect, a client or Relying Party declares one algorithm in its registration data for each specific usage. For example, token_endpoint_auth_signing_alg [OpenID.Registration] declares which signature algorithm a Relying Party uses when signing a JWT for authentication at the OpenID Provider token endpoint. The Relying Party selects a suitable algorithm based on the token_endpoint_auth_signing_alg_values_supported value in the OpenID Provider's Discovery Document [OpenID.Discovery].

In a federation, where a client's metadata may be consumed by several peers, this approach breaks down, since different servers (Authorization Servers or OpenID Providers) may support different sets of algorithms, and the intersection of those sets may be empty.

To handle this problem without the aid of the parameters defined in [OpenID.RP.Choices], federation rules need to contain a list of algorithms that are mandatory for federation participants to support. Such a list MUST cover:¶

A set of algorithms that are mandatory to support for validation of signatures. RECOMMENDED algorithms are:¶
- RS256, RSASSA-PKCS1-v1_5 using SHA-256, as defined in Section 3.3 of [RFC7518].¶
- RS384, RSASSA-PKCS1-v1_5 using SHA-384, as defined in Section 3.3 of [RFC7518].¶
- RS512, RSASSA-PKCS1-v1_5 using SHA-512, as defined in Section 3.3 of [RFC7518].¶
- ES256, ECDSA using P-256 and SHA-256, as defined in Section 3.4 of [RFC7518].¶
- ES384, ECDSA using P-384 and SHA-384, as defined in Section 3.4 of [RFC7518].¶
- ES512, ECDSA using P-521 and SHA-512, as defined in Section 3.4 of [RFC7518].¶
A set of algorithms that are mandatory to support for asymmetric encryption. RECOMMENDED algorithms are:¶
- RSA-OAEP, RSAES OAEP using default parameters, as defined in Section 4.3 of [RFC7518].¶
- RSA-OAEP-256, RSAES OAEP using SHA-256 and MGF1 with SHA-256, as defined in Section 4.3 of [RFC7518].¶
- ECDH-ES, ECDH Ephemeral Static direct key agreement, as defined in Section 4.6 of [RFC7518].¶
Algorithms that an Entity holding an RSA protocol key needs to support for decryption. RECOMMENDED algorithms are:¶
- RSA-OAEP, RSAES OAEP using default parameters, as defined in Section 4.3 of [RFC7518].¶
- RSA-OAEP-256, RSAES OAEP using SHA-256 and MGF1 with SHA-256, as defined in Section 4.3 of [RFC7518].¶
Algorithms that an Entity holding an EC protocol key needs to support for decryption. The RECOMMENDED algorithm is:¶
- ECDH-ES, ECDH Ephemeral Static direct key agreement, as defined in Section 4.6 of [RFC7518].¶

Interoperability Requirements for Client Authentication Methods

Similarly to algorithms, the token_endpoint_auth_method parameter [RFC7591][OpenID.Registration] can hold only one value. In a federation, a single set of client metadata may be resolved and consumed by any number of servers. If support for the token_endpoint_auth_methods_supported parameter, as defined in Section 2 of [OpenID.RP.Choices], is not mandated, this may cause interoperability problems if two servers that the client needs to interact with have different and non-overlapping requirements for client authentication, as the client would be unable to satisfy both simultaneously.

It is RECOMMENDED that the Federation Operator define requirements for which client authentication methods OAuth 2.0 Authorization Servers and OpenID Connect OpenID Providers should support, in order to avoid such interoperability problems.
¶

Requirements for OpenID Connect Subject Types

Section 2 of [OpenID.Registration] defines the subject_type metadata parameter, which is used by an OpenID Connect Relying Party to declare whether it requires subject identifiers in tokens to be public or pairwise. Correspondingly, an OpenID Provider's Discovery metadata contains the subject_types_supported parameter [OpenID.Discovery], listing the subject types the OpenID Provider supports. If OpenID Providers within the federation do not support both types, interoperability issues may arise. It is RECOMMENDED that the Federation Operator, via referenced profiles or federation rules, require OpenID Providers to support both the public and pairwise subject types.
¶

7.1. OAuth 2.0 Considerations

"OpenID Connect Relying Party Metadata Choices 1.0" [OpenID.RP.Choices] defines client metadata parameters in which an OpenID Connect Relying Party can declare a set of supported values, instead of only one, for existing parameters. This addresses the problems discussed in the previous section. However, [OpenID.RP.Choices] does not address OAuth 2.0-specific issues, where the scope parameter [RFC7591] needs special attention.¶

An Authorization Server declares its supported scopes using the scopes_supported parameter [RFC8414], and an OAuth 2.0 client's metadata may contain a scope parameter [RFC7591] listing the scopes it intends to use when requesting tokens. In a non-federation deployment, these scopes may have been authorized as part of the registration process and are often set by the Authorization Server in response to the client registration. In an OpenID Federation deployment, other mechanisms are needed to establish trust in such scope declarations.¶

Furthermore, in a peer-to-peer registration, any scopes referenced are in the context of that specific registration. In an OpenID Federation deployment, generic scope values such as read or write may be ambiguous, since a client may interact with multiple Authorization Servers. One approach to mitigating this is to use unique scope values mapped to specific resources or functions.¶