openid-connect-federation-1_0.txt

                                                         R. Hedberg, Ed.
                                                             independent
                                                                M. Jones
                                                               Microsoft
                                                              A. Solberg
                                                                 Uninett
                                                           S. Gulliksson
                                                               Schibsted
                                                              J. Bradley
                                                                  Yubico
                                                       September 9, 2021


                OpenID Connect Federation 1.0 - draft 17
                     openid-connect-federation-1_0

Abstract

   A federation can be expressed as an agreement between parties that
   trust each other.  In bilateral federations, you can have direct
   trust between the parties.  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 is interacting 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 describes the basic components you will need to
   build a multilateral federation and it provides a guide on how to
   apply them when the underlying protocol used is OpenID Connect.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Overall Architecture  . . . . . . . . . . . . . . . . . . . .   5
   3.  Components  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Entity Statement  . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Trust Chain . . . . . . . . . . . . . . . . . . . . . . .  11
   4.  Metadata  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  RP Metadata . . . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  OP Metadata . . . . . . . . . . . . . . . . . . . . . . .  14
     4.3.  OAuth Authorization Server  . . . . . . . . . . . . . . .  16



Hedberg, et al.          Expires March 13, 2022                 [Page 1]

                        OpenID Connect Federation         September 2021


     4.4.  OAuth Client  . . . . . . . . . . . . . . . . . . . . . .  16
     4.5.  OAuth Protected Resource  . . . . . . . . . . . . . . . .  17
     4.6.  Federation Entity . . . . . . . . . . . . . . . . . . . .  17
   5.  Federation Policy . . . . . . . . . . . . . . . . . . . . . .  18
     5.1.  Metadata Policy . . . . . . . . . . . . . . . . . . . . .  18
       5.1.1.  Operators . . . . . . . . . . . . . . . . . . . . . .  19
       5.1.2.  Restrictions on Policy Entries  . . . . . . . . . . .  19
       5.1.3.  Combining Policies  . . . . . . . . . . . . . . . . .  20
         5.1.3.1.  Merging Operators . . . . . . . . . . . . . . . .  20
       5.1.4.  Applying Policies . . . . . . . . . . . . . . . . . .  21
       5.1.5.  Policy Combination Example  . . . . . . . . . . . . .  22
       5.1.6.  Enforcing Policy  . . . . . . . . . . . . . . . . . .  24
       5.1.7.  Extending the Policy Language . . . . . . . . . . . .  24
       5.1.8.  Policy Example  . . . . . . . . . . . . . . . . . . .  25
     5.2.  Applying Constraints  . . . . . . . . . . . . . . . . . .  27
       5.2.1.  Max Path Length . . . . . . . . . . . . . . . . . . .  27
       5.2.2.  Naming Constraints  . . . . . . . . . . . . . . . . .  28
     5.3.  Trust Marks . . . . . . . . . . . . . . . . . . . . . . .  29
       5.3.1.  Trust Mark Claims . . . . . . . . . . . . . . . . . .  29
       5.3.2.  Validating a Trust Mark . . . . . . . . . . . . . . .  30
       5.3.3.  Trust Mark Example  . . . . . . . . . . . . . . . . .  30
   6.  Obtaining Federation Entity Configuration Information . . . .  31
     6.1.  Federation Entity Configuration Request . . . . . . . . .  31
     6.2.  Federation Entity Configuration Response  . . . . . . . .  31
   7.  Federation API  . . . . . . . . . . . . . . . . . . . . . . .  33
     7.1.  Fetching Entity Statements (REQUIRED) . . . . . . . . . .  33
       7.1.1.  Fetch Entity Statements Request . . . . . . . . . . .  33
       7.1.2.  Fetch Entity Statements Response  . . . . . . . . . .  34
     7.2.  Trust Negotiation (OPTIONAL)  . . . . . . . . . . . . . .  36
       7.2.1.  Trust Negotiation Request . . . . . . . . . . . . . .  36
       7.2.2.  Trust Negotiation Response  . . . . . . . . . . . . .  37
     7.3.  Entity Listings (OPTIONAL)  . . . . . . . . . . . . . . .  38
       7.3.1.  Entity Listings Request . . . . . . . . . . . . . . .  38
       7.3.2.  Entity Listing Response . . . . . . . . . . . . . . .  38
     7.4.  Generic Error Response  . . . . . . . . . . . . . . . . .  39
   8.  Resolving Trust Chain and Metadata  . . . . . . . . . . . . .  40
     8.1.  Fetching Entity Statements to Establish a Trust Chain . .  40
     8.2.  Validating a Trust Chain  . . . . . . . . . . . . . . . .  40
     8.3.  Choosing One of the Valid Trust Chains  . . . . . . . . .  41
     8.4.  Calculating the Expiration Time of a Trust Chain  . . . .  41
   9.  Updating Metadata, Key Rollover, and Revocation . . . . . . .  42
     9.1.  Protocol Key Rollover . . . . . . . . . . . . . . . . . .  42
     9.2.  Key Rollover for a Trust Anchor . . . . . . . . . . . . .  42
     9.3.  Revocation  . . . . . . . . . . . . . . . . . . . . . . .  42
   10. OpenID Connect Communication  . . . . . . . . . . . . . . . .  43
     10.1.  Automatic Registration . . . . . . . . . . . . . . . . .  43
       10.1.1.  Authentication Request . . . . . . . . . . . . . . .  44
         10.1.1.1.  Using a Request Object . . . . . . . . . . . . .  44



Hedberg, et al.          Expires March 13, 2022                 [Page 2]

                        OpenID Connect Federation         September 2021


           10.1.1.1.1.  Processing the Authentication Request  . . .  45
         10.1.1.2.  Using Pushed Authorization . . . . . . . . . . .  46
           10.1.1.2.1.  Processing the Authentication Request  . . .  47
       10.1.2.  Authentication Error Response  . . . . . . . . . . .  48
     10.2.  Explicit Registration  . . . . . . . . . . . . . . . . .  49
       10.2.1.  Client Registration  . . . . . . . . . . . . . . . .  49
         10.2.1.1.  Client Registration Request  . . . . . . . . . .  49
         10.2.1.2.  Client Registration Response . . . . . . . . . .  49
           10.2.1.2.1.  OP Constructing the Response . . . . . . . .  49
           10.2.1.2.2.  RP Parsing the Response  . . . . . . . . . .  50
       10.2.2.  After Client Registration  . . . . . . . . . . . . .  51
         10.2.2.1.  What the RP MUST Do  . . . . . . . . . . . . . .  51
         10.2.2.2.  What the OP MUST Do  . . . . . . . . . . . . . .  51
       10.2.3.  Expiration Times . . . . . . . . . . . . . . . . . .  52
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  52
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  52
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  52
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  52
     13.2.  Informative References . . . . . . . . . . . . . . . . .  54
   Appendix A.  Provider Information Discovery and Client
                Registration in a Federation . . . . . . . . . . . .  54
     A.1.  Setting Up a Federation . . . . . . . . . . . . . . . . .  55
     A.2.  The LIGO Wiki Discovers the OP's Metadata . . . . . . . .  55
       A.2.1.  Configuration Information for op.umu.se . . . . . . .  56
       A.2.2.  Configuration Information for 'https://umu.se'  . . .  58
       A.2.3.  Entity Statement Published by 'https://umu.se' about
               'https://op.umu.se' . . . . . . . . . . . . . . . . .  59
       A.2.4.  Configuration Information for 'https://swamid.se' . .  61
       A.2.5.  Entity Statement Published by 'https://swamid.se'
               about 'https://umu.se'  . . . . . . . . . . . . . . .  62
       A.2.6.  Configuration Information for
               'https://edugain.geant.org' . . . . . . . . . . . . .  64
       A.2.7.  Entity Statement Published by
               'https://edugain.geant.org' about 'https://swamid.se'  65
       A.2.8.  Verified Metadata for op.umu.se . . . . . . . . . . .  66
     A.3.  The Two Ways of Doing Client Registration . . . . . . . .  68
       A.3.1.  RP Sends Authentication Request (Automatic
               Registration) . . . . . . . . . . . . . . . . . . . .  68
         A.3.1.1.  OP Fetches Entity Statements  . . . . . . . . . .  69
         A.3.1.2.  OP Evaluates the RP Metadata  . . . . . . . . . .  70
       A.3.2.  Client Starts with Registration (Explicit Client
               Registration) . . . . . . . . . . . . . . . . . . . .  72
   Appendix B.  Notices  . . . . . . . . . . . . . . . . . . . . . .  75
   Appendix C.  Acknowledgements . . . . . . . . . . . . . . . . . .  76
   Appendix D.  Open Issues  . . . . . . . . . . . . . . . . . . . .  76
   Appendix E.  Document History . . . . . . . . . . . . . . . . . .  77
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  80




Hedberg, et al.          Expires March 13, 2022                 [Page 3]

                        OpenID Connect Federation         September 2021


1.  Introduction

   This specification describes how two entities that would like to
   interact can dynamically fetch and resolve trust and metadata for a
   given protocol through the use of third-party trust anchor.  A trust
   anchor is an entity whose main purpose is to issue statements about
   entities, such as OpenID Connect Relying Parties, OpenID Providers,
   and participating organizations.  An identity federation can be
   realized using this specification using one or more levels of trust
   issuers.  This specification does not mandate a specific way or
   restrict how a federation may be built.  Instead, the specification
   provides the basic technical trust infrastructure building blocks
   needed to build a dynamic and distributed trust network such as a
   federation.

   Note that this specification only concerns itself with how entities
   in a federation get to know about each other.  Furthermore, note that
   a company, as with any real-world organization, MAY be represented by
   more than one entity in a federation.  It is also true that an entity
   can be part of more than one federation.

   OpenID Connect Federation trust chains rely on cryptographically
   signed JSON Web Token (JWT) [RFC7519] documents, and the trust chain
   does not at all rely on TLS [RFC8446] to establish trust.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Terminology

   This specification uses the terms "Claim Name", "Claim Value", "JSON
   Web Token (JWT)", defined by JSON Web Token (JWT) [RFC7519] and the
   terms "OpenID Provider (OP)" and "Relying Party (RP)" defined by
   OpenID Connect Core 1.0 [OpenID.Core].

   This specification also defines the following terms:

   Entity
      Something that has a separate and distinct existence and that can
      be identified in a context.  All entities in an OpenID Connect
      federation MUST have a globally unique identifier.

   Entity identifier
      An URI that is globally unique and that is bound to one Entity.




Hedberg, et al.          Expires March 13, 2022                 [Page 4]

                        OpenID Connect Federation         September 2021


   Entity statement
      An entity statement is issued by an entity, which pertains to a
      subject entity and leaf entities.  An entity statement is always a
      signed JWT.

   Intermediate entity
      An entity that issues an entity statement that appears somewhere
      in between those issued by the trust anchor and the leaf entity in
      a trust chain.

   Leaf Entity
      An entity defined by a certain protocol, e.g., OpenID Connect
      Relying Party or Provider.

   Trust Anchor
      An entity that represents a trusted third party.

   Trust Chain
      A sequence of entity statements that represents a chain starting
      at a leaf entity and ending in a trust anchor.

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 a leaf entity to a trust
   anchor.  This is done by having authority hints in an entity
   statement pointing to its nearest superiors.  Starting with an entity
   statement, you can then find the next level of entity statements by
   following the authority hints.  And then repeat this until you hit a
   trust anchor.

   Once you have followed a path, you have collected a set of entity
   statements that forms a chain.  You can verify that this chain has
   not been tampered with by verifying the signature of each statement.
   How this is done is described in Section 3.2.

   With a verified trust chain in hand, you can now apply federation
   policy to the published metadata.  How this is done is described in
   Section 5.

   Note that this specification is only dealing with trust in that the
   other party is part of the same federation as you and that you can
   trust that the metadata you get that describes the other party is
   what was sent.  The specification does not touch protocol operations
   outside those of metadata exchange.  In OpenID Connect terms, these
   are protocol operations other than discovery and registration.




Hedberg, et al.          Expires March 13, 2022                 [Page 5]

                        OpenID Connect Federation         September 2021


   The fact that we use OpenID Connect in all the examples in this
   specification does not mean that the specification can only be used
   together with OpenID Connect.  On the contrary, it can equally well
   be used to build an OAuth 2.0 federations or for that matter, other
   protocols that depend on dynamic exchange of entity metadata.

3.  Components

3.1.  Entity Statement

   An entity statement is issued by an entity and concerns a subject
   entity and leaf entities in a federation.  An entity statement is
   always a signed JWT.  All entities in a federation SHOULD be prepared
   to publish an entity statement about themselves.  If they are not
   able to do so themselves someone else MUST do it for them.

   An entity statement is composed of the following claims:

   iss
      REQUIRED.  The entity identifier of the issuer of the statement.
      If the "iss" and the "sub" are identical, the issuer is making a
      statement about itself.

   sub
      REQUIRED.  The entity identifier of the subject

   iat
      REQUIRED.  The time the statement was issued.  Its value is a JSON
      number representing the number of seconds from 1970-01-01T0:0:0Z
      as measured in UTC until the date/time.  See RFC 3339 [RFC3339]
      for details regarding date/times in general and UTC in particular.

   exp
      REQUIRED.  Expiration time on or after which the statement MUST
      NOT be accepted for processing.  Its value is a JSON number
      representing the number of seconds from 1970-01-01T0:0:0Z as
      measured in UTC until the date/time.

   jwks
      OPTIONAL.  A JSON Web Key Set (JWKS) [RFC7517] representing the
      public part of the subject entity's signing keys.  The
      corresponding private key is used by leaf entities to sign entity
      statements about themselves, and intermediate entities to sign
      statements about other entities.  The keys that can be found here
      are primarily intended to sign entity statements and SHOULD NOT be
      used in other protocols.  This claim is only OPTIONAL for the
      entity statement returned from an OP when the client is doing




Hedberg, et al.          Expires March 13, 2022                 [Page 6]

                        OpenID Connect Federation         September 2021


      explicit registration.  In all other cases it is REQUIRED.  Every
      JWK in the JWK Set MUST have a Key ID (kid).

   aud
      OPTIONAL.  The entity statement MAY be specifically created for an
      entity.  The entity identifier for that entity MUST appear in this
      claim.

   authority_hints
      OPTIONAL.  Array of strings representing the entity identifiers of
      intermediate entities or trust anchors that MAY issue an entity
      statement about the issuer entity.  For all entities except for
      trust anchors that do not have any superiors this is REQUIRED and
      MUST NOT be the empty list [].  This claim MUST be absent from an
      entity statement issued by a trust anchor with no superiors.

   metadata
      OPTIONAL.  JSON object including protocol specific metadata claims
      that represent the entity's metadata.  Each key of the JSON object
      represents a metadata type identifier, and each value MUST be a
      JSON object representing the metadata according to the metadata
      schema of that metadata type.  An entity statement MAY contain
      multiple metadata statements, but only one for each metadata type.
      If the "iss" of an entity statement points to the same entity as
      the "sub", then the entity statement MUST contain a "metadata"
      claim.  If "iss" and "sub" are not the same, then the entity
      statement MUST NOT contain a "metadata" claim.

   metadata_policy
      OPTIONAL.  JSON object that describes a metadata policy.  Each key
      of the JSON object represents a metadata type identifier, and each
      value MUST be a JSON object representing the metadata policy
      according to the metadata schema of that metadata type.  An entity
      statement MAY contain multiple metadata policy statements, but
      only one for each metadata type.  Only non-leaf entities MAY
      contain a "metadata_policy" claim.  Leaf entities MUST NOT contain
      a "metadata_policy" claim.

   constraints
      OPTIONAL.  JSON object that describes a set of trust chain
      constraints.  There is more about this in Section 5.2.

   crit
      OPTIONAL.  The "crit" (critical) entity statement claim indicates
      that extensions to entity statement claims defined by this
      specification are being used that MUST be understood and
      processed.  It is used in the same way that "crit" is used for
      extension JWS [RFC7515] header parameters that MUST be understood



Hedberg, et al.          Expires March 13, 2022                 [Page 7]

                        OpenID Connect Federation         September 2021


      and processed.  Its value is an array listing the entity statement
      claims present in the entity statement that use those extensions.
      If any of the listed extension entity statement claims are not
      understood and supported by the recipient, then the entity
      statement is invalid.  Producers MUST NOT include entity statement
      claim names defined by this specification or names that do not
      occur as entity statement claim names in the entity statement in
      the "crit" list.  Producers MUST NOT use the empty list "[]" as
      the "crit" value.

   policy_language_crit
      OPTIONAL.  The "policy_language_crit" (critical) entity statement
      claim indicates that extensions to the policy language defined by
      this specification are being used that MUST be understood and
      processed.  It is used in the same way that "crit" is used for
      extension JSON Web Signature (JWS) [RFC7515] header parameters
      that MUST be understood and processed.  Its value is an array
      listing the policy language extensions present in the policy
      language statements that use those extensions.  If any of the
      listed extension policy language extensions are not understood and
      supported by the recipient, then the entity statement is invalid.
      Producers MUST NOT include policy language names defined by this
      specification or names that do not occur in policy language
      statements in the entity statement in the "policy_language_crit"
      list.  Producers MUST NOT use the empty list "[]" as the
      "policy_language_crit" value.

   trust_marks
      OPTIONAL.  A JSON array of signed JSON Web Tokens, each
      representing a certification mark.  There is more about
      certification marks in Section 5.3.

   trust_marks_issuers
      OPTIONAL.  A trust anchor MAY use this claim to tell which trust
      mark identifiers and their issuers are trusted by the federation.
      This claim MUST be ignored if present in an entity statement of
      other entities than trust anchor.  It is a JSON array with keys
      representing trust mark identifiers and values being an array of
      trusted entities representing the accreditation authority.  A
      special value of "*" allows for self-signed trust marks.  There is
      more about certification marks in Section 5.3.










Hedberg, et al.          Expires March 13, 2022                 [Page 8]

                        OpenID Connect Federation         September 2021


   The following is a non-normative example of a "trust_marks_issuers"
   claim value:

   {
     "https://openid.net/certification/op": ["*"],
     "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf":
       ["https://swamid.sunet.se"]
   }

   trust_anchor_id
      OPTIONAL.  An OP MUST use this claim to tell the RP which trust
      anchor it chose to use when responding to an explicit client
      registration.  The value of "trust_anchor_id" is the entity
      identifier of a trust anchor.

   The entity statement is signed using the private key of the issuer
   entity, in the form of a JSON Web Signature (JWS) [RFC7515].
   Entities MUST support signing Entity Statements with the RSA SHA-256
   algorithm (an "alg" value of "RS256").  Consequently entities MUST
   support signature verification where the statement was signed using
   RS256.

   The following is a non-normative example of an entity statement
   before serialization and adding a signature.  The example contains a
   critical extension "jti" (JWT ID) to the entity statement and one
   critical extension to the policy language "regexp" (Regular
   expression).
























Hedberg, et al.          Expires March 13, 2022                 [Page 9]

                        OpenID Connect Federation         September 2021


   {
     "iss": "https://feide.no",
     "sub": "https://ntnu.no",
     "iat": 1516239022,
     "exp": 1516298022,
     "crit": ["jti"],
     "jti": "7l2lncFdY6SlhNia",
     "policy_language_crit": ["regexp"],
     "metadata_policy": {
       "openid_provider": {
         "issuer": {"value": "https://ntnu.no"},
         "organization_name": {"value": "NTNU"},
         "id_token_signing_alg_values_supported":
           {"subset_of": ["RS256", "RS384", "RS512"]},
         "op_policy_uri": {
           "regexp":
             "^https:\/\/[\\w-]+\\.example\\.com\/[\\w-]+\\.html"}
       },
       "openid_relying_party": {
         "organization_name": {"value": "NTNU"},
         "grant_types_supported": {
           "subset_of": ["authorization_code", "implicit"]},
         "scopes": {
           "subset_of": ["openid", "profile", "email", "phone"]}
       }
     },
     "constraints": {
       "max_path_length": 2
     },
     "jwks": {
       "keys": [
         {
           "alg": "RS256",
           "e": "AQAB",
           "key_ops": ["verify"],
           "kid": "key1",
           "kty": "RSA",
           "n": "pnXBOusEANuug6ewezb9J_...",
           "use": "sig"
         }
       ]
     },
     "authority_hints": [
       "https://edugain.org/federation"
     ]
   }





Hedberg, et al.          Expires March 13, 2022                [Page 10]

                        OpenID Connect Federation         September 2021


3.2.  Trust Chain

   In an OpenID Connect Identity Federation, entities that together
   build a trust chain can be categorized as:

   Trust anchor
      An entity that represents a trusted third party.

   Leaf
      In an OpenID Connect Identity Federation, an RP or an OP.

   Intermediate
      Neither a leaf nor a trust anchor.

   A trust chain begins with a leaf entity's self-signed entity
   statement, has zero or more entity statements issued by intermediates
   about subordinates, and ends with an entity statement issued by the
   trust anchor about the top-most intermediate (if there are
   intermediates) or the leaf entity (if there are no intermediates).

   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.  a self-signed entity statement about the RP published by the RP,

   2.  an entity statement about the RP published by Organization A, and

   3.  an entity statement about Organization A published by Federation.
       F

   A trust chain MUST always be possible to order such that: If we name
   the entity statements ES[0] (the leaf entity's self-signed entity
   statement) to ES[i] (an entity statement issued by the trust anchor),
   i>0 then:

   o  The "iss" entity in one entity statement is always the "sub"
      entity in the next.  ES[j]['iss'] == ES[j+1]['sub'], j=0,...,i-1 .

   o  There MUST always be a signing key carried in the "jwks" claim in
      ES[j] that can be used to verify the signature of ES[j-1],
      j=i,...,1 .

   o  It MUST be possible to verify the signature of ES[0] with one of
      the keys in ES[0]['jwks'].






Hedberg, et al.          Expires March 13, 2022                [Page 11]

                        OpenID Connect Federation         September 2021


   The signing key that MUST be used to verify ES[i] is distributed from
   the trust anchors to any entity that needs to verify a trust chain in
   some secure out-of-band way not described in this document.

4.  Metadata

   This specification does allow new metadata types to be defined, to
   support use cases outside OpenID Connect federations.  The metadata
   type identifier will uniquely identify which metadata specification
   to utilize.

   The metadata document MUST be a JSON object.  Beyond that there is no
   restriction.

   Metadata used in federations typically reuses existing metadata
   standards.  If needed, the metadata schema is extended with
   additional properties relevant in a federated context.  For instance,
   for OpenID Connect Federations, this specification uses metadata
   values from OpenID Connect Discovery 1.0 [OpenID.Discovery] and
   OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration]
   and adds additional values used for federations.

4.1.  RP Metadata

   The metadata type identifier is "openid_relying_party".

   All parameters defined in Section 2 of OpenID Connect Dynamic Client
   Registration 1.0 [OpenID.Registration] are allowed in a metadata
   statement.

   To that list is added:

   client_registration_types
      REQUIRED.  Array of strings specifying the client registration
      types the RP wants to use.  Values defined by this specification
      are "automatic" and "explicit".

   organization_name
      OPTIONAL.  A human-readable name representing the organization
      owning the RP.

   signed_jwks_uri
      OPTIONAL.  A URI pointing to a signed JWT having the entity's JWK
      Set as payload.  The JWT is signed with a key that was included in
      the JWK that the entity published in its self-signed entity
      statement.  A signed JWT can contain the following claims, all
      except "keys" defined in [RFC7519]:




Hedberg, et al.          Expires March 13, 2022                [Page 12]

                        OpenID Connect Federation         September 2021


      keys
         REQUIRED.  List of JWKs.

      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.  This claim identifies the time at which the JWT was
         issued.

      exp
         OPTIONAL.  This claim identifies the time at which the JWT is
         no longer valid.

      There are more claims defined in [RFC7519]; of these, "aud" SHOULD
      NOT be used, since the issuer cannot know who the audience is.
      "nbf" and "jti" are deemed to not be very useful in this context
      and are therefore to be omitted.




























Hedberg, et al.          Expires March 13, 2022                [Page 13]

                        OpenID Connect Federation         September 2021


   The following is a non-normative example of a signed JWKS before
   serialization and adding a signature.

   {
     "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",
     "iat": 1618410883
   }

4.2.  OP Metadata

   The metadata type identifier is "openid_provider".

   All parameters defined in Section 3 of OpenID Connect Discovery 1.0
   [OpenID.Discovery] are applicable.

   In addition, the following parameters are defined by this
   specification:

   client_registration_types_supported
      REQUIRED.  Array specifying the federation types supported.
      Federation type values defined by this specification are
      "automatic" and "explicit".

   organization_name
      OPTIONAL.  A human-readable name representing the organization
      owning the OP.  It is intended to be used in the user interface,




Hedberg, et al.          Expires March 13, 2022                [Page 14]

                        OpenID Connect Federation         September 2021


      being recognized by the end users that would be using the OP to
      authenticate.

   federation_registration_endpoint
      OPTIONAL.  URL of the OP's Federation specific Dynamic Client
      Registration Endpoint.  If the OP supports explicit client
      registration as described in Section 10.2, then this claim is
      REQUIRED.

   request_authentication_methods_supported
      OPTIONAL.  In OpenID Connect Core, no client authentication is
      performed at the authentication endpoint.  Instead, you can say
      that a request authentication is performed.  What it amounts to is
      that the OP maps the information in the request to the information
      it has on the client, through static or dynamic registration.  If
      the map is successful, then the request is permitted to proceed.
      Something similar happens when automatic registration is used.
      Since there has been no explicit registration, the OP will gather
      information about the RP using the process outlined in Section 6.
      Once it has the RP metadata, the OP can verify the information the
      RP provides in the request.  We make this a bit more secure by
      demanding the use of the request parameter or pushed
      authorization.
      The claim value is a JSON object with members representing
      processes/endpoints and as values lists of request authentication
      methods that are supported by the authorization endpoint.  In this
      specification we use the processes/endpoints: Authorization
      Request (AR) as described in Section 3 of OpenID Connect Core 1.0
      [OpenID.Core] and Pushed Authorization Request (PAR), as described
      in [PAR].  The request authentication methods are:

      request_object
         This uses a Request Object as described in OpenID Connect Core
         1.0 [OpenID.Core].  There is more about this in Section 10.1.

      private_key_jwt
         The authentication process is described in Section 9 of OpenID
         Connect Core 1.0 [OpenID.Core].  Note that if "private_key_jwt"
         is used, the audience of the signed JWT MUST be either the URL
         of the Authorization Server's Authorization Endpoint or the
         Authorization Server's entity identifier.

      tls_client_auth
         Section 2.1 of [RFC8705].

      self_signed_tls_client_auth
         Section 2.2 of [RFC8705].




Hedberg, et al.          Expires March 13, 2022                [Page 15]

                        OpenID Connect Federation         September 2021


      The only request authentication method that can be used if doing
      authentication as described in OpenID Connect Core 1.0
      [OpenID.Core] is "request_object".  If pushed authorization is
      used then one of "private_key_jwt", "tls_client_auth" and
      "self_signed_tls_client_auth" can be used.

   signed_jwks_uri
      OPTIONAL.  A URI pointing to a signed JWT having the entity's JWK
      Set as payload.  The JWT is signed with a key that was included in
      the JWK that the entity published in its self-signed entity
      statement.

   The following is a non-normative example of OP metadata:'

   {
     "issuer": "https://server.example.com",
     "authorization_endpoint":
       "https://server.example.com/authorization",
     "token_endpoint": "https://server.example.com/token",
     "signed_jwks_uri": "https://server.example.com/jws.json",
     "response_types_supported": ["code", "id_token", "id_token token"],
     "subject_types_supported": ["public"],
     "id_token_signing_alg_values_supported": ["RS256", "ES256"],
     "token_endpoint_auth_methods_supported": ["private_key_jwt"],
     "pushed_authorization_request_endpoint":
       "https://server.example.com/par",
     "client_registration_types_supported": ["automatic", "explicit"],
     "federation_registration_endpoint":
       "https://server.example.com/fedreg",
     "request_authentication_methods_supported": {
       "ar": ["request_object"],
       "par": ["private_key_jwt", "self_signed_tls_client_auth"]
     }
   }

4.3.  OAuth Authorization Server

   The metadata type identifier is "oauth_authorization_server".

   All parameters defined in Section 2 of RFC 8414 [RFC8414] are
   applicable.

4.4.  OAuth Client

   The metadata type identifier is "oauth_client".

   All parameters defined in Section 2 of RFC 7591 [RFC7591] are
   applicable.



Hedberg, et al.          Expires March 13, 2022                [Page 16]

                        OpenID Connect Federation         September 2021


4.5.  OAuth Protected Resource

   The metadata type identifier is "oauth_resource".  There is no
   standard that specifies what parameters can occur in the metadata for
   this kind of entity.  So for the time being, this can be regarded as
   a placeholder.

4.6.  Federation Entity

   The metadata type identifier is "federation_entity".

   All entities participating in a federation are of this type.

   The following properties are allowed:

   federation_api_endpoint
      OPTIONAL.  The endpoint for the Federation API described in
      Section 7.  Intermediate entities and trust anchors MUST publish a
      "federation_api_endpoint".  Leaf entities MUST NOT.

   name
      OPTIONAL.  String.  The human-readable name describing the subject
      entity.  This MAY be, for example, the name of an organization.

   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.

   policy_uri
      OPTIONAL.  URL to documentation of conditions and policies
      relevant to this entity.

   homepage_uri
      OPTIONAL.  URL to a generic home page representing this entity.

   trust_marks
      OPTIONAL.  A JSON array of signed JSON Web Token each representing
      a certification mark.  There is more about certification marks in
      Section 5.3.

   Example









Hedberg, et al.          Expires March 13, 2022                [Page 17]

                        OpenID Connect Federation         September 2021


   "federation_entity": {
     "federation_api_endpoint":
       "https://example.com/federation_api_endpoint",
     "name": "The example cooperation",
     "homepage_uri": "https://www.example.com"
   }

5.  Federation Policy

5.1.  Metadata Policy

   An entity can publish metadata policies pertaining to entities of a
   specific type.  Entity type identifiers specified in this document
   can be found in Section 4.

   Each such metadata policy has the following structure:

   o  It consists of one or more policy entries.

   o  Each policy entry applies to one metadata parameter, such as
      "id_token_signing_alg".

   o  Each policy entry consists of one or more operators, which can be
      value modifiers or value checks.

   o  An operator can only appear once in a policy entry.

   It SHOULD be noted that claim names without language tags are
   different from the same claim but with language tags.

   An example of a policy entry:

   "id_token_signing_alg": {
     "default": "ES256",
     "one_of" : ["ES256", "ES384", "ES512"]
   }

   Which fits into a metadata policy like this:

   "metadata_policy" : {
     "openid_relying_party": {
       "id_token_signing_alg": {
         "default": "ES256",
         "one_of" : ["ES256", "ES384", "ES512"]
       }
     }
   }




Hedberg, et al.          Expires March 13, 2022                [Page 18]

                        OpenID Connect Federation         September 2021


5.1.1.  Operators

   Value modifiers are:

   value
      Disregarding what value the parameter had, if any, the parameter's
      value will be set to the operator's value.

   add
      Adds the value or values specified to the metadata parameter.  If
      any of the specified values are already present as values of the
      parameter, they will not be added.  If the parameter has no value,
      then the parameter is initialized with the specified value(s).

   default
      If no value is assigned to this parameter, then the parameter's
      value will be set to the operator's value(s).

   Value checks are:

   one_of
      The value of the parameter MUST be one of the ones listed in this
      directive.

   subset_of
      The resulting value of the parameter will be the intersection of
      the values in the directive and the values of the parameter.

   superset_of
      The values of the parameter MUST contain the ones in the
      directive.  We define superset the mathematical way, that is,
      equality is included.

   essential
      If "true", then the parameter MUST have a value.

5.1.2.  Restrictions on Policy Entries

   As stated, a policy entry can contain one or more operators.  Not all
   operators are allowed to appear together in a policy entry.

   subset_of/superset_of and one_of
      "subset_of" and "superset_of" applies to parameters that can have
      more than one value (for instance, "contacts") while "one_of"
      applies to parameters that can only have one value (for instance,
      "id_token_signed_response_alg").  This means that "one_of" cannot
      appear beside "subset_of"/ "superset_of" in a policy entry.




Hedberg, et al.          Expires March 13, 2022                [Page 19]

                        OpenID Connect Federation         September 2021


   value
      "value" overrides everything else.  So having "value" together
      with any other operator (except for "essential") does not make
      sense.

   Other restrictions are:

   o  If "subset_of" and "superset_of" both appear as operators, then
      the list of values in "subset_of" MUST be a superset of the values
      in "superset_of".

   o  If "add" appears in a policy entry together with "subset_of" then
      the value/values of "add" MUST be a subset of "subset_of".

   o  If "add" appears in a policy entry together with "superset_of"
      then the values of "add" MUST be a superset of "superset_of".

   o  If "default" appears in a policy entry together with "subset_of"
      then the values of "default" MUST be a subset of "subset_of".

   o  If "default" appears in a policy entry together with "superset_of"
      then the values of "default" MUST be a superset of "superset_of".

   o  If "add" appears in a policy entry together with "one_of" then the
      value of "add" MUST be a member of "one_of".

   o  If "default" appears in a policy entry together with "one_of" then
      the value "default" MUST be a member of "one_of".

5.1.3.  Combining Policies

   If there is more than one metadata policy in a trust chain, then the
   policies MUST be combined before they are applied to the metadata
   statement.

   Using the notation we have defined in Section 3.2, policies are
   combined starting with ES[i] and then adding the policies from ES[j]
   j=i-1,..,1 before applying the combined policy to the entity's
   metadata.

   After each combination, the policy for each parameter MUST adhere to
   the rules defined in Section 5.1.2.

5.1.3.1.  Merging Operators

   subset_of
      The result of merging the values of two "subset_of" operators is
      the intersection of the operator values.



Hedberg, et al.          Expires March 13, 2022                [Page 20]

                        OpenID Connect Federation         September 2021


   one_of
      The result of merging the values of two "one_of" operators is the
      intersection of the operator values.

   superset_of
      The result of merging the values of two "superset_of" operators is
      the union of the operator values.

   add
      The result of merging the values of two "add" operators is the
      union of the values.

   value
      Merging two "value" operators is NOT allowed unless the two
      operator values are equal.

   default
      Merging two "default" operators is NOT allowed unless the two
      operator values are equal.

   essential
      If a superior has specified "essential=true", then a subordinate
      cannot change that.  If a superior has specified
      "essential=false", then a subordinate is allowed to change that to
      "essential=true".  If a superior has not specified "essential",
      then a subordinate can set "essential" to "true" or "false".

5.1.4.  Applying Policies

   Once combining the Metadata policies has been accomplished, the next
   step is to apply the combined policy to the metadata.

   Doing that, one follows these steps for each parameter in the policy.

   1.  If there is a "value" operator in the policy, apply that and you
       are done.

   2.  Add whatever value is specified in an "add" operator.

   3.  If the parameter still has no value apply the "default" if there
       is one.

   4.  Do the essential check.  If "essential" is missing as an operator
       "essential" is to be treated as if set to "false".  If
       "essential" is defined to be "true", then the claim MUST have a
       value by now.  Otherwise applying the operator MUST fail.





Hedberg, et al.          Expires March 13, 2022                [Page 21]

                        OpenID Connect Federation         September 2021


   5.  Do the other checks.  Verified that the value is "one_of" or that
       the values are "subset_of"/"superset_of".  If the parameter
       values do not fall within the allowed boundaries, applying the
       operator MUST fail.

5.1.5.  Policy Combination Example

   A federation's policy for RPs:

   {
     "scopes": {
       "subset_of": [
         "openid",
         "eduperson",
         "phone"
       ],
       "superset_of": [
         "openid"
       ],
       "default": [
         "openid",
         "eduperson"
       ]
     },
     "id_token_signed_response_alg": {
       "one_of": [
         "ES256",
         "ES384",
         "ES512"
       ]
     },
     "contacts": {
       "add": "helpdesk@federation.example.org"
     },
     "application_type": {
       "value": "web"
     }
   }













Hedberg, et al.          Expires March 13, 2022                [Page 22]

                        OpenID Connect Federation         September 2021


   An organization's policy for RPs:

   {
     "scopes": {
       "subset_of": [
         "openid",
         "eduperson",
         "address"
       ],
       "default": [
         "openid",
         "eduperson"
       ]
     },
     "id_token_signed_response_alg": {
       "one_of": [
         "ES256",
         "ES384"
       ],
       "default": "ES256"
     },
     "contacts": {
       "add": "helpdesk@org.example.org"
     }
   }


























Hedberg, et al.          Expires March 13, 2022                [Page 23]

                        OpenID Connect Federation         September 2021


   The combined metadata policy then becomes:

   {
     "scopes": {
       "subset_of": [
         "openid",
         "eduperson"
       ],
       "superset_of": [
         "openid"
       ],
       "default": [
         "openid",
         "eduperson"
       ]
     },
     "id_token_signed_response_alg": {
       "one_of": [
         "ES256",
         "ES384"
       ],
       "default": "ES256"
     },
     "contacts": {
       "add": [
         "helpdesk@federation.example.org",
         "helpdesk@org.example.org"
       ]
     },
     "application_type": {
       "value": "web"
     }
   }

5.1.6.  Enforcing Policy

   If applying policies to a metadata statement results in incorrect
   metadata, then such a metadata statement MUST be regarded as broken
   and MUST NOT be used.

5.1.7.  Extending the Policy Language

   There might be parties that want to extend the policy language
   defined here.  If that happens then the rule is that if software
   compliant with this specification encounters a keyword it does not
   understand, it MUST ignore it unless it is listed in a
   "policy_language_crit" list, as is done for JWS [RFC7515] header
   parameters with the "crit" parameter.  If the policy language



Hedberg, et al.          Expires March 13, 2022                [Page 24]

                        OpenID Connect Federation         September 2021


   extension keyword is listed in the "policy_language_crit" list and
   not understood, then the metadata MUST be rejected.

5.1.8.  Policy Example

   The following is a non-normative example of a set of policies being
   applied to an RP's metadata.

   The RP's metadata:

   {
     "contacts": [
       "rp_admins@cs.example.com"
     ],
     "redirect_uris": [
       "https://cs.example.com/rp1"
     ],
     "response_types": [
       "code"
     ]
   }

   The federation's policy for RPs:

   {
     "scopes": {
       "superset_of": [
         "openid",
         "eduperson"
       ],
       "default": [
         "openid",
         "eduperson"
       ]
     },
     "response_types": {
       "subset_of": [
         "code",
         "code id_token"
       ]
     }
   }









Hedberg, et al.          Expires March 13, 2022                [Page 25]

                        OpenID Connect Federation         September 2021


   The organization's policy for RPs:

   {
     "contacts": {
       "add": "helpdesk@example.com"
     },
     "logo_uri": {
       "one_of": [
         "https://example.com/logo_small.jpg",
         "https://example.com/logo_big.jpg"
       ],
       "default": "https://example.com/logo_small.jpg"
     },
     "policy_uri": {
       "value": "https://example.com/policy.html"
     },
     "tos_uri": {
       "value": "https://example.com/tos.html"
     }
   }

   The metadata for the entity in question, after applying the policies
   above, would then become:

   {
     "contacts": [
       "rp_admins@cs.example.com",
       "helpdesk@example.com"
     ],
     "logo_uri": "https://example.com/logo_small.jpg",
     "policy_uri": "https://example.com/policy.html",
     "tos_uri": "https://example.com/tos.html",
     "scopes": [
       "openid",
       "eduperson"
     ],
     "response_types": [
       "code"
     ],
     "redirect_uris": [
       "https://cs.example.com/rp1"
     ]
   }








Hedberg, et al.          Expires March 13, 2022                [Page 26]

                        OpenID Connect Federation         September 2021


5.2.  Applying Constraints

   A constraint specification can contain the following claims:

   max_path_length
      OPTIONAL.  Integer.  The maximum number of entity statements
      between this entity statement and the last entity statement in the
      trust chain.

   naming_constraints
      OPTIONAL.  JSON object.  Restriction on the entity identifiers of
      the entities below this entity.  The behavior of this claim mimics
      what is defined in Section 4.2.1.10 in [RFC5280].  Restrictions
      are defined in terms of permitted or excluded name subtrees.

   The following is a non-normative example of such a specification:

   {
     "naming_constraints": {
       "permitted": [
         "https://.example.com"
       ],
       "excluded": [
         "https://east.example.com"
       ]
     },
     "max_path_length": 2
   }

   If a subordinate entity statement contains a constraint specification
   that is more restrictive than the one in effect, then the more
   restrictive constraint is in effect from here on.

   If a subordinate entity statement contains a constraint specification
   that is less restrictive than the one in effect, then it MUST be
   ignored.

5.2.1.  Max Path Length

   The "max_path_length" constraint specifies the maximum number of
   entity statement a trust chain can have between the entity statement
   that contains the constraint specification and the leaf's entity
   statement.

   A "max_path_length" constraint of zero indicates that no entity
   statement MAY appear between this entity statement and the leaf
   entity statement.  Where it appears, the "max_path_length" constraint




Hedberg, et al.          Expires March 13, 2022                [Page 27]

                        OpenID Connect Federation         September 2021


   MUST have a value that is greater than or equal to zero.  Where
   "max_path_length" does not appear, no limit is imposed.

   Assuming that we have a trust chain with four entity statements:

   1.  Leaf entity (LE)

   2.  Intermediate 1 (I1)

   3.  Intermediate 2 (I2)

   4.  Trust Anchor (TA)

   Then the trust chain fulfills the constraints if:

   o  The TA specifies a "max_path_length" that is equal to or bigger
      than 2.

   o  TA specifies "max_path_length" of 2, I2 specifies
      "max_path_length" of 1, and I1 specifies no "max_path_length"
      constraint.

   o  Neither TA nor I2 specifies any "max_path_length" constraint while
      I1 specifies "max_path_length" of 0.

   The trust chain does not fulfill the constraints if:

   o  TA has specified "max_path_length" of 1.

5.2.2.  Naming Constraints

   The "naming_constraints" member specifies a namespace within which
   all subject entity identifiers in subordinate entity statements in a
   trust chain MUST be located.

   Restrictions are defined in terms of permitted or excluded name
   subtrees.  Any name matching a restriction in the excluded claim is
   invalid regardless of information appearing in the permitted claim.

   The constraint MUST be specified as a fully qualified domain name and
   MAY specify a host or a domain.  Examples would be "host.example.com"
   and ".example.com".  When the constraint begins with a period, it MAY
   be expanded with one or more labels.  That is, the constraint
   ".example.com" is satisfied by both host.example.com and
   my.host.example.com.  However, the constraint ".example.com" is not
   satisfied by "example.com".  When the constraint does not begin with
   a period, it specifies a host.




Hedberg, et al.          Expires March 13, 2022                [Page 28]

                        OpenID Connect Federation         September 2021


5.3.  Trust Marks

   In this specification we use the US NSTIC definition: "A trustmark is
   used to indicate that a product or service provider has met the
   requirements of the Identity Ecosystem, as determined by an
   accreditation authority".

   Technically, trust marks as used by this specification are signed
   JWTs that represent a statement of conformance to a well-scoped set
   of trust and/or interoperability requirements.

   The trust marks are signed by a federation accredited authority.  The
   validation of such a signed statement is performed in the same way
   that a self-signed entity statement is validated.

   Note that a federation MAY allow an entity to self-sign some trust
   marks.

5.3.1.  Trust Mark Claims

   These are the properties that can occur in a trust mark:

   iss
      REQUIRED.  String.  The issuer of the trust mark.

   sub
      REQUIRED.  String.  The entity this trust mark applies to.

   id
      REQUIRED.  String.  An identifier of the trust mark.

   iat
      REQUIRED.  Number.  When this trust mark was issued.  Expressed as
      Seconds Since the Epoch, per [RFC7519].

   mark
      OPTIONAL.  String.  An URL that points to a mark/logo that the
      subject is allowed to display to a user of the entity.

   exp
      OPTIONAL.  Number.  When this trust mark is not valid anymore.
      Expressed as Seconds Since the Epoch, per [RFC7519].  If not
      present, it means that the trust mark is valid forever.

   ref
      OPTIONAL.  String.  URL that points to information connected to
      the issuance of this trust mark.




Hedberg, et al.          Expires March 13, 2022                [Page 29]

                        OpenID Connect Federation         September 2021


   Other claims MAY be used in conjunction with the claims outlined
   above.  The claim naming recommendations outlined in Section 5.1.2 of
   OpenID Connect Core 1.0 [OpenID.Core] apply.

5.3.2.  Validating a Trust Mark

   An entity SHOULD NOT try to validate a trust mark until it knows
   which trust anchors it wants to use.

   Validating a trust mark follows the procedure set out in Section 8.

   Note that the entity representing the accreditation authority SHOULD
   be well known and trusted for a given trust mark identifier.  A trust
   anchor MAY publish a list of accreditation authorities of trust marks
   that SHOULD be trusted by other federation entities.  A trust anchor
   uses the "trust_marks_issuers" claim in its entity statement to
   publish this information.

   For other externally issued trust marks, it is an out-of-band process
   to define and announce accreditation authorities to other entities
   and it is left to the discretion of the receiving party to assign an
   appropriate level of trust to such trust marks.

5.3.3.  Trust Mark Example

   An example of a self-signed certification mark:

   {
     "iss": "https://example.com/op",
     "sub": "https://example.com/op",
     "iat": 1579621160,
     "id": "https://openid.net/certification/op",
     "mark": "http://openid.net/wordpress-content/uploads/2016/
       05/oid-l-certification-mark-l-cmyk-150dpi-90mm.jpg",
     "ref": "https://openid.net/wordpress-content/uploads/2015/
       09/RolandHedberg-pyoidc-0.7.7-Basic-26-Sept-2015.zip"
   }

   An example of a third-party accreditation authority:

   {
     "iss": "https://swamid.sunet.se",
     "sub": "https://umu.se/op",
     "iat": 1577833200,
     "exp": 1609369200,
     "id":
       "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf"
   }



Hedberg, et al.          Expires March 13, 2022                [Page 30]

                        OpenID Connect Federation         September 2021


6.  Obtaining Federation Entity Configuration Information

   The configuration endpoint is found using the Well-Known URIs
   [RFC8615] specification, with the suffix "openid-federation".  The
   scheme, host, and port are taken directly from the entity identifier
   combined with the following path: "/.well-known/openid-federation".

   If the entity identifier contains a path, it is concatenated after
   "/.well-known/openid-federation" in the same manner that path
   components are concatenated to the well-known identifier in the OAuth
   2.0 Authorization Server Metadata [RFC8414] specification.  Of
   course, in real multi-tenant deployments, in which the entity
   identifier might be of the form "https://multi-tenant-
   service.example.com/my-tenant-identifier" the tenant is very likely
   to not have control over the path "https://multi-tenant-
   service.example.com/.well-known/openid-federation/my-tenant-
   identifier" whereas it is very likely to have control over the path
   "https://multi-tenant-service.example.com/my-tenant-identifier/.well-
   known/openid-federation".  Therefore, if using the configuration
   endpoint at the URL with the tenant path after the well-known part
   fails, it is RECOMMENDED that callers retry at the URL with the
   tenant path before the well-known part (even though this violates
   [RFC8615]).

   Federation Entities SHOULD make an Entity Configuration Document
   available at the configuration endpoint.  There is only one exception
   to this rule and that is for an RP that only does explicit
   registration.  Since it posts the self-signed entity statement to the
   OP during client registration, the OP has everything it needs from
   the RP.

6.1.  Federation Entity Configuration Request

   A federation Entity Configuration Document MUST be queried using an
   HTTP GET request at the previously specified path.  The requesting
   party would make the following request to the Entity
   "https://example.com" to obtain its Configuration information:


     GET /.well-known/openid-federation HTTP/1.1
     Host: example.com

6.2.  Federation Entity Configuration Response

   The response is a self-signed Entity Statement, as described in
   Section 3.1.  If the entity is an intermediate entity or a trust
   anchor, the response MUST contain metadata for a federation entity.




Hedberg, et al.          Expires March 13, 2022                [Page 31]

                        OpenID Connect Federation         September 2021


   A positive response is a signed entity statement, where the content
   type MUST be set to "application/jose".  In case of an error, the
   response will be a JSON object, the content type MUST be set to
   "application/json", and the error response uses the applicable HTTP
   status code value.

   The following is a non-normative example response from an
   intermediate entity, before serialization and adding a signature:

   200 OK
   Last-Modified: Thu, 29 Aug 2019 08:54:26 GMT
   Content-Type: application/jose

   {
     "iss": "https://example.com",
     "sub": "https://example.com",
     "iat": 1516239022,
     "exp": 1516298022,
     "metadata": {
       "federation_entity": {
         "federation_api_endpoint":
           "https://example.com/federation_api_endpoint",
         "name": "The example cooperation",
         "homepage_uri": "https://www.example.com"
       }
     },
     "authority_hints": ["https://federation.example.com"],
     "jwks": {
       "keys": [
         {
           "alg": "RS256",
           "e": "AQAB",
           "key_ops": [
             "verify"
           ],
           "kid": "key1",
           "kty": "RSA",
           "n": "pnXBOusEANuug6ewezb9J_...",
           "use": "sig"
         }
       ]
     }
   }








Hedberg, et al.          Expires March 13, 2022                [Page 32]

                        OpenID Connect Federation         September 2021


7.  Federation API

   All entities that are expected to publish entity statements about
   other entities MUST expose a Federation API endpoint.

   The federation API endpoint of an entity can be found in the
   configuration response as described in Section 6 or by other means.

   The Federation API is an HTTPS API that MAY support multiple
   operations.  Fetching entity statements is one of the operations, and
   the only one that all Federation API endpoints are REQUIRED to
   support.  All the other operations are OPTIONAL.  The list of defined
   operations MAY be extended in the future.

   While all operations on the federation API endpoint make use of a GET
   request, other operations MAY choose to use other HTTP methods.  If
   the "operation" parameter is left out, it is treated as a fetch
   entity statements request.  Unless otherwise mentioned or agreed
   upon, requests to the federation API do not need to be authenticated.

7.1.  Fetching Entity Statements (REQUIRED)

   Fetching entity statements is performed to collect entity statements
   one by one to gather trust chains.

   To fetch an entity statement, an entity needs to know the identifier
   of the entity to ask (the issuer), the federation API endpoint of
   that entity and the identifier of the entity that you want the
   statement to be about (the subject).

7.1.1.  Fetch Entity Statements Request

   The request MUST be an HTTP request using the GET method and the
   https scheme to a resolved federation API endpoint with the following
   query string parameters:

   operation
      OPTIONAL.  If not present, MUST be treated as "fetch".

   iss
      REQUIRED.  The entity identifier of the issuer from which you want
      an entity statement issued.  Because of the normalization of the
      URL, multiple issuers MAY resolve to a shared federation API.
      This parameter makes it explicit exactly which issuer we want
      entity statements from.

   sub




Hedberg, et al.          Expires March 13, 2022                [Page 33]

                        OpenID Connect Federation         September 2021


      OPTIONAL.  The entity identifier of the subject for which you
      would like an entity statement issued.  If this parameter is left
      out, it is considered to be the same as the issuer and would
      indicate a request for a self-issued statement.

   aud
      OPTIONAL.  The entity identifier of the requester.  If the "aud"
      parameter is present in the request, the "aud" claim SHOULD be
      present in the entity statement response and take exactly that
      value.

   The following is a non-normative example of an API request for an
   entity statement:

   GET /federation_api_endpoint?
   iss=https%3A%2F%2Fopenid.sunet.se%2Ffederation HTTP/1.1
   Host: openid.sunet.se

7.1.2.  Fetch Entity Statements Response

   A positive response is a signed entity statement where the content
   type MUST be set to "application/jose".  If it is a negative
   response, it will be a JSON object and the content type MUST be set
   to "application/json".  See more about error responses in
   Section 7.4.


























Hedberg, et al.          Expires March 13, 2022                [Page 34]

                        OpenID Connect Federation         September 2021


   The following is a non-normative example of a response, before
   serialization and adding a signature:

   200 OK
   Last-Modified: Mon, 17 Dec 2018 11:15:56 GMT
   Content-Type: application/jose

   {
     "iss": "https://openid.sunet.se",
     "sub": "https://openid.sunet.se",
     "iat": 1516239022,
     "exp": 1516298022,
     "metadata": {
       "openid_relying_party": {
         "application_type": "web",
         "redirect_uris": [
           "https://openid.sunet.se/rp/callback"
         ],
         "organization_name": "SUNET",
         "logo_uri": "https://www.sunet.se/sunet/images/32x32.png",
         "grant_types": [
           "authorization_code",
           "implicit"
         ],
         "jwks_uri": "https://openid.sunet.se/rp/jwks.json"
       }
     },
     "jwks": {
       "keys": [
         {
           "alg": "RS256",
           "e": "AQAB",
           "key_ops": [
             "verify"
           ],
           "kid": "key1",
           "kty": "RSA",
           "n": "pnXBOusEANuug6ewezb9J_...",
           "use": "sig"
         }
       ]
     },
     "authority_hints": [
       "https://edugain.org/federation"
     ]
   }





Hedberg, et al.          Expires March 13, 2022                [Page 35]

                        OpenID Connect Federation         September 2021


7.2.  Trust Negotiation (OPTIONAL)

   An entity MAY use the trust negotiation operation to fetch resolved
   metadata about itself as seen/trusted by another entity (the peer).
   The result may, for instance, tell an RP what operations, scopes and
   claims an OP would allow the RP to use if a specific trust anchor was
   used.

7.2.1.  Trust Negotiation Request

   The request MUST be an HTTP request using the GET method and the
   https scheme to a resolved federation API endpoint with the following
   query string parameters:

   operation
      REQUIRED.  MUST be set to "resolve_metadata".

   respondent
      REQUIRED.  The entity identifier of the entity whose metadata are
      requested.  Because of the normalization of the URL, multiple
      entity identifiers may resolve to a shared federation API.  This
      parameter makes it explicit exactly which entity is expected.

   peer
      REQUIRED.  The entity identifier of the entity that will collect
      the information.

   type
      REQUIRED.  The metadata type to resolve.  In this document, we use
      the metadata types listed in Section 4.

   anchor
      REQUIRED.  The trust anchor that the entity, defined by the "peer"
      parameter, MUST use when resolving the metadata.  The value is an
      entity identifier.

   The following is a non-normative example of an API request for trust
   negotiation:

   GET /federation_api_endpoint?
   operation=resolve_metadata&
   respondent=https%3A%2F%2Fopenid.sunet.se%2Ffederation&
   type=openid_provider&
   anchor=https%3A%2F%2Fswamid.se&
   peer=https%3A%2F%2Fidp.umu.se%2Fopenid HTTP/1.1
   Host: openid.sunet.se





Hedberg, et al.          Expires March 13, 2022                [Page 36]

                        OpenID Connect Federation         September 2021


7.2.2.  Trust Negotiation Response

   The response is a metadata statement that is the result of applying
   the metadata policies in the trust chain on the entity's metadata.

   The following is a non-normative example of a response:

   200 OK
   Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
   Content-Type: application/json

   {
     "organization_name": "University of Umea",
     "contacts": [
       "legal@umu.se",
       "technical@umu.se"
     ],
     "logo_uri":
       "https://www.umu.se/SRWStatic/img/umu-logo-left-neg-SE.svg",
     "op_policy_uri":
       "https://www.umu.se/en/about-the-website/legal-information/",
     "authorization_endpoint":
       "https://idp.umu.se/openid/authorization",
     "token_endpoint": "https://idp.umu.se/openid/token",
     "response_types_supported": [
       "code",
       "code id_token",
       "token"
     ],
     "grant_types_supported": [
       "authorization_code",
       "implicit",
       "urn:ietf:params:oauth:grant-type:jwt-bearer"
     ],
     "subject_types_supported": [
       "pairwise"
     ],
     "id_token_signing_alg_values_supported": [
       "RS256"
     ],
     "issuer": "https://idp.umu.se/openid",
     "jwks_uri": "https://idp.umu.se/openid/jwks_uri.json"
   }








Hedberg, et al.          Expires March 13, 2022                [Page 37]

                        OpenID Connect Federation         September 2021


7.3.  Entity Listings (OPTIONAL)

   An entity MAY query another entity for a list of all the entities
   immediately subordinate to that entity and about which that entity is
   prepared to issue statements about.  (In some cases, this MAY be a
   very large list.)

7.3.1.  Entity Listings Request

   The request MUST be an HTTP request using the GET method and the
   https scheme to a resolved federation API endpoint with the following
   query string parameters:

   operation
      REQUIRED.  MUST be set to "listing".

   iss
      REQUIRED.  The entity identifier of the entity from which an
      entity listing is requested.  Because of the normalization of the
      URL, multiple entity identifiers may resolve to a shared
      federation API.  This parameter makes it explicit exactly which
      entity is expected.

   is_leaf
      OPTIONAL.  If left out, the result should include both leaf
      entities and intermediate nodes.  If set to "true", the response
      SHOULD contain only leaf entities.  If set to "false", the
      response SHOULD contain only intermediate nodes.

   The following is a non-normative example of an API request for trust
   negotiation:

   GET /federation_api_endpoint?
   operation=listing&
   iss=https%3A%2F%2Fopenid.sunet.se%2Ffederation HTTP/1.1
   Host: openid.sunet.se

7.3.2.  Entity Listing Response

   The response MUST contain an JSON list with the known entity
   identifiers.










Hedberg, et al.          Expires March 13, 2022                [Page 38]

                        OpenID Connect Federation         September 2021


   The following is a non-normative example of a response:

   200 OK
   Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
   Content-Type: application/json

   [
     "https://ntnu.andreas.labs.uninett.no/",
     "https://blackboard.ntnu.no/openid/callback",
     "https://serviceprovider.andreas.labs.uninett.no/application17"
   ]

7.4.  Generic Error Response

   If the request was malformed, or some error occurred during
   processing of the request, the following standardized error format
   SHOULD be used regardless of the operation specified.

   The HTTP response code MUST be something in 400/500-range, giving an
   indication of the type of error.  The response body MUST be a JSON
   object containing the claims below and the content type MUST be set
   to "application/json".

   operation
      REQUIRED.  The operation of the request.

   error
      REQUIRED.  The error code.

   error_description
      REQUIRED.  A human-readable short text describing the error.

   The following is a non-normative example of an error response:

   400 Bad request
   Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
   Content-Type: application/json

   {
     "operation": "fetch",
     "error": "invalid_request",
     "error_description":
       "Required request parameter [iss] was missing."
   }







Hedberg, et al.          Expires March 13, 2022                [Page 39]

                        OpenID Connect Federation         September 2021


8.  Resolving Trust Chain and Metadata

   An entity (e.g., the Consumer) that wants to establish trust with a
   remote peer, MUST have the remote peer's entity identifier and a list
   of entity identifiers of trust anchors together with the public
   version of their signing keys.  The Consumer will first have to fetch
   sufficient entity statements to establish at least one chain of trust
   from the remote peer to one or more of the configured trust anchors.
   After that the entity MUST validate the trust chains independently,
   and -- if there are multiple valid trust chains and if the
   application demands it -- choose one.

8.1.  Fetching Entity Statements to Establish a Trust Chain

   Depending on the circumstances, the Consumer MAY either be handed the
   remote peer's self-issued entity statement, or it may have to fetch
   it by itself.  If it needs to fetch it, it will use the process
   described in Section 7.1.1 with both "iss" and "sub" containing the
   entity identifier of the remote peer.

   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 statement about the remote
   peer from each of the intermediates.  If the received entity
   statement contains an authority hint this process is repeated.  This
   time with the "iss" set to the intermediate's entity identifier and
   the "sub" to be the "iss" of the previous query.  The Consumer SHOULD
   NOT attempt to fetch entity statements it already has fetched during
   this process (loop prevention).

   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 the remote peer to at least one of the
   trusted trust anchors, then the list will be empty and there is no
   way of establishing trust in the remote peer's information.  How the
   Consumer deals with this is out of scope for this specification.

8.2.  Validating a Trust Chain

   As described in Section 3.2, a trust chain consists of an ordered
   list of entity statements.  So whichever way the Consumer 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.

   To validate the chain, the following MUST be done:




Hedberg, et al.          Expires March 13, 2022                [Page 40]

                        OpenID Connect Federation         September 2021


   o  For each entity statement ES[j] j=i,..,0:

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

   o  For j=0 verify that "iss" == "sub".

   o  For j=0,...,i-1: Verify that ES[j]['iss'] == ES[j+1]['sub']

   o  For j=0,...,i-1: Verify the signature of ES[j] using a public key
      carried in ES[j+1]['jwks'].

   o  For j == 0 verify the signature of ES[0] using a public key
      carried in ES[0]['jwks'].

   o  For j == i: verify that a) the issuer matches the configured
      identifier of a trust anchor and b) its signature is valid with
      the likewise configured public key of said trust anchor.

   Verifying the signature is a much more expensive operation then
   verifying the correctness of the statement and the timestamps.  An
   implementer MAY therefor chose to not verify the signature until all
   the other checks have been done.

   Consumers MAY cache Entity Statements or signature verification
   results for a given time until they expire Section 8.4.

   Note that the second bullet point means that, at each step in the
   trust chain resolution, it MUST be verified that the signing JWK is
   also present in the "jwks" statement claim issued by the superior.

8.3.  Choosing One of the Valid Trust Chains

   If multiple valid trust chains are found, the Consumer will need to
   decide on which one to use.

   One simple rule would be to prefer a shorter chain over a longer one.

   Consumers MAY follow other rules according to local policy.

8.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) set.  The expiration time of the whole trust
   chain is set to the minimum value of exp within the chain.



Hedberg, et al.          Expires March 13, 2022                [Page 41]

                        OpenID Connect Federation         September 2021


9.  Updating Metadata, Key Rollover, and Revocation

   This specification allows for a smooth process of updating metadata
   and public keys.

   As described above in Section 8.4, each trust chain has an expiration
   time.  A consumer of metadata using this specification MUST support
   refreshing a trust chain when it expires.  How often a consumer
   SHOULD re-evaluate the trust chain depends on how quickly the
   consumer wants to find out that something has changed in the trust
   chain.

9.1.  Protocol Key Rollover

   If a leaf entity publishes its public keys in the metadata part using
   "jwks", setting an expiration time on the self-signed entity
   statement can be used to control how often the receiving entity is
   fetching an updated version of the public key.

9.2.  Key Rollover for a Trust Anchor

   A trust anchor MUST publish a self-signed entity statement about
   itself.  The trust anchor SHOULD set a reasonable expiration time on
   that statement, such that the consumers will re-fetch the entity
   statement at reasonable intervals.  If the trust anchor wants to roll
   over its signing keys it would have to:

   1.  Add the new keys to the "jwks" representing the trust anchors
       signing keys.

   2.  Keep signing the entity statement using the old keys for a long
       enough time period to allow all subordinates to have gotten
       access to 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.

   It MUST be taken into consideration that clients MAY have manually
   configured public keys as part of their configuration.

9.3.  Revocation

   Since the consumers are expected to check the trust chain at regular,
   reasonably frequent times, this specification does not specify a




Hedberg, et al.          Expires March 13, 2022                [Page 42]

                        OpenID Connect Federation         September 2021


   standard revocation process.  Specific federations MAY make a
   different choice and will then have to add such a process.

10.  OpenID Connect Communication

   This section describes how the trust framework in this specification
   is used to establish trust between an RP and an OP that have no
   explicit configuration or registration in advance.

   There are two alternative approaches to establish trust between an RP
   and an OP, which we call automatic and explicit registration.
   Members of a federation or a community SHOULD agree upon which one to
   use.  While implementations should support both methods, deployments
   MAY choose to disable the use of one of them.

   Independent of whether the RP uses automatic or explicit
   registration, the way that the RP learns about the OP is the same.
   It will use the procedure that is described in Section 8.

10.1.  Automatic Registration

   Automatic registration allows an RP to send Authorization Requests to
   an OP without first registering with the OP.  It basically works by
   the OP using the Client ID in the request to find the RP's metadata
   using the process outlined in Section 8 and then verifies that the RP
   is in control of a private key that is a companion to one of the
   public keys the RP published through its metadata.

   For automatic registration to work a number of things MUST be valid:

   o  The Client ID of the RP MUST be set to be identical to the RP
      entity identifier.

   o  Without a registration process, the RP does not have a client
      secret.  Instead, the automatic registration model requires the RP
      to make use of asymmetric cryptography.  Basically, the RP must
      prove that it has control of the RP's private keys.

   o  The Client ID MUST be a URL from which the OP can fetch the RP's
      self-signed entity statement using the process described in
      Section 6.

   o  The OP MUST publish that it supports a request authentication
      method using the metadata claim
      "request_authentication_methods_supported".






Hedberg, et al.          Expires March 13, 2022                [Page 43]

                        OpenID Connect Federation         September 2021


10.1.1.  Authentication Request

   The Authentication Request is performed by passing a Request Object
   by value as described in Section 6.1 in OpenID Connect Core 1.0
   [OpenID.Core] or using pushed authorization as described in Pushed
   Authorization Requests [PAR].

10.1.1.1.  Using a Request Object

   In the case where a Request Object is used, the value of the
   "request" parameter is a JWT whose Claims are the request parameters
   specified in Section 3.1.2 in OpenID Connect Core 1.0 [OpenID.Core].
   The JWT MUST be signed and MAY be encrypted.  The following
   restrictions apply to the JWT:

   aud
      REQUIRED.  The Audience (aud) MUST be the URL of the Authorization
      Server's Authorization Endpoint.

   iss
      REQUIRED.  The claim "iss" MUST contain the client identifier.

   sub
      MUST NOT be present.  This together with the value of "aud" SHOULD
      make reuse of the statement for "private_key_jwt" client
      authentication not feasible.

   jti
      REQUIRED.  JWT ID.  A unique identifier for the JWT, which can be
      used to prevent reuse of the token.  These tokens MUST only be
      used once, unless conditions for reuse were negotiated between the
      parties; any such negotiation is beyond the scope of this
      specification.

   exp
      REQUIRED.  Expiration time on or after which the JWT MUST NOT be
      accepted for processing.

   iat
      OPTIONAL.  Time at which the JWT was issued.











Hedberg, et al.          Expires March 13, 2022                [Page 44]

                        OpenID Connect Federation         September 2021


   The following is a non-normative example of the Claims in a Request
   Object before base64url encoding and signing:

   {
     "aud": "https://op.example.org/authorization",
     "client_id": "https://rp.example.com",
     "exp": 1589699162,
     "iat": 1589699102,
     "iss": "https://rp.example.com",
     "jti": "4d3ec0f81f134ee9a97e0449be6d32be",
     "nonce": "4LX0mFMxdBjkGmtx7a8WIOnB",
     "redirect_uri": "https://rp.example.com/authz_cb",
     "response_type": "code",
     "scope": "openid profile email address phone",
     "state": "YmX8PM9I7WbNoMnnieKKBiptVW0sP2OZ",
     "sub": "https://rp.example.com"
   }

   The following is a non-normative example of an Authorization Request
   using the request parameter (with line wraps within values for
   display purposes only):

   https://server.example.com/authorize?
       redirect_uri=https%3A%2F%2Frp.example.com%2Fauthz_cb
       &scope=openid+profile+email+address+phone
       &response_type=code
       &client_id=https%3A%2F%2Frp.example.com
       &request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImRVTjJhMDF3Umtoa1
         NXcGxRVGh2Y1ZCSU5VSXdUVWRPVUZVMlRtVnJTbWhFUVhnelpYbHB
         UemRRTkEifQ.eyJzdWIiOiAiaHR0cHM6Ly9ycC5leGFtcGxlLmNvb
         SIsICJpc3MiOiAiaHR0cHM6Ly9ycC5leGFtcGxlLmNvbSIsICJpYX
         QiOiAxNTkzNjE1Nzk0LCAiZXhwIjogMTU5MzYxNTg1NCwgImF1ZCI
         6ICJodHRwczovL29wLmV4YW1wbGUub3JnL2F1dGhvcml6YXRpb24i
         LCAianRpIjogIjlhNDY2Njc3ZDZkOTQ5OWZiOTFjNDg4YTY1NzA0N
         TU2In0.mFq0V4KIb6eM-WV5vvQAvSSwoUyi-cy_ASMDgR1-amotjK
         6El0T1WV9-Hdrkgi_zBJtARs6VE380GmwpXXuMF1p6y-IoyIBJUSR
         w9LaeK9oi3d1stTT_J6VL8JwsNuetB6r9YLAQS-1p6mFKsv7TQSjk
         xNHfw0BTxfZftcDnooCqusC17xrz11qEY1CCtjDbbxYM1cYfzGFwS
         I0UZneQUZqa2ChOqWTguumG7XonB5NFZWieAtvyyPZaSI7AW5wCs2
         sH6kjMxOHEAIvxygZZwKpTiToccYtU7t0n2xKRr-oYDQaFjuRIemE
         xsuzVl6pbvCVYqyjxFscS9NgDB-hAAQ

10.1.1.1.1.  Processing the Authentication Request

   When the OP receives an incoming Authentication Request, the OP
   supports OpenID Connect Federation, the incoming Client ID is a valid
   URL, and the OP does not have the Client ID registered as a known




Hedberg, et al.          Expires March 13, 2022                [Page 45]

                        OpenID Connect Federation         September 2021


   client, then the OP SHOULD try to resolve and fetch trust chains
   starting with the RP's entity statement as described in Section 8.1.

   The OP MUST then validate the possible trust chains, as described in
   Section 8.2, and resolve the RP metadata with type
   "openid_relying_party".

   The OP SHOULD furthermore consider the resolved metadata of the RP,
   and verify that it complies with the client metadata specification in
   OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration].

   Once the OP has the RP's metadata, it can verify that the client was
   actually the one sending the Authorization Request by verifying the
   signature of the Request Object using the key material the client
   published through its metadata.

10.1.1.2.  Using Pushed Authorization

   Pushed Authorization [PAR] provides an interoperable way to push the
   payload of a Request Object directly to the AS in exchange for a
   "request_uri".

   When it comes to request authentication, the applicable methods are
   three:

   o  Using a JWT for Client authentication as described for
      "private_key_jwt" in Section 9 of OpenID Connect Core 1.0
      [OpenID.Core].

   o  mTLS as described in Section 2.2 of [RFC8705] based on self-signed
      certificates.  In this case the self-signed certificate MUST be
      present as the value of an "x5c" claim for one key in the JWK Set
      describing the RP's keys.

   o  mTLS as described in Section 2.1 of [RFC8705] based on public key
      infrastructure (PKI).

   Note that if mTLS is used, TLS client authentication MUST be
   configured and, in case of self-signed certificates, the server must
   omit trust chain validation (optional_no_ca).

   Using the example above, a request could look like this:









Hedberg, et al.          Expires March 13, 2022                [Page 46]

                        OpenID Connect Federation         September 2021


   POST /par HTTP/1.1
   Host: op.example.org
   Content-Type: application/x-www-form-urlencoded

   redirect_uri=https%3A%2F%2Frp.example.com%2Fauthz_cb
   &scope=openid+profile+email+address+phone
   &response_type=code
   &nonce=4LX0mFMxdBjkGmtx7a8WIOnB
   &state=YmX8PM9I7WbNoMnnieKKBiptVW0sP2OZ
   &client_id=https%3A%2F%2Frp.example.com
   &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
     client-assertion-type%3Ajwt-bearer
   &client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6ImRVTjJ
     hMDF3Umtoa1NXcGxRVGh2Y1ZCSU5VSXdUVWRPVUZVMlRtVnJTbW
     hFUVhnelpYbHBUemRRTkEifQ.eyJzdWIiOiAiaHR0cHM6Ly9ycC
     5leGFtcGxlLmNvbSIsICJpc3MiOiAiaHR0cHM6Ly9ycC5leGFtc
     GxlLmNvbSIsICJpYXQiOiAxNTg5NzA0NzAxLCAiZXhwIjogMTU4
     OTcwNDc2MSwgImF1ZCI6ICJodHRwczovL29wLmV4YW1wbGUub3J
     nL2F1dGhvcml6YXRpb24iLCAianRpIjogIjM5ZDVhZTU1MmQ5Yz
     Q4ZjBiOTEyZGM1NTY4ZWQ1MGQ2In0.oUt9Knx_lxb4V2S0tyNFH
     CNZeP7sImBy5XDsFxv1cUpGkAojNXSy2dnU5HEzscMgNW4wguz6
     KDkC01aq5OfN04SuVItS66bsx0h4Gs7grKAp_51bClzreBVzU4g
     _-dFTgF15T9VLIgM_juFNPA_g4Lx7Eb5r37rWTUrzXdmfxeou0X
     FC2p9BIqItU3m9gmH0ojdBCUX5Up0iDsys6_npYomqitAcvaBRD
     PiuUBa5Iar9HVR-H7FMAr7aq7s-dH5gx2CHIfM3-qlc2-_Apsy0
     BrQl6VePR6j-3q6JCWvNw7l4_F2UpHeanHb31fLKQbK-1yoXDNz
     DwA7B0ZqmuSmMFQ

10.1.1.2.1.  Processing the Authentication Request

   There are three different paths the OP MUST follow when processing
   the Authentication Request depending on which request authentication
   method that was used.  It all starts the same though.  When the OP
   receives an incoming Authentication Request, the OP supports OpenID
   Connect Federation, the incoming Client ID is a valid URL, the OP
   does not have the Client ID registered as a known client and the OP
   supports the request authentication method used then the OP SHOULD
   try to resolve and fetch trust chains starting with the RP's entity
   statement as described in Section 8.1.

   The OP SHOULD validate the possible trust chains, as described in
   Section 8.2, and resolve the RP metadata with type
   "openid_relying_party".

   The OP SHOULD consider the resolved metadata of the RP, and verify
   that it complies with the client metadata specification in OpenID
   Connect Dynamic Client Registration 1.0 [OpenID.Registration].




Hedberg, et al.          Expires March 13, 2022                [Page 47]

                        OpenID Connect Federation         September 2021


   Once the OP has the RP's metadata, it can verify the client.  This is
   where it diverges depending on which client authentication method was
   used.

   private_key_jwt
      If this method is used, then the OP will try to verify the
      signature of the signed JWT using the key material published by
      the RP in its metadata.  If the authentication is successful, then
      the registration is regarded as correct.

   tls_client_auth
      If mTLS is used and the certificate used was not self-signed, then
      the Subject Alternative Name of the certificate MUST match the
      entity identifier of the RP.

   self_signed_tls_client_auth
      If mTLS is used and the certificate used is a self-signed
      certificate, then the certificate MUST be present as the value of
      an "x5c" claim for one key in the JWK Set describing the RP's
      keys.

10.1.2.  Authentication Error Response

   If the OP fails to establish trust with the RP, it SHOULD use an
   appropriate error code, and an "error_description" that aids the RP
   to understand what is wrong.

   In addition to the error codes defined in Section 3.1.2.6 of OpenID
   Connect Core, this specification also defines the following error
   codes:

   missing_trust_anchor
      No trusted trust anchor could be found.

   validation_failed
      Trust chain validation failed.

   The following is a non-normative example error response:

   HTTP/1.1 302 Found
     Location: https://client.example.org/cb?
       error=missing_trust_anchor
       &error_description=
         Could%20not%20find%20a%20trusted%20anchor
       &state=af0ifjsldkj






Hedberg, et al.          Expires March 13, 2022                [Page 48]

                        OpenID Connect Federation         September 2021


10.2.  Explicit Registration

   This method involves performing an explicit registration of a new
   client the first time an RP interacts with an OP using something that
   basically follows the steps in OpenID Connect Dynamic Client
   Registration 1.0 [OpenID.Registration] but where the client
   registration request is a signed entity statement.

10.2.1.  Client Registration

10.2.1.1.  Client Registration Request

   The OP MUST support OpenID Dynamic Client Registration as extended by
   this specification.  This is signaled by having the claim
   "federation_registration_endpoint" in the OP's metadata.

   Given that the OP supports explicit registration, the RP progresses
   as follows:

   1.  Once it has the list of acceptable trust chains for the OP, it
       MUST choose the subset it wants to progress with.  The subset can
       be as small as one trust chain, but it can also contain more than
       one.

   2.  Based on the trust anchors referenced in the subset of trust
       chains, the RP will choose a set of "authority_hints" from its
       own set that terminate in those trust anchors.

   3.  The RP will now construct a self-signed entity statement where
       the metadata statement chosen is influenced by the OPs metadata
       and the "authority_hints" included are picked by the process
       described above.  Note that the "aud" claim in the entity
       statement is REQUIRED in this case and MUST be set to the OP
       issuer identifier.

   4.  The entity statement is sent, using POST, to the
       "federation_registration_endpoint" defined in this document.  The
       content type MUST be set to "application/jose".

10.2.1.2.  Client Registration Response

10.2.1.2.1.  OP Constructing the Response

   The trust chains MUST be constructed using the received entity
   statement.

   1.  After the OP receives the request, it collects and evaluates the
       trust chains starting with the "authority_hints" in the



Hedberg, et al.          Expires March 13, 2022                [Page 49]

                        OpenID Connect Federation         September 2021


       registration request.  After it has verified at least one trust
       chain it MUST verify that the signature on the received
       registration request is correct.

   2.  If it finds more than one acceptable trust chain, it MUST choose
       one trust anchor from those chains as the one it will proceed
       with.

   3.  At this point, if there already exists a client registration
       under the same entity identifier then that registration MUST be
       regarded as invalid.  Note that key material from the previous
       registration SHOULD be kept to enable verifying signatures or
       decrypting archived data.

   4.  The OP will now construct a metadata policy that, if applied to
       the RP's metadata statement, will result in metadata that the OP
       finds acceptable.  Note that the Client ID the OP chooses does
       not have to be the same as the entity identifier of the RP.  To
       the entity statement it will add a "trust_anchor_id" claim,
       containing the trust anchor chosen above.

   5.  It will sign and return the registration response (a signed
       entity statement) to the RP.

10.2.1.2.2.  RP Parsing the Response

   1.  The RP verifies the correctness of the received entity statement,
       making sure that the trust chains starting at the
       "authority_hints" terminate in trust anchors that were referenced
       in the entity statement it sent to the OP.

   2.  The RP MUST NOT apply metadata policies from the trust chains
       that the OP provides because those are not valid for the RP's
       metadata.  The RP MUST apply policies to the metadata using one
       of its own trust chains that ends in the trust anchor that the OP
       chose.  Once it has applied those policies, it can then apply the
       policy returned from the OP.  When it has applied all the
       metadata policies to its metadata statement, it then stores the
       result and can continue communicating with the OP using the
       agreed-upon metadata.

   3.  At this point the RP also knows which trust chain it should use
       when evaluating the OP's metadata.  It can therefore apply the
       metadata policies on the OP's metadata using the relevant trust
       chain and store the result as the OPs metadata.






Hedberg, et al.          Expires March 13, 2022                [Page 50]

                        OpenID Connect Federation         September 2021


   4.  If the RP does not accept the received entity statement for some
       reason, then it has the choice to restart the registration
       process or to give up.

10.2.2.  After Client Registration

   A client registration using this specification is not expected to be
   valid forever.  The entity statements exchanged all have expiration
   times, which means that the registration will eventually time out.
   An OP can also, for administrative reasons, decide that a client
   registration is not valid anymore.  An example of this could be that
   the OP leaves the federation in use.

10.2.2.1.  What the RP MUST Do

   At regular intervals, the RP MUST:

   1.  Starting with the OP's entity statement, resolve and verify the
       trust chains it chooses to use when constructing the registration
       request.  If those trust chains do not exist anymore or do not
       verify, then the registration SHOULD be regarded as invalid and a
       new registration process SHOULD be started.

   2.  If the OP's entity statement was properly formed the RP must now
       verify that the entity statement it received about itself from
       the OP is still valid.  Again, if that is not the case the
       registration SHOULD be regarded as invalid and a new registration
       process SHOULD be started.

   What is regarded as reasonable intervals will depend on federation
   policies and risk assessment by the maintainer of the RP.

10.2.2.2.  What the OP MUST Do

   At regular intervals, the OP MUST:

   1.  If the signature on the registration request has expired, it MUST
       mark the registration as invalid and demand that the RP MUST re-
       register.  Else

   2.  starting with the RP's client registration request, the OP MUST
       verify that there still is a valid trust chain terminating in the
       trust anchor the OP chose during the registration process.








Hedberg, et al.          Expires March 13, 2022                [Page 51]

                        OpenID Connect Federation         September 2021


10.2.3.  Expiration Times

   An OP MUST NOT assign an expiration time to an RP's registration that
   is later than the trust chain's expiration time.

11.  IANA Considerations

   TBD Register "federation_types_supported" for OP metadata with
   initial values "automatic" and "explicit".

   TBD Register "federation_type" for RP registration metadata.

   TBD Register "federation_registration_endpoint" for the OP metadata.

12.  Security Considerations

   Some of the interfaces defined in this specification could be used
   for Denial of Service attacks (DOS), most notably, Entity Listings
   (Section 7.3) and automatic client registration (Section 10.1).  If
   you plan to provide these interfaces as a service, you should
   consider applying normal defense methods, such as those described in
   [RFC4732].

13.  References

13.1.  Normative References

   [OpenID.Core]
              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Discovery 1.0", August 2015,
              <http://openid.net/specs/openid-connect-core-1_0.html>.

   [OpenID.Discovery]
              Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
              Connect Discovery 1.0", August 2015,
              <http://openid.net/specs/openid-connect-discovery-
              1_0.html>.

   [OpenID.Registration]
              Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
              Dynamic Client Registration 1.0", August 2015,
              <http://openid.net/specs/openid-connect-registration-
              1_0.html>.

   [PAR]      Lodderstedt, T., Sakimura, N., Campbell, B., Tonge, D.,
              and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
              <https://tools.ietf.org/id/draft-ietf-oauth-par-04.html>.




Hedberg, et al.          Expires March 13, 2022                [Page 52]

                        OpenID Connect Federation         September 2021


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC4732]  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
              Denial-of-Service Considerations", RFC 4732,
              DOI 10.17487/RFC4732, December 2006,
              <https://www.rfc-editor.org/info/rfc4732>.

   [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,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [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,
              <https://www.rfc-editor.org/info/rfc7591>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/info/rfc8414>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.






Hedberg, et al.          Expires March 13, 2022                [Page 53]

                        OpenID Connect Federation         September 2021


   [RFC8705]  Campbell, B., Bradley, J., Sakimura, N., and T.
              Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
              and Certificate-Bound Access Tokens", RFC 8705,
              DOI 10.17487/RFC8705, February 2020,
              <https://www.rfc-editor.org/info/rfc8705>.

13.2.  Informative References

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Appendix A.  Provider Information Discovery and Client Registration in a
             Federation

   Let us assume the following: The project LIGO would like to offer
   access to its wiki to all OPs in EduGAIN.  LIGO is registered to the
   InCommon federation.

   The players

                          EduGAIN
                             |
          +------------------+------------------+
          |                                     |
       SWAMID                               InCommon
          |                                     |
        umu.se                                  |
          |                                     |
      op.umu.se                           wiki.ligo.org

   Both SWAMID and InCommon are identity federations in their own right.
   They also have in common that they both are members of the EduGAIN
   federation.

   SWAMID and InCommon are different in how they register entities.
   SWAMID registers organizations and lets the organizations register
   entities that belong to the organization, while InCommon registers
   all entities directly and not beneath any organization entity.  Hence
   the differences in depth in the federations.

   Let us assume a researcher from Umeae University would like to login
   at the LIGO Wiki.  At the Wiki, the researcher will use some kind of
   discovery service to find the home identity provider (op.umu.se)

   Once the RP-part of the Wiki knows which OP it SHOULD talk to it has
   to find out a couple of things about the OP.  All if those things can




Hedberg, et al.          Expires March 13, 2022                [Page 54]

                        OpenID Connect Federation         September 2021


   be found in the metadata.  But finding the metadata is not enough;
   the RP also has to trust the metadata.

   Let us make a detour and start with what it takes to build a
   federation.

A.1.  Setting Up a Federation

   These are the steps you have to go through to set up your own
   federation.  What you minimally have to do is:

   o  Generate a signing key.  This must be a public/private key pair.

   o  Set up a signing service that can sign JWTs/entity statements
      using the federation operator's signing key.

   o  Set up web services that can publish signed entity statements.
      You need at least two: one for the URL corresponding to the
      federation's entity ID returning self-signed entity statements and
      the other one providing the fetch entity statement request API, as
      described in Section 7.1.1.

   Once you have this, you can start adding entities to your federation.
   Adding an entity comes down to:

   o  Providing the entity with the federation's entity ID and the
      public part of the key pairs used by the federation operator for
      signing entity statements.

   o  Getting the entity's entity ID and the JWKS that the entity plans
      to publish in its self-signed entity statement.

   Now before the federation operator starts adding entities, there have
   to be policies in place on who can be part of the federation and the
   layout of the federation.  Is it supposed to be a one-layer
   federation like Internet2, a two-layer one like the SWAMID
   federation, or a multi-layer federation?  The federation may also
   want to think about implementing other policies using the federation
   policy framework, as described in Section 5.

   With the federation in place, things can start happening.

A.2.  The LIGO Wiki Discovers the OP's Metadata

   Metadata discovery is a sequence of steps that starts with the RP
   fetching the self-signed entity statement of the leaf (in this case
   https://op.umu.se) using the process defined in Section 6.  What
   follows thereafter is this sequence of steps:



Hedberg, et al.          Expires March 13, 2022                [Page 55]

                        OpenID Connect Federation         September 2021


   1.  Pick out the immediate superior entities using the authority
       hints

   2.  Fetch the configuration for each such entity.  This uses the
       process defined in Section 6

   3.  Using the federation API endpoint of the superiors do a fetch
       request Section 7.1.1 on the endpoint asking for information
       about the subordinate entity.

   How many times this has to be repeated depends on the depth of the
   federation.  What follows below is the result of each step the RP has
   to take to find the OP's metadata using the federation setup
   described above.

   When building the trust chain, the entity statements issued by a
   superior about its subordinate are used together with the self-signed
   entity statement issued by the leaf.

   The self-signed entity statement concerning intermediates are not
   part of the trust chain.

A.2.1.  Configuration Information for op.umu.se

   The LIGO WIKI RP fetches the self-signed entity statement from the OP
   (op.umu.se) using the process defined in Section 6.

   The result is this entity statement.

   {
     "authority_hints": [
       "https://umu.se"
     ],
     "exp": 1568397247,
     "iat": 1568310847,
     "iss": "https://op.umu.se",
     "jwks": {
       "keys": [
         {
           "e": "AQAB",
           "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
           "kty": "RSA",
           "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
         }
       ]
     },
     "metadata": {
       "openid_provider": {



Hedberg, et al.          Expires March 13, 2022                [Page 56]

                        OpenID Connect Federation         September 2021


         "issuer": "https://op.umu.se/openid",
         "jwks_uri": "https://op.umu.se/openid/jwks_uri.json",
         "authorization_endpoint":
           "https://op.umu.se/openid/authorization",
         "client_registration_type": [
           "automatic",
           "explicit"
         ],
         "grant_types_supported": [
           "authorization_code",
           "implicit",
           "urn:ietf:params:oauth:grant-type:jwt-bearer"
         ],
         "id_token_signing_alg_values_supported": [
           "ES256", "RS256"
         ],
         "logo_uri":
           "https://www.umu.se/img/umu-logo-left-neg-SE.svg",
         "op_policy_uri":
           "https://www.umu.se/en/website/legal-information/",
         "response_types_supported": [
           "code",
           "code id_token",
           "token"
         ],
         "subject_types_supported": [
           "pairwise",
           "public"
         ],
         "token_endpoint": "https://op.umu.se/openid/token",
         "federation_registration_endpoint":
           "https://op.umu.se/openid/fedreg",
         "token_endpoint_auth_methods_supported": [
           "client_secret_post",
           "client_secret_basic",
           "client_secret_jwt",
           "private_key_jwt"
         ]
       }
     },
     "sub": "https://op.umu.se"
   }

   The "authority_hints" points to the intermediate https://umu.se.  So
   that is the next step.

   This entity statement is the first link in the trust chain.




Hedberg, et al.          Expires March 13, 2022                [Page 57]

                        OpenID Connect Federation         September 2021


A.2.2.  Configuration Information for 'https://umu.se'

   The LIGO RP fetches the self-signed entity statement from
   "https://umu.se" using the process defined in Section 6.

   The request will look like this:

   GET /.well-known/openid-federation HTTP/1.1
   Host: umu.se

   And the GET will return:

   {
     "authority_hints": [
       "https://swamid.se"
     ],
     "exp": 1568397247,
     "iat": 1568310847,
     "iss": "https://umu.se",
     "jwks": {
       "keys": [
         {
           "e": "AQAB",
           "kid": "endwNUZrNTJsX2NyQlp4bjhVcTFTTVltR2gxV2RV...",
           "kty": "RSA",
           "n": "vXdXzZwQo0hxRSmZEcDIsnpg-CMEkor50SOG-1XUlM..."
         }
       ]
     },
     "metadata": {
       "federation_entity": {
         "contacts": "ops@umu.se",
         "federation_api_endpoint": "https://umu.se/oidc/fedapi",
         "homepage_uri": "https://www.umu.se",
         "name": "UmU"
       }
     },
     "sub": "https://umu.se"
   }

   The only piece of information that is used from this entity statement
   is the "federation_api_endpoint", which is used in the next step.









Hedberg, et al.          Expires March 13, 2022                [Page 58]

                        OpenID Connect Federation         September 2021


A.2.3.  Entity Statement Published by 'https://umu.se' about
        'https://op.umu.se'

   The RP uses the federation API and the "fetch" command as defined in
   Section 7.1.1 to fetch information about "https://op.umu.se" from the
   API endpoint published in https://umu.se's configuration.

   The request will look like this:

   GET /oidc/fedapi?sub=https%3A%2F%2Fop.umu.se&
   iss=https%3A%2F%2Fumu.se HTTP/1.1
   Host: umu.se

   and the result is this:





































Hedberg, et al.          Expires March 13, 2022                [Page 59]

                        OpenID Connect Federation         September 2021


   {
     "authority_hints": [
       "https://swamid.se"
     ],
     "exp": 1568397247,
     "iat": 1568310847,
     "iss": "https://umu.se",
     "jwks": {
       "keys": [
         {
           "e": "AQAB",
           "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
           "kty": "RSA",
           "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
         }
       ]
     },
     "metadata_policy": {
       "openid_provider": {
         "contacts": {
           "add": [
             "ops@swamid.se"
           ]
         },
         "organization_name": {
           "value": "University of Ume\u00e5"
         },
         "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"
           ]
         }
       }
     },
     "sub": "https://op.umu.se"
   }



Hedberg, et al.          Expires March 13, 2022                [Page 60]

                        OpenID Connect Federation         September 2021


   This is the second link in the trust chain.

   Notable here is that this path leads to two trust anchors using the
   same next step ("https://swamid.se").

A.2.4.  Configuration Information for 'https://swamid.se'

   The LIGO Wiki RP fetches the self-signed entity statement from
   "https://swamid.se" using the process defined in Section 6.

   The request will look like this:

   GET /.well-known/openid-federation HTTP/1.1
   Host: swamid.se

   And the GET will return:

   {
     "authority_hints": [
       "https://edugain.geant.org"
     ],
     "exp": 1568397247,
     "iat": 1568310847,
     "iss": "https://swamid.se",
     "jwks": {
       "keys": [
         {
           "e": "AQAB",
           "kid": "N1pQTzFxUXZ1RXVsUkVuMG5uMnVDSURGRVdhUzdO...",
           "kty": "RSA",
           "n": "3EQc6cR_GSBq9km9-WCHY_lWJZWkcn0M05TGtH6D9S..."
         }
       ]
     },
     "metadata": {
       "federation_entity": {
         "contacts": "ops@swamid.se",
         "federation_api_endpoint":
           "https://swamid.sunet.se/fedapi",
         "homepage_uri": "https://www.sunet.se/swamid/",
         "name": "SWAMID"
       }
     },
     "sub": "https://swamid.se"
   }

   The only piece of information that is used from this entity statement
   is the "federation_api_endpoint", which is used in the next step.



Hedberg, et al.          Expires March 13, 2022                [Page 61]

                        OpenID Connect Federation         September 2021


A.2.5.  Entity Statement Published by 'https://swamid.se' about
        'https://umu.se'

   The LIGO Wiki RP uses the federation API and the "fetch" command as
   defined in Section 7.1.1 to fetch information about "https://umu.se"
   from the API endpoint published in https://swamid.se's configuration.

   The request will look like this:

   GET /fedapi?sub=https%3A%2F%2Fumu.se&
   iss=https%3A%2F%2Fswamid.se HTTP/1.1
   Host: swamid.se

   and the result is this:





































Hedberg, et al.          Expires March 13, 2022                [Page 62]

                        OpenID Connect Federation         September 2021


   {
     "authority_hints": [
       "https://edugain.geant.org"
     ],
     "exp": 1568397247,
     "iat": 1568310847,
     "iss": "https://swamid.se",
     "jwks": {
       "keys": [
         {
           "e": "AQAB",
           "kid": "endwNUZrNTJsX2NyQlp4bjhVcTFTTVltR2gxV2RV...",
           "kty": "RSA",
           "n": "vXdXzZwQo0hxRSmZEcDIsnpg-CMEkor50SOG-1XUlM..."
         }
       ]
     },
     "metadata_policy": {
       "openid_provider": {
         "id_token_signing_alg_values_supported": {
           "subset_of": [
             "RS256",
             "ES256",
             "ES384",
             "ES512"
           ]
         },
         "token_endpoint_auth_methods_supported": {
           "subset_of": [
             "client_secret_jwt",
             "private_key_jwt"
           ]
         },
         "userinfo_signing_alg_values_supported": {
           "subset_of": [
             "ES256",
             "ES384",
             "ES512"
           ]
         }
       }
     },
     "sub": "https://umu.se"
   }

   This is the third link in the trust chain.





Hedberg, et al.          Expires March 13, 2022                [Page 63]

                        OpenID Connect Federation         September 2021


   If we assume that the issuer of this entity statement is not in the
   list of trust anchors the LIGO Wiki RP has access to we have to go
   one step further.

A.2.6.  Configuration Information for 'https://edugain.geant.org'

   RP fetches the self-signed entity statement from
   "https://edugain.geant.org" using the process defined in Section 6.

   The request will look like this:

   GET /.well-known/openid-federation HTTP/1.1
   Host: edugain.geant.org

   And the GET will return:

   {
     "exp": 1568397247,
     "iat": 1568310847,
     "iss": "https://edugain.geant.org",
     "jwks": {
       "keys": [
         {
           "e": "AQAB",
           "kid": "Sl9DcjFxR3hrRGdabUNIR21KT3dvdWMyc2VUM2Fr...",
           "kty": "RSA",
           "n": "xKlwocDXUw-mrvDSO4oRrTRrVuTwotoBFpozvlq-1q..."
         }
       ]
     },
     "metadata": {
       "federation_entity": {
         "federation_api_endpoint": "https://geant.org/edugain/api"
       }
     },
     "sub": "https://edugain.geant.org"
   }


   Again, the only thing we need is the "federation_api_endpoint".  As
   described in Section 9.2, note SHOULD also be taken to "jwks" as the
   trust anchor MAY be performing a key rollover.









Hedberg, et al.          Expires March 13, 2022                [Page 64]

                        OpenID Connect Federation         September 2021


A.2.7.  Entity Statement Published by 'https://edugain.geant.org' about
        'https://swamid.se'

   The LIGO Wiki RP uses the federation API and the "fetch" command as
   defined in Section 7.1.1 to fetch information about
   "https://swamid.se" from the API endpoint published in
   https://edugain.geant.org's configuration.

   The request will look like this:

   GET /edugain/api?sub=https%3A%2F%2Fswamid.se&
   iss=https%3A%2F%2Fedugain.geant.org HTTP/1.1
   Host: geant.org

   and the result is this:

   {
     "exp": 1568397247,
     "iat": 1568310847,
     "iss": "https://edugain.geant.org",
     "jwks": {
       "keys": [
         {
           "e": "AQAB",
           "kid": "N1pQTzFxUXZ1RXVsUkVuMG5uMnVDSURGRVdhUzdO...",
           "kty": "RSA",
           "n": "3EQc6cR_GSBq9km9-WCHY_lWJZWkcn0M05TGtH6D9S..."
         }
       ]
     },
     "metadata_policy": {
       "openid_provider": {
         "contacts": {
           "add": "ops@edugain.geant.org"
         }
       },
       "openid_relying_party": {
         "contacts": {
           "add": "ops@edugain.geant.org"
         }
       }
     },
     "sub": "https://swamid.se"
   }

   If we assume that the issuer of this statement appears in the list of
   trust anchors the LIGO Wiki RP has access to this would be the fourth
   and final entity statement in the trust chain.



Hedberg, et al.          Expires March 13, 2022                [Page 65]

                        OpenID Connect Federation         September 2021


   We now have the whole chain from the self-signed entity statement of
   the leaf up until the last one that is issued by a trust anchor.  All
   in all, we have:

   1.  Self-signed entity statement by the leaf (https://op.umu.se)

   2.  Statement issued by https://umu.se about https://op.umu.se

   3.  Statement issued by https://swamid.se about https://umu.se

   4.  Statement issued by https://edugain.geant.org about
       https://swamid.se

   We also have the self-signed entity statements from https://umu.se,
   https://swamid.se and https://edugain.geant.org about themselves but
   those are not used in the trust chain verification.

   Using the public keys of the trust anchor that the LIGO Wiki RP has
   been provided with in some secure out-of-band way, it can now verify
   the trust chain as described in Section 8.2.

A.2.8.  Verified Metadata for op.umu.se

   Having verified the chain, the LIGO Wiki RP can proceed with the next
   step.

   Combining the metadata policies from the tree entity statements we
   have by a superior about its subordinate and applying the combined
   policy to the metadata statement that the leaf entity presented, we
   get:





















Hedberg, et al.          Expires March 13, 2022                [Page 66]

                        OpenID Connect Federation         September 2021


   {
     "authorization_endpoint":
       "https://op.umu.se/openid/authorization",
     "claims_parameter_supported": false,
     "contacts": [
       "ops@swamid.se"
     ],
     "federation_registration_endpoint":
       "https://op.umu.se/openid/fedreg",
     "client_registration_type": [
       "automatic",
       "explicit"
     ],
     "grant_types_supported": [
       "authorization_code",
       "implicit",
       "urn:ietf:params:oauth:grant-type:jwt-bearer"
     ],
     "id_token_signing_alg_values_supported": [
       "RS256",
       "ES256"
     ],
     "issuer": "https://op.umu.se/openid",
     "jwks_uri": "https://op.umu.se/openid/jwks_uri.json",
     "logo_uri":
       "https://www.umu.se/img/umu-logo-left-neg-SE.svg",
     "organization_name": "University of Ume\u00e5",
     "op_policy_uri":
       "https://www.umu.se/en/website/legal-information/",
     "request_parameter_supported": false,
     "request_uri_parameter_supported": true,
     "require_request_uri_registration": true,
     "response_types_supported": [
       "code",
       "code id_token",
       "token"
     ],
     "subject_types_supported": [
       "pairwise"
     ],
     "token_endpoint": "https://op.umu.se/openid/token",
     "token_endpoint_auth_methods_supported": [
       "private_key_jwt",
       "client_secret_jwt"
     ],
     "version": "3.0"
   }




Hedberg, et al.          Expires March 13, 2022                [Page 67]

                        OpenID Connect Federation         September 2021


   We have now reached the end of the Provider Discovery process.

A.3.  The Two Ways of Doing Client Registration

   As described in Section 10, there are two ways which can be used to
   do client registration:

   Automatic
      No negotiation between the RP and the OP is made regarding what
      features the client SHOULD use in future communication are done.
      The RP's published metadata filtered by the chosen trust chain's
      metadata policies defines the metadata that is to be used.

   Explicit
      The RP will access the "federation_registration_endpoint", which
      provides the metadata for the RP to use.  The OP MAY return a
      metadata policy that adds restrictions over and above what the
      trust chain already has defined.

A.3.1.  RP Sends Authentication Request (Automatic Registration)

   The LIGO Wiki RP does not do any registration but goes directly to
   sending an Authentication Request.

   Here is an example of such an Authentication Request:


























Hedberg, et al.          Expires March 13, 2022                [Page 68]

                        OpenID Connect Federation         September 2021


   GET /authorize?
     request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImRVTjJhMDF3Umtoa1NXc
       GxRVGh2Y1ZCSU5VSXdUVWRPVUZVMlRtVnJTbWhFUVhnelpYbHBUemRR
       TkEifQ.eyJyZXNwb25zZV90eXBlIjogImNvZGUiLCAic2NvcGUiOiAi
       b3BlbmlkIHByb2ZpbGUgZW1haWwiLCAiY2xpZW50X2lkIjogImh0dHB
       zOi8vd2lraS5saWdvLm9yZyIsICJzdGF0ZSI6ICIyZmY3ZTU4OS0zOD
       Q4LTQ2ZGEtYTNkMi05NDllMTIzNWU2NzEiLCAibm9uY2UiOiAiZjU4M
       WExODYtYWNhNC00NmIzLTk0ZmMtODA0ODQwODNlYjJjIiwgInJlZGly
       ZWN0X3VyaSI6ICJodHRwczovL3dpa2kubGlnby5vcmcvb3BlbmlkL2N
       hbGxiYWNrIiwgImlzcyI6ICIiLCAiaWF0IjogMTU5MzU4ODA4NSwgIm
       F1ZCI6ICJodHRwczovL29wLnVtdS5zZSJ9.cRwSFNcDx6VsacAQDcIx
       5OAt_Pj30I_uUKRh04N4QJd6MZ0f50sETRv8uspSt9fMa-5yV3uzthX
       _v8OtQrV33gW1vzgOSRCdHgeCN40StbzjFk102seDwtU_Uzrcsy7KrX
       YSBp8U0dBDjuxC6h18L8ExjeR-NFjcrhy0wwua7Tnb4QqtN0QCia6DD
       8QBNVTL1Ga0YPmMdT25wS26wug23IgpbZB20VUosmMGgGtS5yCI5AwK
       Bhozv-oBH5KxxHzH1Oss-RkIGiQnjRnaWwEOTITmfZWra1eHP254wFF
       2se-EnWtz1q2XwsD9NSsOEJwWJPirPPJaKso8ng6qrrOSgw
     &response_type=code
     &client_id=https%3A%2F%2Fwiki.ligo.org
     &redirect_uri=https%3A%2F%2Fwiki.ligo.org/openid/callback
     &scope=openid+profile+email
     HTTP/1.1
   Host: op.umu.se

   The OP receiving this Authentication Request will, unless the RP is
   already registered, start to dynamically fetch and establish trust
   with the RP.

A.3.1.1.  OP Fetches Entity Statements

   The OP needs to establish a trust chain for the RP (wiki.ligo.org).
   The OP in this example is configured with public keys of two
   federations:

   o  https://edugain.geant.org

   o  https://swamid.se

   The OP starts to resolve metadata for the client identifier
   https://wiki.ligo.org by fetching the self-issued entity statement
   using the process described in Section 6.

   The process is the same as described in Appendix A.2 and will result
   in a trust chain with the following entity statements:

   1.  Self-signed entity statement by the leaf https://wiki.ligo.org





Hedberg, et al.          Expires March 13, 2022                [Page 69]

                        OpenID Connect Federation         September 2021


   2.  Statement issued by https://incommon.org about
       https://wiki.ligo.org

   3.  Statement issued by https://edugain.geant.org about
       https://incommon.org

A.3.1.2.  OP Evaluates the RP Metadata

   Using the public keys of the trust anchor that the LIGO Wiki RP has
   been provided with in some secure out-of-band way, it can now verify
   the trust chain as described in Section 8.2.

   We will not list the complete entity statements but only the
   "metadata" and "metadata_policy" parts.  There are two metadata
   policies:

   edugain.geant.org

   "metadata_policy": {
     "openid_provider": {
       "contacts": {
         "add": "ops@edugain.geant.org"
       }
     },
     "openid_relying_party": {
       "contacts": {
         "add": "ops@edugain.geant.org"
       }
     }
   }

   incommon.org



















Hedberg, et al.          Expires March 13, 2022                [Page 70]

                        OpenID Connect Federation         September 2021


   "metadata_policy": {
     "openid_relying_party": {
       "application_type": {
         "one_of": [
           "web",
           "native"
         ]
       },
       "contacts": {
         "add": "ops@incommon.org"
       },
       "grant_types": {
         "subset_of": [
           "authorization_code",
           "refresh_token"
         ]
       }
     }
   }

   If you combine these and apply them to the metadata for wiki.ligo.org
   :

   "metadata": {
     "application_type": "web",
     "client_name": "LIGO Wiki",
     "contacts": [
       "ops@ligo.org"
     ],
     "grant_types": [
       "authorization_code",
       "refresh_token"
     ],
     "id_token_signing_alg_values_supported": [
       "RS256",
       "RS512"
     ],
     "jwks_uri": "https://wiki.ligo.org/jwks.json",
     "redirect_uris": [
       "https://wiki.ligo.org/callback"
     ],
     "response_types": [
       "code"
     ],
     "subject_type": "public"
   }

   You will get



Hedberg, et al.          Expires March 13, 2022                [Page 71]

                        OpenID Connect Federation         September 2021


   {
     "application_type": "web",
     "client_name": "LIGO Wiki",
     "contacts": [
       "ops@ligo.org",
       "ops@edugain.geant.org",
       "ops@incommon.org"
     ],
     "grant_types": [
       "refresh_token",
       "authorization_code"
     ],
     "id_token_signing_alg_values_supported": [
       "RS256",
       "RS512"
     ],
     "jwks_uri": "https://wiki.ligo.org/jwks.json",
     "redirect_uris": [
       "https://wiki.ligo.org/callback"
     ],
     "response_types": [
       "code"
     ],
     "subject_type": "public"
   }

   Having that, the registration is done, and the OP MUST now use the
   keys found at the URL specified in "jwks_uri" to verify the signature
   on the Request Object in the Authentication Request.

A.3.2.  Client Starts with Registration (Explicit Client Registration)

   Here the LIGO Wiki RP sends a client registration request to the
   "federation_registration_endpoint" of the OP (op.umu.se).  What it
   sends is a self-signed entity statement.

   Once the OP has the entity statement, it proceeds with the same
   sequence of steps as laid out in Appendix A.2.

   The OP will end up with the same RP metadata as was described in
   Appendix A.3.1.2, but what it now can do is return a metadata policy
   that it wants to be applied to the RP's metadata.  This metadata
   policy will be combined with the trust chain's combined metadata
   policy before being applied to the RP's metadata.

   If we assume that the OP does not support refresh tokens, it MAY want
   to add a metadata policy that says:




Hedberg, et al.          Expires March 13, 2022                [Page 72]

                        OpenID Connect Federation         September 2021


   "metadata_policy": {
     "openid_relying_party": {
       "grant_types": {
         "subset_of": [
           "authorization_code"
         ]
       }
     }
   }

   Thus, the entity statement returned by the OP to the RP MAY look like
   this:


   {
     "trust_anchor_id": "https://edugain.geant.org",
     "metadata_policy": {
       "openid_relying_party": {
         "application_type": {
           "one_of": [
             "web",
             "native"
           ]
         },
         "contacts": {
           "add": [
             "ops@incommon.org",
             "ops@edugain.geant.org"
           ]
         },
         "grant_types": {
           "subset_of": [
             "authorization_code",
             "refresh_token"
           ]
         }
         "registration_access_token": {
           "value": "nLe19cJ5e9SXXiPqnRRuxpjyWI73bDhD"
         },
         "client_id": {
           "value": "m3GyHw"
         },
         "client_secret_expires_at": {
           "value": 1604049619
         },
         "registration_client_uri": {
           "value":
             "https://op.umu.se/openid/registration?client_id=m3GyHw"



Hedberg, et al.          Expires March 13, 2022                [Page 73]

                        OpenID Connect Federation         September 2021


         },
         "client_secret": {
           "value":
             "cb44eed577f3b5edf3e08362d47a0dc44630b3dc6ea99f7a79205"
         },
         "client_id_issued_at": {
           "value": 1601457619
         }
       }
     },
     "authority_hints": [
       "https://incommon.org"
     ],
     "aud": "https://wiki.ligo.org",
     "jwks": {
       "keys": [
         {
           "kty": "RSA",
           "use": "sig",
           "kid":
             "U2JTWHY0VFg0a2FEVVdTaHptVDJsNDNiSDk5MXRBVEtNSFVkeXZwb",
           "e": "AQAB",
           "n":
             "4AZjgqFwMhTVSLrpzzNcwaCyVD88C_Hb3Bmor97vH-2AzldhuVb8K..."
         },
         {
           "kty": "EC",
           "use": "sig",
           "kid": "LWtFcklLOGdrW",
           "crv": "P-256",
           "x": "X2S1dFE7zokQDST0bfHdlOWxOc8FC1l4_sG1Kwa4l4s",
           "y": "812nU6OCKxgc2ZgSPt_dkXbYldG_smHJi4wXByDHc6g"
         }
       ]
     },
     "iss": "https://op.umu.se",
     "iat": 1601457619,
     "exp": 1601544019
   }

   And the resulting metadata used by the RP could look like:










Hedberg, et al.          Expires March 13, 2022                [Page 74]

                        OpenID Connect Federation         September 2021


   {
     "application_type": "web",
     "client_name": "LIGO Wiki",
     "contacts": [
       "ops@edugain.geant.org",
       "ops@incommon.org",
       "ops@ligo.org"
     ],
     "grant_types": [
       "authorization_code"
     ],
     "id_token_signing_alg_values_supported": [
       "RS256",
       "RS512"
     ],
     "jwks_uri": "https://wiki.ligo.org/jwks.json",
     "redirect_uris": [
       "https://wiki.ligo.org/callback"
     ],
     "response_types": [
       "code"
     ],
     "subject_type": "public"
   }

Appendix B.  Notices

   Copyright (c) 2021 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 or
   Final Specification solely for the purposes of (i) developing
   specifications, and (ii) implementing Implementers Drafts and Final
   Specifications 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



Hedberg, et al.          Expires March 13, 2022                [Page 75]

                        OpenID Connect Federation         September 2021


   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 requires contributors to offer a patent
   promise not to assert certain patent claims against other
   contributors and against implementers.  The OpenID Foundation 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.  Acknowledgements

   The authors wish to acknowledge the contributions of the following
   individuals and organizations to this specification: Vladimir
   Dzhuvinov, Heather Flanagan, Jouke Roorda, Mischa Salle, Marcos Sanz,
   Peter Schober, Michael Schwartz, and the JRA3T3 task force of
   GEANT4-2.

Appendix D.  Open Issues

   The following open issues remain to be addressed in this
   specification.

   o  The representation for RPs that are native applications needs to
      be defined.

   o  How are federation operator keys retrieved?

   o  A mechanism is needed for key rotation of federation operator keys
      for long-term security and maintainability of federations.

   o  A mechanism MAY be needed for bounding key lifetimes.

   o  Discuss that Key IDs MAY be chosen as the JWK Thumbprint [RFC
      7638] of the key.

   o  Discuss localization of human-readable strings.

   o  SAML2 as used in Research and Education federations uses
      post-/prefix matching on metadata in some cases.  We might need
      something similar or just use regular expressions.






Hedberg, et al.          Expires March 13, 2022                [Page 76]

                        OpenID Connect Federation         September 2021


   o  Define the relationship between trust anchors and Federation
      Operators, as people will expect to find the Federation Operator
      term in the specification.

   o  Add a diagram showing the relationships between FOs, orgs, sub-
      orgs, and leaf entities.

Appendix E.  Document History

   [[ To be removed from the final specification ]]

   -17

   o  Addressed many working group review comments.  Changes included
      adding the Overall Architecture section, the "trust_marks_issuers"
      claim, and the Setting Up a Federation section.

   -16

   o  Added Security Considerations section on Denial of Service
      attacks.

   -15

   o  Added "signed_jwks_uri", which had been lost somewhere along the
      road.

   -14

   o  Rewrote the federation policy section.

   o  What previously was referred to as "client authentication" in
      connection with automatic client registration is now changed to be
      "request authentication".

   o  Made a distinction between parameters and claims.

   o  Corrected the description of the intended behavior when
      "essential" is absent.

   -13

   o  Added 'trust_marks' as a parameter in the entity statement.

   o  An RP's self-signed entity statement MUST have the OP's issuer
      identifier as the value of 'aud'.

   o  Added RS256 as default signing algorithm for entity statements.



Hedberg, et al.          Expires March 13, 2022                [Page 77]

                        OpenID Connect Federation         September 2021


   o  Specified that the value of 'aud' in the entity statement use in
      automatic client registration MUST have the ASs authorization
      endpoint URL as value.  Also the 'sub' claim MUST NOT be present.

   o  Separating the usage of merge and combine as proposed by Vladimir
      Dzhuvinov in Bitbucket issue #1157.

   o  An RP doing only explicit client registration are not required to
      publish and support a .well-known/openid-federation endpoint.

   o  Every key in a JWK Set in an entity statement MUST have a kid.

   -12

   o  Made JWK Set OPTIONAL in an entity statement returned by OP as
      response of an explicit client registration

   o  Renamed entity type to client registration type.

   o  Added more text describing
      client_registration_auth_methods_supported.

   o  Made "Processing the Authentication Request" into two separate
      sections: one for Authentication Request and one for Pushed
      Authorization Request.

   o  Added example of URLs to some examples in the appendix.

   o  Changed the automatic client registration example in the appendix
      to use Request Object instead of a client_assertion.

   -11

   o  Added section on trust marks.

   o  Clarified private_key_jwt usage in the authentication request.

   o  Fixed Bitbucket issues #1150 and #1155 by Vladimir Dzhuvinov.

   o  Fixed some examples to make them syntactically correct.

   -10

   o  Incorporated additional review feedback from Marcos Sanz.  The
      primary change was moving constraints to their own section of the
      entity statement.

   -09



Hedberg, et al.          Expires March 13, 2022                [Page 78]

                        OpenID Connect Federation         September 2021


   o  Incorporated review feedback from Marcos Sanz.  Major changes were
      as follows.

   o  Separated entity configuration discovery from operations provided
      by the federation API.

   o  Defined new authentication error codes.

   o  Also incorporated review feedback from Michael B.  Jones.

   -08

   o  Incorporated review feedback from Michael B.  Jones.  Major
      changes were as follows.

   o  Deleted "sub_is_leaf" entity statement since it was redundant.

   o  Added "federation_type" RP registration metadata value and
      "federation_types_supported" OP metadata value.

   o  Deleted "openid_discovery" metadata type identifier since its
      purpose is already served by "openid_provider".

   o  Entity identifier paths are now included when using the Federation
      API, enabling use in multi-tenant deployments sharing a common
      domain name.

   o  Renamed "sub_is_leaf" to "is_leaf" in the Entity Listings Request
      operation parameters.

   o  Added "crit" and "policy_language_crit", enabling control over
      which entity statement and policy language extensions MUST be
      understood and processed.

   o  Renamed "openid_client" to "openid_relying_party".

   o  Renamed "oauth_service" to "oauth_authorization_server".

   o  Renamed "implicit" registration to "automatic" registration to
      avoid naming confusion with the implicit grant type.

   o  Renamed "op" to "operation" to avoid naming confusion with the use
      of "OP" as an acronym for "OpenID Provider".

   o  Renamed "url" to "uri" in several identifiers.

   o  Restored Open Issues appendix.




Hedberg, et al.          Expires March 13, 2022                [Page 79]

                        OpenID Connect Federation         September 2021


   o  Corrected document formatting issues.

   -07

   o  Split metadata into metadata and metadata_policy

   o  Updated example

   -06

   o  Some rewrites

   o  Added example of explicit client registration

   -05

   o  A major rewrite.

   -04

   o  Changed client metadata names "scopes" to "rp_scopes" and "claims"
      to "rp_claims".

   o  Added Open Issues appendix.

   o  Added additional references.

   o  Editorial improvements.

   o  Added standard Notices section, which is present in all OpenID
      specifications.

Authors' Addresses

   Roland Hedberg (editor)
   independent

   Email: roland@catalogix.se


   Michael B. Jones
   Microsoft

   Email: mbj@microsoft.com
   URI:   http://self-issued.info/






Hedberg, et al.          Expires March 13, 2022                [Page 80]

                        OpenID Connect Federation         September 2021


   Andreas Aekre Solberg
   Uninett AS

   Email: andreas.solberg@uninett.no
   URI:   https://www.linkedin.com/in/andreassolberg/


   Samuel Gulliksson
   Schibsted Media Group

   Email: samuel.gulliksson@gmail.com


   John Bradley
   Yubico

   Email: ve7jtb@ve7jtb.com
   URI:   http://www.thread-safe.com/

































Hedberg, et al.          Expires March 13, 2022                [Page 81]