openid-federation-entity-collection June 2025
Zachmann Standards Track [Page]
Workgroup:
individual
Published:
Author:
G.Z. Zachmann
Karlsruhe Institute of Technology

OpenID Federation Entity Collection Endpoint 1.0 - draft 00

Abstract

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.

Table of Contents

1. Introduction

TODO

1.1. Requirements Notation and Conventions

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.

2. Terminology

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].

2.1. Endpoint Description

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.

2.1.1. Endpoint Location

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"
    }
  }
}

2.2. Entity Collection Request

2.2.1. Request Format

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.

2.2.1.1. Example Request

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

2.3. Entity Collection Response

2.3.1. Response Format

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].

2.3.2. Response Claims

The claims in the entity collection response are:

  • entities: (REQUIRED) Array of JSON objects, each representing an Federation Entity using the format described below. The list of Entities MUST only contain Entities that are in line with the requested parameters. The responder MAY also filter down the list further at its own discretion.
  • next_entity_id: (OPTIONAL) Entity Identifier for the next element in the result list where the next page begins. This attribute is REQUIRED when additional results are available beyond those included in the entities array.
  • last_updated: (RECOMMENDED) Number. Time when the responder last updated the result list. This is expressed as Seconds Since the Epoch, per [RFC7519]. If the 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.

2.3.2.1. Entity Object Parameters

Each JSON Object in the returned entities array MAY contain the following claims:

  • entity_id: (REQUIRED) The Entity Identifier for the subject entity of the current record.
  • entity_types: (RECOMMENDED) Array of string Entity Type Identifiers. If present this claim MUST contain all Entity Type Identifiers of the subject's Entity the responder knows about.
  • 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:

    • display_name: String. A human-readable name of the Entity to be presented to the End-User.
      This Claim MAY be represented in multiple languages and scripts. To specify the languages and scripts, BCP47 [RFC5646] language tags are added to the Claim name, delimited by a # character.
    • description: String. A human-readable brief description of this Entity presentable to the End-User.
      This Claim MAY be represented in multiple languages and scripts. To specify the languages and scripts, BCP47 [RFC5646] language tags are added to the Claim name, delimited by a # character.
    • keywords: JSON array with one or more strings representing search keywords, tags, categories, or labels that apply to this Entity.
    • logo_uri: String. A URL that points to the logo of this Entity.
    • policy_uri: String. A URL of the documentation of conditions and policies relevant to this Entity.
    • information_uri: String. A URL for documentation of additional information about this Entity viewable by the End-User.
  • 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.

2.3.2.2. Example Response
{
  "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"
      ]
    }
  ]
}

3. Implementation Considerations

3.1. Mapping Entity Configuration Claims to Entity Response Claims

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:

    • For the openid_relying_party Entity Type: client_name
    • For the oauth_client Entity Type: client_name
    • For the oauth_resource Entity Type: resource_name
  • 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.

3.2. Entity Collection Endpoint Scope

The responder is free to restrict the scope of its Entity Collection Endpoint, such as, but not limited to:

  • Only supporting a limited set of Trust Anchors.
  • Filter out Entities from the response at their own discretion. Such additional filters MAY be:

    • Only Entities that have a certain Trust Mark.
    • Only Entities that have a valid Trust Chain to the Trust Anchor.
    • Only Entities that are resolvable at the Resolve Endpoint of the Entity providing the Entity Collection Endpoint.

4. Privacy Considerations

TODO

5. Security Considerations

In additional to the considerations below, the security considerations of OpenID Federation 1.0 [OpenID.Federation] apply to this specification.

5.1. Unsigned Response

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.

6. Normative References

[OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", , <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Federation]
Ed., R. H., Jones, M. B., Solberg, A., Bradley, J., Marco, G. D., and V. Dzhuvinov, "OpenID Federation 1.0", , <https://openid.net/specs/openid-federation-1_0.html>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5646]
Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, , <https://www.rfc-editor.org/info/rfc5646>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/info/rfc6749>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/info/rfc7519>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Appendix A. Notices

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.

Appendix B. Acknowledgements

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.

Appendix C. Document History

[[ To be removed from the final specification ]]

-00

Author's Address

Gabriel Zachmann
Karlsruhe Institute of Technology