OpenID Connect Federation 1.0 - draft 25

3.1. Entity Statement

An Entity Statement contains the information needed for the Entity that is the subject of the Entity Statement to participate in federation(s). An Entity Statement is always a signed JWT. The subject of the JWT is the Entity itself. The issuer of the JWT is the party that issued the Entity Statement. All Entities in a federation SHOULD be prepared to publish an Entity Statement about themselves (Entity Configuration).¶

Entity Statement JWTs MUST be explicitly typed, by setting the typ header parameter to entity-statement+jwt. This is done to prevent cross-JWT confusion (see [RFC8725], section 3.11).¶

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 and this Entity Statement is an Entity Configuration.¶

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 [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

REQUIRED Conditional. 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 intended to verify the signature of the issued Entity Statements and Trust Marks and SHOULD NOT be used in other protocols. Keys to be used in other protocols, such as OpenID Connect, are conveyed in the metadata element of the respective Entity Statement. This claim is only OPTIONAL for the Entity Statement returned from an OP when the client is doing Explicit Registration. In all other cases it is REQUIRED. Every JWK in the JWK Set MUST have a Key ID (kid). It is RECOMMENDED that the Key ID be the JWK Thumbprint [RFC7638] using the SHA-256 hash function of the key.¶

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 Configuration issued by a Trust Anchor with no superiors.¶

metadata

REQUIRED Conditional. 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 Entity Statement is an Entity Configuration, then the Entity Statement MUST contain a metadata claim. If iss and sub are not the same, then the Entity Statement MAY contain a metadata claim containing metadata asserted by a superior about the Entity identified by sub. If a metadata claim appears beside a metadata_policy claim in an Entity Statement then for each entity type, claims that appear in metadata MUST NOT appear in metadata_policy¶

metadata_policy

REQUIRED Conditional. JSON object that describes a metadata policy. A metadata_policy applies to the entity described in this Entity Statement as well as to all entities that appear beneath the entity described in this Entity Statement. This distinguishes metadata_policy from metadata which only applies to the subject itself. 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 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 objects, each representing a Trust Mark. Each JSON object MUST contain the following two claims and MAY contain other claims if needed. All the claims in the JSON object MUST have the same values as those contained in the Trust Mark JSON Web Token.¶

id

The Trust Mark unique identifier. It MUST be the same value as the id claim contained in the Trust Mark JSON Web Token.¶

trust_mark

A signed JSON Web Token that represents a Trust Mark.¶

There is more about Trust Marks in Section 5.3.¶

trust_marks_issuers

OPTIONAL. A Trust Anchor MAY use this claim to tell which combination of Trust Mark identifiers and issuers are trusted by the federation. This claim MUST be ignored if present in an Entity Configuration that describes an entity that is not a Trust Anchor. It is a JSON object with keys representing Trust Mark identifiers and values being an array of trusted entities representing the accreditation authority. If the value list bound to a Trust Mark identifier is empty it means that anyone can issue Trust Marks with that identifier. There is more about Trust Marks in Section 5.3.¶

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 (Explicit Client Registration (Section 10.2)). 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]. Implementations SHOULD support signature verification with the RSA SHA-256 algorithm because OpenID Connect Core requires support for it (alg value of RS256). Federations MAY also specify different mandatory-to-implement algorithms.¶

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.se"]
}

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).¶

{
  "iss": "https://feide.no",
  "sub": "https://ntnu.no",
  "iat": 1516239022,
  "exp": 1516298022,
  "crit": ["jti"],
  "jti": "7l2lncFdY6SlhNia",
  "policy_language_crit": ["regexp"],
  "metadata": {
    "openid_provider": {
      "issuer": "https://ntnu.no",
      "organization_name": "NTNU",
    },
    "oauth_client": {
      "organization_name": "NTNU"
    }
  },
  "metadata_policy": {
    "openid_provider": {
      "id_token_signing_alg_values_supported":
        {"subset_of": ["RS256", "RS384", "RS512"]},
      "op_policy_uri": {
        "regexp":
          "^https:\/\/[\\w-]+\\.example\\.com\/[\\w-]+\\.html"}
    },
    "oauth_client": {
      "grant_types": {
        "subset_of": ["authorization_code", "client_credentials"]},
      "scope": {
        "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"
      }
    ]
  }
}

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 Entity nor a Trust Anchor.¶

A Trust Chain begins with a Leaf Entity Configuration, has zero or more Entity Statements issued by intermediates about subordinates, including the 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). The Trust Chain MAY end with the Entity Configuration of the Trust Anchor.¶

If present, the Trust Anchor's Entity Configuration at the end of the chain contains configuration of the federation, such as the public keys of the Trust Anchor and other parameters considered within the trust evaluation. When this is this case, the Trust Chain consequentially contains the configuration of the federation at the date of the evaluation of the chain.¶

A simple example: If we have an RP that belongs to organization A that is a member of federation F, the Trust Chain for such a setup will contain the following Entity Statements:¶

1. an Entity Configuration about the RP published by the RP,¶
2. an Entity Statement about the RP published by Organization A,¶
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 Entity Configuration) to ES[i] (an Entity Statement issued by the Trust Anchor), i>0 then:¶

• 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 .¶
• 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 .¶
• It MUST be possible to verify the signature of ES[0] with one of the keys in ES[0]['jwks'].¶

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.1. OpenID Connect and OAuth2 Metadata

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

For OAuth2 federations, this specification uses metadata values from OAuth 2.0 Authorization Server Metadata as specified in [RFC8414].¶

For both OpenID Connect and OAuth2 metadata the following additional properties are defined.¶

organization_name

OPTIONAL. A human-readable name representing the organization owning the Entity. If the owner is a physical person this MAY be, for example, the name of a person. Note that this information will be publicly available.¶

signed_jwks_uri

OPTIONAL. A URI pointing to a signed JWT having the Entity's JWK Set as its payload. The JWT MUST be signed using a Federation Entity Key. A signed JWT can contain the following claims, all except keys defined in [RFC7519]:¶

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

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
    }

¶

The following is a non-normative example of an RP's Entity Configuration:¶

    {
      "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"
          ],
          "signed_jwks_uri": "https://openid.sunet.se/rp/jwks.jose",
          "jwks_uri":"https://openid.sunet.se/rp/signed_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"
      ]
    }

¶

jwks

OPTIONAL. JSON Web Key Set document, passed by value, as defined in [RFC7517]. This parameter is intended to be used by participants that, for some reason, are unable to use the signed_jwks_uri parameter. One significant downside of jwks is that it does not enable key rotation (which signed_jwks_uri and jwks_uri do).¶

4.2. Usage of the claims jwks, jwks_uri and signed_jwks_uri

It is RECOMMENDED that an Entity Configuration use only one of jwks, jwks_uri, and signed_jwks_uri in its OpenID Connect or OAuth2 metadata. However, there may be circumstances in which is it desirable to use multiple JWK Set representations, such as when an Entity is in multiple federations and the federations have different policies about the JWK Set representation to be used. When multiple JWK Set representations are used, the keys present in each representation SHOULD be the same. Even if they are not completely the same at a given instant in time (which may be the case during key rollover operations), implementations MUST make them consistent in a timely manner.¶

4.3. 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.¶

In addition, the parameters defined in Section 4 for OpenID Connect and OAuth2 entities and the following are 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.¶

4.4. 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 parameters defined in Section 4 for OpenID Connect and OAuth2 entities and the following are added:¶

client_registration_types_supported

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

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. A JSON Object defining the client authentications supported for each endpoint. The endpoint names are defined in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters]. Other endpoints and authentication methods are possible, if made recognizable according to established standards and not in conflict with the operating principles of this specification. In OpenID Connect Core, no client authentication is performed at the authentication endpoint. Instead, because the request itself is authenticated. What it amounts to is that the OP maps information in the request (like the redirect_uri) to information it has gained on the client, through static or dynamic registration. If the map is successful, then the request is permitted to be processed. If the RP uses Automatic Registration, as defined in Section 10.1, the OP has no prior knowledge of the RP. Therefore, the OP must start by gathering information about the RP using the process outlined in Section 6. Once it has the RP's metadata, the OP can then verify the request in the same way as if it had known the RP's metadata beforehand. To make the request verification more secure we demand the use of a client authentication or verification method that proves that the RP is in possession of a key that appears in the RP's metadata.¶

Client authentication methods are for instance:¶

private_key_jwt

private_key_jwt. This 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].¶

A client verification method, on the other hand, is something like:¶

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. Here the verification is based on the fact that the request object is signed with a key the RP is in control of.¶

The claim value of this parameter is a JSON object with members representing authentication request methods and as values lists of client authentication/verification methods that can be used together with the authentication request method.¶

Examples of authentication request methods are¶

• Authentication Request, as described in Section 3 of OpenID Connect Core 1.0 [OpenID.Core], and¶
• Pushed Authorization Request (PAR), as described in [RFC9126].¶

If AR is used, then a client verification method like request_object can be used. If PAR is used then client authentication methods like private_key_jwt, tls_client_auth and self_signed_tls_client_auth can be used.¶

request_authentication_signing_alg_values_supported

OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported for the signature on the JWT [RFC7519] used in the request_object contained in the request parameter of an authorization request or in the private_key_jwt of a pushed authorization request. This entry MUST be present if either of these authentication methods are specified in the request_authentication_methods_supported entry. No default algorithms are implied if this entry is omitted. Servers SHOULD support RS256. The value none MUST NOT be used.¶

The following is a non-normative example of an OP's Entity Configuration:¶

{
   "iss":"https://op.umu.se",
   "sub":"https://op.umu.se",
   "exp":1568397247,
   "iat":1568310847,
   "metadata":{
      "openid_provider":{
         "issuer":"https://op.umu.se/openid",
         "signed_jwks_uri":"https://op.umu.se/openid/signed_jwks.jose",
         "authorization_endpoint":"https://op.umu.se/openid/authorization",
         "client_registration_types_supported":[
            "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/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"
         ],
         "pushed_authorization_request_endpoint":"https://op.umu.se/openid/par",
         "request_authentication_methods_supported": {
            "authorization_endpoint": [
                "request_object"
            ],
            "pushed_authorization_request_endpoint": [
                "request_object",
                "private_key_jwt",
                "tls_client_auth",
                "self_signed_tls_client_auth"
            ]
        }
      }
   },
   "authority_hints":[
      "https://umu.se"
   ],
   "jwks":{
      "keys":[
         {
            "e":"AQAB",
            "kid":"dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
            "kty":"RSA",
            "n":"x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
         }
      ]
   },
}

5.1. Metadata Policy

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

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

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

{
  "scope": {
    "subset_of": [
      "openid",
      "eduperson",
      "phone"
    ],
    "superset_of": [
      "openid"
    ],
    "default": [
      "openid",
      "eduperson"
    ]
  },
  "token_endpoint_auth_method": {
    "one_of": [
      "client_secret_post",
      "client_secret_basic"
    ]
  },
  "contacts": {
    "add": "helpdesk@federation.example.org"
  }
}

{
  "scope": {
    "subset_of": [
      "openid",
      "eduperson",
      "address"
    ],
    "default": [
      "openid",
      "eduperson"
    ]
  },
  "token_endpoint_auth_method": {
    "one_of": [
      "client_secret_post",
      "client_secret_basic"
    ],
    "default": "client_secret_basic"
  },
  "contacts": {
    "add": "helpdesk@org.example.org"
  }
}

{
  "scope": {
    "subset_of": [
      "openid",
      "eduperson"
    ],
    "superset_of": [
      "openid"
    ],
    "default": [
      "openid",
      "eduperson"
    ]
  },
  "token_endpoint_auth_method": {
    "one_of": [
      "client_secret_post",
      "client_secret_basic"
    ],
    "default": "client_secret_basic"
  },
  "contacts": {
    "add": [
      "helpdesk@federation.example.org",
      "helpdesk@org.example.org"
    ]
  }
}

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

{
  "id_token_signed_response_alg": {
    "one_of": [
      "ES256",
      "ES384"
    ],
    "default": "ES256",
  },
  "response_types": {
    "subset_of": [
      "code",
      "code id_token"
    ]
  }
}

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

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

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 of [RFC5280]. Restrictions are defined in terms of permitted or excluded name subtrees.¶

allowed_leaf_entity_types

OPTIONAL. Array of strings. Each string is an entity type. Entity type identifiers specified in this document can be found in Section 4. This constraint restricts what types of Leaf Entities that MAY appear beneath the entity described in this Entity Statement.¶

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,
  "allowed_leaf_entity_types": ["openid_provider", "openid_relying_party"]
}

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.3. Trust Marks

Technically, Trust Marks as used by this specification are signed JWTs.¶

The Trust Marks are signed by a federation accredited authority. The validation of such a signed statement is performed in the same way that an Entity Configuration is validated. To make this validation possible the key used by the Trust Mark Issuer to sign Trust Marks MUST be one of its the Federation Entity Keys.¶

Note that a federation MAY allow an Entity to self-sign some Trust Marks.¶

Trust Mark JWTs MUST be explicitly typed, by setting the typ header parameter to trust-mark+jwt. This is done to prevent cross-JWT confusion (see [RFC8725], section 3.11).¶

{
  "iss": "https://rp.example.it/spid/",
  "sub": "https://rp.example.it/spid/",
  "iat": 1516239022,
  "exp": 1516298022,
  "trust_marks": [
    {
     "id": "https://www.spid.gov.it/certification/rp/",
     "trust_mark":
        "eyJraWQiOiJmdWtDdUtTS3hwWWJjN09lZUk3Ynlya3N5a0E1bDhPb2RFSXVyOH"
        "JoNFlBIiwidHlwIjoidHJ1c3QtbWFyaytqd3QiLCJhbGciOiJSUzI1NiJ9.eyJ"
        "pc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8vc"
        "nAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJpZCI6Imh0dHB"
        "zOi8vd3d3LnNwaWQuZ292Lml0L2NlcnRpZmljYXRpb24vcnAiLCJsb2dvX3Vya"
        "SI6Imh0dHBzOi8vd3d3LmFnaWQuZ292Lml0L3RoZW1lcy9jdXN0b20vYWdpZC9"
        "sb2dvLnN2ZyIsInJlZiI6Imh0dHBzOi8vZG9jcy5pdGFsaWEuaXQvZG9jcy9zc"
        "GlkLWNpZS1vaWRjLWRvY3MvaXQvdmVyc2lvbmUtY29ycmVudGUvIn0.AGf5Y4M"
        "oJt22rznH4i7Wqpb2EF2LzE6BFEkTzY1dCBMCK-8P_vj4Boz7335pUF45XXr2j"
        "x5_waDRgDoS5vOO-wfc0NWb4Zb_T1RCwcryrzV0z3jJICePMPM_1hZnBZjTNQd"
        "4EsFNvKmUo_teR2yzAZjguR2Rid30O5PO8kJtGaXDmz-rWaHbmfLhlNGJnqcp9"
        "Lo1bhkU_4Cjpn2bdX7RN0JyfHVY5IJXwdxUMENxZd-VtA5QYiw7kPExT53XcJO"
        "89ebe_ik4D0dl-vINwYhrIz2RPnqgA1OdbK7jg0vm8Tb3aemRLG7oLntHwqLO-"
        "gGYr6evM2_SgqwA0lQ9mB9yhw"
    }
  ],
  "metadata": {
    "openid_relying_party": {
      "application_type": "web",
      "client_registration_types": ["automatic"],
      "client_name": "https://rp.example.it/spid/",
      "contacts": [
        "ops@rp.example.it"
      ],

       ... follows other claims ...

   ... follows other claims ...

{
  "id":"https://federation.id/openid_relying_party/public/",
  "iss": "https://trust-anchor.gov.id",
  "sub": "https://rp.cie.id",
  "iat": 1579621160,
  "organization_name": "Organization name",
  "policy_uri": "https://rp.cie.id/privacy_policy",
  "tos_uri": "https://rp.cie.id/info_policy",
  "service_documentation": "https://rp.cie.id/api/v1/get/services",
  "ref": "https://rp.cie.id/documentation/manuale_operativo.pdf"
}

{
  "id":"https://federation.id/openid_relying_party/private/under-age",
  "iss": "https://trust-anchor.gov.id",
  "sub": "https://rp.cie.id",
  "iat": 1579621160,
  "organization_name": "Organization name",
  "policy_uri": "https://rp.cie.id/privacy_policy",
  "tos_uri": "https://rp.cie.id/info_policy"
}

{
  "id": "https://deleghedigitali.gov.it/openid_relying_party/sgd/",
  "iss": "https://deleghedigitali.gov.it",
  "sub": "https://rp.cie.id",
  "iat": 1579621160,
  "logo_uri": "https://deleghedigitali.gov.it/sgd-cmyk-150dpi-90mm.svg",
  "organization_type": "public",
  "id_code": "123456",
  "email": "info@rp.cie.id",
  "organization_name#it": "Nome dell'organizazzione",
  "policy_uri#it": "https://rp.cie.id/privacy_policy",
  "tos_uri#it": "https://rp.cie.id/info_policy",
  "service_documentation": "https://rp.cie.id/api/v1/get/services",
  "ref": "https://deleghedigitali.gov.it/documentation/manuale_operativo.pdf"
}

{
  "iss": "https://secusign.org",
  "sub": "https://example.com/op",
  "iat": 1579621160,
  "id": "https://secusign.org/level/A",
  "logo_uri": "https://secusign.org/static/levels/
    certification-level-A-150dpi-90mm.svg",
  "ref": "https://secusign.org/conformances/"
}

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

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

7.1. Fetching Entity Statements

All Entities that are expected to publish Entity Statements about other entities MUST expose a Fetch endpoint.¶

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 fetch endpoint of that Entity and the identifier of the Entity, that is the subject of the statement.¶

GET /federation_fetch_endpoint?
iss=https%3A%2F%2Fedugain.org%2Ffederation&
sub=https%3A%2F%2Fopenid%2Esunet%2Ese HTTP/1.1
Host: edugain.org

200 OK
Content-Type: application/entity-statement+jwt

{
  "iss": "https://edugain.org/federation",
  "sub": "https://openid.sunet.se"
  "exp": 1568397247,
  "iat": 1568310847,
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
        "kty": "RSA",
        "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
      }
    ]
  },
  "metadata":{
    "organization_name":"SUNET"
  }
  "metadata_policy": {
    "openid_provider": {
      "subject_types_supported": {
        "value": [
          "pairwise"
        ]
      },
      "token_endpoint_auth_methods_supported": {
        "default": [
          "private_key_jwt"
        ],
        "subset_of": [
          "private_key_jwt",
          "client_secret_jwt"
        ],
        "superset_of": [
          "private_key_jwt"
        ]
      }
    }
  }
}

7.2. Resolve Entity Statement

An Entity MAY use the resolve endpoint to fetch resolved metadata and Trust Marks for an Entity as seen/trusted by the resolver. The resolver is supposed to fetch the subject's Entity Configuration, collect a Trust Chain that starts with the subject's Entity Statement and ends with the specified Trust Anchor, verify the Trust Chain and then apply all the policies present in the Trust Chain to the Entity Statements metadata. The resolver is also expected to verify that the present Trust Marks are active. If it finds Trust Marks that are not active, then those should be left out of the response set.¶

GET /resolve?
sub=https%3A%2F%2Fop.example.it%2Fspid&
type=openid_provider&
anchor=https%3A%2F%2Fswamid.se HTTP/1.1
Host: openid.sunet.se

{
  "iss": "https://resolver.spid.gov.it/",
  "sub": "https://op.example.it/spid/",
  "iat": 1516239022,
  "exp": 1516298022,
  "metadata": {
    "openid_provider": {
      "contacts": ["legal@example.it", "technical@example.it"],
      "logo_uri":
        "https://op.example.it/static/img/op-logo.svg",
      "op_policy_uri":
        "https://op.example.it/en/about-the-website/legal-information/",
      "federation_registration_endpoint":"https://op.example.it/spid/fedreg/",
      "authorization_endpoint":
        "https://op.example.it/spid/authorization/",
      "token_endpoint": "https://op.example.it/spid/token/",
      "response_types_supported": [
        "code",
        "code id_token",
        "token"
      ],
      "grant_types_supported": [
        "authorization_code",
        "implicit",
        "urn:ietf:params:oauth:grant-type:jwt-bearer"
      ],
      "subject_types_supported": ["pairwise"],
      "id_token_signing_alg_values_supported": ["RS256"],
      "issuer": "https://op.example.it/spid/",
      "jwks": {
        "keys": [
          {
            "kty": "RSA",
            "use": "sig",
            "n": "1Ta-sE ...",
            "e": "AQAB",
            "kid": "FANFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
          }
        ]
      }
    }
  },
  "trust_marks": [
    {"id": "https://www.spid.gov.it/certification/op/",
     "trust_mark":
       "eyJhbGciOiJSUzI1NiIsImtpZCI6ImRGRTFjMFF4UzBFdFFrWmxNRXR3ZWxOQl"
       "eyJhbGciOiJSUzI1NiIsImtpZCI6Ijh4c3VLV2lWZndTZ0hvZjFUZTRPVWRjeT"
       "RxN2RKcktmRlJsTzV4aEhJYTAifQ.eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkL"
       "mdvdi5pdCIsInN1YiI6Imh0dHBzOi8vb3AuZXhhbXBsZS5pdC9zcGlkLyIsIml"
       "hdCI6MTU3OTYyMTE2MCwiaWQiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZ"
       "XJ0aWZpY2F0aW9uL29wLyIsImxvZ29fdXJpIjoiaHR0cHM6Ly93d3cuYWdpZC5"
       "nb3YuaXQvdGhlbWVzL2N1c3RvbS9hZ2lkL2xvZ28uc3ZnIiwicmVmIjoiaHR0c"
       "HM6Ly9kb2NzLml0YWxpYS5pdC9pdGFsaWEvc3BpZC9zcGlkLXJlZ29sZS10ZWN"
       "uaWNoZS1vaWRjL2l0L3N0YWJpbGUvaW5kZXguaHRtbCJ9"
    }
  ],
  "trust_chain" : [
    "eyJhbGciOiJSUzI1NiIsImtpZCI6Ims1NEhRdERpYnlHY3M5WldWTWZ2aUhm ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ..."
  ]
}

7.3. Entity Listings

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.)¶

GET /list HTTP/1.1
Host: openid.sunet.se

200 OK
Content-Type: application/json

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

7.4. Trust Mark Status

This is to allow an Entity to check whether a Trust Mark is still active or not. The query MUST be sent to the Trust Mark issuer.¶

GET /federation_trust_mark_status_endpoint?
sub=https%3A%2F%2Fopenid.sunet.se%2FRP
&id=https%3A%2F%2Frefeds.org%2Fsirtfi
HTTP/1.1
Host: operations.swamid.se

200 OK
Content-Type: application/json

{
  "active": true
}

7.6. Generic Error Response

If the request was malformed, or some error occurred during processing of the request, the response body SHOULD be a JSON object with the content type set to application/json.¶

In compliance with [RFC6749], the following standardized error format SHOULD be used:¶

error

REQUIRED. One of the following error codes SHOULD be used.¶

invalid_request

The request is incomplete or does not comply with current specifications. The HTTP response status code SHOULD be 400 (Bad Request).¶

invalid_client

The Client can not be authorized or is not a valid participant of the federation. The HTTP response status code SHOULD be 401 (Unauthorized).¶

not_found

The requested Entity Identifier is "not found". The HTTP response status code SHOULD be 404 (Not Found).¶

server_error

The server encountered an unexpected condition that prevented it from fulfilling the request. The HTTP response status code SHOULD be one in the 5xx range, like 500 (Internal Server Error).¶

temporarily_unavailable

The server hosting the federation endpoint is currently unable to handle the request due to a temporary overloading or maintenance. The HTTP response status code SHOULD be 503 (Service Unavailable).¶

unsupported_parameter

The server does not support the requested parameter.¶

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
Content-Type: application/json

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

8.1. Fetching Entity Statements to Establish a Trust Chain

Depending on the circumstances, the consumer MAY either be handed the remote peer's Entity Configuration, or it may have to fetch it by itself. If it needs to fetch it, it will use the process described in Section 6 based on 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 Configuration from each of the intermediates. If the received Entity Configuration contains an authority hint this process is repeated.¶

With the list of all intermediates and the Trust Anchor, the respective federation API (see Section 7) is used to fetch Entity Statements about the intermediates and the remote peer.¶

Note: 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:¶

• 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.¶
• For j=0 verify that iss == sub.¶
• For j=0,...,i-1: Verify that ES[j]['iss'] == ES[j+1]['sub']¶
• For j=0,...,i-1: Verify the signature of ES[j] using a public key carried in ES[j+1]['jwks'].¶
• For j == 0 verify the signature of ES[0] using a public key carried in ES[0]['jwks'].¶
• 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 than verifying the correctness of the statement and the timestamps. An implementer MAY therefore choose 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, per 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.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.¶

10.1. Automatic Registration

Automatic Registration enables an RP to make Authentication Requests without a prior registration step with the OP. The OP resolves the RP's Entity Configuration from the Client ID in the Authentication Request, following the process defined in Section 8.¶

Automatic Registration has the following characteristics:¶

• In all interactions with the OP, the RP employs its Entity Identifier as the Client ID. The OP retrieves the RP's Entity Configuration from a URL derived from the Entity Identifier, as described in Section 6.¶
• Since there is no registration step prior to the Authentication Request, the RP cannot be supplied with a Client Secret. Instead, the Automatic Registration model requires the RP to use asymmetric cryptography to authenticate its requests.¶
• The OP MUST publish that it supports a request authentication method using the metadata claim request_authentication_methods_supported.¶

{
  "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",
  "trust_chain" : [
    "eyJhbGciOiJSUzI1NiIsImtpZCI6Ims1NEhRdERpYnlHY3M5WldWTWZ2aUhm ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ..."
  ]
}

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=eyJhbGciOiJSUzI1NiIsImtpZCI6IjJIbm9GUzNZbkM5dGppQ2FpdmhXTFZVSjNB
      eHdHR3pfOTh1UkZhcU1FRXMifQ.eyJhdWQiOiJodHRwczovL29wLmV4YW1wbGUub
      3JnL2F1dGhvcml6YXRpb24iLCJjbGllbnRfaWQiOiJodHRwczovL3JwLmV4YW1wb
      GUuY29tIiwiZXhwIjoxNTg5Njk5MTYyLCJpYXQiOjE1ODk2OTkxMDIsImlzcyI6I
      mh0dHBzOi8vcnAuZXhhbXBsZS5jb20iLCJqdGkiOiI0ZDNlYzBmODFmMTM0ZWU5Y
      Tk3ZTA0NDliZTZkMzJiZSIsIm5vbmNlIjoiNExYMG1GTXhkQmprR210eDdhOFdJT
      25CIiwicmVkaXJlY3RfdXJpIjoiaHR0cHM6Ly9ycC5leGFtcGxlLmNvbS9hdXRoe
      l9jYiIsInJlc3BvbnNlX3R5cGUiOiJjb2RlIiwic2NvcGUiOiJvcGVuaWQgcHJvZ
      mlsZSBlbWFpbCBhZGRyZXNzIHBob25lIiwic3RhdGUiOiJZbVg4UE05STdXYk5vT
      W5uaWVLS0JpcHRWVzBzUDJPWiIsInN1YiI6Imh0dHBzOi8vcnAuZXhhbXBsZS5jb
      20iLCJ0cnVzdF9wYXRoX2hpbnQiOlsiaHR0cHM6Ly9pbnRlcm1lZGlhcnktb25lL
      m9yZyIsImh0dHBzOi8vaW50ZXJtZWRpYXJ5LXR3by5vcmciLCJodHRwczovL3Ryd
      XN0LWFuY2hvci5vcmciXX0.yJz8KKF-TZPzxG1iKRkhldlVzn6NtNpgpFK0Bm93v
      AGnDu6XxSfK1pHFOTYCnG8DH-c8k2QsL4zHQQjwVElcWJyNJKXUAkOhNufssJD09
      6CizIjDdHuzMs9-LAJH6e7eKbsE_-17xY7JvtxZGLDNAx9Dm4gBEl7H_8U5SorGW
      dSN8biVe3gySBivy7czrG2_afitpaEFMxDgy7wuU5aWKo9L1aaRSpcKpDHNq45Mz
      Ir4JTaSzob0Eil8H-QYUqqQR-ob86_gy7bHFhQMN-0lfXHkIl3riCo2JlxnjLctf
      IRa4r6OKgFMNDqPzGqgwPuXMbjhBTuJptUgsmbEwdsGYw

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

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

10.2. Explicit Registration

This method involves performing an explicit registration step for a new client before the RP interacts with an OP for the first time, similarly to the process specified by OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration], but where the client registration request contains the Entity Configuration or an entire Trust Chain.¶

10.3. Differences between Automatic Registration and Explicit Registration

The primary differences between Automatic Registration and Explicit Registration are:¶

• With Automatic Registration, there is no registration step prior to the Authentication Request, whereas with Explicit Registration, there is. (OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] and OAuth 2.0 Dynamic Client Registration [RFC7591]) also employ a prior registration step.)¶
• With Automatic Registration, the Client ID value is the RP's Entity Identifier, and is supplied to the OP by the RP, whereas with Explicit Registration, a Client ID is assigned by the OP and supplied to the RP.¶
• Instead of using a Client Secret to authenticate the client, with Automatic Registration, the client is authenticated by means of the RP proving that it controls a private key corresponding to one of its Entity Configuration's public keys.¶

10.4. Rationale for the Trust Chain in the Request

Both Automatic and Explicit Client Registration support the submission of the Trust Chain embedded in the Request, calculated by the requestor and related to itself. This enables the following benefits in a federation:¶

12.1. OAuth Authorization Server Metadata Registry

This specification registers the following metadata names in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414].¶

12.2. OAuth Dynamic Client Registration Metadata Registration

This specification registers the following client metadata definition in the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591].¶

12.3. OAuth Extensions Error Registration

This section registers the following values in the IANA "OAuth Extensions Error Registry" registry [IANA.OAuth.Parameters] established by [RFC6749].¶

12.4. Media Type Registration

This section registers the following media types [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838].¶

12.5. OAuth Parameter Registry

This specification registers the following parameter name in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749].¶

13.1. Denial-of-Service Attack Prevention

Some of the interfaces defined in this specification could be used for Denial-of-Service attacks (DoS), most notably, the Resolve endpoint (Section 7.3), Explicit Client Registration (Section 10.2), and Automatic Client Registration (Section 10.1), can be exploited as vectors of http propagation attacks. If these endpoints are provided, some adequate defense methods are required, such as those described below and in [RFC4732].¶

A Trust Mark can be statically validated, using the public key of its issuer. The static validation of the Trust Marks represent a filter against a propagation attacks. An attacker could exploit the Federation Entity Discovery mechanism and use an OIDC Federation to propagate many http requests. For each authorization request, crafted by an anonymous client, the OP would produce ~3 http requests to third parties in absence of intermediaries, and at least 5 http requests with at least one intermediary. If an OP doesn't find at least one valid Trust Mark in an Entity Configuration it should reject the request and temporary bans the requestor.¶

If client authentication is not demanded at the Resolve endpoint then incoming requests should not by default result in immediate collection (Federation Entity Discovery process) and evaluation of Trust Chains.¶

13.2. Unsigned Error Messages

One of the fundamental design goals of this protocol is to protect messages end-to-end. This can not be accomplished by demanding TLS since TLS, in lots of cases, is not end-to-end but ends in a HTTPS to HTTP Reverse Proxy. Allowing unsigned error messages therefore opens up an attack vector for someone who wants to run a Denial of Service attack. This is not specific to OpenID Connect Federation but equally valid for other protocols when HTTPS to HTTP reverse proxies are used.¶