| openid-federation-subordinate-events | January 2026 | |
| De Marco & Jones | Standards Track | [Page] |
This specification defines the Federation Subordinate Events Endpoint for implementations using OpenID Federation 1.0. It provides a mechanism for Trust Anchors and Intermediates to publish historical events related to their Immediate Subordinates, such as registration, revocation, and updates of their Federation Entity Keys.¶
The Federation Subordinate Events Endpoint is introduced to allow Trust Anchors and Intermediates to maintain and publish a track of registration events about their Immediate Subordinates. This endpoint is useful for transparency and accountability within a federation, by providing a historical record of significant events.¶
The keywords "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.¶
This specification uses the terms "Entity" as defined by OpenID Connect Core [OpenID.Core], "Client" as defined by [RFC6749], and "Trust Mark", "Federation Entity", "Federation Entity Key", "Trust Anchor", "Intermediate", and "Subordinate Statement" defined in [OpenID.Federation].¶
The Federation Subordinate Events Endpoint is an optional endpoint that MAY be published by Trust Anchors and Intermediates. It MUST use the https scheme and MAY include port, path, and query parameter components encoded in application/x-www-form-urlencoded format. It MUST NOT contain a fragment component.¶
The location of the Federation Subordinate Events Endpoint is published in the federation_entity metadata, using the federation_subordinate_events_endpoint parameter.¶
The following is a non-normative example of an Entity Configuration payload, for an Immediate Superior that includes the federation_subordinate_events_endpoint:¶
{
"iss": "https://immediate-superior.example.org",
"sub": "https://immediate-superior.example.org",
"iat": 1590000000,
"exp": 1590086400,
"jwks": {
"keys": [
{
"kty": "RSA",
"kid": "key1",
"use": "sig",
"n": "n4EPtAOCc9AlkeQHPzHStgAbgs7bTZLwUBZdR8_KuKPEHLd4rHVTeT",
"e": "AQAB"
}
]
},
"metadata": {
"federation_entity": {
"federation_fetch_endpoint": "https://immediate-superior.example.org/fetch",
"federation_list_endpoint": "https://immediate-superior.example.org/list",
"federation_subordinate_events_endpoint": "https://immediate-superior.example.org/events",
"federation_resolve_endpoint": "https://immediate-superior.example.org/resolve"
}
}
}
¶
The request to the federation_subordinate_events_endpoint MUST be an HTTP GET request with the following query parameters, encoded in application/x-www-form-urlencoded format:¶
When Client authentication is used, the request MUST be an HTTP POST request, with the parameters passed in the POST body.¶
GET /federation_subordinate_events_endpoint?sub=https%3A%2F%2Frp%2Eexample%2Eorg HTTP/1.1 Host: immediate-superior.example.org¶
A successful response MUST use the HTTP status code 200 and the content type application/entity-events-statement+jwt. The response includes relevant events from the federation's perspective of the Entity. If it is a negative response, it will be a JSON object and the content type MUST be application/json and use the errors defined in [OpenID.Federation].¶
The response is a signed JWT that is explicitly typed by setting the typ header parameter to entity-events-statement+jwt to prevent cross-JWT confusion. It is signed with a Federation Entity Key.¶
The claims in the Subordinate events statement response are:¶
iat claim.¶
registration, jwks_update, metadata_policy_update, metadata_update, or revocation.¶
{
"iss": "https://immediate-superior.example.org",
"sub": "https://rp.example.org",
"iat": 1590000000,
"federation_registration_events": [
{
"iat": 1590000000,
"event": "registration"
},
{
"iat": 1590000000,
"event": "jwks_updates"
},
{
"iat": 1600000000,
"event": "revocation",
"event_description": "compromised node"
},
{
"iat": 1610000000,
"event": "registration"
}
]
}
¶
The following event types are defined in this specification:¶
metadata_policy parameter.¶
metadata parameter.¶
metadata_update, metadata_policy_update, and jwks_update events MUST NOT be provided at the same time, since the Entity registration is assumed to configure the initial configuration about that Entity.¶
Additional event types MAY be defined by trust frameworks or federation operators to meet specific requirements. Such custom event types SHOULD be documented in the respective trust framework or federation operator's documentation.¶
The security considerations of OpenID Federation 1.0 [OpenID.Federation] apply to this specification.¶
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.¶
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.¶
We would like to thank the following individuals for their contributions to this specification: Vladimir Dzhuvinov, Roland Hedberg, and Andres Olave.¶
[[ To be removed from the final specification ]]¶
-00¶