OpenID Connect Working Group R. Hedberg independent M.B. Jones, Ed. Self-Issued Consulting G. De Marco independent A.Å. Solberg Sikt J. Bradley Yubico V. Dzhuvinov Connect2id 15 February 2026 OpenID Federation 1.1 - draft 03 openid-federation-1_1 Abstract A federation can be expressed as an agreement between parties that trust each other. In bilateral federations, direct trust can be established between two organizations belonging to the same federation. In a multilateral federation, bilateral agreements might not be practical, in which case, trust can be mediated by a third party. That is the model used in this specification. An Entity in the federation must be able to trust that other Entities it interacts with belong to the same federation. It must also be able to trust that the information the other Entities publish about themselves has not been tampered with during transport and that it adheres to the federation's policies. This specification contains the protocol-independent functionality defined in OpenID Federation 1.0. This includes Entity Statements, Trust Chains, Metadata, Policies, Trust Marks, and Federation Endpoints. These can be used in multilateral federations for the purpose of establishing trust, in combination with the protocol- specific functionality defined by specifications such as OpenID Federation for OpenID Connect 1.1. This specification introduces no new functionality not present in OpenID Federation 1.0. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation and Conventions . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2. Overall Architecture . . . . . . . . . . . . . . . . . . . . 10 Hedberg, et al. Standards Track [Page 1] OpenID Federation 1.1 February 2026 2.1. Cryptographic Trust Mechanism . . . . . . . . . . . . . . 11 3. Entity Statement . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Entity Statement Claims . . . . . . . . . . . . . . . . . 12 3.1.1. Claims that MUST or MAY Appear in both Entity Configurations and Subordinate Statements . . . . . . 12 3.1.2. Claims that MUST or MAY Appear in Entity Configurations but Not in Subordinate Statements . . . . . . . . . . 13 3.1.3. Claims that MUST or MAY Appear in Subordinate Statements but Not in Entity Configurations . . . . . 15 3.2. Entity Statement Validation . . . . . . . . . . . . . . . 16 3.3. Entity Statement Example . . . . . . . . . . . . . . . . 19 4. Trust Chain . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. Beginning and Ending Trust Chains . . . . . . . . . . . . 21 4.2. Trust Chain Example . . . . . . . . . . . . . . . . . . . 22 4.3. Trust Chain Header Parameter . . . . . . . . . . . . . . 24 4.4. Peer Trust Chain Header Parameter . . . . . . . . . . . . 25 5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Entity Type Identifiers . . . . . . . . . . . . . . . . . 25 5.1.1. Federation Entity . . . . . . . . . . . . . . . . . . 26 5.2. Common Metadata Parameters . . . . . . . . . . . . . . . 27 5.2.1. Parameters for JWK Sets in Entity Metadata . . . . . 28 5.2.1.1. Usage of jwks, jwks_uri, and signed_jwks_uri in Entity Metadata . . . . . . . . . . . . . . . . . . 30 5.2.2. Informational Metadata Parameters . . . . . . . . . . 30 6. Federation Policy . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Metadata Policy . . . . . . . . . . . . . . . . . . . . . 31 6.1.1. Principles . . . . . . . . . . . . . . . . . . . . . 32 6.1.2. Structure . . . . . . . . . . . . . . . . . . . . . . 33 6.1.3. Operators . . . . . . . . . . . . . . . . . . . . . . 34 6.1.3.1. Standard Operators . . . . . . . . . . . . . . . 36 6.1.3.1.1. value . . . . . . . . . . . . . . . . . . . . 36 6.1.3.1.2. add . . . . . . . . . . . . . . . . . . . . . 36 6.1.3.1.3. default . . . . . . . . . . . . . . . . . . . 37 6.1.3.1.4. one_of . . . . . . . . . . . . . . . . . . . 38 6.1.3.1.5. subset_of . . . . . . . . . . . . . . . . . . 39 6.1.3.1.6. superset_of . . . . . . . . . . . . . . . . . 40 6.1.3.1.7. essential . . . . . . . . . . . . . . . . . . 40 6.1.3.1.8. Notes on Operators . . . . . . . . . . . . . 41 6.1.3.2. Additional Operators . . . . . . . . . . . . . . 42 6.1.4. Enforcement . . . . . . . . . . . . . . . . . . . . . 43 6.1.4.1. Resolution . . . . . . . . . . . . . . . . . . . 43 6.1.4.2. Application . . . . . . . . . . . . . . . . . . . 45 6.1.5. Metadata Policy Example . . . . . . . . . . . . . . . 46 6.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.1. Max Path Length Constraint . . . . . . . . . . . . . 52 6.2.2. Naming Constraints . . . . . . . . . . . . . . . . . 53 6.2.3. Entity Type Constraints . . . . . . . . . . . . . . . 53 7. Trust Marks . . . . . . . . . . . . . . . . . . . . . . . . . 54 Hedberg, et al. Standards Track [Page 2] OpenID Federation 1.1 February 2026 7.1. Trust Mark Claims . . . . . . . . . . . . . . . . . . . . 54 7.2. Trust Mark Delegation . . . . . . . . . . . . . . . . . . 56 7.2.1. Trust Mark Delegation JWT . . . . . . . . . . . . . . 57 7.2.2. Validating a Trust Mark Delegation . . . . . . . . . 57 7.3. Validating a Trust Mark . . . . . . . . . . . . . . . . . 58 7.4. Trust Mark Examples . . . . . . . . . . . . . . . . . . . 60 7.5. Trust Mark Delegation Example . . . . . . . . . . . . . . 64 8. Federation Endpoints . . . . . . . . . . . . . . . . . . . . 65 8.1. Fetching a Subordinate Statement . . . . . . . . . . . . 65 8.1.1. Fetch Subordinate Statement Request . . . . . . . . . 65 8.1.2. Fetch Subordinate Statement Response . . . . . . . . 66 8.2. Subordinate Listing . . . . . . . . . . . . . . . . . . . 68 8.2.1. Subordinate Listing Request . . . . . . . . . . . . . 69 8.2.2. Subordinate Listing Response . . . . . . . . . . . . 71 8.3. Resolve Entity . . . . . . . . . . . . . . . . . . . . . 71 8.3.1. Resolve Request . . . . . . . . . . . . . . . . . . . 71 8.3.2. Resolve Response . . . . . . . . . . . . . . . . . . 72 8.3.3. Trust Considerations . . . . . . . . . . . . . . . . 76 8.4. Trust Mark Status . . . . . . . . . . . . . . . . . . . . 76 8.4.1. Trust Mark Status Request . . . . . . . . . . . . . . 76 8.4.2. Trust Mark Status Response . . . . . . . . . . . . . 77 8.5. Trust Marked Entities Listing . . . . . . . . . . . . . . 79 8.5.1. Trust Marked Entities Listing Request . . . . . . . . 79 8.5.2. Trust Marked Entities Listing Response . . . . . . . 80 8.6. Trust Mark Endpoint . . . . . . . . . . . . . . . . . . . 81 8.6.1. Trust Mark Request . . . . . . . . . . . . . . . . . 81 8.6.2. Trust Mark Response . . . . . . . . . . . . . . . . . 81 8.7. Federation Historical Keys Endpoint . . . . . . . . . . . 82 8.7.1. Federation Historical Keys Request . . . . . . . . . 82 8.7.2. Federation Historical Keys Response . . . . . . . . . 83 8.7.3. Federation Historical Keys Revocation Reasons . . . . 85 8.7.4. Rationale for the Federation Historical Keys Endpoint . . . . . . . . . . . . . . . . . . . . . . 86 8.8. Client Authentication at Federation Endpoints . . . . . . 87 8.8.1. Client Authentication Metadata for Federation Endpoints . . . . . . . . . . . . . . . . . . . . . . 87 8.9. Error Responses . . . . . . . . . . . . . . . . . . . . . 88 9. Obtaining Federation Entity Configuration Information . . . . 90 9.1. Federation Entity Configuration Request . . . . . . . . . 90 9.2. Federation Entity Configuration Response . . . . . . . . 91 10. Resolving the Trust Chain and Metadata . . . . . . . . . . . 93 10.1. Fetching Entity Statements to Establish a Trust Chain . 93 10.2. Validating a Trust Chain . . . . . . . . . . . . . . . . 95 10.3. Choosing One of the Valid Trust Chains . . . . . . . . . 96 10.4. Calculating the Expiration Time of a Trust Chain . . . . 96 10.5. Transient Trust Chain Validation Errors . . . . . . . . 96 10.6. Resolving the Trust Chain and Metadata with a Resolver . . . . . . . . . . . . . . . . . . . . . . . . 97 Hedberg, et al. Standards Track [Page 3] OpenID Federation 1.1 February 2026 11. Updating Metadata, Key Rollover, and Revocation . . . . . . . 97 11.1. Federation Key Rollover . . . . . . . . . . . . . . . . 97 11.2. Key Rollover for a Trust Anchor . . . . . . . . . . . . 97 11.3. Redundant Retrieval of Trust Anchor Keys . . . . . . . . 98 11.4. Revocation . . . . . . . . . . . . . . . . . . . . . . . 98 12. OpenID Connect Client Registration . . . . . . . . . . . . . 98 13. General-Purpose JWT Claims . . . . . . . . . . . . . . . . . 98 13.1. "jwks" (JSON Web Key Set) Claim . . . . . . . . . . . . 98 13.2. "metadata" Claim . . . . . . . . . . . . . . . . . . . . 99 13.3. "constraints" Claim . . . . . . . . . . . . . . . . . . 99 13.4. "crit" (Critical) Claim . . . . . . . . . . . . . . . . 99 13.5. "ref" (Reference) Claim . . . . . . . . . . . . . . . . 100 13.6. "delegation" Claim . . . . . . . . . . . . . . . . . . . 100 13.7. "logo_uri" (Logo URI) Claim . . . . . . . . . . . . . . 100 14. Claims Languages and Scripts . . . . . . . . . . . . . . . . 101 15. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 101 15.1. "application/entity-statement+jwt" Media Type . . . . . 101 15.2. "application/trust-mark+jwt" Media Type . . . . . . . . 101 15.3. "application/resolve-response+jwt" Media Type . . . . . 101 15.4. "application/trust-chain+json" Media Type . . . . . . . 101 15.5. "application/trust-mark-delegation+jwt" Media Type . . . 102 15.6. "application/jwk-set+jwt" Media Type . . . . . . . . . . 102 15.7. "application/trust-mark-status-response+jwt" Media Type . . . . . . . . . . . . . . . . . . . . . . . . . . 102 16. String Operations . . . . . . . . . . . . . . . . . . . . . . 102 17. Implementation Considerations . . . . . . . . . . . . . . . . 103 17.1. Federation Topologies . . . . . . . . . . . . . . . . . 103 17.2. Federation Discovery and Trust Chain Resolution Patterns . . . . . . . . . . . . . . . . . . . . . . . . 104 17.2.1. Bottom-Up Trust Chain Resolution . . . . . . . . . . 105 17.2.2. Top-Down Discovery . . . . . . . . . . . . . . . . . 106 17.2.3. Single Point of Trust Resolution . . . . . . . . . . 107 17.3. Trust Anchors and Resolvers Go Together . . . . . . . . 108 17.4. One Entity, One Service . . . . . . . . . . . . . . . . 108 17.5. Trust Mark Policies . . . . . . . . . . . . . . . . . . 108 18. Security Considerations . . . . . . . . . . . . . . . . . . . 109 18.1. Denial-of-Service Attack Prevention . . . . . . . . . . 109 18.2. Unsigned Error Messages . . . . . . . . . . . . . . . . 110 19. Privacy Considerations . . . . . . . . . . . . . . . . . . . 110 19.1. Entity Statement Privacy Considerations . . . . . . . . 110 19.2. Trust Mark Status Privacy Considerations . . . . . . . . 110 19.3. Fetch Endpoint Privacy Considerations . . . . . . . . . 111 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 111 21.1. Normative References . . . . . . . . . . . . . . . . . . 111 21.2. Informative References . . . . . . . . . . . . . . . . . 113 Appendix A. Examples Building and Using Trust Chains . . . . . . 114 Appendix B. Notices . . . . . . . . . . . . . . . . . . . . . . 114 Hedberg, et al. Standards Track [Page 4] OpenID Federation 1.1 February 2026 Appendix C. Document History . . . . . . . . . . . . . . . . . . 115 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 116 OpenID Federation 1.1 Acknowledgements . . . . . . . . . . . . 116 OpenID Federation 1.0 Acknowledgements . . . . . . . . . . . . 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116 1. Introduction This specification describes how two Entities that would like to interact can establish trust between them by means of a trusted third party called a Trust Anchor. A Trust Anchor is an Entity whose main purpose is to issue statements about Entities. An identity federation can be realized using this specification using one or more levels of authorities. Examples of authorities are federation operators, organizations, departments within organizations, and individual sites. This specification provides the basic technical trust infrastructure building blocks needed to create a dynamic and distributed trust network, such as a federation. This trust infrastructure can be used with any application protocol. Protocol-specific bindings to the functionality defined by this specification are defined in other specifications, such as the OpenID Federation for OpenID Connect 1.1 [OpenID.Federation.Connect-1.1] specification, which defines protocol-specific functionality for use with OpenID Connect Core 1.0 [OpenID.Core] and OAuth 2.0 [RFC6749] deployments. Note that this specification only concerns itself with how Entities in a federation get to know about each other. An organization MAY be represented by more than one Entity in a federation. An Entity MAY also belong to more than one federation. Determining that two Entities belong to the same federation is the basis for establishing trust between them in this specification. Of course, the word "trust" is also used in the vernacular to encompass confidence in the security, reliability, and integrity of entities and their actions. This kind trust is often established through empirical proof, such as past performance, security certifications, or transparent operational practices, which demonstrate a track record of adherence to security standards and ethical conduct. To be clear, this broader meaning of trust, while important, is largely beyond the scope of what this specification accomplishes. Below is an example of two federations rooted at two different Trust Anchors with some members in common. Every Entity is able to establish mutual trust with any other Entity by means of having at least one common Trust Anchor between them. These abbreviations are Hedberg, et al. Standards Track [Page 5] OpenID Federation 1.1 February 2026 used in the diagram: OpenID Provider (OP), Relying Party (RP), Resource Server (RS), and Authorization Server (AS). .-----------------. .-----------------. | Trust Anchor A | | Trust Anchor B | '------.--.-------' '----.--.--.------' | | | | | .--' '---. .-------------------' | | | | | | | .---v. .-----v-v------. .-----------' | | OP | | Intermediate | | | '----' '--.--.--.-----' | .---------v----. | | | | | Intermediate | .-------' | '------. | '---.--.--.----' | | | | | | | .--v-. .-v--. .v--v. .---' | '----. | RP | | RS | | OP | | | | '----' '----' '----' | .--v-. .-v--. | | RP | | RP | | '----' '----' | .-------v------. | Intermediate | '----.--.--.---' | | | .-----' | '----. | | | .--v-. .--v-. .-v--. | OP | | RP | | AS | '----' '----' '----' Figure 1: Two Coexisting Federations with Some Members in Common 1.1. Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. All uses of JSON Web Signature (JWS) [RFC7515] and JSON Web Encryption (JWE) [RFC7516] data structures in this specification utilize the JWS Compact Serialization or the JWE Compact Serialization; the JWS JSON Serialization and the JWE JSON Serialization are not used. Hedberg, et al. Standards Track [Page 6] OpenID Federation 1.1 February 2026 1.2. Terminology This specification uses the terms "Claim", "Claim Name", "Claim Value", "JSON Web Token (JWT)", and "JWT Claims Set" defined by JSON Web Token (JWT) [RFC7519], the terms "OpenID Provider (OP)" and "Relying Party (RP)" defined by OpenID Connect Core 1.0 [OpenID.Core], and the terms "Authorization Server (AS)", "Client", "Client Authentication", "Protected Resource", "Resource Server (RS)", and "Token Endpoint" defined by OAuth 2.0 [RFC6749]. This specification also defines the following terms: Entity Something that has a separate and distinct existence and that can be identified in a context. Entity Identifier A globally unique string identifier that is bound to one Entity. All Entity Identifiers defined by this specification are URLs that use the https scheme, have a host component, and MAY contain port and path components. It MUST NOT contain query parameter or fragment components. Profiles of this specification MAY define other kinds of Entity Identifiers and processing rules that accompany them. Trust Anchor An Entity that represents a trusted third party. Federation Entity An Entity for which it is possible to construct a Trust Chain from the Entity to a Trust Anchor. Entity Statement A signed JWT that contains the information needed for an Entity to participate in federation(s), including metadata about itself and policies that apply to other Entities for which it is authoritative. Entity Configuration An Entity Statement issued by an Entity about itself. It contains the Entity's signing keys and further data used to control the Trust Chain resolution process, such as authority hints. Subordinate Statement An Entity Statement issued by a Superior Entity about an Entity that is its Immediate Subordinate. Hedberg, et al. Standards Track [Page 7] OpenID Federation 1.1 February 2026 Entity Type A role and function that an Entity plays within a federation. An Entity MUST be of at least one type and MAY be of many types. For example, an Entity can be both an OpenID Provider and Relying Party at the same time. Entity Type Identifier String identifier for an Entity Type. Federation Operator An organization that is authoritative for a federation. A federation operator administers the Trust Anchor(s) for Entities in its federation. Intermediate Entity An Entity that issues an Entity Statement appearing somewhere in between those issued by the Trust Anchor and the subject of a Trust Chain (which is typically a Leaf Entity). The terms Intermediate Entity and Intermediate are used interchangeably in this specification. Leaf Entity An Entity with no Subordinate Entities. Leaf Entities typically play a protocol role, such as an OpenID Connect Relying Party or OpenID Provider. The terms Leaf Entity and Leaf are used interchangeably in this specification. Subordinate Entity An Entity that is somewhere below a Superior Entity (a Trust Anchor or Intermediate) in the trust hierarchy, possibly with Intermediates between them. The terms Subordinate Entity and Subordinate are used interchangeably in this specification. Superior Entity An Entity that is somewhere above one or more Entities (a Leaf or Intermediate) in the trust hierarchy, possibly with Intermediates between them. The terms Superior Entity and Superior are used interchangeably in this specification. Immediate Subordinate Entity An Entity that is immediately below a Superior Entity in the trust hierarchy, with no Intermediates between them. The terms Immediate Subordinate Entity and Immediate Subordinate are used interchangeably in this specification. Hedberg, et al. Standards Track [Page 8] OpenID Federation 1.1 February 2026 Immediate Superior Entity An Entity that is immediately above one or more Subordinate Entities in the trust hierarchy, with no Intermediates between them. The terms Immediate Superior Entity and Immediate Superior are used interchangeably in this specification. Federation Entity Discovery A process that starts with the Entity Identifier for the subject of the Trust Chain and collects Entity Statements until the chosen Trust Anchor is reached. From the collected Entity Statements, a Trust Chain is constructed and verified. The result of the Federation Entity Discovery is that the metadata for the Trust Chain subject is constructed from the Trust Chain. Trust Chain A sequence of Entity Statements that represents a chain starting at an Entity Configuration that is the subject of the chain (typically of a Leaf Entity) and ending in a Trust Anchor. Trust Mark Statement of conformance to a well-scoped set of trust and/or interoperability requirements as determined by an accreditation authority. Each Trust Mark has a Trust Mark type identifier. Trust Mark Issuer A Federation Entity that issues Trust Marks. Trust Mark Owner An Entity that owns the right to a Trust Mark type identifier. Federation Entity Keys Keys used for the cryptographic signatures required by the trust mechanisms defined in this specification. Every participant in a Federation publishes its public Federation Entity Keys in its Entity Configuration. Resolved Metadata The metadata that results from applying the metadata policy in the Trust Chain to the metadata in the Entity Configuration for the subject of the Trust Chain. The Resolved Metadata is the metadata that is used when interacting with the Entity. Hedberg, et al. Standards Track [Page 9] OpenID Federation 1.1 February 2026 2. Overall Architecture The basic component is the Entity Statement, which is a cryptographically signed JSON Web Token (JWT) [RFC7519]. A set of Entity Statements can form a path from an Entity (typically a Leaf Entity) to a Trust Anchor. Entity Configurations issued by Entities about themselves control the Trust Chain resolution process. The Entity Configuration of a Leaf or Intermediate Entity contains one or more references to its Immediate Superiors in the authority_hints parameter described in Section 3.1.2. These references can be used to download the Entity Configuration of each Immediate Superior. One or more Entity Configurations are traversed during the Federation Entity Discovery until the Trust Anchor is reached. The Trust Anchor and its Intermediates issue Entity Statements about their Immediate Subordinate Entities called Subordinate Statements. The sequence of Entity Configurations and Subordinate Statements that validate the relationship between a Superior and a Subordinate, along a path towards the Trust Anchor, forms the proof that the subject of Trust Chain (typically a Leaf Entity) is a member of the federation rooted at the Trust Anchor. The Trust Chain that links the Entity Configurations to one another is verified with the signature of each Entity Configuration, as described in Section 4. Once there is a verified Trust Chain, the federation policy is applied and the metadata for the Trust Chain subject within the Federation is derived, as described in Section 6. This specification deals with trust operations; it does not cover or touch operations of specific protocols using the trust operations, other than enabling metadata derivation and exchange for use by those protocols. OpenID Connect constructs are used in many of the examples in this specification, however this does not mean that this specification can only be used with OpenID Connect. On the contrary, it can also be used to build federations for other protocols. Hedberg, et al. Standards Track [Page 10] OpenID Federation 1.1 February 2026 2.1. Cryptographic Trust Mechanism The objects defined by this specification that are used to establish cryptographic trust between participants are secured as signed JWTs using public key cryptography. In particular, the keys used for securing these objects are managed by the Entities controlling those objects, with the public keys securing them being distributed through those objects themselves. This kind of trust mechanism has been utilized by research and academic federations for over a decade. Note that this cryptographic trust mechanism intentionally does not rely on Web PKI / TLS [RFC9525] certificates for signing keys. Which TLS certificates are considered trusted can vary considerably between systems depending upon which certificate authorities are considered trusted and there have been notable examples of ostensibly trusted certificates being compromised. For those reasons, this specification explicitly eschews reliance on Web PKI in favor of self-managed public keys, in this case, keys represented as JSON Web Keys (JWKs) [RFC7517]. 3. Entity Statement An Entity Statement contains the information needed for the Entity that is the subject of the Entity Statement to participate in federation(s). An Entity Statement is a signed JWT. The subject of the JWT is the Entity itself. The issuer of the JWT is the party that issued the Entity Statement. All Entities in a federation publish an Entity Statement about themselves called an Entity Configuration. Superior Entities in a federation publish Entity Statements about their Immediate Subordinate Entities called Subordinate Statements. Entity Statement JWTs MUST be explicitly typed, by setting the typ header parameter to entity-statement+jwt to prevent cross-JWT confusion, per Section 3.11 of [RFC8725]. Entity Statements without a typ header parameter or with a different typ value MUST be rejected. The Entity Statement is signed using one of the private keys of the issuer Entity in the form of a JSON Web Signature (JWS) [RFC7515]. Federations SHOULD specify mandatory-to-implement signing algorithms. Note that a Trust Chain can contain Entity Statements signed using different signing algorithms, as long as each signature uses a signature algorithm supported by the trust framework and implementations in use. Entity Statement JWTs MUST include the kid (Key ID) header parameter with its value being the Key ID of the signing key used. Hedberg, et al. Standards Track [Page 11] OpenID Federation 1.1 February 2026 3.1. Entity Statement Claims The Claims in an Entity Statement are listed below. Applications and protocols utilizing Entity Statements MAY specify and use additional Claims. 3.1.1. Claims that MUST or MAY Appear in both Entity Configurations and Subordinate Statements iss REQUIRED. The Entity Identifier of the issuer of the Entity Statement. If the iss and the sub are identical, the issuer is making an Entity Statement about itself called an Entity Configuration. sub REQUIRED. The Entity Identifier of the subject. iat REQUIRED. Number. Time when this statement was issued. This is expressed as Seconds Since the Epoch, per [RFC7519]. exp REQUIRED. Number. Expiration time after which the statement MUST NOT be accepted for processing. This is expressed as Seconds Since the Epoch, per [RFC7519]. jwks REQUIRED for all Subordinate Statements, REQUIRED for all Entity Configurations of Trust Anchors and Intermediate Entities, and also REQUIRED for all Entity Configurations of Leaf Entities not using a profile permitting it to be absent. Its value is a JSON Web Key Set (JWKS) [RFC7517] representing the public part of the subject's Federation Entity signing keys. The corresponding private key is used by the Entity to sign the Entity Configuration about itself, by Trust Anchors and Intermediate Entities to sign Subordinate Statements about their Immediate Subordinates, and for other signatures made by Federation Entities, such as Trust Mark signatures. Every JWK in the JWK Set MUST have a unique kid (Key ID) value. It is RECOMMENDED that the Key ID be the JWK Thumbprint [RFC7638] using the SHA-256 hash function of the key. These Federation Entity Keys SHOULD NOT be used in other protocols. (Keys to be used in other protocols, such as OpenID Connect, are conveyed in the metadata elements for the protocol's Entity Type Identifiers, such as the metadata under the openid_provider and openid_relying_party Entity Type Identifiers, which are defined in [OpenID.Federation.Connect-1.1].) Hedberg, et al. Standards Track [Page 12] OpenID Federation 1.1 February 2026 metadata OPTIONAL. JSON object that declares roles that the Entity plays - its Entity Types - and that contains metadata for those Entity Types. Each member name of the JSON object is an Entity Type Identifier, and each value MUST be a JSON object containing metadata parameters according to the metadata schema of the Entity Type. When an Entity participates in a federation or federations with one or more Entity Types, its Entity Configuration MUST contain a metadata Claim with JSON object values for each of the corresponding Entity Type Identifiers, even if the values are the empty JSON object {} (when the Entity Type has no associated metadata or Immediate Superiors supply any needed metadata). An Immediate Superior MAY provide selected or all metadata parameters for an Immediate Subordinate, by using the metadata Claim in a Subordinate Statement. When metadata is used in a Subordinate Statement, it applies only to those Entity Types that are present in the subject's Entity Configuration. Furthermore, the metadata applies only to the subject of the Subordinate Statement and has no effect on the subject's Subordinates. Metadata parameters in a Subordinate Statement have precedence and override identically named parameters under the same Entity Type in the subject's Entity Configuration. If both metadata and metadata_policy appear in a Subordinate Statement, then the stated metadata MUST be applied before the metadata_policy, as described in Section 6.1.4.2. crit OPTIONAL. Entity Statements require that the crit (critical) Claim defined in Section 13.4 be understood and processed. Claims in the Entity Statement whose Claim Names are in the array that is the value of this Claim MUST be understood and processed. Claims specified for use in Entity Statements by this specification MUST NOT be included in the list. 3.1.2. Claims that MUST or MAY Appear in Entity Configurations but Not in Subordinate Statements authority_hints OPTIONAL. An array of strings representing the Entity Identifiers of Intermediate Entities or Trust Anchors that are Immediate Superiors of the Entity. This Claim is REQUIRED in Entity Configurations of the Entities that have at least one Superior above them, such as Leaf and Intermediate Entities. Its value MUST contain the Entity Identifiers of its Immediate Superiors and MUST NOT be the empty array []. This Claim MUST NOT be present in Hedberg, et al. Standards Track [Page 13] OpenID Federation 1.1 February 2026 Entity Configurations of Trust Anchors with no Superiors. trust_anchor_hints OPTIONAL. An array of strings representing the Entity Identifiers of Trust Anchors trusted by the Entity. Its value MUST NOT be the empty array []. This Claim MUST NOT be present in Entity Configurations of Trust Anchors with no Superiors. trust_marks OPTIONAL. An array of JSON objects, each representing a Trust Mark. trust_mark_type REQUIRED. Identifier for the type of the Trust Mark. The value of this Claim MUST be the same as the value of the trust_mark_type Claim contained in the Trust Mark JWT that is the value of the trust_mark Claim in this object. trust_mark REQUIRED. A signed JSON Web Token that represents a Trust Mark. Trust Marks are described in Section 7. trust_mark_issuers OPTIONAL. A Trust Anchor MAY use this Claim to tell which combination of Trust Mark type identifiers and issuers are trusted by the federation. This Claim MUST be ignored if present in an Entity Configuration for an Entity that is not a Trust Anchor. It is a JSON object with member names that are Trust Mark type identifiers and each corresponding value being an array of Entity Identifiers that are trusted to represent the accreditation authority for Trust Marks with that identifier. If the array following a Trust Mark type identifier is empty, anyone MAY issue Trust Marks with that identifier. Trust Marks are described in Section 7. trust_mark_owners OPTIONAL. If a Federation Operator knows that a Trust Mark type identifier is owned by an Entity different from the Trust Mark Issuer, then that knowledge MUST be expressed in this Claim. This Claim MUST be ignored if present in an Entity Configuration for an Entity that is not a Trust Anchor. It is a JSON object with member names that are Trust Mark type identifiers and each corresponding value being a JSON object with these members: sub REQUIRED Identifier of the Trust Mark Owner. Hedberg, et al. Standards Track [Page 14] OpenID Federation 1.1 February 2026 jwks REQUIRED JSON Web Key Set (JWKS) [RFC7517] containing the owner's Federation Entity Keys used for signing. Other members MAY also be defined and used. 3.1.3. Claims that MUST or MAY Appear in Subordinate Statements but Not in Entity Configurations constraints OPTIONAL. JSON object that defines Trust Chain constraints, as described in Section 6.2. The constraints apply to the Entity that is the subject of this Subordinate Statement as well as to all Entities that are Subordinate to it. metadata_policy OPTIONAL. JSON object that defines a metadata policy, as described in Section 6.1. The metadata policy applies to the Entity that is the subject of this Subordinate Statement as well as to all Entities that are Subordinate to it. Applying to Subordinate Entities distinguishes metadata_policy from metadata, which only applies to the subject itself. metadata_policy_crit OPTIONAL. Array of strings specifying critical metadata policy operators other than the standard ones defined in Section 6.1.3.1 that MUST be understood and processed. When included its value MUST NOT be the empty array []. If any of the listed policy operators are not understood and supported, then the Subordinate Statement and thus the Trust Chain that includes it MUST be considered invalid. source_endpoint OPTIONAL. String containing the fetch endpoint URL from which the Entity Statement was issued, as specified in Section 8.1. This parameter enables an optimized refresh of the Subordinate Statements and hence the Trust Chain, by skipping the request to the Entity Configuration that is normally required to discover the federation_fetch_endpoint of the issuing authority. If an Entity Statement cannot be retrieved from the source_endpoint, which can occur if the endpoint URL has changed, the current federation_fetch_endpoint location can be determined by retrieving the Entity Configuration of the issuer. Hedberg, et al. Standards Track [Page 15] OpenID Federation 1.1 February 2026 3.2. Entity Statement Validation Entity Statements MUST be validated in the following manner. These steps MAY be performed in a different order, provided that the result - accepting or rejecting the Entity Statement - is the same. 1. The Entity Statement MUST be a signed JWT. 2. The Entity Statement MUST have a typ header parameter with the value entity-statement+jwt. 3. The Entity Statement MUST have an alg (algorithm) header parameter with a value that is an acceptable JWS signing algorithm; it MUST NOT be none. 4. The Entity Identifier of the Entity to which the Entity Statement refers MUST match the value of the sub (subject) Claim. 5. The Entity Statement MUST have an iss (issuer) Claim with a value that is a valid Entity Identifier. 6. When the iss (issuer) Claim Value matches the sub (subject) Claim Value, then the Entity Statement is this Entity's Entity Configuration. When they do not match, the Entity Statement is a Subordinate Statement. When the Entity Statement is a Subordinate Statement, the iss Claim Value MUST match one of the values in the authority_hints array in the Entity Configuration for the Entity whose Entity Identifier is the value of the sub Claim; otherwise, the Federation graph is not well-formed. 7. The current time MUST be after the time represented by the iat (issued at) Claim (possibly allowing for some small leeway to account for clock skew). 8. The current time MUST be before the time represented by the exp (expiration) Claim (possibly allowing for some small leeway to account for clock skew). 9. The jwks (JWK Set) Claim MUST be present, with a value that is a valid JWK Set [RFC7517]. 10. Obtain the Entity Configuration for the issuing Entity - the Entity with the Issuer Identifier found in the Entity Statement's iss (issuer) Claim. When the iss and sub Claim Values match, this is the Entity Statement being validated itself. Otherwise, this can be obtained either from a Trust Chain or by retrieving it as described in Section 9. Hedberg, et al. Standards Track [Page 16] OpenID Federation 1.1 February 2026 11. The Entity Statement's kid (Key ID) header parameter value MUST be a non-zero length string and MUST exactly match the kid value for a key in the jwks (JWK Set) Claim of the Entity Configuration of the issuing Entity. 12. The Entity Statement's signature MUST validate using the issuing Entity's key identified by the kid value. 13. If the crit Claim is present, then each array element in this Claim's value MUST be a string representing an Entity Statement Claim that is not defined by this specification and that Claim MUST be understood and be able to be processed by the implementation. 14. If the authority_hints Claim is present, the Entity Statement MUST be an Entity Configuration. Verify that its value is syntactically correct, as specified in Section 3.1.2. Implementations MAY also validate that the Entity is a Subordinate of each Entity whose Entity Identifier is listed in the authority_hints array. 15. If the trust_anchor_hints Claim is present, the Entity Statement MUST be an Entity Configuration. Verify that its value is syntactically correct, as specified in Section 3.1.2. 16. If the metadata Claim is present, verify that its value is syntactically correct, not using null as metadata values, as specified in Section 5. 17. If the metadata_policy Claim is present, the Entity Statement MUST be a Subordinate Statement. Verify that its value is syntactically correct, as specified in Section 6.1. 18. If the metadata_policy_crit Claim is present, the Entity Statement MUST be a Subordinate Statement. Each array element in this Claim's value MUST be a string representing a Metadata Policy operator that is not defined by this specification and that operator MUST be understood and be able to be processed by the implementation. 19. If the constraints Claim is present, the Entity Statement MUST be a Subordinate Statement. Verify that its value is syntactically correct, as specified in Section 6.2. 20. If the trust_marks Claim is present, the Entity Statement MUST be an Entity Configuration. Validate that the syntax of this Claim Value conforms to the Claim definition. In particular, for each element of the array that is the Claim Value, validate Hedberg, et al. Standards Track [Page 17] OpenID Federation 1.1 February 2026 that there is a trust_mark_type member whose value matches the trust_mark_type Claim Value in the Trust Mark JWT that is the value of the trust_mark member. Validating the syntax is separate from evaluating whether particular Trust Marks are issued by a trusted party and are trusted; that process is described in Section 7.3 and MAY be performed as a separate step from syntactic validation. 21. If the trust_mark_issuers Claim is present, the Entity Statement MUST be an Entity Configuration. Validate that its Claim Value is a JSON object with Trust Mark type identifiers as the member names and arrays of Entity Identifiers as the values. 22. If the trust_mark_owners Claim is present, the Entity Statement MUST be an Entity Configuration. Validate that its Claim Value is a JSON object with Trust Mark type identifiers as the member names and values that are JSON objects containing a sub member with a value that is an Entity Identifier and a jwks member with a value that is a JSON Web Key Set. 23. If the source_endpoint Claim is present, the Entity Statement MUST be a Subordinate Statement. Validate that its Claim Value is a URL. Implementations MAY also make a fetch call to the URL to validate that this is the fetch endpoint from which the Entity Statement was issued. 24. If the trust_chain header parameter is present, validate that its value is a syntactically valid Trust Chain, as specified in Section 4. The first entry in the Trust Chain MUST be an Entity Configuration for this Entity. Implementations SHOULD validate that the Entity Identifier for the Trust Anchor at the end of the Trust Chain matches one of the Trust Anchors configured for the deployment. 25. If the peer_trust_chain header parameter is present, validate that its value is a syntactically valid Trust Chain, as specified in Section 4. Implementations SHOULD validate that the Entity Identifier for the Trust Anchor at the end of the Trust Chain matches one of the Trust Anchors configured for the deployment. If any of these validation steps fail, the Entity Statement MUST be rejected. Hedberg, et al. Standards Track [Page 18] OpenID Federation 1.1 February 2026 3.3. Entity Statement Example The following is a non-normative example of the JWT Claims Set for an Entity Statement. The example contains a critical extension jti (JWT ID) to the Entity Statement and one critical extension to the policy language regexp (Regular expression). { "iss": "https://feide.no", "sub": "https://ntnu.no", "iat": 1516239022, "exp": 1516843822, "jwks": { "keys": [ { "kty": "RSA", "alg": "RS256", "use": "sig", "kid": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs", "n": "vHOJrp-zLST7FwvzAwelR9Vo...", "e": "AQAB" } ] }, "metadata": { "openid_provider": { "issuer": "https://ntnu.no", "organization_name": "NTNU" }, "oauth_client": { "organization_name": "NTNU" } }, "metadata_policy": { "openid_provider": { "id_token_signing_alg_values_supported": {"subset_of": ["RS256", "RS384", "RS512"]}, "op_policy_uri": { "regexp": "^https:\/\/[\\w-]+\\.example\\.com\/[\\w-]+\\.html"} }, "oauth_client": { "grant_types": { "one_of": ["authorization_code", "client_credentials"] } } }, "constraints": { Hedberg, et al. Standards Track [Page 19] OpenID Federation 1.1 February 2026 "max_path_length": 2 }, "crit": ["jti"], "metadata_policy_crit": ["regexp"], "source_endpoint": "https://feide.no/federation_api/fetch", "jti": "7l2lncFdY6SlhNia" } Figure 2: Example Entity Statement JWT Claims Set 4. Trust Chain Entities whose statements build a Trust Chain are categorized as: Trust Anchor An Entity that represents a trusted third party. Leaf An Entity with no Subordinate Entities, which typically plays a protocol role. For instance, in an OpenID Connect identity federation, an RP or an OP, or in an OAuth 2.0 federation, a Client, Authorization Server, or Protected Resource. Intermediate Neither a Leaf Entity nor a Trust Anchor. A Trust Chain begins with an Entity Configuration that is the subject of the Trust Chain, which is typically a Leaf Entity. The Trust Chain has zero or more Subordinate Statements issued by Intermediates about their Immediate Subordinates, and includes the Subordinate Statement issued by the Trust Anchor about the top-most Intermediate (if there are Intermediates) or the Trust Chain subject (if there are no Intermediates). The Trust Chain logically always ends with the Entity Configuration of the Trust Anchor, even though it MAY be omitted from the JSON array representing the Trust Chain in some cases. The Trust Chain contains the configuration of the federation as it applies to the Trust Chain subject at the time of the evaluation of the chain. A simple example: If we have an RP that belongs to Organization A that is a member of Federation F, the Trust Chain for such a setup will contain the following Entity Statements: 1. an Entity Configuration about the RP published by itself, 2. a Subordinate Statement about the RP published by Organization A, Hedberg, et al. Standards Track [Page 20] OpenID Federation 1.1 February 2026 3. a Subordinate Statement about Organization A published by the Trust Anchor for F, 4. an Entity Configuration about the Trust Anchor for F published by itself. Let us refer to the Entity Statements in the Trust Chain as ES[j], where j = 0,...,i, with 0 being the index of the first Entity Statement and i being the zero-based index of the last. Then: * ES[0] (the Entity Configuration of the Trust Chain subject) is signed using a key in ES[0]["jwks"]. * The iss Claim in an Entity Statement is equal to the sub Claim in the next. Restating this symbolically, for each j = 0,...,i-1, ES[j]["iss"] == ES[j+1]["sub"]. * An Entity Statement is signed using a key from the jwks Claim in the next. Restating this symbolically, for each j = 0,...,i-1, ES[j] is signed by a key in ES[j+1]["jwks"]. * ES[i] (the Trust Anchor's Entity Configuration in the Trust Chain) is signed using a key in ES[i]["jwks"]. The Trust Anchor's public keys are used to verify the signatures on ES[i] (the Trust Anchor's Entity Configuration) and ES[i-1] (the Trust Anchor's Subordinate Statement about its Immediate Subordinate in the Trust Chain). The Trust Anchor's public keys are distributed to Entities that need to verify a Trust Chain in some secure out-of- band way not described in this document. 4.1. Beginning and Ending Trust Chains A Trust Chain begins with the Entity Configuration of an Entity for which trust is being established. This is the subject of the Trust Chain. This Entity typically plays a protocol role, such as being an OpenID Provider or OpenID Relying Party. While such Entities are typically Leaf Entities, other topologies are possible. For instance, an Entity might simultaneously be an OpenID Provider and an Intermediate Entity, with OpenID Relying Parties and/ or other Intermediates being Subordinate to it. This is a case in which the subject of a Trust Chain would not be a Leaf Entity. Hedberg, et al. Standards Track [Page 21] OpenID Federation 1.1 February 2026 A Trust Chain ends with the Entity Configuration of a Trust Anchor. While Trust Anchors typically have no Superiors, a Trust Anchor will have a Superior when the Trust Anchor also acts as an Intermediate Entity in another federation. This will be the case when there is a hierarchy of federations. Thus, while it is typical for a Trust Chain to end with a Trust Anchor with no Superiors, there are situations in which the Trust Chain will end with a Trust Anchor that nonetheless has Superior Entities. 4.2. Trust Chain Example The following is an example of a Trust Chain consisting of a Leaf's Entity Configuration and Subordinate Statements issued by an Intermediate Entity and a Trust Anchor. It shows the relationship between the three Entities, their Entity Configurations, and their Subordinate Statements. The Subordinate Statements are obtained from the federation_fetch_endpoint of the subject's Immediate Superior. The URL of the federation_fetch_endpoint is discovered in the Immediate Superior's Entity Configuration. Note that the first member of the Trust Chain (the Leaf) is depicted at the bottom of the diagram and that the last member (the Trust Anchor) is depicted at the top. Hedberg, et al. Standards Track [Page 22] OpenID Federation 1.1 February 2026 .----------------. .---------------------------. .---------------------------. | Role | | .well-known/ | | Trust Chain | | | | openid-federation | | | .----------------. .---------------------------. .---------------------------. | .------------. | | .-----------------------. | | .-----------------------. | | | | | | | Entity Configuration | | | | Entity Configuration | | | |Trust Anchor+-+--+-> +-+---------+-> | | | | | | | | Federation Entity Keys| | | | Federation Entity Keys| | | '-----.------' | | | Metadata | | | | Metadata | | | | | | | Trust Mark Issuers | | | | Trust Mark Issuers | | | | | | | | | | | | | | | | | '-----------------------' | | '-----------------------' | | | | | | | | | | | | |Fetch | .-----------------------. | | | | | |Endpoint | | Subordinate Statement | | | +--------+--+---------------------------+---------+-> | | | | | | | | Federation Entity Keys| | | | | | | | Metadata Policy | | | | | | | | Metadata | | | | | | | | Constraints | | | | | | | | | | | | | | | '-----------.-----------' | | .------------. | | .-----------------------. | | | | | | | | | | Entity Configuration | | | | | | |Intermediate+-+--+-> | | | |sub and key | | | | | | | Federation Entity Keys| | | | binding | | '------.-----' | | | Metadata | | | .-----------v-----------. | | | | | | Trust Marks | | | | Subordinate Statement | | | | | | | | | | | | | | | | | | | | | | Federation Entity Keys| | | | | | '-----------------------' |Fetch | | Metadata Policy | | | | | | |Endpoint | | Metadata | | | +-------+--+---------------------------+---------+-> | | | | | | | '-----------.-----------' | | | | | | |sub and key | | | | | | | binding | | .------------. | | .-----------------------. | | .-----------v-----------. | | | | | | | Entity Configuration | | | | Entity Configuration | | | | Leaf +-+--+-> +-+---------+-> | | | | | | | | Federation Entity Keys| | | | Federation Entity Keys| | | '------------' | | | Metadata | | | | Metadata | | | | | | Trust Marks | | | | Trust Marks | | | | | | | | | | | | | | | | | | | | | | | | | '-----------------------' | | '-----------------------' | '----------------' '---------------------------' '---------------------------' Hedberg, et al. Standards Track [Page 23] OpenID Federation 1.1 February 2026 Figure 3: Relationships between Federation Entities and Statements Issued in a Trust Chain 4.3. Trust Chain Header Parameter The trust_chain JWS header parameter is a JSON array containing the sequence of Entity Statements that comprise the Trust Chain between an Entity and the selected Trust Anchor. The Trust Chain typically begins with the Entity Configuration of the subject of the JWT in which this header parameter occurs; however, in some cases, the Trust Chain will begin with the Entity Configuration of a different Entity, such as the issuer, which is the case for the Resolve Response defined in Section 8.3.2. The issuer of the JWT SHOULD select a Trust Anchor that the Entity at the beginning of the Trust Chain has in common with the audience of the JWT. Otherwise, the issuer is free to select the Trust Anchor to use. Most signed JWTs MAY include the trust_chain JWS header parameter, with a few exceptions. Entity Configurations and Subordinate Statements MUST NOT contain the trust_chain header parameter, as they are integral components of a Trust Chain. Use of this header parameter is OPTIONAL. The following is a non-normative example of a JWS header with the trust_chain parameter. { "typ": "...", "alg": "RS256", "kid": "SUdtUndEWVY2cUFDeDV5NVlBWDhvOXJodVl2am1mNGNtR0pmd", "trust_chain": [ "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiWjBWRVdtUTRVVFJWZFhNeGRFVnRMVUl3VldWSVRVZDRhekpEVTBrdE5DMXdaWGR2TVRoWWJrTTRUUSJ9.eyJtZXRhZGF0YSI6IHsib3BlbmlkX2NyZWRlbnRpYWxfaXNzdWVyIjogeyJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiUjJSelJYQTBSVkJ5ZHpGT1ZHMWZkV1JUTVRaM1lUUm1ObkUxVjNGZk1FMW9NVVpMZWtsaVkxTllPQSIsICJlIjogIkFRQUIiLCAibiI6ICI1SF9YaDd4Z0RXVHhRVmJKcW1PR3Vyb2tFOGtyMmUxS2dNV2NZT0E3NE9fMVBYZDJ1Z2p5SXE5dDFtVlBTdXd4LXR5U2syUEtwanAtLVdySG4zQTRVS0prdVIxMXpobWRMQnNVOFRPQkJ1NU1aOGF0RHVqZlJ3SUxYZEtzRVhrbHZhQjZQTFQ0emRab2RnQ3MwNUt5MmU1c2I1ejZfQ2lEcWdVVm5XUG1KTE1rZ3BCdFota01kX2xiOVNvb1psbGZVR2xUa3NhdUoyX2dWUS1WcEZVTVhZam9Kak54OTdldWthWW5SRW9DQzNUYV8tOGJjUm9zbHgyeHJJYnVfVUdWcWlwZU4zTlAtbWVmZjlWVFpXWU0zZ21vbHd1cG5NQ1hYaWlrY1I1VVNMVmcwZV9nejZPZm9SVkdLQVdJcFJSTFR6MmFpcXVrVkhaZFpYOXRObXowbXcifV19fSwgImZlZGVyYXRpb25fZW50aXR5IjogeyJvcmdhbml6YXRpb25fbmFtZSI6ICJPcGVuSUQgQ3JlZGVudGlhbCBJc3N1ZXIgZXhhbXBsZSIsICJvcmdhbml6YXRpb25fdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvaG9tZSIsICJwb2xpY3lfdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvcG9saWN5IiwgImxvZ29fdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvc3RhdGljL2xvZ28uc3ZnIiwgImNvbnRhY3RzIjogWyJ0ZWNoQGNyZWRlbnRpYWxfaXNzdWVyLmV4YW1wbGUub3JnIl19fSwgImF1dGhvcml0eV9oaW50cyI6IFsiaHR0cHM6Ly9pbnRlcm1lZGlhdGUuZWlkYXMuZXhhbXBsZS5vcmciXSwgImp3a3MiOiB7ImtleXMiOiBbeyJrdHkiOiAiUlNBIiwgImtpZCI6ICJaMFZFV21RNFVUUlZkWE14ZEVWdExVSXdWV1ZJVFVkNGF6SkRVMGt0TkMxd1pYZHZNVGhZYmtNNFRRIiwgIm4iOiAib0FBcU9wcHc2U3drZzNMZTJESlIzMHh0ZzBuOENrNmtiTDhxMzViZFVGdVBrMDBZaUNLZE9sN2JHQzVGdlBuMnIyZ2lfQkZ3djhscHdreU1ObnJYMHczd0hXTUtVMmdwWEpxLVNnZGVyQXVQZmxHQzgxY04tTGhJM04tQmQwcjF1YThCVktGeXFWdkNpcms3YWNGeVdQa2ZPcGstbTRlVG4tcmtNMzREMUZ1VFdOUDctZXp6T1g3OWx2YXJBVGl5S1Jva205WGRYN05pQ1hPNnkzSDhjRV9BUVE5a2JvSmxkNklHb3gwUFY3dVFvczlkWURlLTFaWDFzWDhKaklMT2IwTDVBeC1VOHI5V3lIX0VkUXVEVW9QMzZMdFN1YlBYaGo5NVpUa0ZrZnhZd3NHUWxmMjJRVmFQWVh1VnVlSmJtejZ1Zk5NSXBpNG1LaDU3Q2JtcmN3IiwgImUiOiAiQVFBQiJ9XX0sICJzdWIiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJpc3MiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzY3NzEwOTg0LCAiZXhwIjogMTc2ODAxMDk4NH0.KmJD9GmgRppKSX9kqoDVrZHb4nD7W0wvPJru3Iz4U6y-o5IMqlOxtq4LGDYRi2s7qsSCBn8qz1NIADuLnkc9IWAP5CUPXrnhAmqNBI05KqMdVIb_y0RtDwY7YK0fpBubxCcCiwaZBlTPHGBY72oRnUq3ZU4bOZ9LKNvqBxe9zINMUzCIykh7JUaeMCPP3RW0jBYSjkJwFu-uDKTztVRYTpzmblxTOXGO8djsjruIsNoRiM5uaiUL_JLiaJPZdQWorKa-PH9RRjTtB88hDSbL7We9oKlRLnOLCG4r6OJoJ1mqDRpbraYz_RsFqT9IXy5y5hmVcHS0Gc94BSfcgxVxDg", "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiYTB0cmVuUmhMWEV5ZUROWmFEa3lXRzQxTmtFMFUyWlNTVWxTUTA0M05rRm5NVkJsWVhWQ1FqVlhhdyJ9.eyJzdWIiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiWjBWRVdtUTRVVFJWZFhNeGRFVnRMVUl3VldWSVRVZDRhekpEVTBrdE5DMXdaWGR2TVRoWWJrTTRUUSIsICJuIjogIm9BQXFPcHB3NlN3a2czTGUyREpSMzB4dGcwbjhDazZrYkw4cTM1YmRVRnVQazAwWWlDS2RPbDdiR0M1RnZQbjJyMmdpX0JGd3Y4bHB3a3lNTm5yWDB3M3dIV01LVTJncFhKcS1TZ2RlckF1UGZsR0M4MWNOLUxoSTNOLUJkMHIxdWE4QlZLRnlxVnZDaXJrN2FjRnlXUGtmT3BrLW00ZVRuLXJrTTM0RDFGdVRXTlA3LWV6ek9YNzlsdmFyQVRpeUtSb2ttOVhkWDdOaUNYTzZ5M0g4Y0VfQVFROWtib0psZDZJR294MFBWN3VRb3M5ZFlEZS0xWlgxc1g4SmpJTE9iMEw1QXgtVThyOVd5SF9FZFF1RFVvUDM2THRTdWJQWGhqOTVaVGtGa2Z4WXdzR1FsZjIyUVZhUFlYdVZ1ZUpibXo2dWZOTUlwaTRtS2g1N0NibXJjdyIsICJlIjogIkFRQUIifV19LCAiaXNzIjogImh0dHBzOi8vaW50ZXJtZWRpYXRlLmVpZGFzLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3Njc3MTA5ODQsICJleHAiOiAxNzY4MDEwOTg0fQ.fUcQI29xFaxfvhOAZINWz3V9J1p-Ju6yyfyVQUmYpOc2j5VKz-jn1CG106gnyYzEPS5D3LMkwvuW1QADmFezgQj9iPpYpCIXn3gVdZbAHUP8RsseTQhm5EGiC11X-7zCA4RqQTuqQTh27fYYYoKkxcmkWeWteqzrFD4Tjw-Ryk0Eey7u9SFErZcZG8pNdpvopSUcUbWg14KG58DU64ssR4KJsZwPRZPfC_xr5CK4oQeyZF2ds8N-5cGAPRRuN68wlCT4IeYRByxmBZDxhX4e81qJT7eiIB95h-Ka6nY-R63A38IMBSN68MlX1Bt8gE_rfinTJhL6Y20LWKmeDyhWFg", "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiT1ZwU2JHUnVlWE5UWmtrek5FNUJjVkF6TFRsRFVIZHBka05CZVZZM2NYbzNhV1paTm00NFJUZGFXUSJ9.eyJzdWIiOiAiaHR0cHM6Ly9pbnRlcm1lZGlhdGUuZWlkYXMuZXhhbXBsZS5vcmciLCAiandrcyI6IHsia2V5cyI6IFt7Imt0eSI6ICJSU0EiLCAia2lkIjogImEwdHJlblJoTFhFeWVETlphRGt5V0c0MU5rRTBVMlpTU1VsU1EwNDNOa0ZuTVZCbFlYVkNRalZYYXciLCAibiI6ICJ6RmpzV3hBbE1ORFkzZUlqT2djaHVhX2ZRb3ZKeUNxbTM4M3dBV2Q5SDV0YU95QW5XbGx0UlJCV18zOHRycUZTWjl6UW0zdHdvZHllcHM2ZnFSNTdKMHF1NzVPWmdseXAyNUloMnBPWlBOWU5GSEFqSXRhbnNqWHI0RjRtakNfVVBMWmpRc3lHNjA1eGtrWUR4MjlqRF9pa0REN0lwUlA1Yk01ZU5vQVF1d1NMbktSWk43d0lMRjU3eDlSZVZZYnp1TEVUVzZOdzU0Y1Q3aDNMb3ljZ2dxQXdoR0dSR09QUEFlOEFsYjhtUDJBeGE4TWdNLUhhUENISHMwamswVy1zOUNDQ0djdzBfWmV5OWQ3eHFzT21KNnQ0QWUxWnhBTlJ1LU9FanhDSVd2WDl6aEJkeXNtVmp4RWVFY2xYSVltajFsd0JtZ0s0U1VmcVBMUGdYUGc5aVEiLCAiZSI6ICJBUUFCIn1dfSwgImlzcyI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzY3NzEwOTg0LCAiZXhwIjogMTc2ODAxMDk4NH0.IHTiWH2H2n2fVtkn7K_4GcP-VoSmuz4BWqOn6CtUNaLxUgIWR6FVeaKHdxdabkkMd_zQk6bG_K5adF2H45ojoJIFVY8uuwJCOfakfsYbOnKRmsWD4qiINXjFPLg8jVutg0lTNGjxjJRm6I-7bs5hGRJUAwhOGGrfdtnO7qtlBfg6ciHCuyr8Jq0tmYooKrvpbmObxQ7-cPqqnHy0J3My2TDlxtbMarqpSfXHEavjCEV0dXz00JXAuu0Iop2XfrMvZJaQXeLWtZM_CsBv1-FhVpslLYvlbktwCnV55nnEa06BItcW2ZdpVEVC-GrBcYc2wXIBXLxKjThZ67Z3SMdqpg", "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiT1ZwU2JHUnVlWE5UWmtrek5FNUJjVkF6TFRsRFVIZHBka05CZVZZM2NYbzNhV1paTm00NFJUZGFXUSJ9.eyJtZXRhZGF0YSI6IHsiZmVkZXJhdGlvbl9lbnRpdHkiOiB7ImZlZGVyYXRpb25fZmV0Y2hfZW5kcG9pbnQiOiAiaHR0cHM6Ly90cnVzdC1hbmNob3IuZXhhbXBsZS5vcmcvZmV0Y2giLCAiZmVkZXJhdGlvbl9yZXNvbHZlX2VuZHBvaW50IjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL3Jlc29sdmUiLCAiZmVkZXJhdGlvbl9saXN0X2VuZHBvaW50IjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL2xpc3QiLCAib3JnYW5pemF0aW9uX25hbWUiOiAiVEEgZXhhbXBsZSIsICJvcmdhbml6YXRpb25fdXJpIjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL2hvbWUiLCAicG9saWN5X3VyaSI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZy9wb2xpY3kiLCAibG9nb191cmkiOiAiaHR0cHM6Ly90cnVzdC1hbmNob3IuZXhhbXBsZS5vcmcvc3RhdGljL2xvZ28uc3ZnIiwgImNvbnRhY3RzIjogWyJ0ZWNoQHRydXN0LWFuY2hvci5leGFtcGxlLm9yZyJdfX0sICJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiT1ZwU2JHUnVlWE5UWmtrek5FNUJjVkF6TFRsRFVIZHBka05CZVZZM2NYbzNhV1paTm00NFJUZGFXUSIsICJuIjogInhDOXBkUHJwMURHNzlQb0wyTmsybGpoTVpnc3dyMUFqTFprcC1KZHN2MTVHYTY3S0FhMUNId0RMQ0JrblZKcHZNb2g0dnFyM0RzYlh1NEFobThFUzY3RlEwUmpUeUNTZXBvREVoNXVtd0dSakQxblhEMTI2dTlGQi10S0xqUFpTaFl5aW5Kd1BaSGp0ekF0U2xjalNfcFg3WjRDQUh1OEhkeHpZb0JDODhOUEszZjBhZmRBY3JxcnM3LVVFWlphODhycVpGZjRYemVZMGdZUVc4cG5TN0h6cU9aNEhLaU1Ld0ZXUnE1WXFVQ2stVkUyZlpsdjIzR3pxd3VyenllaTd2cVZwWXhodFRlTnBmMjZqSWV5T2JhWm5QYTMzUmFVVDNCd2p2bXBROGJEZ0EzUlF3UFhXMFIzTlpzTElfd0Nqc095TVdkMVh6MlJHellRcjVVV2psUSIsICJlIjogIkFRQUIifV19LCAic3ViIjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnIiwgImlzcyI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzY3NzEwOTg0LCAiZXhwIjogMTc2ODAxMDk4NH0.gbpT-NSUz4Psl3wysrNqXXLZ5sYFnH8yB7Mtb6x5Vbwqre5UsHzyS7S9F86hWSfPQT19jofWT4uLFC_R_Ct4xa3OZvGSfVEtv9rYtJ8Q2tCM2JYZO1hFCaV6BM9pa5yU93H5SoOVLuK4YxQzmGE7cuHsjOXHbGCexJ0rcC1CTOwK3q1o8YEOa_0X2KbkEmeQKR1P50oN8c_GK0NkxT3XLCxb-cVwlG4nsHDe28KBwxjX2DObXXgh5SXj1Mz7dXuv-AtfKcHQ9i479mWVJn86rE4IjHRSp5IIEMsZ5Pn72QVWHGxkwno0TOFTBLtUp9FN9Y36gXiZpfMq9RdyvYbl2w" ] } Figure 4: Example JWS Header with a trust_chain Parameter Hedberg, et al. Standards Track [Page 24] OpenID Federation 1.1 February 2026 4.4. Peer Trust Chain Header Parameter The peer_trust_chain JWS header parameter is a JSON array containing the sequence of Entity Statements that comprise the Trust Chain between an Entity that this Entity is establishing trust with and the selected Trust Anchor. If the trust_chain header parameter is also present, the Trust Anchor for both Trust Chains SHOULD be the same. Inclusion of both Trust Chains enables achieving the Federation Integrity and Metadata Integrity properties, as defined in [App-Fed-Linkage]. Entity Configurations and Subordinate Statements MUST NOT contain the peer_trust_chain header parameter, as they are integral components of a Trust Chain. Use of this header parameter is OPTIONAL. 5. Metadata This section defines how to represent and use metadata about Entities. As described in Section 3.1.1, Entity metadata is located in the metadata Claim of an Entity Statement, whose value is a JSON object. The member names of this object are Entity Type Identifiers, as specified in Section 5.1. The metadata data structure following each Entity Type Identifier is a JSON object; it MAY be the empty JSON object {}, which may be the case when Superiors supply any needed metadata values. Top-level JSON object members in the metadata data structures MAY use any JSON value other than null; the use of null is prohibited to prevent likely implementation errors caused by confusing members having null values with omitted members. 5.1. Entity Type Identifiers The Entity Type Identifier uniquely identifies the Entity Type of a federation participant and the metadata format for that Entity Type. This section defines the federation_entity Entity Type Identifier, which is protocol-independent. Use of metadata for OpenID Connect and OAuth 2.0 Federation Entities is defined in Section 5 of [OpenID.Federation.Connect-1.1]. Additional Entity Type Identifiers MAY be defined to support use cases for other protocols. Hedberg, et al. Standards Track [Page 25] OpenID Federation 1.1 February 2026 5.1.1. Federation Entity The Entity Type Identifier is federation_entity. The Entities that contain any of Federation Entity properties defined below MUST use this Entity Type. The following Federation Entity properties are defined: federation_fetch_endpoint OPTIONAL. The fetch endpoint described in Section 8.1. This URL MUST use the https scheme and MAY contain port, path, and query parameter components; it MUST NOT contain a fragment component. Intermediate Entities and Trust Anchors MUST publish a federation_fetch_endpoint. Leaf Entities MUST NOT. federation_list_endpoint OPTIONAL. The list endpoint described in Section 8.2. This URL MUST use the https scheme and MAY contain port, path, and query parameter components; it MUST NOT contain a fragment component. Intermediate Entities and Trust Anchors MUST publish a federation_list_endpoint. Leaf Entities MUST NOT. federation_resolve_endpoint OPTIONAL. The resolve endpoint described in Section 8.3. This URL MUST use the https scheme and MAY contain port, path, and query parameter components; it MUST NOT contain a fragment component. Any Federation Entity MAY publish a federation_resolve_endpoint. federation_trust_mark_status_endpoint OPTIONAL. The Trust Mark Status endpoint described in Section 8.4. Trust Mark Issuers SHOULD publish a federation_trust_mark_status_endpoint. This URL MUST use the https scheme and MAY contain port, path, and query parameter components; it MUST NOT contain a fragment component. federation_trust_mark_list_endpoint OPTIONAL. The endpoint described in Section 8.5. This URL MUST use the https scheme and MAY contain port, path, and query parameter components; it MUST NOT contain a fragment component. Trust Mark Issuers MAY publish a federation_trust_mark_list_endpoint. federation_trust_mark_endpoint OPTIONAL. The endpoint described in Section 8.6. This URL MUST use the https scheme and MAY contain port, path, and query parameter components; it MUST NOT contain a fragment component. Trust Mark Issuers MAY publish a federation_trust_mark_endpoint. Hedberg, et al. Standards Track [Page 26] OpenID Federation 1.1 February 2026 federation_historical_keys_endpoint OPTIONAL. The endpoint described in Section 8.7. This URL MUST use the https scheme and MAY contain port, path, and query parameter components; it MUST NOT contain a fragment component. All Federation Entities MAY publish a federation_historical_keys_endpoint. endpoint_auth_signing_alg_values_supported OPTIONAL. JSON array containing a list of the supported JWS [RFC7515] algorithms (alg values) for signing the JWT [RFC7519] used for private_key_jwt when authenticating to federation endpoints, as described in Section 8.8. No default algorithms are implied if this entry is omitted. Servers SHOULD support RS256. The value none MUST NOT be used. Additional Federation Entity properties MAY be defined and used. It is RECOMMENDED that each Federation Entity contain an organization_name Claim, as defined in Section 5.2.2. The following is a non-normative example of metadata for the federation_entity Entity Type: "federation_entity": { "federation_fetch_endpoint": "https://amanita.caesarea.example.com/federation_fetch", "federation_list_endpoint": "https://amanita.caesarea.example.com/federation_list", "federation_trust_mark_status_endpoint": "https://amanita.caesarea.example.com/status", "federation_trust_mark_list_endpoint": "https://amanita.caesarea.example.com/trust_marked_list", "organization_name": "Ovulo Mushroom", "organization_uri": "https://amanita.caesarea.example.com" } Figure 5: Example of federation_entity Entity Type 5.2. Common Metadata Parameters This section defines additional metadata parameters that MAY be used with all the Entity Types above, with the exception for JWK Sets noted below. Hedberg, et al. Standards Track [Page 27] OpenID Federation 1.1 February 2026 5.2.1. Parameters for JWK Sets in Entity Metadata The following metadata parameters define ways of obtaining JWK Sets for an Entity Type of the Entity. Note that these keys are distinct from the Federation Entity Keys used to sign Entity Statements, which are in the jwks Claim of the Entity Statement, and not within the metadata Claim. These parameters for JWK Sets MUST NOT be used in federation_entity Entity Type metadata. signed_jwks_uri OPTIONAL. URL referencing a signed JWT having the Entity's JWK Set document for that Entity Type as its payload. This URL MUST use the https scheme. The JWT MUST be signed using a Federation Entity Key. A successful response from the URL MUST use the HTTP status code 200 with the content type application/jwk-set+jwt. When both signing and encryption keys are present, a use (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage. Signed JWK Set JWTs are explicitly typed by setting the typ header parameter to jwk-set+jwt to prevent cross-JWT confusion, per Section 3.11 of [RFC8725]. Signed JWK Set JWTs without a typ header parameter or with a different typ value MUST be rejected. Signed JWK Set JWTs MUST include the kid (Key ID) header parameter with its value being the Key ID of the signing key used. The following Claims are specified for use in the payload, all of which except keys are defined in [RFC7519]: keys REQUIRED. Array of JWK values in the JWK Set, as specified in Section 5.1 of [RFC7517]. iss REQUIRED. The "iss" (issuer) Claim identifies the principal that issued the JWT. sub REQUIRED. This Claim identifies the owner of the keys. It SHOULD be the same as the issuer. iat OPTIONAL. Number. Time when this signed JWK Set was issued. This is expressed as Seconds Since the Epoch, per [RFC7519]. Hedberg, et al. Standards Track [Page 28] OpenID Federation 1.1 February 2026 exp OPTIONAL. Number. This Claim identifies the time when the JWT is no longer valid. This is expressed as Seconds Since the Epoch, per [RFC7519]. More Claims are defined in [RFC7519]; of these, aud SHOULD NOT be used since the issuer cannot know who the audience is. nbf and jti are not particularly useful in this context and SHOULD be omitted. Additional Claims MAY be defined and used in conjunction with the Claims above. The following is a non-normative example of the JWT Claims Set for a signed JWK Set. { "keys": [ { "kty": "RSA", "kid": "SUdtUndEWVY2cUFDeDV5NVlBWDhvOXJodVl2am1mNGNtR0pmd", "n": "y_Zc8rByfeRIC9fFZrDZ2MGH2ZnxLrc0ZNNwkNet5rwCPYeRF3Sv 5nihZA9NHkDTEX97dN8hG6ACfeSo6JB2P7heJtmzM8oOBZbmQ90n EA_JCHszkejHaOtDDfxPH6bQLrMlItF4JSUKua301uLB7C8nzTxm tF3eAhGCKn8LotEseccxsmzApKRNWhfKDLpKPe9i9PZQhhJaurwD kMwbWTAeZbqCScU1o09piuK1JDf2PaDFevioHncZcQO74Obe4nN3 oNPNAxrMClkZ9s9GMEd5vMqOD4huXlRpHwm9V3oJ3LRutOTxqQLV yPucu7eHA7her4FOFAiUk-5SieXL9Q", "e": "AQAB" }, { "kty": "EC", "kid": "MFYycG1raTI4SkZvVDBIMF9CNGw3VEZYUmxQLVN2T21nSWlkd3", "crv": "P-256", "x": "qAOdPQROkHfZY1daGofOmSNQWpYK8c9G2m2Rbkpbd4c", "y": "G_7fF-T8n2vONKM15Mzj4KR_shvHBxKGjMosF6FdoPY" } ], "iss": "https://example.org/op", "sub": "https://example.org/op", "iat": 1618410883 } Figure 6: Example JWT Claims Set for a Signed JWK Set Hedberg, et al. Standards Track [Page 29] OpenID Federation 1.1 February 2026 jwks_uri OPTIONAL. URL referencing a JWK Set document containing the Entity's keys for that Entity Type. This URL MUST use the https scheme. When both signing and encryption keys are present, a use (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage. jwks OPTIONAL. JSON Web Key Set document, passed by value, containing the Entity's keys for that Entity Type. When both signing and encryption keys are present, a use (public key use) parameter value is REQUIRED for all keys in the JWK Set to indicate each key's intended usage. This parameter is intended to be used by participants that, for some reason, cannot use the signed_jwks_uri parameter. An upside of using jwks is that the Entity's keys for the Entity Type are recorded in Trust Chains. 5.2.1.1. Usage of jwks, jwks_uri, and signed_jwks_uri in Entity Metadata It is RECOMMENDED that an Entity Configuration use only one of jwks, jwks_uri, and signed_jwks_uri in its OpenID Connect or OAuth 2.0 metadata. However, there may be circumstances in which it is desirable to use multiple JWK Set representations, such as when an Entity is in multiple federations and the federations have different policies about the JWK Set representation to be used. Also note that some implementations might not understand all these representations. For instance, while jwks_uri will certainly be understood in OpenID Connect OP metadata, signed_jwks_uri might not be understood by all OpenID Connect implementations, and so a JWK Set representation that is understood also needs to be present. When multiple JWK Set representations are used, the keys present in each representation SHOULD be the same. Even if they are not completely the same at a given instant in time (which may be the case during key rollover operations), implementations MUST make them consistent in a timely manner. 5.2.2. Informational Metadata Parameters The following metadata parameters define ways of obtaining information about the Entity for an Entity Type. organization_name OPTIONAL. A human-readable name representing the organization owning this Entity. If the owner is a physical person, this MAY be, for example, the person's name. Note that this information will be publicly available. Hedberg, et al. Standards Track [Page 30] OpenID Federation 1.1 February 2026 display_name OPTIONAL. A human-readable name of the Entity to be presented to the End-User. description OPTIONAL. A human-readable brief description of this Entity presentable to the End-User. keywords OPTIONAL. JSON array with one or more strings representing search keywords, tags, categories, or labels that apply to this Entity. contacts OPTIONAL. JSON array with one or more strings representing contact persons at the Entity. These MAY contain names, e-mail addresses, descriptions, phone numbers, etc. logo_uri OPTIONAL. String. A URL that points to the logo of this Entity. The file containing the logo SHOULD be published in a format that can be viewed via the web. policy_uri OPTIONAL. URL of the documentation of conditions and policies relevant to this Entity. information_uri OPTIONAL. URL for documentation of additional information about this Entity viewable by the End-User. organization_uri OPTIONAL. URL of a Web page for the organization owning this Entity. These metadata parameters MAY be present in the Entity's metadata for any Entity Types that it uses. 6. Federation Policy 6.1. Metadata Policy Trust Anchors and Intermediate Entities MAY define policies that apply to the metadata of their Subordinates. Hedberg, et al. Standards Track [Page 31] OpenID Federation 1.1 February 2026 A federation may utilize metadata policies to achieve specific objectives. For example, in a federation of OpenID Connect [OpenID.Core] Entities, one objective may be to ensure the metadata published by OpenID Providers and Relying Parties are interoperable with one another. Another objective may be to ensure the Entity metadata complies with a security profile, for example, FAPI [FAPI]. Note that the metadata_policy is not intended to check and validate the JSON value types of metadata parameters. Such checks SHOULD be performed at the application layer, after obtaining the Entity metadata from a successfully resolved Trust Chain. 6.1.1. Principles OpenID Federation enables the definition of metadata policies with the following properties: Hierarchy Once applied to a metadata parameter, a metadata policy cannot be repealed or made more permissive by Intermediate Entities that are subordinate in the Trust Chain. The hierarchy of policies is preserved in nested federations where a Trust Anchor in one federation acts as an Intermediate Entity in another federation. Equal Opportunity All Superior Entities in a Trust Chain can contribute metadata policies on an equal basis, provided their contributions result in a combined metadata policy that is logically sound. For instance, any Intermediate can further restrict the metadata of its Subordinates relative to what its Superiors specified. An Intermediate that introduces a conflict among the metadata policies causes the Trust Chain to be deemed invalid. Specificity and Granularity Just like metadata, a metadata policy is bound to a specific Entity Type. This ensures policies for different Entity Types are independent and isolated from one another. Policies are expressed at the level of individual metadata parameters. The policies for a given Entity Type metadata parameter are thus independent and isolated from those for other parameters. When a Trust Anchor or an Intermediate Entity defines a metadata policy for an Entity Type, it applies to the metadata of all Subordinate Entities of that type in the Trust Chain. Hedberg, et al. Standards Track [Page 32] OpenID Federation 1.1 February 2026 Because the place to define a policy is the Subordinate Statement and every Entity Statement is issued for a specific subject, a federation authority can choose to define a common Entity Type metadata policy for all its Subordinates, or specific Entity Type metadata policies for specific Subordinates. Operation A policy operates by performing a check, a modification, or both on a given metadata parameter. This specification defines a set of standard operators, described in Section 6.1.3.1. A federation MAY specify and use additional operators, provided they comply with the principles laid out in this section and with Section 6.1.3 and Section 6.1.3.2. Integral Metadata Enforcement The resolution and application of metadata policies is an integral part of the Trust Chain resolution process, as described in Section 10. This means: * A Trust Chain for which the metadata policy resolution fails due to an error, for example, due to an Intermediate Entity's policy conflicting with a Superior's policy, is deemed invalid. * A Trust Chain with Entity metadata that does not comply with the Resolved Metadata policies is deemed invalid. Determinism The resolution and application of metadata policies in a Trust Chain is deterministic. Trust Anchors and Intermediate Entities are thus able to formulate policies that exhibit predictable and reproducible outcomes. 6.1.2. Structure Metadata policies are expressed in the metadata_policy Claim of a Subordinate Statement, as described in Section 3.1.3. The Claim Value is a JSON object that has a data structure consisting of three levels: 1. Metadata policies for Entity Types. The top level contains one or more members, each representing the metadata policy for an Entity Type. Each member name is an Entity Type Identifier, as specified in Section 5.1, for example, openid_relying_party. The member value is a JSON object that contains metadata parameter policies. Hedberg, et al. Standards Track [Page 33] OpenID Federation 1.1 February 2026 2. Metadata parameter policies for the Entity Type. The second level contains one or more members, each representing a policy for a metadata parameter for the Entity Type. Each member name is a metadata parameter name, for example id_token_signed_response_alg. The name MAY include a language tag, as described in Section 14, in which case the metadata parameter policy applies only to the metadata parameter with the specified language tag. The member value is a JSON object that contains policy operators. 3. Operators for the metadata parameter policy for the Entity Type. The third level contains one or more members, each representing an operator that checks or modifies the metadata parameter, as described in Section 6.1.3. Only operators that are allowed to be combined with one another, as defined in the specifications for each operator, can be included together here. Duplicate JSON object member names MUST NOT be present at any of the three levels of the metadata_policy Claim data structure. The following is a non-normative example of a metadata policy for an OpenID Relying Party that consists of a single policy for the id_token_signed_response_alg metadata parameter and uses two operators, default and one_of: "metadata_policy" : { "openid_relying_party": { "id_token_signed_response_alg": { "default": "ES256", "one_of": ["ES256", "ES384", "ES512"] } } } Figure 7: Example metadata_policy Claim 6.1.3. Operators A metadata policy operator: * Is identified by a unique case-sensitive name. Hedberg, et al. Standards Track [Page 34] OpenID Federation 1.1 February 2026 * Acts on a single metadata parameter. The operator definition MUST specify the metadata parameter JSON value types that are mandatory to support, and MAY also specify JSON value types that are optional to support. When the metadata parameter has a JSON value type that is not supported, the operator MUST produce a policy error. * The action on the metadata parameter can be a value check, a value modification, or both. When the operator's action is a value modification, it MAY remove the metadata parameter. * The action of the operator is configured by a JSON value. The operator definition MUST specify the JSON value types that are mandatory to support, and MAY also specify JSON value types that are optional to support. When the operator is configured with a JSON value type that is not supported, the operator MUST produce a policy error. * MUST declare what other operators it may be combined with, which applies to both individual as well as merged metadata parameter policies, as described in Section 6.1.2 and Section 6.1.4. A combination may be unconditional, or conditional, requiring the configured values of the two operators to meet certain criteria. Combinations that are not allowed MUST produce a policy error. * MUST declare in what order it is to be applied to a metadata parameter, absolute or relative to other operators in the metadata parameter policy. Value check operators SHOULD generally be applied after operators that perform value modifications. * MUST specify, when more than one Subordinate Statement in a Trust Chain has a policy for an Entity Type metadata parameter that uses the same operator, whether the operator values are allowed to be merged to produce an identical or more restrictive policy, and if so, under what conditions. The order of the result of such an operator value merge is not defined. If the operator does not allow such a merge, it MUST produce a policy error. * An operator MUST NOT output a metadata parameter with the null value. Note that metadata parameters and policies that conform to the JSON grammar but do not represent interoperable uses of JSON, as per Sections 4 and 8 of [RFC8259], can cause unpredictable behaviors. Hedberg, et al. Standards Track [Page 35] OpenID Federation 1.1 February 2026 6.1.3.1. Standard Operators This specification defines the following metadata policy operators: 6.1.3.1.1. value Name: value Action: The metadata parameter MUST be assigned the value of the operator. When the value of the operator is null, the metadata parameter MUST be removed. Metadata parameter JSON values: * Mandatory to support: string, number, boolean, array Operator JSON values: * Mandatory to support: string, number, boolean, array, null Combination with other operators in a metadata parameter policy: * MAY be combined with add, in which case the values of add MUST be a subset of the values of value. * MAY be combined with default if the value of value is not null. * MAY be combined with one_of, in which case the value of value MUST be among the one_of values. * MAY be combined with subset_of, in which case the values of value MUST be a subset of the values of subset_of. * MAY be combined with superset_of, in which case the values of value MUST be a superset of the values of superset_of. * MAY be combined with essential, except when value is null and essential is true. Order of application: First Operator value merge: Allowed only when the operator values are equal. If not, this MUST produce a policy error. 6.1.3.1.2. add Name: add Hedberg, et al. Standards Track [Page 36] OpenID Federation 1.1 February 2026 Action: The value or values of this operator MUST be added to the metadata parameter. Values that are already present in the metadata parameter MUST NOT be added another time. If the metadata parameter is absent, it MUST be initialized with the value of this operator. Metadata parameter JSON values: * Mandatory to support: array of strings * Optional to support: array of objects, array of numbers Operator JSON values: * Mandatory to support: array of strings * Optional to support: array of objects, array of numbers Combination with other operators in a metadata parameter policy: * MAY be combined with value, in which case the values of add MUST be a subset of the values of value. * MAY be combined with default. * MAY be combined with subset_of, in which case the values of add MUST be a subset of the values of subset_of. * MAY be combined with superset_of. * MAY be combined with essential. Order of application: After value. Operator value merge: The result of merging the values of two add operators is the union of the values. 6.1.3.1.3. default Name: default Action: If the metadata parameter is absent, it MUST be set to the value of the operator. If the metadata parameter is present, this operator has no effect. Metadata parameter JSON values: * Mandatory to support: string, number, boolean, array Hedberg, et al. Standards Track [Page 37] OpenID Federation 1.1 February 2026 Operator JSON values: * Mandatory to support: string, number, boolean, array Combination with other operators in a metadata parameter policy: * MAY be combined with value if the value of value is not null. * MAY be combined with add. * MAY be combined with one_of. * MAY be combined with subset_of. * MAY be combined with superset_of. * MAY be combined with essential. Order of application: After add. Operator value merge: The operator values MUST be equal. If the values are not equal this MUST produce a policy error. 6.1.3.1.4. one_of Name: one_of Action: If the metadata parameter is present, its value MUST be one of those listed in the operator value. Metadata parameter JSON values: * Mandatory to support: string * Optional to support: object, number Operator JSON values: * Mandatory to support: array of strings * Optional to support: array of objects, array of numbers Combination with other operators in a metadata parameter policy: * MAY be combined with value, in which case the value of value MUST be among the one_of values. * MAY be combined with default. Hedberg, et al. Standards Track [Page 38] OpenID Federation 1.1 February 2026 * MAY be combined with essential. Order of application: After default. Operator value merge: The result of merging the values of two one_of operators is the intersection of the operator values. If the intersection is empty, this MUST result in a policy error. 6.1.3.1.5. subset_of Name: subset_of Action: If the metadata parameter is present, it is assigned the intersection between the values of the operator and the metadata parameter. Note that the resulting intersection may thus be an empty array []. Also note that subset_of is a potential value modifier in addition to it being a value check. Metadata parameter JSON values: * Mandatory to support: array of strings * Optional to support: array of objects, array of numbers Operator JSON values: * Mandatory to support: array of strings * Optional to support: array of objects, array of numbers Combination with other operators in a metadata parameter policy: * MAY be combined with value, in which case the values of value MUST be a subset of the values of subset_of. * MAY be combined with add, in which case the values of add MUST be a subset of the values of subset_of. * MAY be combined with default. * MAY be combined with superset_of, in which case the values of subset_of MUST be a superset of the values of superset_of. * MAY be combined with essential. Order of application: After one_of. Hedberg, et al. Standards Track [Page 39] OpenID Federation 1.1 February 2026 Operator value merge: The result of merging the values of two subset_of operators is the intersection of the operator values. Note that the resulting intersection may thus be an empty array []. 6.1.3.1.6. superset_of Name: superset_of Action: If the metadata parameter is present, its values MUST contain those specified in the operator value. By mathematically defining supersets, equality is included. Metadata parameter JSON values: * Mandatory to support: array of strings * Optional to support: array of objects, array of numbers Operator JSON values: * Mandatory to support: array of strings * Optional to support: array of objects, array of numbers Combination with other operators in a metadata parameter policy: * MAY be combined with value, in which case the values of value MUST be a superset of the values of superset_of. * MAY be combined with add. * MAY be combined with default. * MAY be combined with subset_of, in which case the values of subset_of MUST be a superset of the values of superset_of. * MAY be combined with essential. Order of application: After subset_of. Operator value merge: The result of merging the values of two superset_of operators is the union of the operator values. 6.1.3.1.7. essential Name: essential Hedberg, et al. Standards Track [Page 40] OpenID Federation 1.1 February 2026 Action: If the value of this operator is true, then the metadata parameter MUST be present. If false, the metadata parameter is voluntary and may be absent. If the essential operator is omitted, this is equivalent to including it with a value of false. Metadata parameter JSON values: * Mandatory to support: string, number, boolean, object, array Operator JSON values: * Mandatory to support: boolean Combination with other operators in a metadata parameter policy: * MAY be combined with value, except when value is null and essential is true. * MAY be combined with any other operator. Order of application: Last Operator value merge: The result of merging the values of two essential operators is the logical disjunction (OR) of the operator values. 6.1.3.1.8. Notes on Operators A "set equals" metadata parameter policy can be expressed by combining the operators subset_of and superset_of with identical array values. Some JSON libraries may have issues comparing JSON objects. For this reason, support for applying metadata policy to metadata values that are JSON objects is mandatory only for the essential operator, which does not require comparison of values. It is OPTIONAL for the add, one_of, subset_of, and superset_of operators, which operate on JSON arrays and therefore require comparison of values. And it is OPTIONAL for the value and default operators, since merging values and defaults requires comparing the operators' values with existing ones. Hedberg, et al. Standards Track [Page 41] OpenID Federation 1.1 February 2026 The scope OAuth 2.0 client metadata parameter, defined in [RFC7591] and represented by a string of space-separated string values, is to be regarded and processed as a string array by policy operators, such as the operators default, subset_of and superset_of. The resulting scope metadata parameter is a space-separated string of individual scope values, where the scope values present are taken from the array of values produced by applying the metadata operators to the scope parameter. The following table is a map of the outputs produced by combinations of the essential and subset_of policy operators with different input metadata parameter values. Note, the subset_of check is skipped when the metadata parameter is absent and designated as voluntary, as shown in the last row. +-----------------------+-----------------------------+ | Policy | Metadata Parameter | +-----------+-----------+--------------+--------------+ | essential | subset_of | input | output | +-----------+-----------+--------------+--------------+ | true | [a,b,c] | [a,e] | [a] | +-----------+-----------+--------------+--------------+ | false | [a,b,c] | [a,e] | [a] | +-----------+-----------+--------------+--------------+ | true | [a,b,c] | [d,e] | [] | +-----------+-----------+--------------+--------------+ | false | [a,b,c] | [d,e] | [] | +-----------+-----------+--------------+--------------+ | true | [a,b,c] | no parameter | error | +-----------+-----------+--------------+--------------+ | false | [a,b,c] | no parameter | no parameter | +-----------+-----------+--------------+--------------+ Table 1: Examples of Outputs with Combinations of essential and subset_of for Different Inputs 6.1.3.2. Additional Operators Federations MAY specify and use additional metadata policy operators that conform with the principles in Section 6.1.1 and in Section 6.1.3. Additional operators MUST observe the following rules in regard to the order of their application relative to the standard operators defined in Section 6.1.3.1: Hedberg, et al. Standards Track [Page 42] OpenID Federation 1.1 February 2026 * Additional operators that modify metadata parameters MUST be applied after the value operator that is specified in Section 6.1.3.1.1. * Additional operators that check metadata parameters MUST be applied before the essential operator that is specified in Section 6.1.3.1.7. Implementations MUST ignore additional operators that are not understood, unless the operator name is included in the metadata_policy_crit Subordinate Statement Claim, in which case the operator MUST be understood and processed. If an additional operator listed in metadata_policy_crit is not understood or cannot be processed, then this MUST produce a policy error and the Trust Chain MUST be considered invalid. 6.1.4. Enforcement This section describes the resolution of the metadata policy for a Trust Chain and its application to the metadata of the Federation Entity that is the Trust Chain subject. If a policy error or another error is encountered during the metadata policy resolution or its application, the Trust Chain MUST be considered invalid. 6.1.4.1. Resolution The metadata policy for a Trust Chain is determined by the sequence of the present metadata_policy Claims of the Subordinate Statements that make up the chain. The resolution process MUST first gather the names of all policy operators other than the standard ones defined in Section 6.1.3.1 that are declared as critical. This is done by checking each Subordinate Statement in the Trust Chain for the optional metadata_policy_crit Claim, described in Section 3.1.3, and collecting any operator names that are found in it. The resolution process proceeds by iterating through the Subordinate Statements. The sequence of this iteration is crucial - it MUST begin with the Subordinate Statement issued by the most Superior Entity and end with the Subordinate Statement issued by the Immediate Superior of the Trust Chain subject. An important task during the iteration is the metadata_policy validation. It MUST ensure the data structure is compliant and that every metadata parameter policy contains only allowed operator Hedberg, et al. Standards Track [Page 43] OpenID Federation 1.1 February 2026 combinations, as described in Section 6.1.3, and in accordance with the specifications of the operators. It MUST also be ensured that the metadata_policy contains no operators that cannot be understood and processed whose names are among the collected metadata_policy_crit values. An unsuccessful validation MUST produce a policy error. At each iteration step, the Subordinate Statement MUST be checked for the presence of a metadata_policy Claim. The first encountered metadata_policy MUST be validated as described above, after which it becomes the current metadata policy. If the iteration yields a next subordinate metadata_policy Claim, it MUST be validated as described above, then merged into the current metadata policy. The merge is performed at each of the three levels of the metadata_policy data structure described in Section 6.1.2, by starting from the top level: 1. The metadata policies for Entity Types. 2. The metadata parameter policies for an Entity Type. 3. The operators for a metadata parameter policy for an Entity Type. At the level of metadata policies for Entity Types, the merge proceeds as follows: * If the next subordinate metadata_policy Claim contains a metadata policy for an Entity Type that is already present in the current metadata policy, it MUST be merged according to the rules of the next lower level (the metadata parameter policies). * Entity Type metadata policies in the next subordinate metadata_policy Claim that are not present in the current metadata policy MUST be copied to it. At the level of metadata parameter policies, the merge proceeds as follows: * If a metadata parameter policy is already present in the current Entity Type metadata policy, it MUST be merged according to the rules of the next lower level (the operators for the metadata parameter policy). If the resulting metadata parameter policy contains combinations that are not allowed, as described in Section 6.1.3 and in accordance with the specifications of the operators, this MUST produce a policy error. Hedberg, et al. Standards Track [Page 44] OpenID Federation 1.1 February 2026 * Subordinate metadata parameter policies that are not present in the current Entity Type metadata policy MUST be copied to it. At the level of operators, the merge proceeds as follows: * If an operator is already present in the current metadata parameter policy, the values of the subordinate operator MUST be merged, as described in Section 6.1.3 and in accordance with the operator specification. If an operator value merge is not allowed or otherwise unsuccessful this MUST produce a policy error. * Subordinate operators that are not present in the current metadata parameter policy MUST be copied to it. If no further Subordinate Statements with a metadata_policy Claim are found, the current metadata policy becomes the resolved one for the Trust Chain. 6.1.4.2. Application If the Subordinate Statement about the Trust Chain subject contains a metadata Claim, this MUST first be applied, as described in the Claim definition in Section 3.1.1, and only then it can be proceeded with applying the Resolved Metadata policy. If the process described in Section 6.1.4.1 found no Subordinate Statements in the Trust Chain with a metadata_policy Claim, the metadata of the Trust Chain subject resolves simply to the metadata found in its Entity Configuration, with any metadata parameters provided by the Immediate Superior applied to it. If a metadata policy was resolved for the Trust Chain, for every Entity Type metadata and metadata parameter for which a corresponding metadata parameter policy is present, the included policy operators MUST be applied as described in Section 6.1.3 and in accordance with the specifications of the operators. The operators MUST be applied to the metadata parameter in a sequence that is determined by the absolute or relative order specified for each operator. If the application of metadata policies results in illegal or otherwise incorrect Resolved Metadata, then the metadata MUST be regarded as broken and MUST NOT be used. The Trust Chain subject is responsible to verify that it is able to support and comply with the Resolved Metadata that results from the application of federation metadata policies. For instance, this may involve a check that cryptographic algorithms required by the resulting Resolved Metadata are supported. Likewise, the Trust Chain Hedberg, et al. Standards Track [Page 45] OpenID Federation 1.1 February 2026 subject MUST verify that all the required metadata parameters for its Entity Types are present and all the metadata values in the Resolved Metadata are valid. When metadata policies change, Trust Chain subjects may need to reevaluate their support and compliance. 6.1.5. Metadata Policy Example The following is a non-normative example of resolving and applying Trust Chain metadata policies for an OpenID relying party. We start with a federation Trust Anchor's metadata_policy for RPs: Hedberg, et al. Standards Track [Page 46] OpenID Federation 1.1 February 2026 "metadata_policy": { "openid_relying_party": { "grant_types": { "default": [ "authorization_code" ], "subset_of": [ "authorization_code", "refresh_token" ], "superset_of": [ "authorization_code" ] }, "token_endpoint_auth_method": { "one_of": [ "private_key_jwt", "self_signed_tls_client_auth" ], "essential": true }, "token_endpoint_auth_signing_alg" : { "one_of": [ "PS256", "ES256" ] }, "subject_type": { "value": "pairwise" }, "contacts": { "add": [ "helpdesk@federation.example.org" ] } } } Figure 8: Example Metadata Policy of a Trust Anchor for RPs Next, we have an Intermediate organization's metadata_policy for Subordinate RPs together with metadata values for its Immediate Subordinate RPs: Hedberg, et al. Standards Track [Page 47] OpenID Federation 1.1 February 2026 { "metadata_policy": { "openid_relying_party": { "grant_types": { "subset_of": [ "authorization_code" ] }, "token_endpoint_auth_method": { "one_of": [ "self_signed_tls_client_auth" ] }, "contacts": { "add": [ "helpdesk@org.example.org" ] } } }, "metadata": { "openid_relying_party": { "sector_identifier_uri": "https://org.example.org/sector-ids.json", "policy_uri": "https://org.example.org/policy.html" } } } Figure 9: Example Metadata Policy and Metadata Values of an Intermediate Entity for RPs Merging the example RP metadata policy of the Intermediate Entity into the RP metadata policy of the Trust Anchor produces the following policy for the Trust Chain: Hedberg, et al. Standards Track [Page 48] OpenID Federation 1.1 February 2026 { "grant_types": { "default": [ "authorization_code" ], "superset_of": [ "authorization_code" ], "subset_of": [ "authorization_code" ] }, "token_endpoint_auth_method": { "one_of": [ "self_signed_tls_client_auth" ], "essential": true }, "token_endpoint_auth_signing_alg": { "one_of": [ "PS256", "ES256" ] }, "subject_type": { "value": "pairwise" }, "contacts": { "add": [ "helpdesk@federation.example.org", "helpdesk@org.example.org" ] } } Figure 10: Example Merged Metadata Policy for RPs The Trust Chain subject is a Leaf Entity, which publishes the following RP metadata in its Entity Configuration: Hedberg, et al. Standards Track [Page 49] OpenID Federation 1.1 February 2026 "metadata": { "openid_relying_party": { "redirect_uris": [ "https://rp.example.org/callback" ], "response_types": [ "code" ], "token_endpoint_auth_method": "self_signed_tls_client_auth", "contacts": [ "rp_admins@rp.example.org" ] } } Figure 11: Example Entity Configuration RP Metadata The metadata values specified by the Intermediate Entity for its Immediate Subordinates are applied to the Trust Chain subject metadata. After that, the merged metadata policy is applied, to produce the following resulting RP Resolved Metadata: { "redirect_uris": [ "https://rp.example.org/callback" ], "grant_types": [ "authorization_code" ], "response_types": [ "code" ], "token_endpoint_auth_method": "self_signed_tls_client_auth", "subject_type": "pairwise", "sector_identifier_uri": "https://org.example.org/sector-ids.json", "policy_uri": "https://org.example.org/policy.html", "contacts": [ "rp_admins@rp.example.org", "helpdesk@federation.example.org", "helpdesk@org.example.org" ] } Figure 12: The Resulting RP Resolved Metadata for the Trust Chain Subject Hedberg, et al. Standards Track [Page 50] OpenID Federation 1.1 February 2026 6.2. Constraints Trust Anchors and Intermediate Entities MAY define constraining criteria that apply to their Subordinates. They are expressed in the constraints Claim of a Subordinate Statement, as described in Section 3.1.3. The following constraint parameters are defined: max_path_length OPTIONAL. Integer specifying the maximum number of Intermediate Entities between the Entity setting the constraint and the Trust Chain subject. naming_constraints OPTIONAL. JSON object specifying restrictions on the URIs of the Entity Identifiers of Subordinate Entities. Restrictions are defined in terms of permitted and excluded URI name subtrees. allowed_entity_types OPTIONAL. Array of string Entity Type Identifiers. Entity Type Identifiers are defined in Section 5.1. This constraint specifies the Entity Types and hence the metadata that Subordinate Entities are allowed to have. Additional constraint parameters MAY be defined and used. If they are not understood, they MUST be ignored. The following is a non-normative example of a set of constraints: { "max_path_length": 2, "naming_constraints": { "permitted": [ ".example.com" ], "excluded": [ "east.example.com" ] }, "allowed_entity_types": [ "openid_provider", "openid_relying_party" ] } Figure 13: Example Set of Constraints Hedberg, et al. Standards Track [Page 51] OpenID Federation 1.1 February 2026 When resolving the Trust Chain for an Entity the constraints Claim in each Subordinate Statement MUST be independently applied, if present. If any of the constraints checks fails, the Trust Chain MUST be considered invalid. 6.2.1. Max Path Length Constraint The max_path_length constraint specifies the maximum allowed number of Intermediate Entities in a Trust Chain between a Trust Anchor or Intermediate that sets the constraint and the Trust Chain subject. A max_path_length constraint of zero indicates that no Intermediates MAY appear between this Entity and the Trust Chain subject. The max_path_length constraint MUST have a value greater than or equal to zero. Omitting the max_path_length constraint means that there are no additional constraints apart from those already in effect. Assuming that we have a Trust Chain with four Entity Statements: 1. Entity Configuration of a Leaf Entity (LE) 2. Subordinate Statement by an Intermediate 1 (I1) about LE 3. Subordinate Statement by an Intermediate 2 (I2) about I1 4. Subordinate Statement by a Trust Anchor (TA) about I2 Then the Trust Chain fulfills the constraints if, for instance: * The TA specifies a max_path_length that is greater than or equal to 2. * TA specifies a max_path_length of 2, I2 specifies a max_path_length of 1, and I1 omits the max_path_length constraint. * Neither TA nor I2 specifies any max_path_length constraint while I1 sets max_path_length to 0. The Trust Chain does not fulfill the constraints if, for instance, the: * The TA sets the max_path_length to 1. Hedberg, et al. Standards Track [Page 52] OpenID Federation 1.1 February 2026 6.2.2. Naming Constraints The naming_constraints member specifies a URI namespace within which the Entity Identifiers of Subordinate Entities in a Trust Chain MUST be located. Restrictions are defined in terms of URI name subtrees, using permitted and/or excluded members within the naming_constraints member, each of which contains an array of names to be permitted or excluded. Any name matching a restriction in the excluded list is invalid, regardless of the information appearing in the permitted list. This specification uses the syntax of domain name constraints specified in Section 4.2.1.10 of [RFC5280]. As stated there, a domain name constraint MUST be specified as a fully qualified domain name and MAY specify a host or a domain. Examples are "host.example.com" and ".example.com". When the domain name constraint begins with a period, it MAY be expanded with one or more labels. That is, the domain name constraint ".example.com" is satisfied by both host.example.com and my.host.example.com. However, the domain name constraint ".example.com" is not satisfied by "example.com". When the domain name constraint does not begin with a period, it specifies a host. As in RFC 5280, domain name constraints apply to the host part of the URI. 6.2.3. Entity Type Constraints The allowed_entity_types constraint specifies the acceptable metadata Entity Types of Subordinate Entities in a Trust Chain. If there is no allowed_entity_types constraint, it means that any Entity Type is allowed. The federation_entity Entity Type Identifier, specified in Section 5.1.1, is always allowed and MUST NOT be included in the constraint. If the constraint is the empty array [], it means that only the federation_entity Entity Type is allowed. To apply the allowed_entity_types constraint during Trust Chain Resolution all Entity Types that are not listed in the allowed_entity_types constraint MUST be removed from the metadata Claim in the subject's Entity Configuration. The federation_entity Entity Type MUST NOT be removed. This MUST be done before applying Metadata Policies but after applying Metadata from a direct superior's Subordinate Statement. Hedberg, et al. Standards Track [Page 53] OpenID Federation 1.1 February 2026 7. Trust Marks Per the definition in Section 1.2, Trust Marks are statements of conformance to sets of criteria determined by an accreditation authority. Trust Marks used by this specification are signed JWTs. Entity Statements MAY include Trust Marks, as described in the trust_marks Claim definition in Section 3.1.2. Trust Marks are signed by a federation-accredited authority called a Trust Mark Issuer. All Trust Mark Issuers MUST be represented in the federation by an Entity. The fact that a Trust Mark Issuer is accepted by the federation is expressed in the trust_mark_issuers Claim of the Trust Anchor's Entity Configuration. The key used by the Trust Mark issuer to sign its Trust Marks MUST be one of the private keys in its set of Federation Entity Keys. Trust Mark JWTs MUST include the kid (Key ID) header parameter with its value being the Key ID of the signing key used. Note that a federation MAY allow an Entity to self-sign Trust Marks. Trust Mark JWTs MUST be explicitly typed by using the typ header parameter to prevent cross-JWT confusion, per Section 3.11 of [RFC8725]. The typ header parameter value MUST be trust-mark+jwt unless the trust framework in use defines a more specific media type value for the particular kind of Trust Mark. Trust Marks without a typ header parameter or an unrecognized typ value MUST be rejected. The following is a non-normative example of a trust_mark_issuers Claim: "trust_mark_issuers": { "https://openid.net/certification/op": [], "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf": ["https://swamid.se"] } Figure 14: Example trust_mark_issuers Claim 7.1. Trust Mark Claims The Claims in a Trust Mark are: iss REQUIRED. String. The Entity Identifier of the issuer of the Trust Mark. Hedberg, et al. Standards Track [Page 54] OpenID Federation 1.1 February 2026 sub REQUIRED. String. The Entity Identifier of the Entity this Trust Mark applies to. trust_mark_type REQUIRED. The trust_mark_type Claim is used in Trust Marks to provide the identifier of the type of the Trust Mark. The Trust Mark type identifier MUST be collision-resistant across multiple federations. It is RECOMMENDED that the identifier value is built using a URL that uniquely identifies the federation or the trust framework within which it was issued. This is required to prevent Trust Marks issued in different federations from having colliding identifiers. iat REQUIRED. Number. Time when this Trust Mark was issued. This is expressed as Seconds Since the Epoch, per [RFC7519]. logo_uri OPTIONAL. String. URL that references a logo for the issued Trust Mark. The value of this field MUST point to a valid image file. exp OPTIONAL. Number. Time when this Trust Mark is no longer valid. This is expressed as Seconds Since the Epoch, per [RFC7519]. If not present, it means that the Trust Mark does not expire. ref OPTIONAL. The ref (reference) Claim defined in Section 13.5 is used in Trust Marks to provide a URL referring to human-readable information about the issuance of the Trust Mark. delegation OPTIONAL. The delegation Claim defined in Section 13.6 is used in Trust Marks to delegate the right to issue Trust Marks with a particular identifier. Its value is a Trust Mark delegation JWT, as defined in Section 7.2.1. Additional Claims MAY be defined and used in conjunction with the Claims above. Hedberg, et al. Standards Track [Page 55] OpenID Federation 1.1 February 2026 7.2. Trust Mark Delegation There will be cases where the owner of a Trust Mark for some reason does not match the Trust Mark Issuer due to administrative or technical requirements. Take as an example vehicle inspection. Vehicle inspection is a procedure mandated by national or subnational governments in many countries, in which a vehicle is inspected to ensure that it conforms to regulations governing safety, emissions, or both. The body that mandates the inspections does not perform them; instead, there may be commercial companies performing the inspections, after which they issue the Trust Mark. The fact that a Trust Mark is issued by a Trust Mark Issuer that is not the owner of the Trust Mark is expressed by including a delegation Claim in the Trust Mark, whose value is a Trust Mark delegation JWT, as defined in Section 7.2.1. If the Federation Operator knows that Trust Marks with a certain Trust Mark type identifier may legitimately be issued by Trust Mark Issuers that are not the owner of the Trust Mark type identifier, then information about the owner and the Trust Mark type identifier MUST be included in the trust_mark_owners Claim in the Trust Anchor's Entity Configuration. The following is a non-normative example of a trust_mark_owners Claim: "trust_mark_owners": { "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf": { "sub": "https://refeds.org/sirtfi", "jwks" : { "keys": [ { "alg": "RS256", "e": "AQAB", "kid": "Jlob6qNFuSHj3sfuntz9C_9s...", "kty": "RSA", "n": "_LioMsSeycE4pELlpPYgZluB...", "use": "sig" } ] } } } Figure 15: Example trust_mark_owners Claim Hedberg, et al. Standards Track [Page 56] OpenID Federation 1.1 February 2026 7.2.1. Trust Mark Delegation JWT A Trust Mark Delegation JWT is a signed JWT issued by a Trust Mark Owner that identifies a legitimate delegated issuer of Trust Marks with a particular identifier. A Trust Mark delegation JWT MUST be explicitly typed, by setting the typ header parameter to trust-mark-delegation+jwt to prevent cross- JWT confusion, per Section 3.11 of [RFC8725]. Trust Mark delegation JWTs without a typ header parameter or with a different typ value MUST be rejected. It is signed with a Federation Entity Key. Trust Mark delegation JWTs MUST include the kid (Key ID) header parameter with its value being the Key ID of the signing key used. The Claims in a Trust Mark delegation JWT are: iss REQUIRED. String. The owner of the Trust Mark. sub REQUIRED. String. The Entity this delegation applies to. trust_mark_type REQUIRED. String. The identifier for the type of the Trust Mark. iat REQUIRED. Number. Time when this delegation was issued. This is expressed as Seconds Since the Epoch, per [RFC7519]. exp OPTIONAL. Number. Time when this delegation stops being valid. This is expressed as Seconds Since the Epoch, per [RFC7519]. If not present, it means that the delegation does not expire. ref OPTIONAL. String. URL that points to human-readable information connected to the Trust Mark. Additional Claims MAY be defined and used in conjunction with the Claims above. 7.2.2. Validating a Trust Mark Delegation Validating a Trust Mark Delegation means validating a Trust Mark Delegation instance represented by a specific signed JWT. Hedberg, et al. Standards Track [Page 57] OpenID Federation 1.1 February 2026 Henceforth, "delegation" is used as a shorthand for a Trust Mark Delegation JWT. The Trust Anchor referenced below is a Trust Anchor that has been successfully used when establishing trust in the Trust Mark Issuer. To validate a delegation, the following validation steps MUST be performed. Please note that if any of these validation checks fail, the entire validation process fails and the delegation is considered invalid. 1. The delegation MUST be a signed JWT 2. The delegation MUST have a typ header with the value trust-mark- delegation+jwt 3. The delegation MUST have an alg (algorithm) header parameter with a value that is an acceptable JWS signing algorithm; it MUST NOT be none 4. The Entity Identifier of the Trust Mark Issuer MUST match the value of sub in the delegation 5. The Entity Identifier of the Trust Mark Owner MUST match the value of iss in the delegation. 6. The current time MUST be after the time represented by the iat (issued at) Claim in the delegation (possibly allowing for some small leeway to account for clock skew). 7. If the exp (expiration) Claim is present in the delegation, the current time MUST be before the time it represents (possibly allowing for some small leeway to account for clock skew). 8. The value of the Claim trust_mark_type in the delegation MUST be the same as the value of the Claim trust_mark_type in the Trust Mark. 9. The delegation's signature MUST validate using one of the Trust Mark Owner's keys identified by the value of the header parameter kid. The Trust Mark Owner's keys can be found in the trust_mark_owners Claim in the Trust Anchor's Entity Configuration. 7.3. Validating a Trust Mark Validating a Trust Mark means validating a Trust Mark instance represented by a specific signed JWT. It is NOT about validating whether a Trust Mark of a particular kind can exist or not. Hedberg, et al. Standards Track [Page 58] OpenID Federation 1.1 February 2026 The trust in the Trust Mark Issuer comes before the trust in the trust mark. If the Trust Mark Issuer is not trusted then the trust mark cannot be trusted. An Entity MUST therefore establish trust in the Trust Mark Issuer by following the procedure defined in Section 10 prior to starting the Trust Mark validation process defined below. Henceforth, "instance" is used as a shorthand for Trust Mark instance. The Trust Anchor referenced below is a Trust Anchor that has been successfully used when establishing trust in the Trust Mark Issuer. To validate an instance, the following validation steps MUST be performed. Please note that if any of these validation checks fail, the entire validation process fails and the instance is considered invalid. 1. The instance MUST be a signed JWT 2. The instance MUST have a typ header with the value trust-mark+jwt 3. The instance MUST have an alg (algorithm) header parameter with a value that is an acceptable JWS signing algorithm; it MUST NOT be none. 4. The Entity Identifier of the Entity whose Entity Configuration contains the instance MUST match the value of the Claim sub in the Trust Mark. 5. The current time MUST be after the time represented by the iat (issued at) Claim (possibly allowing for some small leeway to account for clock skew). 6. The current time MUST be before the time represented by the exp (expiration) Claim (possibly allowing for some small leeway to account for clock skew). 7. The instance's signature MUST validate using the Trust Mark issuer's key identified by the kid value. 8. If the trust_mark_type of the instance appears in the trust_mark_owners Claim in the Trust Anchor's Entity Configuration, then the instance MUST contain a delegation Claim. 9. If there is a delegation Claim in the instance, the value of that Claim MUST be validated according to Section 7.2.2. Hedberg, et al. Standards Track [Page 59] OpenID Federation 1.1 February 2026 If Trust Marks are issued without an expiration time, it is RECOMMENDED that a mechanism be provided to validate them, such as the Trust Mark Status endpoint and/or the Trust Marked Entities Listing endpoint. As an alternative to the above procedure for validating Trust Marks, implementations MAY use the Trust Mark Status endpoint to verify that the Trust Mark is valid and still active, as described in Section 8.4. 7.4. Trust Mark Examples A non-normative example of a trust_marks Claim in the JWT Claims Set for an Entity Configuration is: Hedberg, et al. Standards Track [Page 60] OpenID Federation 1.1 February 2026 { "iss": "https://rp.example.it/spid", "sub": "https://rp.example.it/spid", "iat": 1516239022, "exp": 1516843822, "trust_marks": [ { "trust_mark_type": "https://www.spid.gov.it/certification/rp", "trust_mark": "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoia29 zR20yd3VaaDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9. eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8 vcnAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYX JrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL 3JwIiwibG9nb191cmkiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMv Y3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl hLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3ZlcnNpb25lLWNvcnJlbn RlLyJ9. L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJW QBdZpjxnHBBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzS an5nOmkxuAtMinU8k_-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0Y AvbMlq2pPWO5OWKdZhiFRMSprwh0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2f XShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nIkp6W-V4jCBOpxp7Yo8LZ30o_xpE OzGTIECGWVR86azOAlwVC8XSiAA" } ], "metadata": { "openid_relying_party": { "application_type": "web", "client_registration_types": ["automatic"], "client_name": "https://rp.example.it/spid", "contacts": [ "ops@rp.example.it" ] } } } Figure 16: Trust Mark in an Entity Configuration JWT Claims Set An example of a decoded Trust Mark payload issued to an RP, attesting to conformance to a national public service profile: Hedberg, et al. Standards Track [Page 61] OpenID Federation 1.1 February 2026 { "trust_mark_type": "https://mushrooms.federation.example.com/openid_relying_party/public/", "iss": "https://epigeo.tm-issuer.example.it", "sub": "https://porcino.example.com/rp", "iat": 1579621160, "organization_name": "Porcino Mushrooms & Co.", "policy_uri": "https://porcino.example.com/privacy_policy", "tos_uri": "https://porcino.example.com/info_policy", "service_documentation": "https://porcino.example.com/api/v1/get/services", "ref": "https://porcino.example.com/documentation/manuale_operativo.pdf" } Figure 17: Trust Mark for a National Profile An example of a decoded Trust Mark payload issued to an RP, attesting to its conformance to the rules for data management of underage users: { "trust_mark_type": "https://mushrooms.federation.example.com/openid_relying_party/private/under-age", "iss": "https://trustissuer.pinarolo.example.it", "sub": "https://vavuso.example.com/rp", "iat": 1579621160, "organization_name": "Pinarolo Suillus luteus", "policy_uri": "https://vavuso.example.com/policy", "tos_uri": "https://vavuso.example.com/tos" } Figure 18: Trust Mark Issued to an RP An example of a decoded Trust Mark payload attesting a stipulation of an agreement between two organization's Entities: { "trust_mark_type": "https://mushrooms.federation.example.com/arrosto/agreements", "iss": "https://agaricaceae.example.it", "sub": "https://coppolino.example.com", "iat": 1579621160, "logo_uri": "https://coppolino.example.com/sgd-cmyk-150dpi-90mm.svg", "organization_type": "public", "id_code": "123456", "email": "info@coppolino.example.com", "organization_name#it": "Mazza di Tamburo", "policy_uri#it": "https://coppolino.example.com/privacy_policy", "tos_uri#it": "https://coppolino.example.com/info_policy", "service_documentation": "https://coppolino.example.com/api/v1/get/services", "ref": "https://agaricaceae.example.it/documentation/agaricaceae.pdf" } Hedberg, et al. Standards Track [Page 62] OpenID Federation 1.1 February 2026 Figure 19: Trust Mark Attesting to an Agreement Between Entities An example of a decoded Trust Mark payload asserting conformance to a security profile: { "trust_mark_type": "https://mushrooms.federation.example.com/ottimo/commestibile", "iss": "https://cantharellus.cibarius.example.org", "sub": "https://gallinaccio.example.com/op", "iat": 1579621160, "logo_uri": "https://cantharellus.cibarius/static/images/cantharellus-cibarius.svg", "ref": "https://cantharellus.cibarius/cantharellus/cibarius" } Figure 20: Trust Mark Asserting Conformance to a Security Profile An example of a decoded self-signed Trust Mark: { "trust_mark_type": "https://mushrooms.federation.example.com/trust-marks/self-signed", "iss": "https://amanita.muscaria.example.com", "sub": "https://amanita.muscaria.example.com", "iat": 1579621160, "logo_uri": "https://amanita.muscaria.example.com/img/amanita-mus.svg", "ref": "https://amanita.muscaria.example.com/uploads/cookbook.zip" } Figure 21: Self-Signed Trust Mark An example of a third-party accreditation authority for Trust Marks: { "iss": "https://swamid.se", "sub": "https://umu.se/op", "iat": 1577833200, "exp": 1609369200, "trust_mark_type": "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf" } Figure 22: Third-Party Accreditation Authority for Trust Marks Hedberg, et al. Standards Track [Page 63] OpenID Federation 1.1 February 2026 7.5. Trust Mark Delegation Example A non-normative example of a trust_marks Claim in the JWT Claims Set for an Entity Configuration in which the Trust Mark is issued by an Entity that issues Trust Marks on behalf of another Entity. The fact that a Trust Mark is issued by a Trust Mark Issuer that is not the owner of the Trust Mark is expressed by including a delegation Claim in the Trust Mark, whose value is a signed JWT. { "delegation": "eyJ0eXAiOiJ0cnVzdC1tYXJrLWRlbGVnYXRpb24rand0IiwiYWxnIjoiUl MyNTYiLCJraWQiOiJrb3NHbTJ3dVpoOURHbU54QXRrdU80MHBQanBMMy1qQ 2YxTi1xUE8tWWVVIn0. eyJzdWIiOiJodHRwczovL3RtaS5leGFtcGxlLm9yZyIsInRydXN0X21hcmt fdHlwZSI6Imh0dHBzOi8vcmVmZWRzLm9yZy9zaXJ0ZmkiLCJpc3MiOiJodH RwczovL3RtX293bmVyLmV4YW1wbGUub3JnIiwiaWF0IjoxNzI1MTc2MzAyfQ. ao0rWGpVjEgpNyFxsKawps8q71eYnp78TzRdY4P52 CT8QX6etXt-2L2Z1Vw5A6jx2mhjpPwWi_sOxfiOSA5TugJfN0Gbwj7teTzM 0IMciuasCWgnLrKyLZjS147ZE50I9e9P8Ot8UQwhmXcLiuwsbDxSdqM4pVp 75lfWnmzPH0L2pDZG5COFgIgSOAlK3TVMBOR8fziF-VmWNPzAfB0lSc-hjH -7q66GyT43o3Exnm6DsoLxyB8bxG99BQltLxURDT90CzM6szGcF3OG64Rbe 0I4lT_LAOfvhlrRbT56eK4sJNCsbVbGnDBfFmyfB_HIeBMGP0L7T5JPMOUU 9bjIlA", "iat": 1725176302, "trust_mark_type": "https://refeds.org/sirtfi", "sub": "https://entity.example.org", "exp": 1727768302, "iss": "https://tmi.example.org" } Figure 23: Example JWT Claims Set of a Trust Mark using Delegation JWS Header Parameters for the Trust Mark delegation JWT in the "delegation" Claim above: { "typ": "trust-mark-delegation+jwt", "alg": "RS256", "kid": "kosGm2wuZh9DGmNxAtkuO40pPjpL3-jCf1N-qPO-YeU" } Figure 24: Trust Mark Delegation JWT JWS Header Parameters JWT Claims Set of the Trust Mark delegation JWT in the "delegation" Claim above: Hedberg, et al. Standards Track [Page 64] OpenID Federation 1.1 February 2026 { "sub": "https://tmi.example.org", "trust_mark_type": "https://refeds.org/sirtfi", "iss": "https://tm_owner.example.org", "iat": 1725176302 } Figure 25: Trust Mark Delegation JWT Claim Set 8. Federation Endpoints The federation endpoints of an Entity can be found in the configuration response as described in Section 9 or by other means. For all federation endpoints, additional request parameters beyond those initially specified MAY be defined and used. If they are not understood, they MUST be ignored. 8.1. Fetching a Subordinate Statement The fetch endpoint is used to collect Subordinate Statements one-by- one when assembling Trust Chains. An Entity with Subordinates MUST expose a fetch endpoint. An Entity MUST publish Subordinate Statements about its Immediate Subordinates via its fetch endpoint. The fetch endpoint location is published in the Entity's federation_entity metadata in the federation_fetch_endpoint parameter defined in Section 5.1.1. Since this endpoint is used when building and validating Trust Chains, its location MUST be available before metadata and metadata policies from Superiors can be applied. Therefore, this endpoint MUST be published directly in Entity Configuration metadata and not in Subordinate Statements. To fetch a Subordinate Statement, one needs to know the identifier of the Entity to ask (the issuer), the fetch endpoint of that Entity, and the Entity Identifier of the subject of the Subordinate Statement. The issuer is normally the Immediate Superior of the subject of the Subordinate Statement. 8.1.1. Fetch Subordinate Statement Request When client authentication is not used, the request MUST be an HTTP request using the GET method to a fetch endpoint with the following query parameter, encoded in application/x-www-form-urlencoded format. The request is made to the fetch endpoint of the specified issuer. Hedberg, et al. Standards Track [Page 65] OpenID Federation 1.1 February 2026 sub REQUIRED. The Entity Identifier of the subject for which the Subordinate Statement is being requested. When client authentication is used, the request MUST be an HTTP request using the POST method, with the parameters passed in the POST body. The following is a non-normative example of an HTTP GET request for a Subordinate Statement from edugain.org about https://sunet.se: GET /federation_fetch_endpoint? sub=https%3A%2F%2Fsunet%2Ese HTTP/1.1 Host: edugain.org Figure 26: API Request for a Subordinate Statement 8.1.2. Fetch Subordinate Statement Response A successful response MUST use the HTTP status code 200 with the content type application/entity-statement+jwt, to make it clear that the response contains an Entity Statement. If it is an error response, it will be a JSON object and the content type MUST be application/json. If the fetch endpoint cannot provide data for the requested sub parameter, returning the not_found error code is RECOMMENDED. If the sub parameter references the Entity Identifier of the Issuing Entity, returning the invalid_request error code is RECOMMENDED. See more about error responses in Section 8.9. The following is a non-normative example of the JWT Claims Set for a fetch response: Hedberg, et al. Standards Track [Page 66] OpenID Federation 1.1 February 2026 { "iss": "https://edugain.org", "sub": "https://sunet.se", "exp": 1568397247, "iat": 1568310847, "source_endpoint": "https://edugain.org/federation_fetch_endpoint", "jwks": { "keys": [ { "e": "AQAB", "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...", "kty": "RSA", "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..." } ] }, "metadata":{ "federation_entity": { "organization_name": "SUNET" } } "metadata_policy": { "openid_provider": { "subject_types_supported": { "value": [ "pairwise" ] }, "token_endpoint_auth_methods_supported": { "default": [ "private_key_jwt" ], "subset_of": [ "private_key_jwt", "client_secret_jwt" ], "superset_of": [ "private_key_jwt" ] } } } } Figure 27: Fetch Response JWT Claims Set Hedberg, et al. Standards Track [Page 67] OpenID Federation 1.1 February 2026 8.2. Subordinate Listing The listing endpoint is exposed by Federation Entities acting as a Trust Anchor, Intermediate, or Trust Mark Issuer. The endpoint lists the Immediate Subordinates about which the Trust Anchor, Intermediate, or Trust Mark Issuer issues Entity Statements. As a Trust Mark Issuer, the endpoint MAY list the Immediate Subordinates for which Trust Marks have been issued and are still valid, if the issuer exposing this endpoint supports Trust Mark filtering, as defined below. In both cases, the list contained in the result MAY be a very large list. The list endpoint location is published in the Entity's federation_entity metadata in the federation_list_endpoint parameter defined in Section 5.1.1. This endpoint MUST be published directly in Entity Configuration metadata and not in Subordinate Statements. The following example shows a tree of Entities belonging to the same federation including the Trust Anchor, Intermediate Entities, and Leaf Entities, discovered and collected through the Subordinate listing endpoints: Hedberg, et al. Standards Track [Page 68] OpenID Federation 1.1 February 2026 +----------------------+ | Trust Anchor | +----------------------+ +---------------+ Subordinate Listing +--------------+ | +----------+-----------+ | | | | | | | | | | | | | | | | +------v-------+ +----------v-----------+ +------v-------+ | Leaf | | Intermediate | | Leaf | +--------------+ +----------------------+ +--------------+ +----+ Subordinate Listing | | +------------+---------+ | | | | | | +----------v-----------+ | | Intermediate | | +----------------------+ | | Subordinate Listing | | +-+---------+----------+ | | | | | | | +-------v--+ +v--------+ +--v------+ | Leaf | | Leaf | | Leaf | +----------+ +---------+ +---------+ Figure 28: Tree of Entities in a Federation Collected through Subordinate Listing Endpoints 8.2.1. Subordinate Listing Request When client authentication is not used, the request MUST be an HTTP request using the GET method to a list endpoint with the following query parameters, encoded in application/x-www-form-urlencoded format. Hedberg, et al. Standards Track [Page 69] OpenID Federation 1.1 February 2026 entity_type OPTIONAL. The value of this parameter is an Entity Type Identifier. If the responder knows the Entity Types of its Immediate Subordinates, the result MUST be filtered to include only those that include the specified Entity Type. When multiple entity_type parameters are present, for example entity_type=openid_provider&entity_type=openid_relying_party, the result MUST be filtered to include all specified Entity Types. If the responder does not support this feature, it MUST use the HTTP status code 400 and the content type application/json, with the error code unsupported_parameter. trust_marked OPTIONAL. Boolean. If the parameter trust_marked is present and set to true, the result contains only the Immediate Subordinates for which at least one Trust Mark has been issued and is still valid. If the responder does not support this feature, it MUST use the HTTP status code 400 and set the content type to application/json, with the error code unsupported_parameter. trust_mark_type OPTIONAL. The value of this parameter is the identifier for the type of the Trust Mark. If the responder has issued Trust Marks with the specified Trust Mark type identifier, the list in the response is filtered to include only the Immediate Subordinates for which that Trust Mark type identifier has been issued and is still valid. If the responder does not support this feature, it MUST use the HTTP status code 400 and set the content type to application/json, with the error code unsupported_parameter. intermediate OPTIONAL. Boolean. If the parameter intermediate is present and set to true, then if the responder knows whether its Immediate Subordinates are Intermediates or not, the result MUST be filtered accordingly. If the responder does not support this feature, it MUST use the HTTP status code 400 and the content type application/json, with the error code unsupported_parameter. When client authentication is used, the request MUST be an HTTP request using the POST method, with the parameters passed in the POST body. The following is a non-normative example of an HTTP GET request for a list of Immediate Subordinates: GET /list HTTP/1.1 Host: sunet.se Hedberg, et al. Standards Track [Page 70] OpenID Federation 1.1 February 2026 Figure 29: Subordinate Listing Request 8.2.2. Subordinate Listing Response A successful response MUST use the HTTP status code 200 with the content type application/json, containing a JSON array with the known Entity Identifiers. An error response is as defined in Section 8.9. The following is a non-normative example of a response containing the Immediate Subordinate Entities: 200 OK Content-Type: application/json [ "https://ntnu.andreas.labs.uninett.no", "https://blackboard.ntnu.no/openid/callback", "https://serviceprovider.andreas.labs.uninett.no/application17" ] Figure 30: Subordinate Listing Response 8.3. Resolve Entity An Entity MAY use a resolve endpoint to fetch Resolved Metadata, the Trust Chain used, and Trust Marks for an Entity. The resolver fetches the subject's Entity Configuration, assembles a Trust Chain that starts with the subject's Entity Configuration and ends with the specified Trust Anchor's Entity Configuration, verifies the Trust Chain, and then applies all the policies present in the Trust Chain to the subject's metadata. The resolver MUST verify that all present Trust Marks with identifiers recognized within the Federation are active. The response set MUST include only verified Trust Marks. The resolve endpoint location is published in the Entity's federation_entity metadata in the federation_resolve_endpoint parameter defined in Section 5.1.1. 8.3.1. Resolve Request When client authentication is not used, the request MUST be an HTTP request using the GET method to a resolve endpoint with the following query parameters, encoded in application/x-www-form-urlencoded format. Hedberg, et al. Standards Track [Page 71] OpenID Federation 1.1 February 2026 sub REQUIRED. The Entity Identifier of the Entity whose resolved data is requested. trust_anchor REQUIRED. The Trust Anchor that the resolve endpoint MUST use when resolving the metadata. The value is an Entity Identifier. The trust_anchor request parameter MAY occur multiple times, in which case, the resolver MAY return a successful resolve response using any of the Trust Anchor values provided. entity_type OPTIONAL. A specific Entity Type to resolve. Its value is an Entity Type Identifier, as specified in Section 5.1. If this parameter is not present, then all Entity Types are returned. The entity_type request parameter MAY occur multiple times, in which case, data for each Entity Type whose Entity Type Identifier is in an entity_type parameter value is returned. When client authentication is used, the request MUST be an HTTP request using the POST method, with the parameters passed in the POST body. The following is a non-normative example of a Resolve Request: GET /resolve? sub=https%3A%2F%2Fop.example.it%2Fspid& entity_type=openid_provider& trust_anchor=https%3A%2F%2Fswamid.se HTTP/1.1 Host: sunet.se Figure 31: Resolve Request 8.3.2. Resolve Response A successful response MUST use the HTTP status code 200 with the content type application/resolve-response+jwt, containing Resolved Metadata and verified Trust Marks. The response is a signed JWT that is explicitly typed by setting the typ header parameter to resolve-response+jwt to prevent cross-JWT confusion, per Section 3.11 of [RFC8725]. Resolve responses without a typ header parameter or with a different typ value MUST be rejected. It is signed with a Federation Entity Key. Hedberg, et al. Standards Track [Page 72] OpenID Federation 1.1 February 2026 The resolve response JWT MUST include the kid (Key ID) header parameter with its value being the Key ID of the signing key used. The resolve response JWT MUST return the Trust Chain from the subject to the Trust Anchor in its trust_chain parameter. The resolve response MAY also return the Trust Chain from its issuer to the Trust Anchor in the trust_chain JWS header parameter, as specified in Section 4.3. When this is present, the Trust Anchor in the Trust Chain MUST match the Trust Anchor requested in the related request in the trust_anchor parameter. An issuer that provides its Trust Chain within the resolve response makes it evident that it is part of the same federation as the subject of the response. Thus, when the Trust Chains of both the issuer and the subject are available and the Federation Historical Keys endpoint is provided by the Trust Anchor, the resolve response becomes a long-lived attestation; it can be always verified, even when the Federation Keys change in the future. The response SHOULD contain the aud Claim only if the requesting party is authenticated as described in Section 8.8, in which case, the value MUST be the Entity Identifier of the requesting party and MUST NOT include any other values. The Claims in a resolve response are: iss REQUIRED. String. Entity Identifier of the issuer of the resolve response. sub REQUIRED. String. Entity Identifier of the subject of the resolve response. iat REQUIRED. Number. Time when this resolution was issued. This is expressed as Seconds Since the Epoch, per [RFC7519]. exp REQUIRED. Number. Time when this resolution is no longer valid. This is expressed as Seconds Since the Epoch, per [RFC7519]. It MUST be the minimum of the exp value of the Trust Chain from which the resolve response was derived, as well as any Trust Mark included in the response. Hedberg, et al. Standards Track [Page 73] OpenID Federation 1.1 February 2026 metadata REQUIRED. JSON object containing the subject's Resolved Metadata, according to the requested type and expressed in the metadata format defined in Section 3.1.1. trust_chain REQUIRED. Array containing the sequence of Entity Statements that compose the Trust Chain, starting with the subject and ending with the selected Trust Anchor. trust_marks OPTIONAL. Array of objects, each representing a Trust Mark, as defined in Section 3.1.2. Only valid Trust Marks that have been issued by Trust Mark issuers trusted by the Trust Anchor to issue such Trust Marks MAY appear in the resolver response. Additional Claims MAY be defined and used in conjunction with the Claims above. An error response is as defined in Section 8.9. The following is a non-normative example of the JWT Claims Set for a resolve response: { "iss": "https://resolver.spid.gov.it", "sub": "https://op.example.it/spid", "iat": 1516239022, "exp": 1516843822, "metadata": { "openid_provider": { "contacts": ["legal@example.it", "technical@example.it"], "logo_uri": "https://op.example.it/static/img/op-logo.svg", "op_policy_uri": "https://op.example.it/en/about-the-website/legal-information", "federation_registration_endpoint": "https://op.example.it/spid/fedreg", "authorization_endpoint": "https://op.example.it/spid/authorization", "token_endpoint": "https://op.example.it/spid/token", "response_types_supported": [ "code", "code id_token", "token" ], "grant_types_supported": [ "authorization_code", "urn:ietf:params:oauth:grant-type:jwt-bearer" Hedberg, et al. Standards Track [Page 74] OpenID Federation 1.1 February 2026 ], "subject_types_supported": ["pairwise"], "id_token_signing_alg_values_supported": ["RS256"], "issuer": "https://op.example.it/spid", "jwks": { "keys": [ { "kty": "RSA", "use": "sig", "n": "1Ta-sE ...", "e": "AQAB", "kid": "FANFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs" } ] } } }, "trust_marks": [ {"trust_mark_type": "https://www.spid.gov.it/certification/op/", "trust_mark": "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiOH hzdUtXaVZmd1NnSG9mMVRlNE9VZGN5NHE3ZEpyS2ZGUmxPNXhoSElhMCJ9. eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi 8vb3AuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9t YXJrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW 9uL29wLyIsImxvZ29fdXJpIjoiaHR0cHM6Ly93d3cuYWdpZC5nb3YuaXQvdGhl bWVzL2N1c3RvbS9hZ2lkL2xvZ28uc3ZnIiwicmVmIjoiaHR0cHM6Ly9kb2NzLm l0YWxpYS5pdC9pdGFsaWEvc3BpZC9zcGlkLXJlZ29sZS10ZWNuaWNoZS1vaWRj L2l0L3N0YWJpbGUvaW5kZXguaHRtbCJ9. xyz-PDQ_..." } ], "trust_chain" : [ "eyJhbGciOiJSUzI1NiIsImtpZCI6Ims1NEhRdERpYnlHY3M5WldWTWZ2aUhm ...", "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ...", "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ..." ] } Figure 32: Resolve Response JWT Claims Set Hedberg, et al. Standards Track [Page 75] OpenID Federation 1.1 February 2026 8.3.3. Trust Considerations The basic assumption of this specification is that an Entity should have direct trust in no party except the Trust Anchor and its own capabilities. However, Entities MAY establish a kind of transitive trust in other Entities. For example, the Trust Anchor states who its Immediate Subordinates are, and Entities MAY choose to trust them. If a party uses the resolve service of another Entity to obtain federation data, it is trusting the resolver to perform validation of the cryptographically protected metadata correctly and to provide it with authentic results. 8.4. Trust Mark Status This enables determining whether a Trust Mark Instance that has been issued to an Entity is still active. The query MUST be sent to the Trust Mark Issuer. The Trust Mark Status endpoint location is published in the Entity's federation_entity metadata in the federation_trust_mark_status_endpoint parameter defined in Section 5.1.1. This endpoint MUST be published directly in Entity Configuration metadata and not in Subordinate Statements. 8.4.1. Trust Mark Status Request The request MUST be an HTTP request using the POST method to a Trust Mark Status endpoint with the following parameter, encoded in application/x-www-form-urlencoded format. trust_mark REQUIRED. The Trust Mark to be validated. When client authentication is used, the request MUST be an HTTP request using the POST method, with the parameters passed in the POST body. The following is a non-normative example of a Trust Mark Status request: POST /federation_trust_mark_status_endpoint HTTP/1.1 Host: op.example.org Content-Type: application/x-www-form-urlencoded trust_mark=eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6 ... Figure 33: Trust Mark Status Request Hedberg, et al. Standards Track [Page 76] OpenID Federation 1.1 February 2026 8.4.2. Trust Mark Status Response A successful response MUST use the HTTP status code 200 with the content type application/trust-mark-status-response+jwt, containing a signed JWT that is a Trust Mark Status Response. The Trust Mark Status Response is a signed JWT that is explicitly typed by setting the typ header parameter to trust-mark-status- response+jwt to prevent cross-JWT confusion, per Section 3.11 of [RFC8725]. Trust Mark Status Responses without a typ header parameter or with a different typ value MUST be rejected. It is signed with a Federation Entity Key. The Trust Mark Status Response JWT MUST include the kid (Key ID) header parameter with its value being the Key ID of the signing key used. The JWT Claims Set of the Trust Mark Status JWT is a JSON object containing the following Claims: iss REQUIRED. String. Entity Identifier of the issuer of the Trust Mark Status JWT. iat REQUIRED. Number. Time when this Trust Mark Status JWT was issued. This is expressed as Seconds Since the Epoch, per [RFC7519]. trust_mark REQUIRED. String. The Trust Mark JWT that this status response is about. status REQUIRED. Case-sensitive string value indicating the status of the Trust Mark. Values defined by this specification are: active The Trust Mark is active expired The Trust Mark has expired revoked The Trust Mark was revoked invalid Signature validation failed or another error was detected Hedberg, et al. Standards Track [Page 77] OpenID Federation 1.1 February 2026 Additional status values MAY be defined and used in addition to those above. Additional Trust Mark Status JWT Claims MAY be defined and used in addition to those listed above. The following is a non-normative example of the JWT Claims Set for a response with the status active: { "iss": "https://www.agid.gov.it", "trust_mark": "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2 lkIjoia29zR20yd3VaaDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9. eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8 vcnAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYX JrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL 3JwIiwibG9nb191cmkiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMv Y3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl hLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3ZlcnNpb25lLWNvcnJlbn RlLyJ9. L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJW QBdZpjxnHBBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzS an5nOmkxuAtMinU8k_-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0Y AvbMlq2pPWO5OWKdZhiFRMSprwh0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2f XShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nIkp6W-V4jCBOpxp7Yo8LZ30o_xpE OzGTIECGWVR86azOAlwVC8XSiAA", "iat": 1759897995, "status": "active" } Figure 34: Active Trust Mark Status Response JWT Claims Set The following is a non-normative example of the JWT Claims Set for a response with the status revoked: Hedberg, et al. Standards Track [Page 78] OpenID Federation 1.1 February 2026 { "iss": "https://www.agid.gov.it", "trust_mark": "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2 lkIjoia29zR20yd3VaaDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9. eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8 vcnAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYX JrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL 3JwIiwibG9nb191cmkiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMv Y3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl hLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3ZlcnNpb25lLWNvcnJlbn RlLyJ9. L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJW QBdZpjxnHBBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzS an5nOmkxuAtMinU8k_-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0Y AvbMlq2pPWO5OWKdZhiFRMSprwh0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2f XShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nIkp6W-V4jCBOpxp7Yo8LZ30o_xpE OzGTIECGWVR86azOAlwVC8XSiAA", "iat": 1759898057, "status": "revoked" } Figure 35: Revoked Trust Mark Status Response JWT Claims Set An error response to a Trust Mark Status request is as defined in Section 8.9. If the Trust Mark Issuer receives a request about the status of an unknown Trust Mark, something it did not issue or is not aware of, it MUST respond with an HTTP status code 404 (Not found). 8.5. Trust Marked Entities Listing The Trust Marked Entities Listing endpoint is exposed by Trust Mark Issuers and lists all the Entities for which Trust Marks have been issued and are still valid. The Trust Marked Entities Listing endpoint location is published in the Entity's federation_entity metadata in the federation_trust_mark_list_endpoint parameter defined in Section 5.1.1. 8.5.1. Trust Marked Entities Listing Request When client authentication is not used, the request MUST be an HTTP request using the GET method to a list endpoint with the following query parameters, encoded in application/x-www-form-urlencoded format. Hedberg, et al. Standards Track [Page 79] OpenID Federation 1.1 February 2026 trust_mark_type REQUIRED. Identifier for the type of the Trust Mark. If the responder has issued Trust Marks with the specified Trust Mark type identifier, the list in the response is filtered to include only the Entities for which that Trust Mark type identifier has been issued and is still valid. sub OPTIONAL. The Entity Identifier of the Entity to which the Trust Mark was issued. The list obtained in the response MUST be filtered to only the Entity matching this value. When client authentication is used, the request MUST be an HTTP request using the POST method, with the parameters passed in the POST body. The following is a non-normative example of an HTTP GET request for a list of Trust Marked Entities: GET /trust_marked_list?trust_mark_type=https%3A%2F%2Ffederation.example.org%2Fopenid_relying_party%2Fprivate%2Funder-age HTTP/1.1 Host: trust-mark-issuer.example.org Figure 36: Trust Marked Entities Listing Request 8.5.2. Trust Marked Entities Listing Response A successful response MUST use the HTTP status code 200 with the content type application/json, containing a JSON array with Entity Identifiers. An error response is as defined in Section 8.9. The following is a non-normative example of a response, containing the Trust Marked Entities: 200 OK Content-Type: application/json [ "https://blackboard.ntnu.no/openid/rp", "https://that-rp.example.org" ] Figure 37: Trust Marked Entities Listing Response Hedberg, et al. Standards Track [Page 80] OpenID Federation 1.1 February 2026 8.6. Trust Mark Endpoint The Trust Mark endpoint is exposed by a Trust Mark Issuer to provide Trust Marks to subjects. The Trust Mark endpoint location is published in the Entity's federation_entity metadata in the federation_trust_mark_endpoint parameter defined in Section 5.1.1. 8.6.1. Trust Mark Request When client authentication is not used, the request MUST be an HTTP request using the GET method with the following query parameters, encoded in application/x-www-form-urlencoded format. trust_mark_type REQUIRED. Identifier for the type of the Trust Mark. sub REQUIRED. The Entity Identifier of the Entity to which the Trust Mark is issued. When client authentication is used, the request MUST be an HTTP request using the POST method, with the parameters passed in the POST body. The Trust Mark endpoint MAY choose to allow authenticated requests from clients that are not the Trust Mark subject, as indicated by the sub parameter. An example use case is to let a Federation Entity retrieve the Trust Mark for another Entity. The following is a non-normative example of an HTTP request for a Trust Mark with a specific Trust Mark type identifier and subject: GET /trust_mark?trust_mark_type=https%3A%2F%2Fwww.spid.gov.it%2Fcertification%2Frp&sub=https%3A%2F%2Frp.example.it%2Fspid HTTP/1.1 Host: tuber.cert.example.org Figure 38: Trust Mark Request 8.6.2. Trust Mark Response A successful response MUST use the HTTP status code 200 with the content type application/trust-mark+jwt, containing the Trust Mark. If the specified Entity does not have the specified Trust Mark, the response is an error response and MUST use the HTTP status code 404. The following is a non-normative example of a response, containing the Trust Mark for the specified Entity (with line wraps within values for display purposes only): Hedberg, et al. Standards Track [Page 81] OpenID Federation 1.1 February 2026 200 OK Content-Type: application/trust-mark+jwt eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoia29zR20yd3Va aDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9. eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8vcnAuZXhh bXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYXJrX3R5cGUiOiJodHRw czovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL3JwIiwibG9nb191cmkiOiJodHRw czovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMvY3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYi OiJodHRwczovL2RvY3MuaXRhbGlhLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3Zl cnNpb25lLWNvcnJlbnRlLyJ9. L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJWQBdZpjxnH BBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzSan5nOmkxuAtMinU8k_ -aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0YAvbMlq2pPWO5OWKdZhiFRMSprwh 0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2fXShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nI kp6W-V4jCBOpxp7Yo8LZ30o_xpEOzGTIECGWVR86azOAlwVC8XSiAA Figure 39: Trust Mark Response 8.7. Federation Historical Keys Endpoint Each Federation Entity MAY publish its previously used Federation Entity Keys at the historical keys endpoint defined in Section 5.1.1. The purpose of this endpoint is to provide the list of keys previously used by the Federation Entity to provide non-repudiation of statements signed by it after key rotation. This endpoint also discloses the reason for the retraction of the keys and whether they were expired or revoked, including the reason for the revocation. Note that an expired key can be later additionally marked as revoked, to indicate a key compromise event discovered after the expiration of the key. The publishing of the historical keys guarantees that Trust Chains will remain verifiable and usable as inputs to trust decisions after the key expiration, unless the key becomes revoked for a security reason. 8.7.1. Federation Historical Keys Request When client authentication is not used, the request MUST be an HTTP request using the GET method to the federation historical keys endpoint. When client authentication is used, the request MUST be an HTTP request using the POST method, with the client authentication parameters passed in the POST body. Hedberg, et al. Standards Track [Page 82] OpenID Federation 1.1 February 2026 The following is a non-normative example of a historical keys request: GET /federation_historical_keys HTTP/1.1 Host: trust-anchor.example.com Figure 40: Federation Historical Keys Request 8.7.2. Federation Historical Keys Response The response is a signed JWK Set containing the historical keys. It is signed with a Federation Entity Key. A signed JWK Set is a signed JWT with a JWK Set [RFC7517] as its payload. A successful response MUST use the HTTP status code 200 with the content type application/ jwk-set+jwt. Historical keys JWTs are explicitly typed by setting the typ header parameter to jwk-set+jwt to prevent cross-JWT confusion, per Section 3.11 of [RFC8725]. Historical keys JWTs without a typ header parameter or with a different typ value MUST be rejected. Historical keys JWTs MUST include the kid (Key ID) header parameter with its value being the Key ID of the signing key used. The Claims in a historical keys JWT are: iss REQUIRED. String. The Entity's Entity Identifier. iat REQUIRED. Number. Time when this historical keys JWT was issued. This is expressed as Seconds Since the Epoch, per [RFC7519]. keys REQUIRED. Array of JSON objects containing the signing keys for the Entity in JWK format. JWKs in the keys Claim use the following parameters: kid REQUIRED. Parameter used to match a specific key. It is RECOMMENDED that the Key ID be the JWK Thumbprint [RFC7638] of the key using the SHA-256 hash function. iat OPTIONAL. Number. Time when this key was issued. This is expressed as Seconds Since the Epoch, per [RFC7519]. Hedberg, et al. Standards Track [Page 83] OpenID Federation 1.1 February 2026 exp REQUIRED. Number. Expiration time for the key. This is expressed as Seconds Since the Epoch, per [RFC7519], After this time the key MUST NOT be considered valid. revoked OPTIONAL. JSON object that contains the properties of the revocation, as defined below: revoked_at REQUIRED. Time when the key was revoked or must be considered revoked, using the time format defined for the iat Claim in [RFC7519]. reason OPTIONAL. String that identifies the reason for the key revocation, as defined in Section 8.7.3. Additional members of the revoked object MAY be defined and used. Additional Claims MAY be defined and used in conjunction with the Claims above. JWKs in the keys Claim MAY also contain the nbf parameter. For use in Historical Keys, iat and exp are sufficient to establish the key lifetime, making nbf typically superfluous; however, it is registered for use by profiles that may choose to issue keys that do not immediately become valid at the time of issuance. Its definition is: nbf OPTIONAL. Time before which the key is not valid, using the time format defined for the nbf Claim in [RFC7519]. The following is a non-normative example of the JWT Claims Set for a historical keys response: Hedberg, et al. Standards Track [Page 84] OpenID Federation 1.1 February 2026 { "iss": "https://trust-anchor.federation.example.com", "iat": 1666335600, "keys": [ { "kty": "RSA", "n": "5s4qi ...", "e": "AQAB", "kid": "2HnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs", "iat": 1661151600, "exp": 1677052800 }, { "kty": "RSA", "n": "ng5jr ...", "e": "AQAB", "kid": "8KnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMJJr", "iat": 1647932400, "exp": 1663830000, "revoked": { "revoked_at": 1661151600, "reason": "compromised", } } ] } Figure 41: Federation Historical Keys Response JWT Claims Set 8.7.3. Federation Historical Keys Revocation Reasons Federation Entities are strongly encouraged to use a meaningful reason value when indicating the revocation reason for a Federation Entity Key. The reason MAY be omitted instead of using the unspecified value. Below is the definition of the reason values. The following table defines Federation Entity Keys revocation reasons. These reasons are inspired by Section 5.3.1 of [RFC5280]. +-------------+-------------------------------+ | Reason | Description | +-------------+-------------------------------+ | unspecified | General or unspecified reason | | | for the JWK status change. | +-------------+-------------------------------+ Hedberg, et al. Standards Track [Page 85] OpenID Federation 1.1 February 2026 | compromised | The private key is believed | | | to have been compromised. | +-------------+-------------------------------+ | superseded | The JWK is no longer active. | +-------------+-------------------------------+ Table 2: Federation Entity Keys Revocation Reasons. A federation MAY specify and utilize additional reasons depending on the trust or security framework in use. 8.7.4. Rationale for the Federation Historical Keys Endpoint The Federation Historical Keys endpoint solves the problem of verifying historical Trust Chains when the Federation Entity Keys have changed, either due to expiration or revocation. The Federation Historical Keys endpoint publishes the list of public keys used in the past by the Entity. These keys are needed to verify Trust Chains created in the past with Entity keys no longer published in the Entity's Entity Configuration. The Federation Historical Keys endpoint response contains a signed JWT that attests to all the expired and revoked Entity keys. Based on the attributes contained in the Entity Statements that form a Trust Chain, it MAY also be possible to verify the non-federation public keys used in the past by Leaf Entities for signature operations for OpenID Connect requests and responses. For example, an Entity Statement issued for a Leaf MAY also include the jwks Claim for the Leaf's Entity Types, in its metadata or metadata_policy Claims. A simple example: In the following Trust Chain, the Federation Intermediate attests to the Leaf's OpenID Connect RP jwks in the Subordinate Statement issued about the Leaf. The result is a Trust Chain that contains the Leaf's OpenID Connect RP JWK Set, needed to verify historical signature on Request Objects and any other signed JWT issued by the Leaf as an RP. This example Trust Chain contains: 1. an Entity Configuration about the RP published by the RP, 2. a Subordinate Statement about the RP published by Organization A, with the Claim jwks contained in metadata or metadata_policy attesting the Leaf's OpenID Connect RP jwks, and Hedberg, et al. Standards Track [Page 86] OpenID Federation 1.1 February 2026 3. a Subordinate Statement about Organization A published by Federation F. 8.8. Client Authentication at Federation Endpoints Client authentication is not used at any of the federation endpoints, by default. Federations can choose to make client authentication OPTIONAL, REQUIRED, and/or not allowed at particular federation endpoints. Client authentication with private_key_jwt is the default client authentication method to federation endpoints when client authentication is supported. This client authentication method is described in Section 9 of OpenID Connect Core 1.0 [OpenID.Core]. The client authentication JWT MUST be signed with a Federation Entity Key. The audience of the JWT MUST be the Entity Identifier of the Entity whose federation endpoint is being authenticated to. The endpoint MUST NOT accept JWTs containing audience values other than its Entity Identifier. When client authentication is used, the request MUST be an HTTP request using the POST method, with the client authentication and endpoint request parameters passed in the POST body. Federations can choose to also use other client authentication methods. 8.8.1. Client Authentication Metadata for Federation Endpoints Like other OAuth and OpenID endpoints supporting client authentication, this specification defines metadata parameters saying which client authentication methods are supported for each endpoint. These largely parallel the token_endpoint_auth_methods_supported metadata value defined in Section 3 of OpenID Connect Discovery 1.0 [OpenID.Discovery]. Specifically, for each of the federation endpoints defined in Section 5.1.1, parameters named *_auth_methods are defined, where the * represents the federation endpoint names federation_fetch_endpoint, federation_list_endpoint, ..., federation_historical_keys_endpoint. The *_auth_methods metadata parameters list supported client authentication methods for these endpoints, just as token_endpoint_auth_methods_supported does for the Token Endpoint. In addition, the value none MAY be used to indicate that client authentication is not required at the endpoint. So, for instance, this metadata declaration states that requests authenticated with private_key_jwt are REQUIRED at the federation_trust_mark_endpoint: Hedberg, et al. Standards Track [Page 87] OpenID Federation 1.1 February 2026 "federation_trust_mark_endpoint_auth_methods": ["private_key_jwt"] Figure 42: Declaring that Client Authentication is REQUIRED at an Endpoint If omitted, the default value for these methods is ["none"], indicating that only unauthenticated requests are accepted. The endpoint_auth_signing_alg_values_supported metadata parameter lists supported client authentication signing algorithms supported for these endpoints, just as token_endpoint_auth_signing_alg_values_supported does for the Token Endpoint. 8.9. Error Responses If the request was malformed or an error occurred during the processing of the request, the response body SHOULD be a JSON object with the content type application/json. In compliance with [RFC6749], the following standardized error format SHOULD be used: error REQUIRED. Error codes in the IANA "OAuth Extensions Error Registry" [IANA.OAuth.Parameters] MAY be used. In particular, these existing error codes are used by this specification: invalid_request The request is incomplete or does not comply with current specifications. The HTTP response status code SHOULD be 400 (Bad Request). server_error The server encountered an unexpected condition that prevented it from fulfilling the request. The HTTP response status code SHOULD be one in the 5xx range, like 500 (Internal Server Error). temporarily_unavailable The server hosting the federation endpoint is currently unable to handle the request due to temporary overloading or maintenance. The HTTP response status code SHOULD be 503 (Service Unavailable). This specification also defines the following error codes: Hedberg, et al. Standards Track [Page 88] OpenID Federation 1.1 February 2026 invalid_client The Client cannot be authorized or is not a valid participant of the federation. The HTTP response status code SHOULD be 401 (Unauthorized). invalid_issuer The endpoint cannot serve the requested issuer. The HTTP response status code SHOULD be 404 (Not Found). invalid_subject The endpoint cannot serve the requested subject. The HTTP response status code SHOULD be 404 (Not Found). invalid_trust_anchor The Trust Anchor cannot be found or used. The HTTP response status code SHOULD be 404 (Not Found). invalid_trust_chain The Trust Chain cannot be validated. The HTTP response status code SHOULD be 400 (Bad Request). invalid_metadata Metadata or Metadata Policy values are invalid or conflict. The HTTP response status code SHOULD be 400 (Bad Request). not_found The requested Entity Identifier cannot be found. The HTTP response status code SHOULD be 404 (Not Found). unsupported_parameter The server does not support the requested parameter. The HTTP response status code SHOULD be 400 (Bad Request). error_description REQUIRED. Human-readable text providing additional information used to assist the developer in understanding the error that occurred. The following is a non-normative example of an error response: 400 Bad request Content-Type: application/json { "error": "invalid_request", "error_description": "Required request parameter [sub] was missing." } Hedberg, et al. Standards Track [Page 89] OpenID Federation 1.1 February 2026 Figure 43: Example Error Response 9. Obtaining Federation Entity Configuration Information The Entity Configuration of all Trust Anchor and Intermediate Federation Entities MUST be published at their configuration endpoint and the Entity Configuration for Leaf Entities SHOULD be published there. Its location is determined by concatenating the string /.well-known/openid-federation to the Entity Identifier (which MUST use the https scheme and contain a host component and MAY also contain port and path components). For instance, the configuration endpoint for the Entity Identifier https://entity.example is the URL https://entity.example/.well-known/openid-federation. If the Entity Identifier contains a trailing "/" character, it MUST be removed before concatenating /.well-known/openid-federation. Furthermore, any Entity Configuration including the Entity Type Identifier federation_entity MUST be published at its configuration endpoint. While Leaf Federation Entities SHOULD make an Entity Configuration document available at their configuration endpoints, an exception to this requirement is that clients that use a client registration method that results in the server having the client's Entity Configuration MAY omit doing so. For instance, since an RP using Explicit Registration posts its Entity Configuration to the OP during client registration, the OP has everything it needs from the RP. Profiles of this specification MAY define other exceptions for Leaf Entities that do not use the Entity Type Identifier federation_entity and processing rules that accompany them. 9.1. Federation Entity Configuration Request An Entity Configuration document MUST be queried using an HTTP GET request at the previously specified path. In this example, the requesting party would make the following request to the Entity https://op.sunet.se to obtain its Entity Configuration: GET /.well-known/openid-federation HTTP/1.1 Host: op.sunet.se Figure 44: Request for Entity Configuration Hedberg, et al. Standards Track [Page 90] OpenID Federation 1.1 February 2026 9.2. Federation Entity Configuration Response The response is an Entity Configuration. If the Entity is an Intermediate Entity or a Trust Anchor, the response MUST contain metadata for a Federation Entity (federation_entity). A successful response MUST use the HTTP status code 200 with the content type application/entity-statement+jwt, to make it clear that the response contains an Entity Statement. In case of an error, the response is as defined in Section 8.9. The following is a non-normative example JWT Claims Set for a response from an Intermediate Entity: { "iss": "https://sunet.se", "sub": "https://sunet.se", "iat": 1516239022, "exp": 1516843822, "metadata": { "federation_entity": { "contacts": ["ops@sunet.se"], "federation_fetch_endpoint": "https://sunet.se/fetch", "organization_uri": "https://www.sunet.se", "organization_name": "SUNET" }, "jwks": { "keys": [ { "alg": "RS256", "e": "AQAB", "kid": "O-wFRGNsy0-4SR2jbXYwDHy6...", "kty": "RSA", "n": "Qo3n0N0Gv7L8T9I_2sAMc0I4...", "use": "sig" } ] }, "authority_hints": [ "https://edugain.org" ] } Figure 45: Entity Configuration Response JWT Claims Set for an Intermediate The following is a non-normative example JWT Claims Set for a response from an OpenID Provider Entity: Hedberg, et al. Standards Track [Page 91] OpenID Federation 1.1 February 2026 { "iss": "https://op.sunet.se", "sub": "https://op.sunet.se", "iat": 1516239022, "exp": 1516843822, "metadata": { "openid_provider": { "issuer": "https://op.sunet.se", "signed_jwks_uri": "https://op.sunet.se/jwks.jose", "authorization_endpoint": "https://op.sunet.se/authorization", "client_registration_types_supported": [ "automatic", "explicit" ], "grant_types_supported": [ "authorization_code" ], "id_token_signing_alg_values_supported": [ "ES256", "RS256" ], "contacts": ["ops@sunet.se"], "organization_uri": "https://www.sunet.se", "organization_name": "SUNET" "logo_uri": "https://www.sunet.se/sunet/images/32x32.png", "op_policy_uri": "https://www.sunet.se/en/website/legal-information/", "response_types_supported": [ "code" ], "subject_types_supported": [ "pairwise", "public" ], "token_endpoint": "https://op.sunet.se/token", "federation_registration_endpoint": "https://op.sunet.se/fedreg", "token_endpoint_auth_methods_supported": [ "private_key_jwt" ] } }, "jwks": { "keys": [ { "alg": "RS256", "e": "AQAB", Hedberg, et al. Standards Track [Page 92] OpenID Federation 1.1 February 2026 "kid": "yHozfrAd5G-pnmG4e1jCXpfc...", "kty": "RSA", "n": "HIoSq4wkZiEkJDTPHiv7torK...", "use": "sig" } ] }, "authority_hints": [ "https://sunet.se" ] } Figure 46: Entity Configuration Response JWT Claims Set for an OP 10. Resolving the Trust Chain and Metadata An Entity (Party A) that wants to establish trust with another Entity (Party B) MUST have Party B's Entity Identifier and a list of Entity Identifiers of Trust Anchors and their public signing keys. Party A will first have to fetch sufficient Entity Statements to establish at least one chain of trust from Party B to one or more of the Trust Anchors. After that, Party A MUST validate the Trust Chains independently, and if there are multiple valid Trust Chains and if the application demands it, choose one to use. To delegate the Trust Chain evaluation to a trusted third party, the Entity (Party A) that wants to establish trust with another Entity (Party B) MAY use a resolve endpoint, as defined in Section 8.3. 10.1. Fetching Entity Statements to Establish a Trust Chain Depending on the circumstances, Party A MAY be handed Party B's Entity Configuration, or it may have to fetch it by itself. If it needs to fetch it, it will use the process described in Section 9 based on the Entity Identifier of Party B. The next step is to iterate through the list of Intermediates listed in authority_hints, ignoring the authority hints that end in an unknown Trust Anchor, requesting an Entity Configuration from each of the Intermediates. If the received Entity Configuration contains an authority hint, this process is repeated. With the list of all Intermediates and the Trust Anchor, the respective fetch endpoints, as defined in Section 8.1, are used to fetch Entity Statements about the Intermediates and Party B. Hedberg, et al. Standards Track [Page 93] OpenID Federation 1.1 February 2026 Federation participants MUST NOT attempt to fetch Entity Statements they already have obtained during this process to prevent loops. If a loop is detected, the authority hint that led to it MUST NOT be used. A successful operation will return one or more lists of Entity Statements. Each of the lists terminating in a self-signed Entity Statement is issued by a Trust Anchor. If there is no path from Party B to at least one of the trusted Trust Anchors, then the list will be empty and there is no way of establishing trust in Party B's information. How Party A deals with this is out of scope for this specification. The following sequence diagram represents the interactions between the RP, the OP, and the Trust Anchor during a trust evaluation made by the OP about the RP. Relating this to the preceding description, in this diagram, Party A is the OP and Party B is the RP. +-----+ +-----+ +--------------+ | RP | | OP | | Trust Anchor | +-----+ +-----+ +--------------+ | | | | Entity Configuration Request | | |<------------------------------| | | | | | Entity Configuration Response | | |------------------------------>| | | | | | | Evaluates authority_hints | | |-------------------------- | | | | | | |<------------------------- | | | | | | Entity Configuration Request | | |--------------------------------------->| | | | | | Entity Configuration Response | | |<---------------------------------------| | | | | | Obtains Fetch Endpoint | | |----------------------- | | | | | | |<---------------------- | | | | | | Request Subordinate Statement about RP | | |--------------------------------------->| | | | Hedberg, et al. Standards Track [Page 94] OpenID Federation 1.1 February 2026 | | Subordinate Statement about RP | | |<---------------------------------------| | | | | | Evaluates the Trust Chain | | |-------------------------- | | | | | | |<------------------------- | | | | | | Applies Metadata Policies | | |-------------------------- | | | | | | |<------------------------- | | | | | | Applies Constraints | | |-------------------- | | | | | | |<------------------- | | | | | | Derives the RP's Resolved Metadata | | |----------------------------------- | | | | | | |<---------------------------------- | Figure 47: Resolving Trust Chain and Metadata from the Perspective of an OP 10.2. Validating a Trust Chain As described in Section 4, a Trust Chain consists of an ordered list of Entity Statements. So however Party A has acquired the set of Entity Statements, it MUST now verify that it is a proper Trust Chain using the rules laid out in that section. Let us refer to the Entity Statements in the Trust Chain as ES[j], where j = 0,...,i, with 0 being the index of the first Entity Statement and i being the zero-based index of the last. To validate the Trust Chain, the following MUST be done: * For each Entity Statement ES[j], where j = 0,..,i: - Verify that the statement contains all the required Claims. - Verify that iat has a value in the past. - Verify that exp has a value that is in the future. * For ES[0] (the Entity Configuration of the Trust Chain subject), verify that iss == sub. Hedberg, et al. Standards Track [Page 95] OpenID Federation 1.1 February 2026 * For ES[0], verify that its signature validates with a public key in ES[0]["jwks"]. * For each j = 0,...,i-1, verify that ES[j]["iss"] == ES[j+1]["sub"]. * For each j = 0,...,i-1, verify that the signature of ES[j] validates with a public key in ES[j+1]["jwks"]. * For ES[i] (the Trust Anchor's Entity Configuration), verify that the issuer matches the Entity Identifier of the Trust Anchor. * For ES[i], verify that its signature validates with a public key of the Trust Anchor. Verifying the signature is a much more expensive operation than verifying the correctness of the statement and the timestamps. An implementer MAY therefore choose not to verify the signatures until all the other checks have been done. Federation participants MAY cache Entity Statements and signature verification results until they expire, per Section 10.4. After the preceding validation, metadata MUST be resolved to the subject of the Trust Chain, as described in Section 6.1.4. Furthermore, constraints MUST be enforced for each Subordinate Statement of the Trust Chain, as explained in Section 6.2. 10.3. Choosing One of the Valid Trust Chains If multiple valid Trust Chains are found, Party A will need to decide on which one to use. One simple rule would be to prefer a shorter chain over a longer one. Federation participants MAY follow other rules according to local policy. 10.4. Calculating the Expiration Time of a Trust Chain Each Entity Statement in a Trust Chain is signed and MUST have an expiration time (exp). The expiration time of the whole Trust Chain is the minimum (exp) value within the Trust Chain. 10.5. Transient Trust Chain Validation Errors If the federation topology is being updated, for example, when a set of Leaf Entities is moved to a new Intermediate Entity, the Trust Chain validation may fail in a transient manner. Retrying after a period of time may resolve the situation. Hedberg, et al. Standards Track [Page 96] OpenID Federation 1.1 February 2026 10.6. Resolving the Trust Chain and Metadata with a Resolver Note that an alternative method for resolving a Trust Chain for an Entity (Party B) using the methods described above is to use a resolve endpoint, as described in Section 8.3. This lets the resolver do the work that otherwise the Entity (Party A) wanting to establish trust would have to do for itself. 11. Updating Metadata, Key Rollover, and Revocation This specification facilitates smoothly updating metadata and public keys. As described in Section 10.4, each Trust Chain has an expiration time. Federation participants MUST support refreshing a Trust Chain when it expires. How often a participant reevaluates the Trust Chain depends on how quickly it wants to find out that something has changed. 11.1. Federation Key Rollover The expiration time (exp) of an Entity Configuration is used to control how often it needs to be retrieved to fetch an updated set of Federation Keys from its jwks member. 11.2. Key Rollover for a Trust Anchor A Trust Anchor MUST publish an Entity Configuration about itself. The expiration time (exp) set on this Entity Configuration should be chosen such that it ensures that federation participants re-fetch it at reasonable intervals. When a Trust Anchor rolls over its signing keys, it needs to: 1. Add the new keys to the jwks representing the Trust Anchor's signing keys in its Entity Configuration. 2. Keep signing the Entity Configuration and the Entity Statements using the old keys for a long enough time period to allow all Subordinates to have obtained the new keys. 3. Switch to signing with the new keys. 4. After a reasonable time period, remove the old keys. What is regarded as a reasonable time is dependent on the security profile and risk assessment of the Trust Anchor. Hedberg, et al. Standards Track [Page 97] OpenID Federation 1.1 February 2026 11.3. Redundant Retrieval of Trust Anchor Keys It is RECOMMENDED that Federation Operators provide a means of retrieving the public keys for the Trust Anchors it administers that is independent of those Trust Anchors' Entity Configurations. This is intended to provide redundancy in the eventuality of the compromise of the Web PKI [RFC9525] infrastructure underlying retrieval of public keys from Entity Configurations. The keys retrieved via the independent mechanism specified by the Federation Operator SHOULD be compared to those retrieved via the Trust Anchor's Entity Configuration. If they do not match, both SHOULD be retrieved again. If they still do not match, it is indicative of a security or configuration problem. The appropriate remediation steps in that eventuality SHOULD be specified by the Federation Operator. 11.4. Revocation Since the participants in federations are expected to check the Trust Chain on a regular frequent basis, this specification does not define a revocation process. Specific federations MAY make a different choice and will then have to define their own revocation process. 12. OpenID Connect Client Registration Protocol-specific means of performing client registration for OpenID Connect and OAuth 2.0 are defined in Section 12 of [OpenID.Federation.Connect-1.1]. 13. General-Purpose JWT Claims This section defines general-purpose JWT Claims designed to be used by many different JWT profiles. They are also used in specific kinds of JWTs defined by this specification. 13.1. "jwks" (JSON Web Key Set) Claim The jwks (JSON Web Key Set) Claim value is a JWK Set, as defined in [RFC7517]. It is used to convey a set of cryptographic keys. Use of this Claim is OPTIONAL. For instance, the jwks (JSON Web Key Set) Claim might be used to represent a set of signing keys for an application. This Claim is used in this specification as specified in Section 3.1.1 to represent the public keys used to sign the Entity Statement. Hedberg, et al. Standards Track [Page 98] OpenID Federation 1.1 February 2026 13.2. "metadata" Claim The metadata Claim is used for conveying metadata pertaining to the JWT. Its value is a JSON object. The details of the metadata contained are application-specific. Use of this Claim is OPTIONAL. For instance, the metadata Claim might be used to represent a set of endpoint URLs and algorithm identifiers in an API description. This Claim is used in this specification as specified in Section 3.1.1 to represent metadata about the Entity. 13.3. "constraints" Claim The constraints Claim is used for conveying constraints pertaining to the JWT. Its value is a JSON object. The details of the constraints contained are application-specific. Use of this Claim is OPTIONAL. For instance, this Claim is used in this specification as specified in Section 3.1.3 to represent constraints on the Trust Chain for the Entity. 13.4. "crit" (Critical) Claim The crit (critical) Claim indicates that extensions to the set of Claims specified for use in this type of JWT are being used that MUST be understood and processed. It is used in the same way that the crit header parameter is used for extension JOSE header parameters that MUST be understood and processed. Its value is an array listing the Claim Names present in the JWT that use those extensions. If any of the listed Claims are not understood and supported by the recipient, then the JWT is invalid. Producers MUST NOT include Claim Names already specified for use in this type of JWT, duplicate names, or names that do not occur as Claim Names in the JWT in the crit list. Producers MUST NOT use the empty array [] as the crit value. Use of this Claim is OPTIONAL. Section 4 of [RFC7519] states that "Specific applications of JWTs will require implementations to understand and process some claims in particular ways. However, in the absence of such requirements, all claims that are not understood by implementations MUST be ignored." Thus, for the crit (critical) Claim to be effective, the definition for the particular kind of JWT using it MUST specify that crit MUST be understood and processed, as allowed in the statement above. This Claim is used in this specification as specified in Section 3.1.1 to identify Claims not defined by this specification that MUST be understood and processed when used in Entity Statements. Hedberg, et al. Standards Track [Page 99] OpenID Federation 1.1 February 2026 13.5. "ref" (Reference) Claim The ref (reference) Claim is used for conveying the URI for a resource pertaining to the JWT. It plays a similar role in a JWT as the href property does in HTML. The nature of the content at the referenced resource is generally application specific. The ref value is a case-sensitive string containing a URI value. Use of this Claim is OPTIONAL. For instance, a JWT referring to a contract between two parties might use the ref (reference) Claim to refer to a resource at which the contract terms can be read. This Claim is used in this specification as specified in Section 7.1 to provide a URL referring to human- readable information about the issuance of the Trust Mark. 13.6. "delegation" Claim The delegation Claim expresses that authority is being delegated to the party referenced in the Claim Value. The delegation value is a case-sensitive string containing a StringOrURI value. Use of this Claim is OPTIONAL. For instance, the delegation Claim might be used to express that the referenced party may sign a legal document on behalf of the subject. This Claim is used in this specification as specified in Section 7.1 to represent delegation of the right to issue Trust Marks with a particular identifier. Note that the delegation Claim is both syntactically and semantically distinct from the existing act Claim [IANA.JWT.Claims]. act is a JSON object whereas delegation is a StringOrURI. Semantically, the Delegation JWT defined in Section 7.2.1 carries a signature by an issuer cryptographically proving the right to delegate to the party. The act Claim, carrying no signature, cannot achieve this. 13.7. "logo_uri" (Logo URI) Claim The logo_uri Claim value is a URI that references a logo pertaining to the JWT. Use of this Claim is OPTIONAL. For instance, the logo_uri Claim might be used to represent the location from which to retrieve the logo of an organization to display in a user interface. This Claim is used in this specification as specified in Section 7.1 to convey a URL that references a logo for the Entity. Hedberg, et al. Standards Track [Page 100] OpenID Federation 1.1 February 2026 14. Claims Languages and Scripts Human-readable Claim Values and Claim Values that reference human- readable values MAY be represented in multiple languages and scripts. This specification enables such representations in the same manner as defined in Section 5.2 of OpenID Connect Core 1.0 [OpenID.Core]. As described in OpenID Connect Core, to specify the languages and scripts, BCP47 [RFC5646] language tags are added to member names, delimited by a # character. For example, family_name#ja-Kana-JP expresses the Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same name represented as family_name#ja-Hani-JP. Language tags can be used in any data structures containing or referencing human-readable values, including metadata parameters and Trust Mark parameters. For instance, both organization_name and organization_name#de might occur together in metadata. 15. Media Types These media types [RFC2046] are defined by this specification. 15.1. "application/entity-statement+jwt" Media Type The application/entity-statement+jwt media type is used to specify that the associated content is an Entity Statement, as defined in Section 3. No parameters are used with this media type. 15.2. "application/trust-mark+jwt" Media Type The application/trust-mark+jwt media type is used to specify that the associated content is a Trust Mark, as defined in Section 7. No parameters are used with this media type. 15.3. "application/resolve-response+jwt" Media Type The application/resolve-response+jwt media type is used to specify that the associated content is a Resolve Response, as defined in Section 8.3.2. No parameters are used with this media type. 15.4. "application/trust-chain+json" Media Type The application/trust-chain+json media type is used to specify that the associated content is a JSON array representing a Trust Chain, as defined in Section 4. No parameters are used with this media type. Hedberg, et al. Standards Track [Page 101] OpenID Federation 1.1 February 2026 15.5. "application/trust-mark-delegation+jwt" Media Type The application/trust-mark-delegation+jwt media type is used to specify that the associated content is a Trust Mark delegation, as defined in Section 7.2.1. No parameters are used with this media type. 15.6. "application/jwk-set+jwt" Media Type The application/jwk-set+jwt media type is used to specify that the associated content is a signed JWK Set, as defined in Section 8.7.2. No parameters are used with this media type. 15.7. "application/trust-mark-status-response+jwt" Media Type The application/trust-mark-status-response+jwt media type is used to specify that the associated content is a Trust Mark Status Response, as defined in Section 8.4.2. No parameters are used with this media type. 16. String Operations Processing some OpenID Federation messages requires comparing values in the messages to other values. For example, the Entity Identifier in an iss Claim might be compared to the Entity Identifier in a sub Claim. Comparing Unicode [UNICODE] strings, however, has significant security implications. Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below: 1. Remove any JSON applied escaping to produce an array of Unicode code points. 2. Unicode Normalization [USA15] MUST NOT be applied at any point to either the JSON string or to the string it is to be compared against. 3. Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison. Note that this is the same comparison procedure as specified in Section 14 of OpenID Connect Core 1.0 [OpenID.Core]. Hedberg, et al. Standards Track [Page 102] OpenID Federation 1.1 February 2026 17. Implementation Considerations This section provides guidance to implementers and deployers of Federations on situations and properties that they should consider for their Federations. 17.1. Federation Topologies It is possible to construct Federation topologies that have multiple trust paths between Entities. The specification does not disallow this, but it can create ambiguities that deployers need to be aware of. Consider the following Federation topology: .--------------. | Trust Anchor | '--.---.-----.-' | | | .--' '--. '---------------. | | | .-------------v--. .--v-------------. | | Intermediate 1 | | Intermediate 2 | | '-------------.--' '--.-------------' | | | .-v--. | | | OP | .--v---------v---. '----' | Intermediate 3 | '-------.--------' | | .-v--. | RP | '----' Figure 48: Example Topology with Multiple Trust Paths between Entities In this topology, there are multiple trust paths between the RP and the Trust Anchor, meaning that multiple different Trust Chains could be built between them. If the metadata policies of Intermediate 1 and Intermediate 2 are different, this could result in the Resolved Metadata for the RP differing, depending upon which Intermediate is used when building the Trust Chain. Some such differences will be innocuous and some can cause failures. Hedberg, et al. Standards Track [Page 103] OpenID Federation 1.1 February 2026 It is the job of the Federation architects to deploy topologies and metadata policies that work as intended, no matter which trust path is chosen when building a Trust Chain. Of course, one way to avoid potential ambiguities is to only use topologies that are trees, without multiple paths between two Entities. Topologies that are not trees are permitted, but should be used consciously and with care. Even when a Federation topology contains loops, Trust Chains built from them MUST NOT contain loops, as mandated in Section 10.1. 17.2. Federation Discovery and Trust Chain Resolution Patterns This section describes different patterns that implementations may use for discovering entities within a federation and for resolving Trust Chains. It is important to distinguish between two related but distinct concepts: * *Discovery*: The process of finding entities that are part of a federation, typically to build directories or catalogs of available service providers. * *Trust Chain Resolution*: The process of building and validating a Trust Chain from a known entity to a Trust Anchor, as described in Section 10. This process is also known as Federation Entity Discovery in this specification (per the definition in Section 1.2). While these patterns may involve both discovery and Trust Chain resolution, they serve different purposes and may be used independently, depending on the use case. For example, a discovery service building a directory of OpenID Providers may collect entity identifiers without necessarily resolving Trust Chains for all discovered entities, since the actual Trust Chain resolution may occur later on, for example, when an RP and OP engage in an authentication transaction, and use the Trust Chain resolution process described in Section 10. Implementations may support one or more of the following patterns: * Bottom-Up Trust Chain Resolution (Section 17.2.1): Resolving Trust Chains starting from a known entity identifier, as described in Section 10. * Top-Down Discovery (Section 17.2.2): Finding entities within a federation by starting from a Trust Anchor and traversing down the hierarchy. Hedberg, et al. Standards Track [Page 104] OpenID Federation 1.1 February 2026 * Single Point of Trust Resolution (Section 17.2.3): Delegating Trust Chain resolution to a trusted resolver implementing the Resolve Endpoint. Federation operators may choose to support multiple patterns to accommodate different use cases and integration scenarios. The choice of supported patterns affects the federation's usability and the types of applications that can effectively integrate with it. 17.2.1. Bottom-Up Trust Chain Resolution Bottom-up Trust Chain resolution is the process described in Section 10, also known as Federation Entity Discovery (see the definition in the Terminology section). This process starts with a known Entity Identifier and builds a Trust Chain by traversing up the federation hierarchy until reaching a Trust Anchor. This pattern is not discovery in the sense of finding unknown entities, but rather trust resolution for a known entity. This pattern is used when an entity needs to verify the trustworthiness of another entity whose Entity Identifier is already known. This is typically used for: * OpenID Providers verifying Relying Parties during authentication requests, * Resource servers verifying Client trustworthiness, * Any Entity validating incoming requests from known parties, and * Dynamic trust establishment in federated environments. The bottom-up Trust Chain resolution process follows these steps, as described in Section 10: 1. Start with the subject entity's Entity Configuration (provided or fetched using the process defined in Section 9). 2. Use authority_hints to identify immediate superior entities. 3. Fetch Entity Configuration for each Superior Entity. 4. Use Fetch Endpoints (as defined in Section 8.1.1) to obtain Subordinate Statements about the subject entity. 5. Recursively traverse up the hierarchy until reaching a Trust Anchor. Hedberg, et al. Standards Track [Page 105] OpenID Federation 1.1 February 2026 6. Build and validate the complete Trust Chain. 7. Apply federation policies to derive Resolved Metadata. 17.2.2. Top-Down Discovery Top-down discovery is the process of finding entities that are part of a federation by starting from a known Trust Anchor and traversing down the federation hierarchy. This pattern is used when the goal is to discover available entities, particularly entities of specific Entity Types, without necessarily knowing their Entity Identifiers in advance. This pattern is particularly useful for: * Service discovery by Relying Parties looking for OpenID Providers, * Resource discovery by Clients looking for specific service types, * Federation browsing and exploration, and * Building provider directories and catalogs (e.g., WAYF services, Seamless Access). The top-down discovery process follows these steps: 1. Start with a known Trust Anchor that the discovering entity trusts. 2. Use the list endpoint (as defined in Section 8.2) to discover Immediate Subordinate entities. 3. Filter by entity_type parameter to find protocol-specific providers (e.g., openid_provider). 4. For Intermediate entities, recursively traverse their Subordinates. 5. Collect Entity Identifiers and optionally Entity Configurations for discovered entities. Hedberg, et al. Standards Track [Page 106] OpenID Federation 1.1 February 2026 Note that top-down discovery may or may not include Trust Chain resolution, depending on the use case. For example, when building a directory of OpenID Providers for user selection at login time, the discovery service may collect entity identifiers and basic metadata without resolving Trust Chains for all discovered entities. However, if the discovery service needs to verify that entities are properly registered in the federation before including them in the directory, it may choose to perform Trust Chain resolution as part of the discovery process. 17.2.3. Single Point of Trust Resolution Single point of trust resolution delegates the entire Trust Chain resolution process to a trusted resolver implementing the Resolve Endpoint defined in Section 8.3. This pattern allows entities to offload the complexity of Trust Chain resolution to a specialized service. This pattern is useful for: * Entities that want to offload Trust Chain resolution complexity, * Centralized trust evaluation services, * Performance optimization by caching Resolved Metadata, and * Simplified integration for lightweight clients. Note that this pattern requires the Entity Identifier of the subject entity to be known in advance. It does not provide discovery functionality in the sense of finding unknown entities within a federation. The single point of trust resolution process follows these steps: 1. Identify a trusted resolver with a Resolve Endpoint. 2. Submit the subject Entity Identifier and Trust Anchor to the resolver. 3. The resolver performs complete Trust Chain resolution internally (following the bottom-up pattern). 4. The resolver returns Resolved Metadata and Trust Marks. 5. Optionally verify the resolver's own Trust Chain. 6. Use Resolved Metadata for protocol operations. Hedberg, et al. Standards Track [Page 107] OpenID Federation 1.1 February 2026 17.3. Trust Anchors and Resolvers Go Together If only one resolver is present in a federation, that entity should be both Trust Anchor and Resolver. If so, users of the resolver will not have to collect and evaluate Trust Chains for the Resolver. The Trust Anchor is by definition trusted and if the entity also serves as Resolver, that service will be implicitly trusted. 17.4. One Entity, One Service Apart from letting an entity provide both the Trust Anchor and Resolver services, there is a good reason for having each entity only do one thing. The reason is that, later in time, it will be much easier to share specific services between federations. 17.5. Trust Mark Policies When validating trust marks in an Entity Statement, it can be split into three parts. Validating Trust Marks in the Context of Validating an Entity Statement According to the text on Entity Statement Validation in Section 3.2, validating a Trust Mark is confined to validating the syntax of the Claim Value, including that the trust_mark_type value is consistent. Validating a Specific Trust Mark This is what is described in Section 7.3. In order to validate a Trust Mark, the entity must find a Trust Chain for the Trust Mark Issuer to a Trust Anchor the Entity trusts. This has nothing to do with which federation that will later be used for the application protocol. Deciding which Trust Marks to Use A federation MAY have a policy that states that only Trust Marks that match certain criteria SHOULD be used. An example of such criteria could be that the Trust Mark's trust_mark_type must be listed in the Trust Anchor's trust_mark_issuers, and if so, that the instance's iss appears in the corresponding list of Entity Identifiers. Note that the list may be an empty list, which signifies that anyone can issue a Trust Mark with the trust_mark_type in question. Such Trust Marks can appear for various reasons, such as the Entity Configuration including Trust Marks associated with another federation, or Trust Marks intended for specific purposes or Entity audiences. Hedberg, et al. Standards Track [Page 108] OpenID Federation 1.1 February 2026 An Entity MAY also choose, at its own discretion, to utilize Trust Marks presented to it that are not recognized within the federation, and where the accreditation authority is established by an out-of-band mechanism. 18. Security Considerations 18.1. Denial-of-Service Attack Prevention Some of the interfaces defined in this specification could be used for Denial-of-Service attacks (DoS), most notably, the resolve endpoint (Section 8.3) can be exploited as a vector of HTTP propagation attacks. Below is an explanation of how such an attack can occur and the countermeasures to prevent it. An adversary, providing hundreds of fake authority_hints in its Entity Configuration, could exploit the Federation Entity Discovery mechanism to propagate many HTTP requests. Imagine an adversary controlling an RP that sends an authorization request to an OP. For each request crafted by the adversary, the OP produces one request for the adversary's Entity Configuration and another one for each URL found in the authority_hints. Some adequate defense methods are required, such as those described below and in [RFC4732]. Implementations should set a limit on the number of authority_hints they are willing to inspect. This is to protect against attacks where an adversary might define a large count of false authority_hints in their Entity Configuration. A Trust Mark can be statically validated using the public key of its issuer. The static validation of the Trust Marks represents a filter against propagation attacks. If the OpenID Provider (OP) discovers at least one valid Trust Mark within an Entity Configuration, this may serve as evidence of the reliability of the Relying Party that initiated the request. Given that the Trust Mark is optional, the decision to require one is at the discretion of the federation implementation, where a federation may define and require Trust Marks according to specific needs. Hedberg, et al. Standards Track [Page 109] OpenID Federation 1.1 February 2026 If Client authentication is not required at the resolve endpoint, then incoming requests should not automatically trigger the collection (Federation Entity Discovery process) and assessment of Trust Chains. Instead, the resolve endpoint should only respond to unauthenticated Client requests with cached information about Entities that have already been evaluated and deemed trustworthy. The initiation of the Federation Entity Discovery process should not be the default action for the resolve endpoint in this case. 18.2. Unsigned Error Messages One of the fundamental design goals of this protocol is to protect messages end-to-end. This cannot be accomplished by demanding TLS since TLS, in lots of cases, is not end-to-end but ends in an HTTPS to HTTP Reverse Proxy. Allowing unsigned error messages therefore opens an attack vector for someone who wants to run a Denial-of- Service attack. This is not specific to OpenID Federation but equally valid for other protocols when HTTPS to HTTP reverse proxies are used. 19. Privacy Considerations Implementers should be aware of these privacy considerations. 19.1. Entity Statement Privacy Considerations Entity Statements are designed to establish trust relationships between organizational entities within a federation, rather than between individuals or for specific business applications. Trust and reputation assessments for individuals or legal entities, such as those required for Know Your Customer and Anti-Money Laundering processes, should be managed through specialized platforms tailored for those purposes. Given that Entity Statements facilitate trust relationships using a public infrastructure, they should be limited to the essential information necessary for federation operations and organizational trust establishment. 19.2. Trust Mark Status Privacy Considerations The Trust Mark Status endpoint enables querying the status of Trust Marks in real time. Similar to the Fetch endpoint, in cases where the Trust Mark Status endpoint is not protected by any client authentication method, requests to validate Trust Marks may not necessarily indicate an actual interaction or relationship between Entities, as they could simply be part of routine network inspection or discovery processes. This could potentially enable Trust Mark issuers to track Entities evaluating Trust Marks about other Entities through standard network diagnostic tools like IPv4/IPv6 addresses Hedberg, et al. Standards Track [Page 110] OpenID Federation 1.1 February 2026 and DNS Whois entries. To mitigate tracking risks, implementations can use short-lived Trust Marks, or use the Trust Marked Entities Listing (Section 8.5) with only the trust_mark_type parameter and not the sub parameter, reducing the need to use the Trust Mark Status endpoint. 19.3. Fetch Endpoint Privacy Considerations The Fetch endpoint enables querying Subordinate Statements in real time. Similar to Trust Mark Status validation, in the cases where the federation infrastructure is public and widely browsable and endpoints are not protected by any client authentication method, requests to fetch Subordinate Statements may not necessarily indicate an actual interaction or relationship between Entities, as they could simply be part of routine network inspection or discovery processes. However, this could potentially enable Trust Anchors or Intermediates to track Entities evaluating trust relationships with other Entities through standard network diagnostic tools like IPv4/IPv6 addresses and DNS Whois entries. To mitigate tracking risks around Entities inspecting and interacting with other Entities, implementers should consider using static and short-lived Trust Chains where appropriate, which can reduce the need for real-time fetching of Subordinate Statements. 20. IANA Considerations This specification makes no requests of IANA. It relies on the IANA registrations already made in Section 20 of OpenID Federation 1.0 [OpenID.Federation-1.0]. 21. References 21.1. Normative References [OpenID.Core] Sakimura, N., Bradley, J., Jones, M.B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", 15 December 2023, . [OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M.B., and E. Jay, "OpenID Connect Discovery 1.0", 15 December 2023, . Hedberg, et al. Standards Track [Page 111] OpenID Federation 1.1 February 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . Hedberg, et al. Standards Track [Page 112] OpenID Federation 1.1 February 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [UNICODE] The Unicode Consortium, "The Unicode Standard", . [USA15] Whistler, K., "Unicode Normalization Forms", Unicode Standard Annex 15, 30 July 2025, . 21.2. Informative References [App-Fed-Linkage] Dzhuvinov, V., "How to link an application protocol to an OpenID Federation 1.0 trust layer", 4 December 2024, . [FAPI] Sakimura, N., Bradley, J., and E. Jay, "Financial-grade API Security Profile 1.0 - Part 2: Advanced", 12 March 2021, . [IANA.JWT.Claims] IANA, "JSON Web Token Claims", . [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . [OpenID.Federation-1.0] Hedberg, R., Ed., Jones, M.B., Solberg, A.Å., Bradley, J., De Marco, G., and V. Dzhuvinov, "OpenID Federation 1.0", 15 February 2026, . Hedberg, et al. Standards Track [Page 113] OpenID Federation 1.1 February 2026 [OpenID.Federation.Connect-1.1] Hedberg, R., Jones, M.B., Ed., De Marco, G., Solberg, A.Å., Bradley, J., and V. Dzhuvinov, "OpenID Federation for OpenID Connect 1.1", 15 February 2026, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . Appendix A. Examples Building and Using Trust Chains Appendix A of [OpenID.Federation.Connect-1.1] contains examples building and using Trust Chains for trust establishment between parties wanting to cooperate within a federation. The examples are there because some of the operations depicted are protocol specific. That said, many of the operations depicted operate in a protocol- independent manner, especially setting up a federation and the subsequent descriptions of building a Trust Chain and creating Resolved Metadata. Appendix B. Notices Copyright (c) 2026 The OpenID Foundation. The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF. Hedberg, et al. Standards Track [Page 114] OpenID Federation 1.1 February 2026 The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non- infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification. Appendix C. Document History [[ To be removed from the final specification ]] -03 * Synced acknowledgements with OpenID Federation 1.0. * Reference, rather than define, the existing error values invalid_request, server_error, and temporarily_unavailable. -02 * Moved statement about signing Entity Statements with "RS256" from this specification to OpenID Federation for OpenID Connect 1.1 since the motivation for supporting it comes from OpenID Connect. -01 * Use the new specification name OpenID Federation for OpenID Connect 1.1, which was previously named OpenID Connect Federation 1.1. * Merged in changes made to OpenID Federation 1.0 between January 7 and January 19, 2026. Hedberg, et al. Standards Track [Page 115] OpenID Federation 1.1 February 2026 -00 * Began life as a copy of OpenID Federation 1.0 as of December 10, 2025. * Removed protocol-specific functionality. * Merged in changes made to OpenID Federation 1.0 as of January 7, 2026. * Appled corrections identified by Andreas Solberg. Acknowledgements OpenID Federation 1.1 Acknowledgements The authors wish to acknowledge the contributions of the following organization to this specification: the SIROS Foundation. OpenID Federation 1.0 Acknowledgements The authors wish to acknowledge the contributions of the following individuals and organizations to the OpenID Federation 1.0 specification: Marcus Almgren, Patrick Amrein, Pål Axelsson, Pasquale Barbaro, Ralph Bragg, Peter Brand, Brian Campbell, David Chadwick, Michele D'Amico, Kushal Das, Andrii Deinega, Erick Domingues, Heather Flanagan, Michael Fraser, Samuel Gulliksson, Joseph Heenan, Pedram Hosseyni, Marko Ivančić, Łukasz Jaromin, Leif Johansson, Takahiko Kawasaki, Ralf Küsters, Torsten Lodderstedt, Josh Mandel, Francesco Marino, John Melati, Alexey Melnikov, Henri Mikkonen, Aaron Parecki, Eduardo Perottoni, Chris Phillips, Roberto Polli, Justin Richer, Jouke Roorda, Nat Sakimura, Mischa Sallé, Stefan Santesson, Marcos Sanz, Michael Schwartz, Giada Sciarretta, Amir Sharif, Yaron Sheffer, Sean Turner, Davide Vaghetti, Niels van Dijk, Luiky Vasconcelos, Tim Würtele, Kristina Yasuda, Gabriel Zachmann, the JRA3T3 task force of GEANT4-2, and the SIROS Foundation. Authors' Addresses Roland Hedberg independent Email: roland@catalogix.se Michael B. Jones (editor) Self-Issued Consulting Email: michael_b_jones@hotmail.com URI: https://self-issued.info/ Hedberg, et al. Standards Track [Page 116] OpenID Federation 1.1 February 2026 Giuseppe De Marco independent Email: demarcog83@gmail.com URI: https://www.linkedin.com/in/giuseppe-de-marco-bb054245/ Andreas Åkre Solberg Sikt Email: Andreas.Solberg@sikt.no URI: https://www.linkedin.com/in/andreassolberg/ John Bradley Yubico Email: ve7jtb@ve7jtb.com URI: https://www.linkedin.com/in/ve7jtb/ Vladimir Dzhuvinov Connect2id Email: vladimir@connect2id.com URI: https://www.linkedin.com/in/vladimirdzhuvinov/ Hedberg, et al. Standards Track [Page 117]