openid-federation-entity-collection | June 2025 | |
Zachmann | Standards Track | [Page] |
This specification acts as an extension to the [OpenID.Federation]. It defines an additional federation endpoint to retrieve a filterable list of Entities in a (sub-)federation.¶
TODO¶
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 Entity Collection Endpoint is an optional endpoint that MAY be published by Federation Entities. 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.
Federation Entities publishing this endpoint SHOULD also publish a
federation_resolve_endpoint
.¶
The location of the Federation Entity Collection Endpoint is published in the federation_entity
metadata, using the federation_collection_endpoint
parameter.¶
The following is a non-normative example of an Entity Configuration payload, for an Trust Anchor that includes the federation_collection_endpoint
:¶
{ "iss": "https://ta.example.org", "sub": "https://ta.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://ta.example.org/fetch", "federation_list_endpoint": "https://ta.example.org/list", "federation_resolve_endpoint": "https://ta.example.org/resolve", "federation_collection_endpoint": "https://ta.example.org/entities" } } }¶
When client authentication is not used, the request to the federation_collection_endpoint
MUST be an HTTP request using the GET method with the following query parameters, encoded in application/x-www-form-urlencoded
format:¶
from_entity_id: (OPTIONAL) If this parameter is present, the resulting list MUST be the subset of the overall ordered response starting from the index of the Entity referenced with this parameter.
If the Entity Identifier in this parameter is not or not longer known to the responder, it MUST use the HTTP status code 404 and the content type application/json
with the error code entity_id_not_found
.
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
.¶
limit: (OPTIONAL) Requested number of results included in the response.
If this parameter is present, the number of results in the returned list MUST NOT be greater than the minimum of the responder’s upper limit and the value of this parameter.
If this parameter is not present the server MUST fall back on the upper limit.
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
.¶
entity_type: (OPTIONAL) The value of this parameter is an Entity Type Identifier. The result MUST be filtered to include only those entities 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_mark_type: (OPTIONAL) The value of this parameter is a Trust Mark Type Identifier. The list in the response is filtered to include only Entities that publish a Trust Mark with this Trust Mark Type in their Entity Configuration and is verified by the responder. The responder SHOULD verify the Trust Mark using the same Trust Anchor that is used to collect the Entities. When multiple trust_mark_type
parameters are present, the result MUST be filtered to include all specified Trust Marks.
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_anchor: (RECOMMENDED) The Trust Anchor that the collection endpoint MUST use when collecting Entities. The value is an Entity Identifier. If omitted, the responder sets this parameter to its own Entity Identifier. If the responder does not have a defined Entity Identifier, it MUST use the HTTP status code 400 and set the content type to application/json
, with the error code invalid_request
.¶
query: (OPTIONAL) The value of this parameter is used by the responder to
filter down the list of returned Entities to only entities that match this
parameter value. It is entirely up to the responder to define when an Entity
matches the query.
If the responder does not support this feature, it SHOULD use the HTTP status code 400 and the content type application/json
, with the error code unsupported_parameter
.¶
claims: (OPTIONAL) Array of claims to be included in the response for each returned Entity.
If this parameter is NOT present it is at the discretion of the responder which claims are included or not.
If this parameter is present and it is NOT an empty array, each JSON object that represents an Entity MUST include the requested claims if available.
If the responder does not support a requested claim, it MUST use the HTTP status code 400 and set the content type to 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 a collection request:¶
GET /collection?entity_type=openid_provider&trust_mark_type=https%3A%2F%2Frp%2Erefeds.org%2Fsitfi&trust_anchor=https%3A%2F%2Fswamid.se HTTP/1.1 Host: openid.sunet.se¶
A successful response MUST use the HTTP status code 200 and the content type application/json
.¶
The response is a JSON object as described below.¶
If the response is negative, it will be a JSON object and the content type MUST be application/json
and use the errors defined here or in [OpenID.Federation].¶
The claims in the entity collection response are:¶
entities
array.¶
last_updated
time changes between paginated calls, this might be an indication for the client that it might have received outdated information in a previous call.¶
Additional claims MAY be defined and used in conjunction with the claims above.¶
Each JSON Object in the returned entities
array MAY contain the following
claims:¶
ui_infos: (OPTIONAL) JSON Object containing information intended to be displayed to the user for each entity
type. Each member name of the JSON object is an Entity Type Identifier and each
value is a JSON Object as defined below.
If the request contains the entity_type
parameter, the ui_infos
Object MUST
only contain Entity Types that are among the ones requested, with the exception
of the federation_entity
Entity Type, which MAY also appear if not requested.
Additional claims MAY be defined and used in conjunction
with the following claims:¶
#
character.¶
#
character.¶
trust_marks: (OPTIONAL) Array of objects, each representing a Trust Mark, as defined in Section 3 of [OpenID.Federation].¶
Additional claims MAY be defined and used in conjunction with the claims above.¶
{ "federation_entities": [ { "entity_id": "https://green.example.com", "entity_types": [ "federation_entity" ], "ui_infos": { "federation_entity": { "display_name": "The green organization", "logo_uri": "https://green.example.com/logo.png" } } }, { "entity_id": "https://red.example.com", "entity_types": [ "openid_relying_party", "federation_entity" ], "ui_infos": { "federation_entity": { "display_name": "Red Organization", "logo_uri": "https://red.example.com/logo.png" }, "openid_relying_party": { "display_name": "Red RP", "logo_uri": "https://red.example.com/logo.png" } } }, { "entity_id": "https://op.example.com", "entity_types": [ "openid_provider" ] } ] }¶
It is up to the implementation to decide how the responded ui_infos
claims about an entity are
populated. Implementations SHOULD consider the information published by entities
in their Entity Configuration and MAY consider additional information.¶
The following mapping between Claims in the ui_infos
response Claim and Metadata Claims in the
Entity Configuration SHOULD be considered:¶
display_name
: The display_name
Claim is a common Metadata Claim useable with all Entity Types. If set it SHOULD be copied to the response. If the display_name
Claim is not set other Claims MAY be considered, such as:¶
description
: The description
Claim is a common Metadata Claim useable with all Entity Types. It SHOULD be copied to the response.¶
keywords
: The keywords
Claim is a common Metadata Claim useable with all Entity Types. It SHOULD be copied to the response.¶
logo_uri
: The logo_uri
Claim is a common Metadata Claim useable with all Entity Types. It SHOULD be copied to the response.¶
policy_uri
: The policy_uri
Claim is a common Metadata Claim useable with all Entity Types. It SHOULD be copied to the response.¶
information_uri
: The information_uri
Claim is a common Metadata Claim useable with all Entity Types. It SHOULD be copied to the response.¶
The responder is free to restrict the scope of its Entity Collection Endpoint, such as, but not limited to:¶
In additional to the considerations below, the security considerations of OpenID Federation 1.0 [OpenID.Federation] apply to this specification.¶
The response from the Entity Collection Endpoint is not signed and the obtained information should only be considered as informational. To verify an Entity proper trust validation according to OpenID Federation 1.0 [OpenID.Federation] still MUST be done.¶
It is also noted that Trust Marks returned in the response MAY not be verified and clients MUST consider them as not yet verified.¶
Copyright (c) 2025 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: Niels van Dijk, Stefan Santesson, Phil Smart, Zacharias Törnblom, and the Geant Trust & Identity Incubator of Geant5-2.¶
[[ To be removed from the final specification ]]¶
-00¶