openid-federation-1_0.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
        "http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd">
<!--
  NOTE:  This XML file is input used to produce the authoritative copy of an
  OpenID Foundation specification.  The authoritative copy is the HTML output.
  This XML source file is not authoritative.  The statement ipr="none" is
  present only to satisfy the document compilation tool and is not indicative
  of the IPR status of this specification.  The IPR for this specification is
  described in the "Notices" section.  This is a public OpenID Foundation
  document and not a private document, as the private="..." declaration could
  be taken to indicate.
-->
<rfc category="std" docName="openid-federation-1_0" ipr="none"
     submissionType="IETF" consensus="true"
     xmlns:xi="http://www.w3.org/2001/XInclude">

  <?rfc toc="yes" ?>
  <?rfc tocdepth="5" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc strict="yes" ?>
  <?rfc iprnotified="no" ?>
  <?rfc private="Final" ?>

  <front>
    <title abbrev="OpenID Federation">OpenID Federation 1.0</title>

    <author fullname="Roland Hedberg" initials="R." role="editor"
            surname="Hedberg">
      <organization>independent</organization>
      <address>
        <email>roland@catalogix.se</email>
      </address>
    </author>

    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization>Self-Issued Consulting</organization>
      <address>
        <email>michael_b_jones@hotmail.com</email>
        <uri>https://self-issued.info/</uri>
      </address>
    </author>

    <author fullname="Andreas Åkre Solberg" initials="A.Å."
            surname="Solberg">
      <organization>Sikt</organization>
      <address>
        <email>Andreas.Solberg@sikt.no</email>
        <uri>https://www.linkedin.com/in/andreassolberg/</uri>
      </address>
    </author>

    <author fullname="John Bradley" initials="J." surname="Bradley">
      <organization abbrev="Yubico">Yubico</organization>
      <address>
        <email>ve7jtb@ve7jtb.com</email>
        <uri>https://www.linkedin.com/in/ve7jtb/</uri>
      </address>
    </author>

    <author fullname="Giuseppe De Marco" initials="G." surname="De Marco">
      <organization>independent</organization>
      <address>
        <email>demarcog83@gmail.com</email>
        <uri>https://www.linkedin.com/in/giuseppe-de-marco-bb054245/</uri>
      </address>
    </author>

    <author fullname="Vladimir Dzhuvinov" initials="V." surname="Dzhuvinov">
      <organization>Connect2id</organization>
      <address>
        <email>vladimir@connect2id.com</email>
        <uri>https://www.linkedin.com/in/vladimirdzhuvinov/</uri>
      </address>
    </author>

    <date day="17" month="February" year="2026"/>

    <workgroup>OpenID Connect Working Group</workgroup>

    <keyword>OpenID</keyword>
    <keyword>OpenID Connect</keyword>
    <keyword>Federation</keyword>
    <keyword>Multilateral Federation</keyword>
    <keyword>Federation Entity</keyword>
    <keyword>Federation Operator</keyword>
    <keyword>Trust Anchor</keyword>
    <keyword>Trust Chain</keyword>
    <keyword>Trust Establishment</keyword>
    <keyword>Trust Mark</keyword>

    <abstract>
      <t>
        A federation can be expressed as an agreement between parties that trust each other.
        In bilateral federations, direct trust can be established between
        two organizations belonging to the same federation.
        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.
      </t>
      <t>
        An Entity in the federation must be able to trust that other Entities
        it interacts 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.
          </t>
      <t>
        This specification defines basic components to build multilateral
        federations. It also defines how to apply them in the contexts of OpenID
        Connect and OAuth 2.0. These components can be used by other application
        protocols for the purpose of establishing trust.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>
        This specification describes how two Entities that would like to
        interact can establish trust between them by means of a trusted third party
        called a Trust Anchor.
        A Trust Anchor is an Entity whose main purpose is to issue statements
        about Entities.
        An identity federation can be realized using this specification using
        one or more levels of authorities.
        Examples of authorities are federation operators, organizations,
        departments within organizations, and individual sites.
        This
        specification provides the basic technical trust infrastructure building
        blocks needed to create a dynamic and distributed trust network, such as a
        federation.
      </t>
      <t>
        Note that this specification only concerns itself with how Entities
        in a federation get to know about each other. An organization MAY
        be represented by more than one Entity in a federation. An Entity
        MAY also belong to more than one federation. Determining that two
        Entities belong to the same federation is the basis for
        establishing trust between them in this specification.
      </t>
      <t>
        Of course, the word "trust" is also used in the vernacular to
        encompass confidence in the security, reliability, and integrity of entities
        and their actions. This kind of trust is often established through
        empirical proof, such as past performance, security certifications,
        or transparent operational practices, which demonstrate a track
        record of adherence to security standards and ethical conduct.
        To be clear, this broader meaning of trust, while important,
        is largely beyond the scope of what this specification accomplishes.
      </t>
      <figure>
	<preamble>
	  Below is an example of two federations rooted at two different
	  Trust Anchors with some members in common.
	  Every Entity is able to establish mutual trust with any
	  other Entity by means of having at least one
	  common Trust Anchor between them.
	  These abbreviations are used in the diagram:
	  OpenID Provider (OP),
	  Relying Party (RP),
	  Resource Server (RS),
	  and
	  Authorization Server (AS).
	</preamble>
	<name>
	  Two Coexisting Federations with Some Members in Common
	</name>
<!--
  NOTE: this figure was made with ASCIIflow and its editable sources
  are available at the following link:
  https://asciiflow.com/#/share/eJzlVc1Kw0AQfpWw5x5ED2pvUQP2YCtpvC1I0JQWtEIM0lIKkrOHHBbJwWOPfQLxafokbn6aZHZnt5v2IrgEsruZ%2Bb7Z2fkmCzL1nwPSJaPgMQj9aPIyvR9P%2BCx8GM9Jhzz58yDknxeUvAXhK%2F9MSfe4Q8mMv89Pzvhsnu2cHvFZFMwivqDE4mPDPjbsveWTWMjYG4nSaeEfy5DxvsArHKvB5bl3Q8%2By%2B5fXA9eyKy40CGB7IWMp4o6rteYEuyJlW8P1rjNXBqnAHtfQTOGiedI6GvG41QJlQ9d%2FH6u8rc8fsdwPRI2twS3muh8aky%2FpYNTaAtZrnQp0M2nBYiDmldXre45741z1bM%2FZAmnVhAYIb69kB0WikhaqilTOKhYnxlQ7wu0mmkbma2mStmKqE1bmKRFsi7ei2yZ6FoblqiD7hgUvsjFg6uamOi7s4mDxQwbclDMoBY5wwSHhFyPHjMsjCFlHWVDUzAEUcuWQ4%2BvO7A51gTcqAoYo6l6TWSWmykHC1g80fHMMo46FZ7YlvNSdvqQuY4InKmBH88kzCzuMIYtu%2Fp9xFE0RVy26a8YC%2FvpQgtnL3irXDA1VG76N7lKyJMtfPimJxQ%3D%3D)
-->
	<artwork><![CDATA[
.-----------------.            .-----------------.
|  Trust Anchor A |            |  Trust Anchor B |
'------.--.-------'            '----.--.--.------'
       |  |                         |  |  |
    .--'  '---. .-------------------'  |  |
    |         | |                      |  |
.---v.  .-----v-v------.   .-----------'  |
| OP |  | Intermediate |   |              |
'----'  '--.--.--.-----'   |    .---------v----.
           |  |  |         |    | Intermediate |
   .-------'  |  '------.  |    '---.--.--.----'
   |          |         |  |        |  |  |
.--v-.      .-v--.     .v--v.   .---'  |  '----.
| RP |      | RS |     | OP |   |      |       |
'----'      '----'     '----'   |   .--v-.   .-v--.
                                |   | RP |   | RP |
                                |   '----'   '----'
                                |
                        .-------v------.
                        | Intermediate |
                        '----.--.--.---'
                             |  |  |
                       .-----'  |  '----.
                       |        |       |
                    .--v-.   .--v-.   .-v--.
                    | OP |   | RP |   | AS |
                    '----'   '----'   '----'
]]>
        </artwork>
      </figure>

      <section anchor="requirements-language" title="Requirements Notation and Conventions">
        <t>
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
          "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
          in this document are to be interpreted as described in
          BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	  when, and only when, they appear in all capitals, as shown here.
        </t>
	<t>
	  All uses of JSON Web Signature (JWS) <xref target="RFC7515"/>
	  and JSON Web Encryption (JWE) <xref target="RFC7516"/>
	  data structures in this specification utilize
	  the JWS Compact Serialization or the JWE Compact Serialization;
	  the JWS JSON Serialization and the JWE JSON Serialization are not used.
	</t>
      </section>
      <section anchor="Terminology" title="Terminology">
        <t>
          This specification uses the terms "Claim",
          "Claim Name", "Claim Value", "JSON Web Token (JWT)", and "JWT Claims Set"
          defined by <xref target="RFC7519">JSON Web Token (JWT)</xref>,
          the terms "OpenID Provider (OP)" and "Relying Party (RP)" defined
          by <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>, and
	  the terms "Authorization Endpoint", "Authorization Server (AS)",
	  "Client", "Client Authentication", "Client Identifier", "Client Secret",
	  "Protected Resource", "Redirection URI", "Refresh Token",
	  "Resource Server (RS)", and "Token Endpoint"
	  defined by <xref target="RFC6749">OAuth 2.0</xref>.

        </t>
        <t>
          This specification also defines the following terms:
          <list style="hanging">
            <t hangText="Entity">
              <vspace/>
              Something that has a separate and distinct existence and that can
              be identified in a context.
            </t>
            <t hangText="Entity Identifier">
              <vspace/>
              A globally unique string identifier that is bound to one Entity.
	      All Entity Identifiers defined by this specification are
	      URLs that use the <spanx style="verb">https</spanx> scheme,
	      have a host component, and MAY contain port and path components.
	      It MUST NOT contain query parameter or fragment components.
	      Profiles of this specification MAY define other kinds of
	      Entity Identifiers and processing rules that accompany them.
            </t>
            <t hangText="Trust Anchor">
              <vspace/>
              An Entity that represents a trusted third party.
            </t>
            <t hangText="Federation Entity">
              <vspace/>
              An Entity for which it is possible to construct a Trust Chain
              from the Entity to a Trust Anchor.
            </t>
            <t hangText="Entity Statement">
              <vspace/>
              A signed JWT that contains the information needed
              for an Entity to participate in federation(s),
              including metadata about itself
              and policies that apply to other Entities for which it is authoritative.
            </t>
            <t hangText="Entity Configuration">
              <vspace/>
              An Entity Statement issued by an Entity about itself. It contains
              the Entity's signing keys and further data used to control the
              Trust Chain resolution process, such as authority hints.
            </t>
            <t hangText="Subordinate Statement">
              <vspace/>
              An Entity Statement issued by a Superior Entity about
	      an Entity that is its Immediate Subordinate.
            </t>
            <t hangText="Entity Type">
              <vspace/>
              A role and function that an Entity plays
              within a federation. An Entity MUST be of at
              least one type and MAY be of many types.
              For example, an Entity can be both an OpenID Provider
              and Relying Party at the same time.
            </t>
            <t hangText="Entity Type Identifier">
              <vspace/>
              String identifier for an Entity Type.
            </t>
            <t hangText="Federation Operator">
              An organization that is authoritative for a federation.
              A federation operator administers the Trust Anchor(s) for Entities in its federation.
            </t>
            <t hangText="Intermediate Entity">
              <vspace/>
              An Entity that issues
              an Entity Statement appearing somewhere in between those
              issued by the Trust Anchor and the subject of a Trust Chain
	      (which is typically a Leaf Entity).
              The terms Intermediate Entity and Intermediate are used
              interchangeably in this specification.
            </t>
            <t hangText="Leaf Entity">
              <vspace/>
	      An Entity with no Subordinate Entities.
	      Leaf Entities typically play a protocol role,
	      such as an OpenID Connect Relying Party or OpenID Provider.
	      The terms Leaf Entity and Leaf
	      are used interchangeably in this specification.
            </t>
            <t hangText="Subordinate Entity">
              <vspace/>
	      An Entity that is somewhere below a Superior Entity
	      (a Trust Anchor or Intermediate) in the trust hierarchy,
	      possibly with Intermediates between them.
	      The terms Subordinate Entity and Subordinate
	      are used interchangeably in this specification.
            </t>
            <t hangText="Superior Entity">
              <vspace/>
	      An Entity that is somewhere above one or more Entities
	      (a Leaf or Intermediate) in the trust hierarchy,
	      possibly with Intermediates between them.
	      The terms Superior Entity and Superior
	      are used interchangeably in this specification.
            </t>
	    <t hangText="Immediate Subordinate Entity">
	      <vspace/>
	      An Entity that is immediately below a Superior Entity
	      in the trust hierarchy, with no Intermediates between them.
	      The terms Immediate Subordinate Entity and Immediate Subordinate
	      are used interchangeably in this specification.
	    </t>
	    <t hangText="Immediate Superior Entity">
	      <vspace/>
	      An Entity that is immediately above one or more Subordinate Entities
	      in the trust hierarchy, with no Intermediates between them.
	      The terms Immediate Superior Entity and Immediate Superior
	      are used interchangeably in this specification.
	    </t>
            <t hangText="Federation Entity Discovery">
              <vspace/>
              A process that starts with the Entity Identifier
	      for the subject of the Trust Chain and collects
              Entity Statements until the chosen Trust Anchor is reached.
              From the collected Entity Statements, a Trust Chain
              is constructed and verified.
              The result of the Federation Entity Discovery is that the
              metadata for the Trust Chain subject is constructed from the Trust Chain.
            </t>
            <t hangText="Trust Chain">
              <vspace/>
              A sequence of Entity Statements that represents a chain
              starting at an Entity Configuration that is the subject of the chain
	      (typically of a Leaf Entity) and ending in a Trust Anchor.
            </t>
            <t hangText="Trust Mark">
              Statement of conformance to a
              well-scoped set of trust and/or interoperability requirements
              as determined by an accreditation authority.
              Each Trust Mark has a Trust Mark type identifier.
            </t>
            <t hangText="Trust Mark Issuer">
              A Federation Entity that issues Trust Marks.
            </t>
            <t hangText="Trust Mark Owner">
              An Entity that owns the right to a Trust Mark type identifier.
            </t>
            <t hangText="Federation Entity Keys">
              Keys used for the cryptographic signatures required by
              the trust mechanisms defined in this specification.
              Every participant in a Federation publishes its public
              Federation Entity Keys in its Entity Configuration.
            </t>
            <t hangText="Resolved Metadata">
              The metadata that results from applying the metadata policy
              in the Trust Chain to the metadata in the Entity Configuration
              for the subject of the Trust Chain. The Resolved Metadata
              is the metadata that is used when interacting with
              the Entity.
            </t>
          </list>
        </t>
      </section>
    </section>

    <section title="Overall Architecture" anchor="architecture">
      <t>
        The basic component is the Entity Statement, which is a cryptographically
        signed <xref target="RFC7519">JSON Web Token (JWT)</xref>.
        A set of Entity Statements can form a path from an Entity
	(typically a Leaf Entity) to
        a Trust Anchor. Entity Configurations
        issued by Entities about themselves control the Trust Chain
        resolution process.
      </t>
      <t>
        The Entity Configuration of a Leaf or Intermediate Entity contains one or more
        references to its Immediate Superiors in the
	<spanx style="verb">authority_hints</spanx> parameter
	described in <xref target="authority_hints"/>.
        These references can be used to download the Entity Configuration of each Immediate Superior.
        One or more Entity Configurations are traversed during the Federation Entity Discovery
        until the Trust Anchor is reached.
      </t>
      <t>
        The Trust Anchor and its Intermediates issue Entity Statements
        about their Immediate Subordinate Entities called Subordinate Statements.
	The sequence of Entity Configurations
        and Subordinate Statements that validate the relationship between
        a Superior and a Subordinate, along a path towards the Trust Anchor,
        forms the proof that the subject of Trust Chain
	(typically a Leaf Entity) is a member of
        the federation rooted at the Trust Anchor.
      </t>
      <t>
        The Trust Chain that links the Entity Configurations to one another
	is verified with the signature of each Entity Configuration,
	as described in <xref target="trust_chain"/>.
      </t>
      <t>
        Once there is a verified Trust Chain, the federation policy is applied
        and the metadata for the Trust Chain subject
	within the Federation is derived,
        as described in <xref target="federation_policy"/>.
      </t>
      <t>
        This specification deals with trust operations;
        it does not cover or touch protocol operations
        other than metadata derivation and exchange.
        In OpenID Connect terms, these are the protocol operations specified in
        <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref>
        and
        <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>.
      </t>
      <t>
        OpenID Connect constructs are used in many of the examples in this
        specification, however this does not mean that this specification can only be used
        with OpenID Connect. On the contrary, it can also be
        used to build federations for other protocols.
      </t>

      <section title="Cryptographic Trust Mechanism" anchor="CryptographicTrustMechanism">
	<t>
	  The objects defined by this specification
	  that are used to establish cryptographic trust between participants
	  are secured as signed JWTs using public key cryptography.
	  In particular, the keys used for securing these objects are managed by
	  the Entities controlling those objects, with the public keys securing them
	  being distributed through those objects themselves.
	  This kind of trust mechanism has been utilized by
	  research and academic federations for over a decade.
	</t>
	<t>
	  Note that this cryptographic trust mechanism intentionally does not rely on
	  Web PKI / TLS <xref target="RFC9525"/> certificates for signing keys.
	  Which TLS certificates are considered trusted can vary considerably between systems
	  depending upon which certificate authorities are considered trusted
	  and there have been notable examples of ostensibly trusted certificates being compromised.
	  For those reasons, this specification explicitly eschews reliance on Web PKI
	  in favor of self-managed public keys, in this case,
	  keys represented as JSON Web Keys (JWKs) <xref target="RFC7517"/>.
	</t>
      </section>
    </section>

      <section anchor="entity-statement" title="Entity Statement">
        <t>
          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 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 publish an Entity Statement about themselves
          called an Entity Configuration.
          Superior Entities in a federation publish Entity Statements about
          their Immediate Subordinate Entities called Subordinate Statements.
        </t>
        <t>
          Entity Statement JWTs MUST be explicitly typed, by setting the
          <spanx style="verb">typ</spanx> header parameter to
          <spanx style="verb">entity-statement+jwt</spanx> to prevent
          cross-JWT confusion, per Section 3.11 of <xref target="RFC8725"/>.
          Entity Statements without a <spanx style="verb">typ</spanx> header parameter
          or with a different <spanx style="verb">typ</spanx> value MUST be rejected.
        </t>
        <t>
          The Entity Statement is signed using one of the private keys of the issuer
          Entity in the form of a <xref target="RFC7515">JSON Web Signature
          (JWS)</xref>.
          Implementations SHOULD support signature verification with
          the RSA SHA-256 algorithm because OpenID Connect Core
          requires support for it (<spanx style="verb">alg</spanx>
          value of <spanx style="verb">RS256</spanx>).
          Federations MAY also specify different mandatory-to-implement algorithms.
          Note that a Trust Chain can contain Entity Statements signed using different
          signing algorithms, as long as each signature uses a signature algorithm
          supported by the trust framework and implementations in use.
        </t>
	<t>
	  Entity Statement JWTs MUST include the
	  <spanx style="verb">kid</spanx> (Key ID) header parameter
	  with its value being the Key ID of the signing key used.
	</t>

	<section anchor="ESClaims" title="Entity Statement Claims">

        <t>
          The Claims in an Entity Statement are listed below.
          Applications and protocols utilizing Entity Statements MAY specify
          and use additional Claims.
        </t>

	<section title="Claims that MUST or MAY Appear in both Entity Configurations and Subordinate Statements"
		 anchor="common-claims">

        <t>
          <list style="hanging">
            <t hangText="iss">
              <vspace/>
              REQUIRED. The Entity Identifier of the issuer of
              the Entity Statement.
	      If the <spanx style="verb">iss</spanx> and
              the <spanx style="verb">sub</spanx> are identical,
	      the issuer is making an Entity Statement about itself
	      called an Entity Configuration.
            </t>
            <t hangText="sub">
              <vspace/>
              REQUIRED. The Entity Identifier of the subject.
            </t>
            <t hangText="iat">
              <vspace/>
              REQUIRED. Number. Time when this statement was issued.
                This is expressed as Seconds Since the Epoch, per
                <xref target="RFC7519"/>.
            </t>
            <t hangText="exp">
              <vspace/>
              REQUIRED. Number.
              Expiration time after which the statement MUST NOT be
              accepted for processing. This is expressed as Seconds
              Since the Epoch, per <xref target="RFC7519"/>.
            </t>
            <t hangText="jwks">
              <vspace/>
              REQUIRED. A <xref target="RFC7517">JSON Web Key Set (JWKS)</xref>
              representing the public part of the subject's Federation Entity
              signing keys. The corresponding private key is
              used by the Entity to sign the Entity Configuration about itself,
              by Trust Anchors and Intermediate Entities
	      to sign Subordinate Statements about their Immediate Subordinates,
	      and for other signatures made by Federation Entities,
	      such as Trust Mark signatures.
              However, this claim is OPTIONAL for the Entity Statement returned
              as an Explicit Registration Response, as defined in <xref target="cliregresp"/>;
              in all other cases, it is REQUIRED.
              Every JWK in the JWK Set MUST have a unique <spanx style="verb">kid</spanx> (Key ID) value.
              It is RECOMMENDED that the Key ID be the JWK Thumbprint <xref target="RFC7638"/>
              using the SHA-256 hash function of the key.
	      <vspace blankLines="1"/>
	      These Federation Entity Keys SHOULD NOT be used in other protocols.
	      (Keys to be used in other protocols, such as OpenID Connect,
	      are conveyed in the <spanx style="verb">metadata</spanx> elements
	      for the protocol's Entity Type Identifiers,
	      such as the metadata under the
	      <spanx style="verb">openid_provider</spanx> and
	      <spanx style="verb">openid_relying_party</spanx>
	      Entity Type Identifiers.)
            </t>
            <t hangText="metadata">
              <vspace/>
              OPTIONAL.
              JSON object that declares roles that the Entity plays -
              its Entity Types - and that contains metadata for those Entity Types.
              Each member name of the JSON
              object is an Entity Type Identifier, and each value MUST be a JSON
              object containing metadata parameters according to the metadata
              schema of the Entity Type.
              <vspace blankLines="1" />
              When an Entity participates in a federation or federations with
              one or more Entity Types, its Entity Configuration MUST contain a
              <spanx style="verb">metadata</spanx> Claim with JSON object values
              for each of the corresponding Entity Type Identifiers, even if the
              values are the empty JSON object <spanx style="verb">{}</spanx>
              (when the Entity Type has no associated metadata or Immediate
              Superiors supply any needed metadata).
              <vspace blankLines="1"/>
              An Immediate Superior MAY provide selected or all metadata
              parameters for an Immediate Subordinate, by using the
              <spanx style="verb">metadata</spanx> Claim in a Subordinate
              Statement. When <spanx style="verb">metadata</spanx> is used in a
              Subordinate Statement, it applies only to those Entity Types that
              are present in the subject's Entity Configuration. Furthermore,
              the metadata applies only to the subject of the Subordinate
              Statement and has no effect on the subject's Subordinates.
              Metadata parameters in a Subordinate Statement have precedence and
              override identically named parameters under the same Entity Type
              in the subject's Entity Configuration. If both
              <spanx style="verb">metadata</spanx> and
              <spanx style="verb">metadata_policy</spanx> appear in a
              Subordinate Statement, then the stated
              <spanx style="verb">metadata</spanx> MUST be applied before the
              <spanx style="verb">metadata_policy</spanx>, as described in
              <xref target="metadata_policy_application"/>.
            </t>
	    <t hangText="crit">
              <vspace/>
              OPTIONAL.
	      Entity Statements require that
	      the <spanx style="verb">crit</spanx> (critical) Claim
	      defined in <xref target="critClaim"/> be understood and processed.
	      Claims in the Entity Statement whose Claim Names are in the array
	      that is the value of this Claim MUST be understood and processed.
	      Claims specified for use in Entity Statements by this specification
	      MUST NOT be included in the list.
            </t>

          </list>
        </t>
      </section>

      <section anchor="ec-specific"
	       title="Claims that MUST or MAY Appear in Entity Configurations but Not in Subordinate Statements">
	<t>
	  <list style="hanging">
            <t hangText="authority_hints" anchor="authority_hints">
              <vspace/>
              OPTIONAL. An array of strings representing
              the Entity Identifiers of Intermediate Entities or Trust Anchors
              that are Immediate Superiors of the Entity.
              This Claim is REQUIRED in Entity Configurations of
              the Entities that have at least one Superior above them,
              such as Leaf and Intermediate Entities.
              Its value MUST contain the Entity Identifiers of
	      its Immediate Superiors and
	      MUST NOT be the empty array
              <spanx style="verb">[]</spanx>.
              This Claim MUST NOT be present in Entity Configurations
              of Trust Anchors with no Superiors.
            </t>
            <t hangText="trust_anchor_hints" anchor="trust_anchor_hints">
              <vspace/>
              OPTIONAL. An array of strings representing
              the Entity Identifiers of Trust Anchors
              trusted by the Entity.
              Its value MUST NOT be the empty array
              <spanx style="verb">[]</spanx>.
              This Claim MUST NOT be present in Entity Configurations
              of Trust Anchors with no Superiors.
            </t>
            <t hangText="trust_marks">
              <vspace/>
              OPTIONAL. An array of JSON objects, each representing
              a Trust Mark.
              <list style="hanging">
                <t hangText="trust_mark_type">
                  REQUIRED. Identifier for the type of the Trust Mark.
                  The value of this Claim MUST be the same as the value of the
                  <spanx style="verb">trust_mark_type</spanx>
                  Claim contained in the Trust Mark JWT that is the value of the
		              <spanx style="verb">trust_mark</spanx> Claim in this object.
                </t>
                <t hangText="trust_mark">
                  REQUIRED. A signed JSON Web Token that represents a Trust Mark.
                </t>
              </list>
              Trust Marks are described in <xref target="trust_marks"/>.
            </t>
            <t hangText="trust_mark_issuers">
              <vspace/>
              OPTIONAL.
              A Trust Anchor MAY use this Claim to tell which combination of
              Trust Mark type identifiers and issuers are trusted by the federation.
              This Claim MUST be ignored if present in an Entity Configuration
              for an Entity that is not a Trust Anchor.
              It is a JSON object with member names that are Trust Mark type identifiers and
              each corresponding value being an array of Entity Identifiers
              that are trusted to represent the accreditation authority
              for Trust Marks with that identifier.
              If the array following a Trust Mark type identifier is empty,
              anyone MAY issue Trust Marks with that identifier.
              Trust Marks are described in <xref target="trust_marks"/>.
            </t>
            <t hangText="trust_mark_owners">
              <vspace/>
              OPTIONAL.
              If a Federation Operator knows that a Trust Mark type identifier is owned
              by an Entity different from the Trust Mark Issuer, then that
              knowledge MUST be expressed in this Claim.
              This Claim MUST be ignored if present in an Entity Configuration
              for an Entity that is not a Trust Anchor.
              It is a JSON object with member names that are Trust Mark type identifiers and
              each corresponding value being a JSON object with these members:
              <list style="hanging">
                <t hangText="sub">
                  <vspace/>
                  REQUIRED
                  Identifier of the Trust Mark Owner.
                </t>
                <t hangText="jwks">
                  <vspace/>
                  REQUIRED
                  <xref target="RFC7517">JSON Web Key Set (JWKS)</xref>
                  containing the owner's Federation Entity Keys used for signing.
                </t>
              </list>
	      Other members MAY also be defined and used.
            </t>
	  </list>
	</t>
      </section>

      <section anchor="ss-specific"
	       title="Claims that MUST or MAY Appear in Subordinate Statements but Not in Entity Configurations">
	<t>
	  <list style="hanging">
            <t hangText="constraints">
              <vspace/>
              OPTIONAL. JSON object that defines Trust Chain constraints, as
              described in <xref target="chain_constraints"/>. The constraints apply to the
              Entity that is the subject of this Subordinate Statement as well
              as to all Entities that are Subordinate to it.
            </t>
	    <t hangText="metadata_policy">
              <vspace/>
              OPTIONAL. JSON object that defines a metadata policy, as described
              in <xref target="metadata_policy"/>. The metadata policy applies to the Entity
              that is the subject of this Subordinate Statement as well as to
              all Entities that are Subordinate to it. Applying to Subordinate
              Entities distinguishes <spanx style="verb">metadata_policy</spanx>
              from <spanx style="verb">metadata</spanx>, which only applies to
              the subject itself.
            </t>

	    <t hangText="metadata_policy_crit">
              <vspace/>
              OPTIONAL.
              Array of strings specifying critical metadata policy operators
              other than the standard ones defined in
              <xref target="standard_metadata_policy_operators"/> that MUST be
              understood and processed. When included its value MUST NOT be the empty array
              <spanx style="verb">[]</spanx>. If any of the listed policy
              operators are not understood and supported, then the Subordinate
              Statement and thus the Trust Chain that includes it MUST be
              considered invalid.
            </t>
            <t hangText="source_endpoint">
              <vspace/>
              OPTIONAL. String containing the fetch endpoint URL
              from which the Entity Statement was issued,
              as specified in <xref target="fetch_endpoint"/>.
              This parameter enables an optimized refresh of the Subordinate Statements
	      and hence the Trust Chain, by skipping the
              request to the Entity Configuration
              that is normally required to discover the
              <spanx style="verb">federation_fetch_endpoint</spanx>
              of the issuing authority.
              If an Entity Statement cannot be retrieved from the
	      <spanx style="verb">source_endpoint</spanx>,
	      which can occur if the endpoint URL has changed,
	      the current <spanx style="verb">federation_fetch_endpoint</spanx>
	      location can be determined by retrieving
	      the Entity Configuration of the issuer.
            </t>

	  </list>
	</t>
      </section>

	<section title="Claims Used in Explicit Registration Requests"
		 anchor="explicit-reg-request-specific">
	  <list style="hanging">
	    <t hangText="aud">
	      <vspace/>
	      OPTIONAL.
	      The "aud" (audience) value MUST be the Entity Identifier of the OP
	      and MUST NOT include any other values.
	      This Claim is used in Explicit Registration requests;
	      it is not a general Entity Statement Claim.
	    </t>
	  </list>
	</section>

	<section title="Claims Used in Explicit Registration Responses"
		 anchor="explicit-reg-response-specific">
	  <list style="hanging">
	    <t hangText="aud">
	      <vspace/>
	      OPTIONAL.
	      The "aud" (audience) value MUST be the Entity Identifier of the RP
	      and MUST NOT include any other values.
	      This Claim is used in Explicit Registration responses;
	      it is not a general Entity Statement Claim.
	    </t>
            <t hangText="trust_anchor">
              <vspace/>
              OPTIONAL.  Its value MUST be the Entity Identifier of the Trust Anchor
                that the OP selected to process the Explicit Registration request,
		as specified in <xref target="trust_anchor-claim"/>.
		This Claim is specific to Explicit Registration responses;
		it is not a general Entity Statement Claim.
            </t>
          </list>
        </section>

	</section>

	<section anchor="ESValidation" title="Entity Statement Validation">
	  <t>
	    Entity Statements MUST be validated in the following manner.
	    These steps MAY be performed in a different order, provided that
	    the result - accepting or rejecting the Entity Statement - is the same.
	    <list style="numbers">
	      <t>
		The Entity Statement MUST be a signed JWT.
	      </t>
	      <t>
		The Entity Statement MUST have a
		<spanx style="verb">typ</spanx> header parameter with the value
		<spanx style="verb">entity-statement+jwt</spanx>.
	      </t>
	      <t>
		The Entity Statement MUST have an
		<spanx style="verb">alg</spanx> (algorithm) header parameter
		with a value that is an acceptable JWS signing algorithm;
		it MUST NOT be <spanx style="verb">none</spanx>.
	      </t>
	      <t>
		The Entity Identifier of the Entity to which the Entity Statement refers
		MUST match the value of the
		<spanx style="verb">sub</spanx> (subject) Claim.
	      </t>
	      <t>
		The Entity Statement MUST have an
		<spanx style="verb">iss</spanx> (issuer) Claim
		with a value that is a valid Entity Identifier.
	      </t>
	      <t>
		When the <spanx style="verb">iss</spanx> (issuer) Claim Value
		matches the <spanx style="verb">sub</spanx> (subject) Claim Value,
		then the Entity Statement is this Entity's Entity Configuration.
		When they do not match, the Entity Statement is a Subordinate Statement.
		When the Entity Statement is a Subordinate Statement,
		the <spanx style="verb">iss</spanx> Claim Value MUST match
		one of the values in the
		<spanx style="verb">authority_hints</spanx> array
		in the Entity Configuration for the Entity whose Entity Identifier
		is the value of the <spanx style="verb">sub</spanx> Claim;
		otherwise, the Federation graph is not well-formed.
	      </t>
	      <t>
		The current time MUST be after the time represented by the
		<spanx style="verb">iat</spanx> (issued at) Claim
		(possibly allowing for some small leeway to account for clock skew).
	      </t>
	      <t>
		The current time MUST be before the time represented by the
		<spanx style="verb">exp</spanx> (expiration) Claim
		(possibly allowing for some small leeway to account for clock skew).
	      </t>
	      <t>
		The <spanx style="verb">jwks</spanx> (JWK Set) Claim
		MUST be present, with a value that is a valid
		JWK Set <xref target="RFC7517"/>.
	      </t>
	      <t>
		Obtain the Entity Configuration for the issuing Entity -
		the Entity with the Issuer Identifier found in the Entity Statement's
		<spanx style="verb">iss</spanx> (issuer) Claim.
		When the <spanx style="verb">iss</spanx> and
		<spanx style="verb">sub</spanx> Claim Values match, this is
		the Entity Statement being validated itself.
		Otherwise, this can be obtained either from a Trust Chain or
		by retrieving it as described in
		<xref target="federation_configuration"/>.
	      </t>
	      <t>
		The Entity Statement's
		<spanx style="verb">kid</spanx> (Key ID) header parameter value
		MUST be a non-zero length string and
		MUST exactly match the <spanx style="verb">kid</spanx> value
		for a key in the <spanx style="verb">jwks</spanx> (JWK Set) Claim
		of the Entity Configuration of the issuing Entity.
	      </t>
	      <t>
		The Entity Statement's signature MUST validate using
		the issuing Entity's key identified by the
		<spanx style="verb">kid</spanx> value.
	      </t>
	      <t>
		If the <spanx style="verb">crit</spanx> Claim is present,
		then each array element in this Claim's value
		MUST be a string representing an Entity Statement Claim
		that is not defined by this specification
		and that Claim MUST be understood
		and be able to be processed by the implementation.
	      </t>
	      <t>
		If the <spanx style="verb">authority_hints</spanx> Claim is present,
		the Entity Statement MUST be an Entity Configuration.
		Verify that its value is syntactically correct,
		as specified in <xref target="authority_hints"/>.
		Implementations MAY also validate that the Entity is a Subordinate
		of each Entity whose Entity Identifier is listed in the
		<spanx style="verb">authority_hints</spanx> array.
	      </t>
	      <t>
		If the <spanx style="verb">trust_anchor_hints</spanx> Claim is present,
		the Entity Statement MUST be an Entity Configuration.
		Verify that its value is syntactically correct,
		as specified in <xref target="trust_anchor_hints"/>.
	      </t>
	      <t>
		If the <spanx style="verb">metadata</spanx> Claim is present,
		verify that its value is syntactically correct,
		not using <spanx style="verb">null</spanx> as metadata values,
		as specified in <xref target="metadata"/>.
	      </t>
	      <t>
		If the <spanx style="verb">metadata_policy</spanx> Claim is present,
		the Entity Statement MUST be a Subordinate Statement.
		Verify that its value is syntactically correct,
		as specified in <xref target="metadata_policy"/>.
	      </t>
	      <t>
		If the <spanx style="verb">metadata_policy_crit</spanx> Claim is present,
		the Entity Statement MUST be a Subordinate Statement.
		Each array element in this Claim's value
		MUST be a string representing a Metadata Policy operator
		that is not defined by this specification
		and that operator MUST be understood
		and be able to be processed by the implementation.
	      </t>
	      <t>
		If the <spanx style="verb">constraints</spanx> Claim is present,
		the Entity Statement MUST be a Subordinate Statement.
		Verify that its value is syntactically correct,
		as specified in <xref target="chain_constraints"/>.
	      </t>
	      <t>
		If the <spanx style="verb">trust_marks</spanx> Claim is present,
		the Entity Statement MUST be an Entity Configuration.
		Validate that the syntax of this Claim Value conforms to the
		Claim definition.
		In particular, for each element of the array that is the Claim Value,
		validate that there is a <spanx style="verb">trust_mark_type</spanx>
		member whose value matches the
		<spanx style="verb">trust_mark_type</spanx> Claim Value in the
		Trust Mark JWT that is the value of the
		<spanx style="verb">trust_mark</spanx> member.
		Validating the syntax is separate from evaluating whether particular
		Trust Marks are issued by a trusted party and are trusted;
		that process is described in <xref target="trust-mark-validation"/>
		and MAY be performed as a separate step from syntactic validation.
	      </t>
	      <t>
		If the <spanx style="verb">trust_mark_issuers</spanx> Claim is present,
		the Entity Statement MUST be an Entity Configuration.
		Validate that its Claim Value is a JSON object with
		Trust Mark type identifiers as the member names and
		arrays of Entity Identifiers as the values.
	      </t>
	      <t>
		If the <spanx style="verb">trust_mark_owners</spanx> Claim is present,
		the Entity Statement MUST be an Entity Configuration.
		Validate that its Claim Value is a JSON object with
		Trust Mark type identifiers as the member names and
		values that are JSON objects containing
		a <spanx style="verb">sub</spanx> member with a value that is
		an Entity Identifier and
		a <spanx style="verb">jwks</spanx> member with a value that is
		a JSON Web Key Set.
	      </t>
	      <t>
		If the <spanx style="verb">source_endpoint</spanx> Claim is present,
		the Entity Statement MUST be a Subordinate Statement.
		Validate that its Claim Value is a URL.
		Implementations MAY also make a fetch call to the URL
		to validate that this is the fetch endpoint
		from which the Entity Statement was issued.
	      </t>
	      <t>
		If the <spanx style="verb">trust_chain</spanx> header parameter is present,
		validate that its value is a syntactically valid Trust Chain,
		as specified in <xref target="trust_chain"/>.
		The first entry in the Trust Chain
		MUST be an Entity Configuration for this Entity.
		Implementations SHOULD validate that the Entity Identifier
		for the Trust Anchor at the end of the Trust Chain matches
		one of the Trust Anchors configured for the deployment.
	      </t>
	      <t>
		If the <spanx style="verb">peer_trust_chain</spanx> header parameter is present,
		validate that its value is a syntactically valid Trust Chain,
		as specified in <xref target="trust_chain"/>.
		Implementations SHOULD validate that the Entity Identifier
		for the Trust Anchor at the end of the Trust Chain matches
		one of the Trust Anchors configured for the deployment.
	      </t>
	      <t>
		If the <spanx style="verb">aud</spanx> Claim is present,
		if the Entity Statement is an Explicit Registration request,
		validate that the value is the Entity Identifier for an OP,
		or if the Entity Statement is an Explicit Registration response,
		validate that the value is the Entity Identifier for an RP.
		This Claim MUST NOT be present in Entity Statements that are not
		Explicit Registration requests or responses
		unless its use is otherwise specified in an extension being employed.
	      </t>
	      <t>
		If the <spanx style="verb">trust_anchor</spanx> Claim is present,
		validate that its value is a URL
		using the <spanx style="verb">https</spanx> scheme.
		Implementations SHOULD validate that the Entity Identifier matches
		one of the Trust Anchors configured for the deployment.
		Furthermore, implementations SHOULD validate that the
		Entity Configuration for the Entity Identifier contains
		information compatible with the configured Trust Anchor information
		- especially the keys.
		This Claim MUST NOT be present in Entity Statements that are not
		Explicit Registration responses
		unless its use is otherwise specified in an extension being employed.
	      </t>
	    </list>
	  </t>
	  <t>
	    If any of these validation steps fail,
	    the Entity Statement MUST be rejected.
	  </t>
	</section>

          <section title="Entity Statement Example" anchor="es_example">

        <figure>
          <preamble>
            The following is a non-normative example of the JWT Claims Set for an Entity Statement.
            The example contains
            a critical extension <spanx style="verb">jti</spanx> (JWT ID) to the
            Entity Statement and one critical extension to the policy language
            <spanx style="verb">regexp</spanx>
            (Regular expression).
          </preamble>
          <name>
            Example Entity Statement JWT Claims Set
          </name>

          <artwork><![CDATA[
{
  "iss": "https://feide.no",
  "sub": "https://ntnu.no",
  "iat": 1516239022,
  "exp": 1516843822,
  "jwks": {
    "keys": [
      {
        "kty": "RSA",
        "alg": "RS256",
        "use": "sig",
        "kid": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
        "n": "vHOJrp-zLST7FwvzAwelR9Vo...",
        "e": "AQAB"
      }
    ]
  },
  "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": {
        "one_of": ["authorization_code", "client_credentials"]
      }
    }
  },
  "constraints": {
    "max_path_length": 2
  },
  "crit": ["jti"],
  "metadata_policy_crit": ["regexp"],
  "source_endpoint": "https://feide.no/federation_api/fetch",
  "jti": "7l2lncFdY6SlhNia"
}
]]></artwork>
        </figure>
          </section>

      </section>

      <section title="Trust Chain" anchor="trust_chain">
        <t>
          Entities whose statements build a Trust Chain are categorized as:
          <list style="hanging">
            <t hangText="Trust Anchor">
              <vspace/>
              An Entity that represents a trusted third party.
            </t>
            <t hangText="Leaf">
              <vspace/>
	      An Entity with no Subordinate Entities,
	      which typically plays a protocol role.
              For instance, in an OpenID Connect identity federation, an RP or an OP,
	      or in an OAuth 2.0 federation, a Client, Authorization Server, or Protected Resource.
            </t>
            <t hangText="Intermediate">
              <vspace/>
              Neither a Leaf Entity nor a Trust Anchor.
            </t>
          </list>
        </t>
        <t>
          A Trust Chain begins with an Entity Configuration
	  that is the subject of the Trust Chain,
	  which is typically a Leaf Entity.
          The Trust Chain has zero or more Subordinate Statements
          issued by Intermediates about their Immediate Subordinates,
          and includes the Subordinate Statement issued by the
          Trust Anchor about the top-most Intermediate
          (if there are Intermediates) or the Trust Chain subject
          (if there are no Intermediates).
          The Trust Chain logically always ends with the
          Entity Configuration of the Trust Anchor,
	  even though it MAY be omitted from
	  the JSON array representing the Trust Chain in some cases.
        </t>
        <t>
	  The Trust Chain contains the configuration of the federation
	  as it applies to the Trust Chain subject
          at the time of the evaluation of the chain.
        </t>
        <t>
          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:
          <list style="numbers">
            <t>
              an Entity Configuration about the RP published by itself,
            </t>
            <t>
              a Subordinate Statement about the RP published by Organization A,
            </t>
            <t>
              a Subordinate Statement about Organization A published by the Trust Anchor for F,
            </t>
	    <t>
	      an Entity Configuration about the Trust Anchor for F published by itself.
	    </t>
          </list>
        </t>
        <t>
	  Let us refer to the Entity Statements in the Trust Chain as
	  ES[j], where j = 0,...,i,
	  with 0 being the index of the first Entity Statement
	  and i being the zero-based index of the last.
	  Then:
          <list style="symbols">
	    <t>
	      ES[0] (the Entity Configuration of the Trust Chain subject)
	      is signed using a key in ES[0]["jwks"].
	    </t>
            <t>
	      The <spanx style="verb">iss</spanx> Claim in an Entity Statement
	      is equal to the <spanx style="verb">sub</spanx> Claim in the next.
	      Restating this symbolically,
	      for each j = 0,...,i-1,
	      ES[j]["iss"] == ES[j+1]["sub"].
            </t>
            <t>
	      An Entity Statement is signed using a key from
	      the <spanx style="verb">jwks</spanx> Claim in the next.
	      Restating this symbolically,
	      for each j = 0,...,i-1,
	      ES[j] is signed by a key in ES[j+1]["jwks"].
            </t>
	    <t>
	      ES[i] (the Trust Anchor's Entity Configuration in the Trust Chain)
	      is signed using a key in ES[i]["jwks"].
	    </t>
          </list>
        </t>
        <t>
	  The Trust Anchor's public keys are used to verify the signatures on
	  ES[i] (the Trust Anchor's Entity Configuration) and
	  ES[i-1] (the Trust Anchor's Subordinate Statement about its
	  Immediate Subordinate in the Trust Chain).
	  The Trust Anchor's public keys are distributed
	  to Entities that need to verify a
          Trust Chain in some secure out-of-band way not described in this
          document.
        </t>

	<section title="Beginning and Ending Trust Chains"
		 anchor="trust-chain-ends">
	  <t>
	    A Trust Chain begins with the Entity Configuration of an Entity
	    for which trust is being established.
	    This is the subject of the Trust Chain.
	    This Entity typically plays a protocol role,
	    such as being an OpenID Provider or OpenID Relying Party.
	  </t>
	  <t>
	    While such Entities are typically Leaf Entities,
	    other topologies are possible.
	    For instance, an Entity might simultaneously be an OpenID Provider
	    and an Intermediate Entity, with OpenID Relying Parties
	    and/or other Intermediates being Subordinate to it.
	    This is a case in which the subject of a Trust Chain
	    would not be a Leaf Entity.
	  </t>
	  <t>
	    A Trust Chain ends with the Entity Configuration of a Trust Anchor.
	    While Trust Anchors typically have no Superiors,
	    a Trust Anchor will have a Superior when the Trust Anchor
	    also acts as an Intermediate Entity in another federation.
	    This will be the case when there is a hierarchy of federations.
	  </t>
	  <t>
	    Thus, while it is typical for a Trust Chain to end with
	    a Trust Anchor with no Superiors,
	    there are situations in which the Trust Chain will end with
	    a Trust Anchor that nonetheless has Superior Entities.
	  </t>
	</section>

	<section title="Trust Chain Example" anchor="trust-chain-example">

	<figure>
          <preamble>
            The following is an example of a Trust Chain consisting of
            a Leaf's Entity Configuration and Subordinate Statements issued
            by an Intermediate Entity and a Trust Anchor. It shows
            the relationship between the three Entities,
	    their Entity Configurations, and their Subordinate Statements.
	    The Subordinate Statements are obtained from the
            <spanx style="verb">federation_fetch_endpoint</spanx> of
            the subject's Immediate Superior. The URL of the
            <spanx style="verb">federation_fetch_endpoint</spanx> is
            discovered in the Immediate Superior's Entity Configuration.
            Note that the first member of the Trust Chain (the Leaf)
            is depicted at the bottom of the diagram and that the last
            member (the Trust Anchor) is depicted at the top.
          </preamble>
          <name>
            Relationships between Federation Entities and Statements Issued in a Trust Chain
          </name>
<!--
  NOTE: this figure was made with ASCIIflow and its editable sources
  are available at the following link:
  https://asciiflow.com/#/share/eJzVlt9vmzAQx%2F8Vyy88tGTTHvajD5OmqJWqrdK09pEXJziNFWJXxrRFpf%2F7HCCJDZwxhEjbCSXGPj65nP294w1zsqX4Cj%2FM8SVOSE6lvnmL8DOVKRM8wlefLiP8qr%2B%2Fff6oR%2Flu5stXPVL0VembCM%2FChs0Qas3Zy7U5vaKIF%2BiPSCg6WrG7Zi80ScINFy%2F8A7KsMEYPMksVmq8J46jhVZKbk7tLPFHO4nBFYyqJ0n%2B%2FkwzbjnzObFgeszobINeM2eFVkq1%2FVVTkAl1zxVSO5oKv2GO2T0lhkR1eFbnaiB98uRbyIrwI9fUdyF%2B5XBvsVThjvjluXh3YT5qnzZhBr5IcVLmpAgn25DuqSEwUaUVjjUEv49QVx%2BnymSpFd0Ru0G2aZlp6XWTQy0EGM9g59o85AM5TYJEdXiAZNn8NDibfULVcV459ShlIvubxk2BclXm%2BzxZCxowTRdG90p9bWq0Y5IMCSqXANkQprWnvPPcp5RTyQSm%2FRcKW%2BYQx%2B2hwHFkXuVRJ3VNUOjEZ8jmVbGrQPNt7DY7vKd2%2FWN6d2FN6ybdcUbmlMdMa6ukpDnKaLRDhMdrQ3B2zT0%2BxH1wwrnX%2BaMQcmFswqKeYu%2FEMVqTDI62ekoJkv4rUJPvk2fM8jyJ7VSSL7OhDRuX3rEgWGTa78ntVpH1J%2Fycqf1%2FdGE%2B25js0OBG5Q4PTvD93afCM78%2FoFyWr2v2%2Fen8%2BHhj%2FWjemd%2FvWOtDLQQYz2DkeEvO5yFO8mbdWAwQ%2BUS%2FX5vSK8Dt%2B%2Fwu8J4Py)
-->
          <artwork><![CDATA[
.----------------.  .---------------------------.         .---------------------------.
| Role           |  | .well-known/              |         | Trust Chain               |
|                |  | openid-federation         |         |                           |
.----------------.  .---------------------------.         .---------------------------.
| .------------. |  | .-----------------------. |         | .-----------------------. |
| |            | |  | | Entity Configuration  | |         | | Entity Configuration  | |
| |Trust Anchor+-+--+->                       +-+---------+->                       | |
| |            | |  | | Federation Entity Keys| |         | | Federation Entity Keys| |
| '-----.------' |  | | Metadata              | |         | | Metadata              | |
|       |        |  | | Trust Mark Issuers    | |         | | Trust Mark Issuers    | |
|       |        |  | |                       | |         | |                       | |
|       |        |  | '-----------------------' |         | '-----------------------' |
|       |        |  |                           |         |                           |
|       |        |  |                           |Fetch    | .-----------------------. |
|       |        |  |                           |Endpoint | | Subordinate Statement | |
|       +--------+--+---------------------------+---------+->                       | |
|                |  |                           |         | | Federation Entity Keys| |
|                |  |                           |         | | Metadata Policy       | |
|                |  |                           |         | | Metadata              | |
|                |  |                           |         | | Constraints           | |
|                |  |                           |         | |                       | |
|                |  |                           |         | '-----------.-----------' |
| .------------. |  | .-----------------------. |         |             |             |
| |            | |  | | Entity Configuration  | |         |             |             |
| |Intermediate+-+--+->                       | |         |             |sub and key  |
| |            | |  | | Federation Entity Keys| |         |             | binding     |
| '------.-----' |  | | Metadata              | |         | .-----------v-----------. |
|        |       |  | | Trust Marks           | |         | | Subordinate Statement | |
|        |       |  | |                       | |         | |                       | |
|        |       |  | |                       | |         | | Federation Entity Keys| |
|        |       |  | '-----------------------' |Fetch    | | Metadata Policy       | |
|        |       |  |                           |Endpoint | | Metadata              | |
|        +-------+--+---------------------------+---------+->                       | |
|                |  |                           |         | '-----------.-----------' |
|                |  |                           |         |             |sub and key  |
|                |  |                           |         |             | binding     |
| .------------. |  | .-----------------------. |         | .-----------v-----------. |
| |            | |  | | Entity Configuration  | |         | | Entity Configuration  | |
| | Leaf       +-+--+->                       +-+---------+->                       | |
| |            | |  | | Federation Entity Keys| |         | | Federation Entity Keys| |
| '------------' |  | | Metadata              | |         | | Metadata              | |
|                |  | | Trust Marks           | |         | | Trust Marks           | |
|                |  | |                       | |         | |                       | |
|                |  | |                       | |         | |                       | |
|                |  | '-----------------------' |         | '-----------------------' |
'----------------'  '---------------------------'         '---------------------------'
]]>
	  </artwork>
	</figure>
	</section>

        <section title="Trust Chain Header Parameter" anchor="trust_chain_head_param">
         <t>
          The <spanx style="verb">trust_chain</spanx> JWS header parameter is a
          JSON array containing the sequence of Entity Statements
	  that comprise the Trust Chain between
	  an Entity and the selected Trust Anchor.
	  The Trust Chain typically begins with the Entity Configuration
	  of the subject of the JWT in which this header parameter occurs;
	  however, in some cases, the Trust Chain will begin with
	  the Entity Configuration of a different Entity,
	  such as the issuer, which is the case for
	  the Resolve Response defined in <xref target="resolve-response"/>.
          The issuer of the JWT SHOULD select a Trust Anchor
	  that the Entity at the beginning of the Trust Chain
	  has in common with the audience of the JWT.
	  Otherwise, the issuer is free to select the Trust Anchor to use.
	 </t>
	 <t>
          Most signed JWTs MAY include the
          <spanx style="verb">trust_chain</spanx> JWS header parameter,
          with a few exceptions.
          Entity Configurations and Subordinate Statements MUST NOT
          contain the <spanx style="verb">trust_chain</spanx> header parameter,
          as they are integral components of a Trust Chain.
          Use of this header parameter is OPTIONAL.
          </t>

	  <figure>
	    <preamble>
	      The following is a non-normative example of a JWS header with
	      the <spanx style="verb">trust_chain</spanx> parameter.
	    </preamble>
	    <name>
	      Example JWS Header with a <spanx style="verb">trust_chain</spanx> Parameter
	    </name>
	    <artwork><![CDATA[
{
  "typ": "...",
  "alg": "RS256",
  "kid": "SUdtUndEWVY2cUFDeDV5NVlBWDhvOXJodVl2am1mNGNtR0pmd",
  "trust_chain": [
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiWjBWRVdtUTRVVFJWZFhNeGRFVnRMVUl3VldWSVRVZDRhekpEVTBrdE5DMXdaWGR2TVRoWWJrTTRUUSJ9.eyJtZXRhZGF0YSI6IHsib3BlbmlkX2NyZWRlbnRpYWxfaXNzdWVyIjogeyJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiUjJSelJYQTBSVkJ5ZHpGT1ZHMWZkV1JUTVRaM1lUUm1ObkUxVjNGZk1FMW9NVVpMZWtsaVkxTllPQSIsICJlIjogIkFRQUIiLCAibiI6ICI1SF9YaDd4Z0RXVHhRVmJKcW1PR3Vyb2tFOGtyMmUxS2dNV2NZT0E3NE9fMVBYZDJ1Z2p5SXE5dDFtVlBTdXd4LXR5U2syUEtwanAtLVdySG4zQTRVS0prdVIxMXpobWRMQnNVOFRPQkJ1NU1aOGF0RHVqZlJ3SUxYZEtzRVhrbHZhQjZQTFQ0emRab2RnQ3MwNUt5MmU1c2I1ejZfQ2lEcWdVVm5XUG1KTE1rZ3BCdFota01kX2xiOVNvb1psbGZVR2xUa3NhdUoyX2dWUS1WcEZVTVhZam9Kak54OTdldWthWW5SRW9DQzNUYV8tOGJjUm9zbHgyeHJJYnVfVUdWcWlwZU4zTlAtbWVmZjlWVFpXWU0zZ21vbHd1cG5NQ1hYaWlrY1I1VVNMVmcwZV9nejZPZm9SVkdLQVdJcFJSTFR6MmFpcXVrVkhaZFpYOXRObXowbXcifV19fSwgImZlZGVyYXRpb25fZW50aXR5IjogeyJvcmdhbml6YXRpb25fbmFtZSI6ICJPcGVuSUQgQ3JlZGVudGlhbCBJc3N1ZXIgZXhhbXBsZSIsICJvcmdhbml6YXRpb25fdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvaG9tZSIsICJwb2xpY3lfdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvcG9saWN5IiwgImxvZ29fdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvc3RhdGljL2xvZ28uc3ZnIiwgImNvbnRhY3RzIjogWyJ0ZWNoQGNyZWRlbnRpYWxfaXNzdWVyLmV4YW1wbGUub3JnIl19fSwgImF1dGhvcml0eV9oaW50cyI6IFsiaHR0cHM6Ly9pbnRlcm1lZGlhdGUuZWlkYXMuZXhhbXBsZS5vcmciXSwgImp3a3MiOiB7ImtleXMiOiBbeyJrdHkiOiAiUlNBIiwgImtpZCI6ICJaMFZFV21RNFVUUlZkWE14ZEVWdExVSXdWV1ZJVFVkNGF6SkRVMGt0TkMxd1pYZHZNVGhZYmtNNFRRIiwgIm4iOiAib0FBcU9wcHc2U3drZzNMZTJESlIzMHh0ZzBuOENrNmtiTDhxMzViZFVGdVBrMDBZaUNLZE9sN2JHQzVGdlBuMnIyZ2lfQkZ3djhscHdreU1ObnJYMHczd0hXTUtVMmdwWEpxLVNnZGVyQXVQZmxHQzgxY04tTGhJM04tQmQwcjF1YThCVktGeXFWdkNpcms3YWNGeVdQa2ZPcGstbTRlVG4tcmtNMzREMUZ1VFdOUDctZXp6T1g3OWx2YXJBVGl5S1Jva205WGRYN05pQ1hPNnkzSDhjRV9BUVE5a2JvSmxkNklHb3gwUFY3dVFvczlkWURlLTFaWDFzWDhKaklMT2IwTDVBeC1VOHI5V3lIX0VkUXVEVW9QMzZMdFN1YlBYaGo5NVpUa0ZrZnhZd3NHUWxmMjJRVmFQWVh1VnVlSmJtejZ1Zk5NSXBpNG1LaDU3Q2JtcmN3IiwgImUiOiAiQVFBQiJ9XX0sICJzdWIiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJpc3MiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzY3NzEwOTg0LCAiZXhwIjogMTc2ODAxMDk4NH0.KmJD9GmgRppKSX9kqoDVrZHb4nD7W0wvPJru3Iz4U6y-o5IMqlOxtq4LGDYRi2s7qsSCBn8qz1NIADuLnkc9IWAP5CUPXrnhAmqNBI05KqMdVIb_y0RtDwY7YK0fpBubxCcCiwaZBlTPHGBY72oRnUq3ZU4bOZ9LKNvqBxe9zINMUzCIykh7JUaeMCPP3RW0jBYSjkJwFu-uDKTztVRYTpzmblxTOXGO8djsjruIsNoRiM5uaiUL_JLiaJPZdQWorKa-PH9RRjTtB88hDSbL7We9oKlRLnOLCG4r6OJoJ1mqDRpbraYz_RsFqT9IXy5y5hmVcHS0Gc94BSfcgxVxDg",
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiYTB0cmVuUmhMWEV5ZUROWmFEa3lXRzQxTmtFMFUyWlNTVWxTUTA0M05rRm5NVkJsWVhWQ1FqVlhhdyJ9.eyJzdWIiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiWjBWRVdtUTRVVFJWZFhNeGRFVnRMVUl3VldWSVRVZDRhekpEVTBrdE5DMXdaWGR2TVRoWWJrTTRUUSIsICJuIjogIm9BQXFPcHB3NlN3a2czTGUyREpSMzB4dGcwbjhDazZrYkw4cTM1YmRVRnVQazAwWWlDS2RPbDdiR0M1RnZQbjJyMmdpX0JGd3Y4bHB3a3lNTm5yWDB3M3dIV01LVTJncFhKcS1TZ2RlckF1UGZsR0M4MWNOLUxoSTNOLUJkMHIxdWE4QlZLRnlxVnZDaXJrN2FjRnlXUGtmT3BrLW00ZVRuLXJrTTM0RDFGdVRXTlA3LWV6ek9YNzlsdmFyQVRpeUtSb2ttOVhkWDdOaUNYTzZ5M0g4Y0VfQVFROWtib0psZDZJR294MFBWN3VRb3M5ZFlEZS0xWlgxc1g4SmpJTE9iMEw1QXgtVThyOVd5SF9FZFF1RFVvUDM2THRTdWJQWGhqOTVaVGtGa2Z4WXdzR1FsZjIyUVZhUFlYdVZ1ZUpibXo2dWZOTUlwaTRtS2g1N0NibXJjdyIsICJlIjogIkFRQUIifV19LCAiaXNzIjogImh0dHBzOi8vaW50ZXJtZWRpYXRlLmVpZGFzLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3Njc3MTA5ODQsICJleHAiOiAxNzY4MDEwOTg0fQ.fUcQI29xFaxfvhOAZINWz3V9J1p-Ju6yyfyVQUmYpOc2j5VKz-jn1CG106gnyYzEPS5D3LMkwvuW1QADmFezgQj9iPpYpCIXn3gVdZbAHUP8RsseTQhm5EGiC11X-7zCA4RqQTuqQTh27fYYYoKkxcmkWeWteqzrFD4Tjw-Ryk0Eey7u9SFErZcZG8pNdpvopSUcUbWg14KG58DU64ssR4KJsZwPRZPfC_xr5CK4oQeyZF2ds8N-5cGAPRRuN68wlCT4IeYRByxmBZDxhX4e81qJT7eiIB95h-Ka6nY-R63A38IMBSN68MlX1Bt8gE_rfinTJhL6Y20LWKmeDyhWFg",
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiT1ZwU2JHUnVlWE5UWmtrek5FNUJjVkF6TFRsRFVIZHBka05CZVZZM2NYbzNhV1paTm00NFJUZGFXUSJ9.eyJzdWIiOiAiaHR0cHM6Ly9pbnRlcm1lZGlhdGUuZWlkYXMuZXhhbXBsZS5vcmciLCAiandrcyI6IHsia2V5cyI6IFt7Imt0eSI6ICJSU0EiLCAia2lkIjogImEwdHJlblJoTFhFeWVETlphRGt5V0c0MU5rRTBVMlpTU1VsU1EwNDNOa0ZuTVZCbFlYVkNRalZYYXciLCAibiI6ICJ6RmpzV3hBbE1ORFkzZUlqT2djaHVhX2ZRb3ZKeUNxbTM4M3dBV2Q5SDV0YU95QW5XbGx0UlJCV18zOHRycUZTWjl6UW0zdHdvZHllcHM2ZnFSNTdKMHF1NzVPWmdseXAyNUloMnBPWlBOWU5GSEFqSXRhbnNqWHI0RjRtakNfVVBMWmpRc3lHNjA1eGtrWUR4MjlqRF9pa0REN0lwUlA1Yk01ZU5vQVF1d1NMbktSWk43d0lMRjU3eDlSZVZZYnp1TEVUVzZOdzU0Y1Q3aDNMb3ljZ2dxQXdoR0dSR09QUEFlOEFsYjhtUDJBeGE4TWdNLUhhUENISHMwamswVy1zOUNDQ0djdzBfWmV5OWQ3eHFzT21KNnQ0QWUxWnhBTlJ1LU9FanhDSVd2WDl6aEJkeXNtVmp4RWVFY2xYSVltajFsd0JtZ0s0U1VmcVBMUGdYUGc5aVEiLCAiZSI6ICJBUUFCIn1dfSwgImlzcyI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzY3NzEwOTg0LCAiZXhwIjogMTc2ODAxMDk4NH0.IHTiWH2H2n2fVtkn7K_4GcP-VoSmuz4BWqOn6CtUNaLxUgIWR6FVeaKHdxdabkkMd_zQk6bG_K5adF2H45ojoJIFVY8uuwJCOfakfsYbOnKRmsWD4qiINXjFPLg8jVutg0lTNGjxjJRm6I-7bs5hGRJUAwhOGGrfdtnO7qtlBfg6ciHCuyr8Jq0tmYooKrvpbmObxQ7-cPqqnHy0J3My2TDlxtbMarqpSfXHEavjCEV0dXz00JXAuu0Iop2XfrMvZJaQXeLWtZM_CsBv1-FhVpslLYvlbktwCnV55nnEa06BItcW2ZdpVEVC-GrBcYc2wXIBXLxKjThZ67Z3SMdqpg",
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiT1ZwU2JHUnVlWE5UWmtrek5FNUJjVkF6TFRsRFVIZHBka05CZVZZM2NYbzNhV1paTm00NFJUZGFXUSJ9.eyJtZXRhZGF0YSI6IHsiZmVkZXJhdGlvbl9lbnRpdHkiOiB7ImZlZGVyYXRpb25fZmV0Y2hfZW5kcG9pbnQiOiAiaHR0cHM6Ly90cnVzdC1hbmNob3IuZXhhbXBsZS5vcmcvZmV0Y2giLCAiZmVkZXJhdGlvbl9yZXNvbHZlX2VuZHBvaW50IjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL3Jlc29sdmUiLCAiZmVkZXJhdGlvbl9saXN0X2VuZHBvaW50IjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL2xpc3QiLCAib3JnYW5pemF0aW9uX25hbWUiOiAiVEEgZXhhbXBsZSIsICJvcmdhbml6YXRpb25fdXJpIjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL2hvbWUiLCAicG9saWN5X3VyaSI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZy9wb2xpY3kiLCAibG9nb191cmkiOiAiaHR0cHM6Ly90cnVzdC1hbmNob3IuZXhhbXBsZS5vcmcvc3RhdGljL2xvZ28uc3ZnIiwgImNvbnRhY3RzIjogWyJ0ZWNoQHRydXN0LWFuY2hvci5leGFtcGxlLm9yZyJdfX0sICJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiT1ZwU2JHUnVlWE5UWmtrek5FNUJjVkF6TFRsRFVIZHBka05CZVZZM2NYbzNhV1paTm00NFJUZGFXUSIsICJuIjogInhDOXBkUHJwMURHNzlQb0wyTmsybGpoTVpnc3dyMUFqTFprcC1KZHN2MTVHYTY3S0FhMUNId0RMQ0JrblZKcHZNb2g0dnFyM0RzYlh1NEFobThFUzY3RlEwUmpUeUNTZXBvREVoNXVtd0dSakQxblhEMTI2dTlGQi10S0xqUFpTaFl5aW5Kd1BaSGp0ekF0U2xjalNfcFg3WjRDQUh1OEhkeHpZb0JDODhOUEszZjBhZmRBY3JxcnM3LVVFWlphODhycVpGZjRYemVZMGdZUVc4cG5TN0h6cU9aNEhLaU1Ld0ZXUnE1WXFVQ2stVkUyZlpsdjIzR3pxd3VyenllaTd2cVZwWXhodFRlTnBmMjZqSWV5T2JhWm5QYTMzUmFVVDNCd2p2bXBROGJEZ0EzUlF3UFhXMFIzTlpzTElfd0Nqc095TVdkMVh6MlJHellRcjVVV2psUSIsICJlIjogIkFRQUIifV19LCAic3ViIjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnIiwgImlzcyI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzY3NzEwOTg0LCAiZXhwIjogMTc2ODAxMDk4NH0.gbpT-NSUz4Psl3wysrNqXXLZ5sYFnH8yB7Mtb6x5Vbwqre5UsHzyS7S9F86hWSfPQT19jofWT4uLFC_R_Ct4xa3OZvGSfVEtv9rYtJ8Q2tCM2JYZO1hFCaV6BM9pa5yU93H5SoOVLuK4YxQzmGE7cuHsjOXHbGCexJ0rcC1CTOwK3q1o8YEOa_0X2KbkEmeQKR1P50oN8c_GK0NkxT3XLCxb-cVwlG4nsHDe28KBwxjX2DObXXgh5SXj1Mz7dXuv-AtfKcHQ9i479mWVJn86rE4IjHRSp5IIEMsZ5Pn72QVWHGxkwno0TOFTBLtUp9FN9Y36gXiZpfMq9RdyvYbl2w"
  ]
}
]]>
	    </artwork>
	  </figure>
        </section>

	<section title="Peer Trust Chain Header Parameter" anchor="peer_trust_chain_head_param">
	  <t>
	    The <spanx style="verb">peer_trust_chain</spanx> JWS header parameter is a
	    JSON array containing the sequence of Entity Statements
	    that comprise the Trust Chain between
	    an Entity that this Entity is establishing trust with
	    and the selected Trust Anchor.
	    If the <spanx style="verb">trust_chain</spanx> header parameter
	    is also present,
	    the Trust Anchor for both Trust Chains SHOULD be the same.
	    Inclusion of both Trust Chains enables achieving
	    the Federation Integrity and Metadata Integrity properties,
	    as defined in <xref target="App-Fed-Linkage"/>.
	  </t>
	  <t>
	    Entity Configurations and Subordinate Statements MUST NOT
	    contain the <spanx style="verb">peer_trust_chain</spanx> header parameter,
	    as they are integral components of a Trust Chain.
	    Use of this header parameter is OPTIONAL.
	  </t>
	</section>

      </section>

    <section anchor="metadata" title="Metadata">
      <t>
	This section defines how to represent and use metadata about Entities.
	It uses existing OpenID Connect and OAuth 2.0 metadata standards
	that are applicable to each Entity Type.
      </t>
      <t>
	As described in <xref target="common-claims"/>,
	Entity metadata is located in the <spanx style="verb">metadata</spanx>
	Claim of an Entity Statement, whose value is a JSON object.
	The member names of this object are Entity Type Identifiers,
	as specified in <xref target="entity_types"/>.
	The metadata data structure following each Entity Type Identifier is a JSON object;
	it MAY be the empty JSON object <spanx style="verb">{}</spanx>,
	which may be the case when Superiors supply any needed metadata values.
      </t>
      <t>
	Top-level JSON object members in the metadata data structures MAY use
	any JSON value other than <spanx style="verb">null</spanx>;
	the use of <spanx style="verb">null</spanx> is prohibited to prevent likely
	implementation errors caused by confusing members having
	<spanx style="verb">null</spanx> values with omitted members.
      </t>

      <section anchor="entity_types" title="Entity Type Identifiers">
	<t>
      The Entity Type Identifier uniquely identifies the Entity Type of a
      federation participant and the metadata format for that Entity Type. This
      section defines the <spanx style="verb">federation_entity</spanx> Entity
      Type Identifier as well as identifiers for OpenID Connect and OAuth 2.0
      Federation Entities.
	</t>
	<t>
	  Additional Entity Type Identifiers MAY be defined to
	  support use cases for other protocols.
	</t>

      <section anchor="federation_entity" title="Federation Entity">
        <t>
          The Entity Type Identifier is
          <spanx style="verb">federation_entity</spanx>.
        </t>
        <t>
          The Entities that contain any of Federation Entity properties defined below
          MUST use this Entity Type.
          The following Federation Entity properties are defined:
          <list style="hanging">
            <t hangText="federation_fetch_endpoint">
              <vspace/>
              OPTIONAL.
              The fetch endpoint described in
              <xref target="fetch_endpoint"/>.
              This URL MUST use the <spanx style="verb">https</spanx>
              scheme and MAY contain port,
              path, and query parameter components;
              it MUST NOT contain a fragment component.
              Intermediate Entities and
              Trust Anchors MUST publish a
              <spanx style="verb">federation_fetch_endpoint</spanx>.
              Leaf Entities MUST NOT.
            </t>
            <t hangText="federation_list_endpoint">
              <vspace/>
              OPTIONAL.
              The list endpoint described in
              <xref target="entity_listing"/>.
              This URL MUST use the <spanx style="verb">https</spanx>
              scheme and MAY contain port,
              path, and query parameter components;
              it MUST NOT contain a fragment component.
              Intermediate Entities and
              Trust Anchors MUST publish a
              <spanx style="verb">federation_list_endpoint</spanx>.
              Leaf Entities MUST NOT.
            </t>
            <t hangText="federation_resolve_endpoint">
              <vspace/>
              OPTIONAL.
              The resolve endpoint described in
              <xref target="resolve"/>.
              This URL MUST use the <spanx style="verb">https</spanx>
              scheme and MAY contain port,
              path, and query parameter components;
              it MUST NOT contain a fragment component.
              Any Federation Entity MAY publish a
              <spanx style="verb">federation_resolve_endpoint</spanx>.
            </t>
            <t hangText="federation_trust_mark_status_endpoint">
              <vspace/>
              OPTIONAL.
              The Trust Mark Status endpoint described in
              <xref target="status_endpoint"/>. Trust Mark Issuers SHOULD
              publish a
              <spanx style="verb">federation_trust_mark_status_endpoint</spanx>.
              This URL MUST use the <spanx style="verb">https</spanx>
              scheme and MAY contain port,
              path, and query parameter components;
              it MUST NOT contain a fragment component.
            </t>
            <t hangText="federation_trust_mark_list_endpoint">
              <vspace/>
              OPTIONAL.
              The endpoint described in
              <xref target="tm_listing"/>.
              This URL MUST use the <spanx style="verb">https</spanx>
              scheme and MAY contain port,
              path, and query parameter components;
              it MUST NOT contain a fragment component.
              Trust Mark Issuers MAY publish a
              <spanx style="verb">federation_trust_mark_list_endpoint</spanx>.
            </t>
            <t hangText="federation_trust_mark_endpoint">
              <vspace/>
              OPTIONAL.
              The endpoint described in
              <xref target="tm_endpoint"/>.
              This URL MUST use the <spanx style="verb">https</spanx>
              scheme and MAY contain port,
              path, and query parameter components;
              it MUST NOT contain a fragment component.
              Trust Mark Issuers MAY publish a
              <spanx style="verb">federation_trust_mark_endpoint</spanx>.
            </t>
	    <t hangText="federation_historical_keys_endpoint">
	      <vspace/>
	      OPTIONAL.
	      The endpoint described in <xref target="historical_keys"/>.
	      This URL MUST use the <spanx style="verb">https</spanx>
	      scheme and MAY contain port,
	      path, and query parameter components;
	      it MUST NOT contain a fragment component.
          All Federation Entities MAY publish a
	      <spanx style="verb">federation_historical_keys_endpoint</spanx>.
	    </t>

            <t hangText="endpoint_auth_signing_alg_values_supported">
              <vspace/>
              OPTIONAL.
              JSON array containing a list of the supported
              <xref target="RFC7515">JWS</xref> algorithms
              (<spanx style="verb">alg</spanx> values)
              for signing the <xref target="RFC7519">JWT</xref>
              used for <spanx style="verb">private_key_jwt</spanx>
	      when authenticating to federation endpoints,
	      as described in <xref target="ClientAuthentication"/>.
              No default algorithms are implied if this entry is omitted.
              Servers SHOULD support <spanx style="verb">RS256</spanx>.
              The value <spanx style="verb">none</spanx> MUST NOT be used.
            </t>
          </list>
        </t>
	<t>
	  Additional Federation Entity properties MAY be defined and used.
	</t>
	<t>
	  It is RECOMMENDED that each Federation Entity contain
	  an <spanx style="verb">organization_name</spanx> Claim,
	  as defined in <xref target="informational_metadata"/>.
	</t>
        <figure>
	  <preamble>
	    The following is a non-normative example of metadata for the <spanx style="verb">federation_entity</spanx> Entity Type:
	  </preamble>
          <name>
            Example of <spanx style="verb">federation_entity</spanx> Entity Type
          </name>
          <artwork><![CDATA[
"federation_entity": {
  "federation_fetch_endpoint":
    "https://amanita.caesarea.example.com/federation_fetch",
  "federation_list_endpoint":
    "https://amanita.caesarea.example.com/federation_list",
  "federation_trust_mark_status_endpoint": "https://amanita.caesarea.example.com/status",
  "federation_trust_mark_list_endpoint": "https://amanita.caesarea.example.com/trust_marked_list",
  "organization_name": "Ovulo Mushroom",
  "organization_uri": "https://amanita.caesarea.example.com"
}
]]></artwork>
        </figure>
      </section>

      <section title="OpenID Connect Relying Party" anchor="RP_metadata">
        <t>
          The Entity Type Identifier is
          <spanx style="verb">openid_relying_party</spanx>.
        </t>
        <t>
          All parameters defined in Section 2 of
          <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>,
	  in <xref target="OpenID.RP.Choices"/>,
          and in <xref target="common_metadata"/> are applicable,
	  as well as additional parameters registered in the
	  IANA "OAuth Dynamic Client Registration Metadata" registry
	  <xref target="IANA.OAuth.Parameters"/>,
	  excluding those parameters that are defined in the registry solely for use in
	  registration responses (for example, <spanx style="verb">client_secret</spanx>).
        </t>
        <t>
          In addition, the following RP metadata parameter is defined:
          <list style="hanging">
            <t hangText="client_registration_types">
              <vspace/>
              RECOMMENDED. An array of strings specifying the client registration
              types the RP supports. Values defined by this specification
              are
              <spanx style="verb">automatic</spanx>
              and <spanx style="verb">explicit</spanx>.
	      Additional values MAY be defined and used, without restriction by this specification.
            </t>
          </list>
        </t>
	<figure>
	  <preamble>
	    The following is a non-normative example of the JWT Claims Set for an RP's Entity Configuration:
	  </preamble>
	  <name>
	    Example Relying Party Entity Configuration JWT Claims Set
	  </name>
	  <artwork><![CDATA[
    {
      "iss": "https://rp.sunet.se",
      "sub": "https://rp.sunet.se",
      "iat": 1516239022,
      "exp": 1516843822,
      "metadata": {
        "openid_relying_party": {
          "application_type": "web",
          "redirect_uris": [
            "https://rp.sunet.se/callback"
          ],
          "organization_name": "SUNET",
          "logo_uri": "https://www.sunet.se/sunet/images/32x32.png",
          "grant_types": [
            "authorization_code",
            "implicit"
          ],
          "signed_jwks_uri": "https://rp.sunet.se/signed_jwks.jose",
          "jwks_uri": "https://rp.sunet.se/jwks.json",
          "client_registration_types": ["automatic"]
        }
      },
      "jwks": {
        "keys": [
          {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "Ge7hs3smulgio8glvURJadmj...",
            "kty": "RSA",
            "n": "iE0ZGqI4TNopx52dGHm0EYhl...",
            "use": "sig"
          }
        ]
      },
      "authority_hints": [
        "https://edugain.org/federation"
      ]
    }
]]>
	  </artwork>
	</figure>
      </section>

      <section title="OpenID Connect OpenID Provider" anchor="OP_metadata">
        <t>
          The Entity Type Identifier is
          <spanx style="verb">openid_provider</spanx>.
        </t>
        <t>
          All parameters defined in Section 3 of
          <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref>
          and <xref target="common_metadata"/> are applicable,
	  as well as additional parameters registered in the
	  IANA "OAuth Authorization Server Metadata" registry
	  <xref target="IANA.OAuth.Parameters"/>.
	  For instance, the <spanx style="verb">require_signed_request_object</spanx>
	  and <spanx style="verb">require_pushed_authorization_requests</spanx>
	  metadata parameters can be used.
        </t>

        <t>
          The <spanx style="verb">issuer</spanx> parameter value
          in the <spanx style="verb">openid_provider</spanx> metadata MUST
          match the Federation Entity Identifier
          (the <spanx style="verb">iss</spanx> parameter within the Entity Configuration).
        </t>

        <t>
          In addition, the following OP metadata parameters are defined:
        </t>
        <t>
          <list style="hanging">
            <t hangText="client_registration_types_supported">
              <vspace/>
              RECOMMENDED. An array of strings specifying the client registration
              types the OP supports. Values defined by this specification are
              <spanx style="verb">automatic</spanx>
              and <spanx style="verb">explicit</spanx>.
	      Additional values MAY be defined and used, without restriction by this specification.
            </t>
            <t hangText="federation_registration_endpoint">
              <vspace/>
              OPTIONAL.
              URL of the OP's federation-specific Dynamic Client Registration
              Endpoint. If the OP supports Explicit Client Registration Endpoint
              this URL MUST use the <spanx style="verb">https</spanx>
              scheme and MAY contain port,
              path, and query parameter components;
              it MUST NOT contain a fragment component.
              If the OP supports Explicit Client
              Registration as described in <xref target="explicit"/>,
              then this Claim is REQUIRED.
            </t>
          </list>
        </t>

        <figure>
	  <preamble>
	    The following is a non-normative example of the JWT Claims Set for an OP's Entity Configuration:
	  </preamble>
          <name>
            Example OpenID Provider Entity Configuration JWT Claims Set
          </name>
          <artwork><![CDATA[
{
   "iss": "https://op.umu.se",
   "sub": "https://op.umu.se",
   "exp": 1568397247,
   "iat": 1568310847,
   "metadata":{
      "openid_provider":{
         "issuer": "https://op.umu.se",
         "signed_jwks_uri": "https://op.umu.se/signed_jwks.jose",
         "authorization_endpoint": "https://op.umu.se/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/token",
         "federation_registration_endpoint": "https://op.umu.se/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/par",
         "request_object_signing_alg_values_supported": [
            "ES256",
            "RS256"
         ],
         "token_endpoint_auth_signing_alg_values_supported": [
            "ES256",
            "RS256"
         ]
      }
   },
   "authority_hints":[
      "https://umu.se"
   ],
   "jwks":{
      "keys":[
         {
            "e": "AQAB",
            "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
            "kty": "RSA",
            "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
         }
      ]
   }
}
]]></artwork>
        </figure>

      </section>
      <section anchor="oauth-as" title="OAuth Authorization Server">
        <t>
          The Entity Type Identifier is
          <spanx style="verb">oauth_authorization_server</spanx>.
        </t>
        <t>
          All parameters defined in Section 2 of
          <xref target="RFC8414"/>
          and <xref target="common_metadata"/> are applicable,
	  as well as additional parameters registered in the
	  IANA "OAuth Authorization Server Metadata" registry
	  <xref target="IANA.OAuth.Parameters"/>.
        </t>

        <t>
          The <spanx style="verb">issuer</spanx> parameter value
          in the <spanx style="verb">oauth_authorization_server</spanx> metadata MUST
          match the Federation Entity Identifier
          (the <spanx style="verb">iss</spanx> Claim in the Entity Configuration).
        </t>

      </section>

      <section anchor="oauth-client" title="OAuth Client">
        <t>
          The Entity Type Identifier is
          <spanx style="verb">oauth_client</spanx>.
        </t>
        <t>
          All parameters defined in Section 2 of
          <xref target="RFC7591">OAuth 2.0 Dynamic Client Registration Protocol</xref>
          and <xref target="common_metadata"/> are applicable,
	  as well as additional parameters registered in the
	  IANA "OAuth Dynamic Client Registration Metadata" registry
	  <xref target="IANA.OAuth.Parameters"/>.
        </t>
      </section>

      <section anchor="oauth-resource" title="OAuth Protected Resource">
        <t>
          The Entity Type Identifier is
          <spanx style="verb">oauth_resource</spanx>.
	  The parameters defined in <xref target="common_metadata"/> are applicable.
	  In addition,
	  deployments MAY use the protected resource metadata parameters
	  defined in <xref target="RFC9728"/>.
        </t>
      </section>

      </section>

      <section title="Common Metadata Parameters" anchor="common_metadata">
        <t>
	  This section defines additional metadata parameters
	  that MAY be used with all the Entity Types above,
	  with the exception for JWK Sets noted below.
        </t>

	<section anchor="jwks_metadata"
		 title="Parameters for JWK Sets in Entity Metadata">
	  <t>
	    The following metadata parameters define ways of obtaining
	    JWK Sets for an Entity Type of the Entity.
	    Note that these keys are distinct from the Federation Entity Keys
	    used to sign Entity Statements, which are in
	    the <spanx style="verb">jwks</spanx> Claim of the Entity Statement,
	    and not within the <spanx style="verb">metadata</spanx> Claim.
	    These parameters for JWK Sets MUST NOT be used in
	    <spanx style="verb">federation_entity</spanx> Entity Type metadata.
	  </t>
	  <t>
	    <list style="hanging">
	      <t hangText="signed_jwks_uri">
		<vspace/>
		OPTIONAL. URL referencing a signed JWT having the Entity's
		JWK Set document for that Entity Type as its payload.
		This URL MUST use the <spanx style="verb">https</spanx> scheme.
		The JWT MUST be signed using a Federation Entity Key.
		A successful response from the URL MUST use the HTTP status code 200
		with the content type
		<spanx style="verb">application/jwk-set+jwt</spanx>.
		When both signing and encryption keys are present,
		a <spanx style="verb">use</spanx> (public key use) parameter
		value is REQUIRED for all keys in the referenced JWK Set
		to indicate each key's intended usage.
	      </t>
	      <t>
		Signed JWK Set JWTs are explicitly typed by setting the
		<spanx style="verb">typ</spanx> header parameter to
		<spanx style="verb">jwk-set+jwt</spanx> to prevent
		cross-JWT confusion, per Section 3.11 of <xref target="RFC8725"/>.
		Signed JWK Set JWTs without a <spanx style="verb">typ</spanx> header parameter
		or with a different <spanx style="verb">typ</spanx> value MUST be rejected.
	      </t>
	      <t>
		Signed JWK Set JWTs MUST include the
		<spanx style="verb">kid</spanx> (Key ID) header parameter
		with its value being the Key ID of the signing key used.
	      </t>
	      <t>
		The following Claims are specified for use in the payload,
		all of which except <spanx style="verb">keys</spanx>
		are defined in <xref target="RFC7519"/>:
		<list style="hanging">
		  <t hangText="keys">
		    <vspace/>
		    REQUIRED. Array of JWK values in the JWK Set,
		    as specified in Section 5.1 of <xref target="RFC7517"/>.
		  </t>
		  <t hangText="iss">
		    <vspace/>
		    REQUIRED. The "iss" (issuer) Claim identifies the principal
		    that issued the JWT.
		  </t>
		  <t hangText="sub">
		    <vspace/>
		    REQUIRED. This Claim identifies the owner of the keys.
		    It SHOULD be the same as the issuer.
		  </t>
		  <t hangText="iat">
		    <vspace/>
		    OPTIONAL. Number. Time when this signed JWK Set was issued.
        This is expressed as Seconds Since the Epoch, per
        <xref target="RFC7519"/>.
		  </t>
		  <t hangText="exp">
		    <vspace/>
		    OPTIONAL. Number. This Claim identifies the time when the JWT is
		    no longer valid. This is expressed as Seconds
        Since the Epoch, per <xref target="RFC7519"/>.
		  </t>
		</list>
		More Claims are defined in <xref target="RFC7519"/>; of
		these, <spanx style="verb">aud</spanx> SHOULD NOT be used since
		the issuer cannot know who the audience is.
		<spanx style="verb">nbf</spanx> and <spanx style="verb">jti</spanx>
		are not particularly useful in this context and SHOULD be omitted.
	      </t>
	      <t>
		Additional Claims MAY be defined and used in conjunction with the Claims above.

		<figure>
		  <preamble>
		    The following is a non-normative example of the JWT Claims Set for a signed JWK Set.
		  </preamble>
		  <name>
		    Example JWT Claims Set for a Signed JWK Set
		  </name>
		  <artwork><![CDATA[
    {
      "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",
      "sub": "https://example.org/op",
      "iat": 1618410883
    }
]]>
		  </artwork>
		</figure>
	      </t>

	      <t hangText="jwks_uri">
		<vspace/>
		OPTIONAL.
		URL referencing a JWK Set document
		containing the Entity's keys for that Entity Type.
		This URL MUST use the <spanx style="verb">https</spanx> scheme.
		When both signing and encryption keys are present,
		a <spanx style="verb">use</spanx> (public key use) parameter
		value is REQUIRED for all keys in the referenced JWK Set
		to indicate each key's intended usage.
	      </t>

	      <t hangText="jwks">
		<vspace/>
		OPTIONAL.
		JSON Web Key Set document, passed by value,
		containing the Entity's keys for that Entity Type.
		When both signing and encryption keys are present,
		a <spanx style="verb">use</spanx> (public key use) parameter
		value is REQUIRED for all keys in the JWK Set
		to indicate each key's intended usage.
		This parameter is intended
		to be used by participants that, for some reason,
		cannot use the <spanx style="verb">signed_jwks_uri</spanx>
		parameter.
		An upside of using <spanx style="verb">jwks</spanx> is that
		the Entity's keys for the Entity Type are recorded in Trust Chains.
	      </t>

	    </list>
	  </t>

	  <section title="Usage of jwks, jwks_uri, and signed_jwks_uri in Entity Metadata" anchor="jwks_usage">
	    <t>
	      It is RECOMMENDED that an Entity Configuration
	      use only one of
	      <spanx style="verb">jwks</spanx>,
	      <spanx style="verb">jwks_uri</spanx>, and
	      <spanx style="verb">signed_jwks_uri</spanx> in its OpenID Connect or OAuth 2.0 metadata.
	      However, there may be circumstances in which it is 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.
	      Also note that some implementations might not understand
	      all these representations.  For instance, while
	      <spanx style="verb">jwks_uri</spanx> will certainly be understood
	      in OpenID Connect OP metadata,
	      <spanx style="verb">signed_jwks_uri</spanx> might not be understood
	      by all OpenID Connect implementations, and so
	      a JWK Set representation that is understood also needs to be present.
	    </t>
	    <t>
	      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.
	    </t>
	  </section>
	</section>

	<section anchor="informational_metadata" title="Informational Metadata Parameters">
	  <t>
	    The following metadata parameters define ways of obtaining
	    information about the Entity for an Entity Type.
	  </t>
          <list style="hanging">
            <t hangText="organization_name">
              <vspace/>
              OPTIONAL. A human-readable
              name representing the organization owning this Entity.
              If the owner is a physical person,
              this MAY be, for example, the person's name. Note
              that this information will be publicly available.
            </t>
            <t hangText="display_name">
              <vspace/>
              OPTIONAL. A human-readable
              name of the Entity to be presented to the End-User.
            </t>
            <t hangText="description">
              <vspace/>
              OPTIONAL. A human-readable brief description of this Entity
              presentable to the End-User.
            </t>
            <t hangText="keywords">
              <vspace/>
              OPTIONAL. JSON array with one or more
              strings representing search keywords, tags, categories, or labels that apply to this Entity.
            </t>
            <t hangText="contacts">
              <vspace/>
              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.
            </t>
            <t hangText="logo_uri">
              <vspace/>
              OPTIONAL. String. A URL that points to the logo of this Entity.
              The file containing the logo SHOULD be published
              in a format that can be viewed via the web.
            </t>
            <t hangText="policy_uri">
              <vspace/>
              OPTIONAL. URL of the documentation of
              conditions and policies relevant to this Entity.
            </t>
            <t hangText="information_uri">
              <vspace/>
              OPTIONAL. URL for documentation of
              additional information about this Entity viewable by the End-User.
            </t>
            <t hangText="organization_uri">
              <vspace/>
              OPTIONAL. URL of a Web page for the organization owning this Entity.
            </t>
	  </list>
	  <t>
	    These metadata parameters MAY be present in
	    the Entity's metadata for any Entity Types that it uses.
	  </t>
	</section>
      </section>

    </section>


    <section title="Federation Policy" anchor="federation_policy">
      <section title="Metadata Policy" anchor="metadata_policy">
        <t>
          Trust Anchors and Intermediate Entities MAY define policies that apply
          to the metadata of their Subordinates.
        </t>
        <t>
          A federation may utilize metadata policies to achieve specific
          objectives. For example, in a federation of
          <xref target="OpenID.Core">OpenID Connect</xref> Entities, one
          objective may be to ensure the metadata published by OpenID Providers
          and Relying Parties are interoperable with one another. Another
          objective may be to ensure the Entity metadata complies with a
          security profile, for example, <xref target="FAPI">FAPI</xref>.
        </t>

        <t>
          Note that the <spanx style="verb">metadata_policy</spanx> is not
          intended to check and validate the JSON value types of metadata
          parameters. Such checks SHOULD be performed at the application
          layer, after obtaining the Entity metadata from a successfully
          resolved Trust Chain.
        </t>

        <section title="Principles" anchor="metadata_policy_principles">
          <t>
            OpenID Federation enables the definition of metadata policies with
            the following properties:

            <list style="hanging">
              <t hangText="Hierarchy">
                <vspace/>
                Once applied to a metadata parameter, a metadata policy cannot be
                repealed or made more permissive by Intermediate Entities that are
                subordinate in the Trust Chain.
                <vspace/>
                The hierarchy of policies is preserved in nested federations where
                a Trust Anchor in one federation acts as an Intermediate Entity in
                another federation.
              </t>

	      <t hangText="Equal Opportunity">
		<vspace/>
		All Superior Entities in a Trust Chain can contribute metadata policies
		on an equal basis, provided their contributions result in a combined
        metadata policy that is logically sound.
		For instance, any Intermediate can further restrict the metadata
		of its Subordinates relative to what its Superiors specified.
        An Intermediate that introduces a conflict among the metadata policies
        causes the Trust Chain to be deemed invalid.
	      </t>

              <t hangText="Specificity and Granularity">
                <vspace/>
                Just like metadata, a metadata policy is bound to a specific
                Entity Type. This ensures policies for different Entity Types are
                independent and isolated from one another.
                <vspace/>
                Policies are expressed at the level of individual metadata
                parameters. The policies for a given Entity Type metadata
                parameter are thus independent and isolated from those for other
                parameters.
                <vspace/>
                When a Trust Anchor or an Intermediate Entity defines a metadata
                policy for an Entity Type, it applies to the metadata of all
                Subordinate Entities of that type in the Trust Chain.
                <vspace/>
                Because the place to define a policy is the Subordinate Statement
                and every Entity Statement is issued for a specific subject, a
                federation authority can choose to define a common Entity Type
                metadata policy for all its Subordinates, or specific Entity Type
                metadata policies for specific Subordinates.
              </t>

              <t hangText="Operation">
                <vspace/>
                A policy operates by performing a check, a modification, or both
                on a given metadata parameter. This specification defines a set
                of standard operators, described in
                <xref target="standard_metadata_policy_operators"/>. A
                federation MAY specify and use additional operators, provided
                they comply with the principles laid out in this section and with
                <xref target="metadata_policy_operators"/> and
                <xref target="additional_metadata_policy_operators"/>.
              </t>

              <t hangText="Integral Metadata Enforcement">
                <vspace/>
                The resolution and application of metadata policies is an integral
                part of the Trust Chain resolution process, as described in
                <xref target="resolving_trust"/>.
                <vspace/>
                This means:
                <list style="symbols">
                  <t>
                    A Trust Chain for which the metadata policy resolution fails
                    due to an error, for example, due to an Intermediate Entity's
                    policy conflicting with a Superior's policy, is deemed invalid.
                  </t>
                  <t>
                    A Trust Chain with Entity metadata that does not comply with
                    the Resolved Metadata policies is deemed invalid.
                  </t>
                </list>
              </t>

              <t hangText="Determinism">
                <vspace/>
                The resolution and application of metadata policies in a Trust Chain
                is deterministic. Trust Anchors and Intermediate Entities
                are thus able to formulate policies that exhibit predictable and
                reproducible outcomes.
              </t>

            </list>

          </t>

        </section>

        <section title="Structure" anchor="metadata_policy_structure">

          <t>
            Metadata policies are expressed in the
            <spanx style="verb">metadata_policy</spanx> Claim of a Subordinate
            Statement, as described in <xref target="ss-specific"/>. The
            Claim Value is a JSON object that has a data structure consisting of
            three levels:
          </t>

          <t>
            <list style="numbers">
              <t>
                Metadata policies for Entity Types.
                <vspace/>
                The top level contains one or more members, each representing
                the metadata policy for an Entity Type. Each member name is an
                Entity Type Identifier, as specified in
                <xref target="entity_types"/>, for example,
                <spanx style="verb">openid_relying_party</spanx>. The member
                value is a JSON object that contains metadata parameter
                policies.
              </t>
              <t>
                Metadata parameter policies for the Entity Type.
                <vspace/>
                The second level contains one or more members, each representing
                a policy for a metadata parameter for the Entity Type. Each
                member name is a metadata parameter name, for example
                <spanx style="verb">id_token_signed_response_alg</spanx>. The
                name MAY include a language tag, as described in
                <xref target="ClaimsLanguagesAndScripts"/>, in which case the
                metadata parameter policy applies only to the metadata parameter
                with the specified language tag. The member value is a JSON
                object that contains policy operators.
              </t>
              <t>
                Operators for the metadata parameter policy for the Entity
                Type.
                <vspace/>
                The third level contains one or more members, each representing
                an operator that checks or modifies the metadata parameter, as
                described in <xref target="metadata_policy_operators"/>.
		Only operators that are allowed to be combined with one another,
		as defined in the specifications for each operator,
		can be included together here.
              </t>
            </list>
          </t>

          <t>
            Duplicate JSON object member names MUST NOT be present at any of
            the three levels of the <spanx style="verb">metadata_policy</spanx>
            Claim data structure.
          </t>

          <t>
            <figure>
              <preamble>
                The following is a non-normative example of a metadata policy
                for an OpenID Relying Party that consists of a single policy for
                the <spanx style="verb">id_token_signed_response_alg</spanx>
                metadata parameter and uses two operators,
                <spanx style="verb">default</spanx> and
                <spanx style="verb">one_of</spanx>:
              </preamble>
              <name>
                Example <spanx style="verb">metadata_policy</spanx> Claim
              </name>
              <artwork><![CDATA[
"metadata_policy" : {
  "openid_relying_party": {
    "id_token_signed_response_alg": {
      "default": "ES256",
      "one_of": ["ES256", "ES384", "ES512"]
    }
  }
}
]]></artwork>
            </figure>
          </t>
        </section>

        <section title="Operators" anchor="metadata_policy_operators">
          <t>
            A metadata policy operator:
          </t>
          <t>
            <list style="symbols">
              <t>
                Is identified by a unique case-sensitive name.
              </t>
              <t>
                Acts on a single metadata parameter. The operator definition
                MUST specify the metadata parameter JSON value types that are
                mandatory to support, and MAY also specify JSON value types that
                are optional to support. When the metadata parameter has a JSON
                value type that is not supported, the operator MUST produce a
                policy error.
              </t>
              <t>
                The action on the metadata parameter can be a value check, a
                value modification, or both. When the operator's action is a
                value modification, it MAY remove the metadata parameter.
              </t>
              <t>
                The action of the operator is configured by a JSON value. The
                operator definition MUST specify the JSON value types that are
                mandatory to support, and MAY also specify JSON value types that
                are optional to support. When the operator is configured with a
                JSON value type that is not supported, the operator MUST produce
                a policy error.
              </t>
              <t>
                MUST declare what other operators it may be combined with,
                which applies to both individual as well as merged metadata
                parameter policies, as described in
                <xref target="metadata_policy_structure"/> and
                <xref target="metadata_policy_enforcement"/>. A combination may
                be unconditional, or conditional, requiring the configured
                values of the two operators to meet certain criteria.
                Combinations that are not allowed MUST produce a policy error.
              </t>
              <t>
                MUST declare in what order it is to be applied to a metadata
                parameter, absolute or relative to other operators in the
                metadata parameter policy. Value check operators SHOULD
                generally be applied after operators that perform value
                modifications.
              </t>
              <t>
                MUST specify, when more than one Subordinate Statement in a
                Trust Chain has a policy for an Entity Type metadata parameter
                that uses the same operator, whether the operator values are
                allowed to be merged to produce an identical or more restrictive
                policy, and if so, under what conditions.
                  The order of the result of such an operator value merge is not defined.
                  If the operator does not allow such a merge, it MUST produce a policy error.
              </t>
              <t>
                An operator MUST NOT output a metadata parameter with the
                <spanx style="verb">null</spanx> value.
              </t>
            </list>
          </t>

	  <t>
	    Note that metadata parameters and policies that conform to
	    the JSON grammar but do not represent interoperable uses of JSON,
	    as per Sections 4 and 8 of <xref target="RFC8259"/>,
	    can cause unpredictable behaviors.
	  </t>

          <section title="Standard Operators" anchor="standard_metadata_policy_operators">

            <t>This specification defines the following metadata policy
              operators:</t>

            <section title="value" anchor="value_operator">
              <t>
                Name: <spanx style="verb">value</spanx>
              </t>
              <t>
                Action: The metadata parameter MUST be assigned the value of the
                operator. When the value of the operator is
                <spanx style="verb">null</spanx>, the metadata parameter MUST be
                removed.
              </t>
              <t>
                Metadata parameter JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: string, number, boolean, array
                  </t>
                </list>
              </t>
              <t>
                Operator JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: string, number, boolean, array, null
                  </t>
                </list>
              </t>
              <t>
                Combination with other operators in a metadata parameter policy:
                <list style="symbols">
                  <t>
                    MAY be combined with <spanx style="verb">add</spanx>,
                    in which case the values of <spanx style="verb">add</spanx>
                    MUST be a subset of the values of
                    <spanx style="verb">value</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">default</spanx>
                    if the value of <spanx style="verb">value</spanx> is not
                    <spanx style="verb">null</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">one_of</spanx>,
                    in which case the value of <spanx style="verb">value</spanx>
                    MUST be among the <spanx style="verb">one_of</spanx> values.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">subset_of</spanx>,
                    in which case the values of <spanx style="verb">value</spanx>
                    MUST be a subset of the values of
                    <spanx style="verb">subset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">superset_of</spanx>,
                    in which case the values of <spanx style="verb">value</spanx>
                    MUST be a superset of the values of
                    <spanx style="verb">superset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">essential</spanx>,
                    except when <spanx style="verb">value</spanx> is <spanx style="verb">null</spanx> and
                    <spanx style="verb">essential</spanx> is true.
                  </t>
                </list>
              </t>
              <t>
                Order of application: First
              </t>
              <t>
                Operator value merge: Allowed only when the operator values are
                equal. If not, this MUST produce a policy error.
              </t>
            </section>

            <section title="add" anchor="add_operator">
              <t>
                Name: <spanx style="verb">add</spanx>
              </t>
              <t>
                Action: The value or values of this operator MUST be added to
                the metadata parameter. Values that are already present in the
                metadata parameter MUST NOT be added another time. If the
                metadata parameter is absent, it MUST be initialized with the
                value of this operator.
              </t>
              <t>
                Metadata parameter JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: array of strings
                  </t>
                  <t>
                    Optional to support: array of objects, array of numbers
                  </t>
                </list>
              </t>
              <t>
                Operator JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: array of strings
                  </t>
                  <t>
                    Optional to support: array of objects, array of numbers
                  </t>
                </list>
              </t>
              <t>
                Combination with other operators in a metadata parameter policy:
                <list style="symbols">
                  <t>
                    MAY be combined with <spanx style="verb">value</spanx>,
                    in which case the values of <spanx style="verb">add</spanx>
                    MUST be a subset of the values of
                    <spanx style="verb">value</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">default</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">subset_of</spanx>,
                    in which case the values of <spanx style="verb">add</spanx>
                    MUST be a subset of the values of
                    <spanx style="verb">subset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">superset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">essential</spanx>.
                  </t>
                </list>
              </t>
              <t>
                Order of application: After <spanx style="verb">value</spanx>.
              </t>
              <t>
                Operator value merge: The result of merging the values of two
                <spanx style="verb">add</spanx> operators is the union of the
                values.
              </t>
            </section>

            <section title="default" anchor="default_operator">
              <t>
                Name: <spanx style="verb">default</spanx>
              </t>
              <t>
                Action: If the metadata parameter is absent, it MUST be set to
                the value of the operator. If the metadata parameter is present,
                this operator has no effect.
              </t>
              <t>
                Metadata parameter JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: string, number, boolean, array
                  </t>
                </list>
              </t>
              <t>
                Operator JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: string, number, boolean, array
                  </t>
                </list>
              </t>
              <t>
                Combination with other operators in a metadata parameter policy:
                <list style="symbols">
                  <t>
                    MAY be combined with <spanx style="verb">value</spanx>
                    if the value  of <spanx style="verb">value</spanx> is not
                    <spanx style="verb">null</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">add</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">one_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">subset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">superset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">essential</spanx>.
                  </t>
                </list>
              </t>
              <t>
                Order of application: After <spanx style="verb">add</spanx>.
              </t>
              <t>
                Operator value merge: The operator values MUST be equal. If the
                values are not equal this MUST produce a policy error.
              </t>
            </section>

            <section title="one_of" anchor="one_of_operator">
              <t>
                Name: <spanx style="verb">one_of</spanx>
              </t>
              <t>
                Action: If the metadata parameter is present, its value MUST be
                one of those listed in the operator value.
              </t>
              <t>
                Metadata parameter JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: string
                  </t>
                  <t>
                    Optional to support: object, number
                  </t>
                </list>
              </t>
              <t>
                Operator JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: array of strings
                  </t>
                  <t>
                    Optional to support: array of objects, array of numbers
                  </t>
                </list>
              </t>
              <t>
                Combination with other operators in a metadata parameter policy:
                <list style="symbols">
                  <t>
                    MAY be combined with <spanx style="verb">value</spanx>,
                    in which case the value of <spanx style="verb">value</spanx>
                    MUST be among the <spanx style="verb">one_of</spanx> values.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">default</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">essential</spanx>.
                  </t>
                </list>
              </t>
              <t>
                Order of application: After <spanx style="verb">default</spanx>.
              </t>
              <t>
                Operator value merge: The result of merging the values of two
                <spanx style="verb">one_of</spanx> operators is the intersection
                of the operator values. If the intersection is empty, this MUST
                result in a policy error.
              </t>
            </section>

            <section title="subset_of" anchor="subset_of_operator">
              <t>
                Name: <spanx style="verb">subset_of</spanx>
              </t>
              <t>
                Action: If the metadata parameter is present, it is assigned the
                intersection between the values of the operator and the
                metadata parameter. Note that the resulting intersection may
                thus be an empty array <spanx style="verb">[]</spanx>. Also note
                that <spanx style="verb">subset_of</spanx> is a potential value
                modifier in addition to it being a value check.
              </t>
              <t>
                Metadata parameter JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: array of strings
                  </t>
                  <t>
                    Optional to support: array of objects, array of numbers
                  </t>
                </list>
              </t>
              <t>
                Operator JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: array of strings
                  </t>
                  <t>
                    Optional to support: array of objects, array of numbers
                  </t>
                </list>
              </t>
              <t>
                Combination with other operators in a metadata parameter policy:
                <list style="symbols">
                  <t>
                    MAY be combined with <spanx style="verb">value</spanx>,
                    in which case the values of <spanx style="verb">value</spanx>
                    MUST be a subset of the values of
                    <spanx style="verb">subset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">add</spanx>, in
                    which case the values of <spanx style="verb">add</spanx>
                    MUST be a subset of the values of
                    <spanx style="verb">subset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">default</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">superset_of</spanx>,
                    in which case the values of
                    <spanx style="verb">subset_of</spanx> MUST be a superset of
                    the values of <spanx style="verb">superset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">essential</spanx>.
                  </t>
                </list>
              </t>
              <t>
                Order of application: After <spanx style="verb">one_of</spanx>.
              </t>
              <t>
                Operator value merge: The result of merging the values of two
                <spanx style="verb">subset_of</spanx> operators is the
                intersection of the operator values. Note that the resulting
                intersection may thus be an empty array
                <spanx style="verb">[]</spanx>.
              </t>
            </section>

            <section title="superset_of" anchor="superset_of_operator">
              <t>
                Name: <spanx style="verb">superset_of</spanx>
              </t>
              <t>
                Action: If the metadata parameter is present, its values MUST
                contain those specified in the operator value. By mathematically
                defining supersets, equality is included.
              </t>
              <t>
                Metadata parameter JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: array of strings
                  </t>
                  <t>
                    Optional to support: array of objects, array of numbers
                  </t>
                </list>
              </t>
              <t>
                Operator JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: array of strings
                  </t>
                  <t>
                    Optional to support: array of objects, array of numbers
                  </t>
                </list>
              </t>
              <t>
                Combination with other operators in a metadata parameter policy:
                <list style="symbols">
                  <t>
                    MAY be combined with <spanx style="verb">value</spanx>,
                    in which case the values of <spanx style="verb">value</spanx>
                    MUST be a superset of the values of
                    <spanx style="verb">superset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">add</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">default</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">subset_of</spanx>,
                    in which case the values of
                    <spanx style="verb">subset_of</spanx> MUST be a superset of
                    the values of <spanx style="verb">superset_of</spanx>.
                  </t>
                  <t>
                    MAY be combined with <spanx style="verb">essential</spanx>.
                  </t>
                </list>
              </t>
              <t>
                Order of application: After <spanx style="verb">subset_of</spanx>.
              </t>
              <t>
                Operator value merge: The result of merging the values of two
                <spanx style="verb">superset_of</spanx> operators is the union
                of the operator values.
              </t>
            </section>

            <section title="essential" anchor="essential_operator">
              <t>
                Name: <spanx style="verb">essential</spanx>
              </t>
              <t>
                Action: If the value of this operator is
                <spanx style="verb">true</spanx>, then the metadata parameter
                MUST be present. If <spanx style="verb">false</spanx>, the
                metadata parameter is voluntary and may be absent. If the
                <spanx style="verb">essential</spanx> operator is omitted, this
                is equivalent to including it with a value of
                <spanx style="verb">false</spanx>.
              </t>
              <t>
                Metadata parameter JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: string, number, boolean, object, array
                  </t>
                </list>
              </t>
              <t>
                Operator JSON values:
                <list style="symbols">
                  <t>
                    Mandatory to support: boolean
                  </t>
                </list>
              </t>
              <t>
                Combination with other operators in a metadata parameter policy:
                <list style="symbols">
                  <t>
                    MAY be combined with <spanx style="verb">value</spanx>,
                    except when <spanx style="verb">value</spanx> is <spanx style="verb">null</spanx> and
                    <spanx style="verb">essential</spanx> is true.
                  </t>
                  <t>
                    MAY be combined with any other operator.
                  </t>
                </list>
              </t>
              <t>
                Order of application: Last
              </t>
              <t>
                Operator value merge: The result of merging the values of two
                <spanx style="verb">essential</spanx> operators is the logical
                disjunction (<spanx style="verb">OR</spanx>) of the operator values.
              </t>
            </section>

            <section title="Notes on Operators" anchor="standard_metadata_policy_operators_notes">

              <t>
                A "set equals" metadata parameter policy can be expressed by
                combining the operators <spanx style="verb">subset_of</spanx> and
                <spanx style="verb">superset_of</spanx> with identical array
                values.
              </t>
	      <t>
		Some JSON libraries may have issues comparing JSON objects.
		For this reason, support for applying metadata policy to
		metadata values that are JSON objects is mandatory only for the
		<spanx style="verb">essential</spanx>
		operator, which does not require comparison of values.
		It is OPTIONAL for the
		<spanx style="verb">add</spanx>,
		<spanx style="verb">one_of</spanx>,
		<spanx style="verb">subset_of</spanx>, and
		<spanx style="verb">superset_of</spanx>
		operators, which operate on JSON arrays
		and therefore require comparison of values.
		And it is OPTIONAL for the
		<spanx style="verb">value</spanx> and
		<spanx style="verb">default</spanx> operators,
		since merging values and defaults requires comparing
		the operators' values with existing ones.
	      </t>
              <t>
                The <spanx style="verb">scope</spanx> OAuth 2.0 client metadata
                parameter, defined in <xref target="RFC7591"/> and represented by
                a string of space-separated string values, is to be regarded and
                processed as a string array by policy operators, such as the
                operators <spanx style="verb">default</spanx>,
                <spanx style="verb">subset_of</spanx> and
                <spanx style="verb">superset_of</spanx>. The resulting
                <spanx style="verb">scope</spanx> metadata parameter is a
                space-separated string of individual scope values, where the
                scope values present are taken from the array of values produced
                by applying the metadata operators to the
                <spanx style="verb">scope</spanx> parameter.
              </t>

              <table>
                <preamble>
                  The following table is a map of the outputs produced by
                  combinations of the <spanx style="verb">essential</spanx> and
                  <spanx style="verb">subset_of</spanx> policy operators with
                  different input metadata parameter values.
                  Note, the <spanx style="verb">subset_of</spanx> check is skipped
                  when the metadata parameter is absent and designated as
                  voluntary, as shown in the last row.
                </preamble>
                <name>
                  Examples of Outputs with Combinations of
                  <spanx style="verb">essential</spanx> and
                  <spanx style="verb">subset_of</spanx> for Different Inputs
                </name>
                <thead>
                  <tr>
                    <td colspan="2">Policy</td>
                    <td colspan="2">Metadata Parameter</td>
                  </tr>
                  <tr>
                    <td colspan="">essential</td>
                    <td colspan="">subset_of</td>
                    <td colspan="">input</td>
                    <td colspan="">output</td>
                  </tr>
                </thead>

                <tbody>
                  <tr>
                    <td>true</td>
                    <td>[a,b,c]</td>
                    <td>[a,e]</td>
                    <td>[a]</td>
                  </tr>

                  <tr>
                    <td>false</td>
                    <td>[a,b,c]</td>
                    <td>[a,e]</td>
                    <td>[a]</td>
                  </tr>

                  <tr>
                    <td>true</td>
                    <td>[a,b,c]</td>
                    <td>[d,e]</td>
                    <td>[]</td>
                  </tr>

                  <tr>
                    <td>false</td>
                    <td>[a,b,c]</td>
                    <td>[d,e]</td>
                    <td>[]</td>
                  </tr>

                  <tr>
                    <td>true</td>
                    <td>[a,b,c]</td>
                    <td>no parameter</td>
                    <td>error</td>
                  </tr>

                  <tr>
                    <td>false</td>
                    <td>[a,b,c]</td>
                    <td>no parameter</td>
                    <td>no parameter</td>
                  </tr>
                </tbody>
              </table>
            </section>

          </section>

          <section title="Additional Operators" anchor="additional_metadata_policy_operators">

            <t>
              Federations MAY specify and use additional metadata policy
              operators that conform with the principles in
              <xref target="metadata_policy_principles"/> and in
              <xref target="metadata_policy_operators"/>.
            </t>

            <t>
              Additional operators MUST observe the following rules in regard to
              the order of their application relative to the standard operators
              defined in <xref target="standard_metadata_policy_operators"/>:
                <list style="symbols">
                  <t>
                    Additional operators that modify metadata parameters MUST be
                    applied after the <spanx style="verb">value</spanx> operator
                    that is specified in <xref target="value_operator"/>.
                  </t>
                  <t>
                    Additional operators that check metadata parameters MUST be
                    applied before the <spanx style="verb">essential</spanx>
                    operator that is specified in
                    <xref target="essential_operator"/>.
                  </t>
                </list>
            </t>

            <t>
              Implementations MUST ignore additional operators that are not
              understood, unless the operator name is included in the
              <spanx style="verb">metadata_policy_crit</spanx> Subordinate
              Statement Claim, in which case the operator MUST be understood
              and processed. If an additional operator listed in
              <spanx style="verb">metadata_policy_crit</spanx> is not understood
              or cannot be processed, then this MUST produce a policy error and
              the Trust Chain MUST be considered invalid.
            </t>

          </section>

        </section>

        <section title="Enforcement" anchor="metadata_policy_enforcement">

            <t>
              This section describes the resolution of the metadata policy for a
              Trust Chain and its application to the metadata of the Federation
              Entity that is the Trust Chain subject.
            </t>

            <t>
              If a policy error or another error is encountered during the
              metadata policy resolution or its application, the Trust Chain
              MUST be considered invalid.
            </t>

            <section title="Resolution" anchor="metadata_policy_resolution">

              <t>
                The metadata policy for a Trust Chain is determined by the
                sequence of the present <spanx style="verb">metadata_policy</spanx>
                Claims of the Subordinate Statements that make up the chain.
              </t>

              <t>
                The resolution process MUST first gather the names of all policy
                operators other than the standard ones defined in
                <xref target="standard_metadata_policy_operators"/> that are
                declared as critical. This is done by checking each Subordinate
                Statement in the Trust Chain for the optional
                <spanx style="verb">metadata_policy_crit</spanx> Claim,
                described in <xref target="ss-specific"/>, and collecting
                any operator names that are found in it.
              </t>

              <t>
                The resolution process proceeds by iterating through the
                Subordinate Statements. The sequence of this iteration is
                crucial - it MUST begin with the Subordinate Statement issued by
                the most Superior Entity and end with the Subordinate Statement
                issued by the Immediate Superior of the Trust Chain subject.
              </t>

              <t>
                An important task during the iteration is the
                <spanx style="verb">metadata_policy</spanx> validation. It MUST
                ensure the data structure is compliant and that every metadata
                parameter policy contains only allowed operator combinations, as
                described in <xref target="metadata_policy_operators"/>, and in
                accordance with the specifications of the operators. It MUST
                also be ensured that the <spanx style="verb">metadata_policy</spanx>
                contains no operators that cannot be understood and processed
                whose names are among the collected
                <spanx style="verb">metadata_policy_crit</spanx> values. An
                unsuccessful validation MUST produce a policy error.
              </t>

              <t>
                At each iteration step, the Subordinate Statement MUST be checked
                for the presence of a <spanx style="verb">metadata_policy</spanx>
                Claim. The first encountered
                <spanx style="verb">metadata_policy</spanx> MUST be validated as
                described above, after which it becomes the current metadata
                policy.
              </t>

              <t>
                If the iteration yields a next subordinate
                <spanx style="verb">metadata_policy</spanx> Claim, it MUST be
                validated as described above, then merged into the current
                metadata policy.
              </t>

              <t>
                The merge is performed at each of the three levels of the
                <spanx style="verb">metadata_policy</spanx> data structure
                described in <xref target="metadata_policy_structure"/>, by
                starting from the top level:
                <t>
                  <list style="numbers">
                    <t>
                      The metadata policies for Entity Types.
                    </t>
                    <t>
                      The metadata parameter policies for an Entity Type.
                    </t>
                    <t>
                      The operators for a metadata parameter policy for an
                      Entity Type.
                    </t>
                  </list>
                </t>
              </t>

              <t>
                At the level of metadata policies for Entity Types, the merge
                proceeds as follows:
                <t>
                  <list style="symbols">
                    <t>
                      If the next subordinate
                      <spanx style="verb">metadata_policy</spanx> Claim contains
                      a metadata policy for an Entity Type that is already
                      present in the current metadata policy, it MUST be merged
                      according to the rules of the next lower level (the
                      metadata parameter policies).
                    </t>
                    <t>
                      Entity Type metadata policies in the next subordinate
                      <spanx style="verb">metadata_policy</spanx> Claim that are
                      not present in the current metadata policy MUST be copied
                      to it.
                    </t>
                  </list>
                </t>
              </t>

              <t>
                At the level of metadata parameter policies, the merge proceeds
                as follows:
                <t>
                  <list style="symbols">
                    <t>
                      If a metadata parameter policy is already present in the
                      current Entity Type metadata policy, it MUST be merged
                      according to the rules of the next lower level (the
                      operators for the metadata parameter policy). If the
                      resulting metadata parameter policy contains combinations
                      that are not allowed, as described in
                      <xref target="metadata_policy_operators"/> and in
                      accordance with the specifications of the operators, this
                      MUST produce a policy error.
                    </t>
                    <t>
                      Subordinate metadata parameter policies that are not
                      present in the current Entity Type metadata policy MUST be
                      copied to it.
                    </t>
                  </list>
                </t>
              </t>

              <t>
                At the level of operators, the merge proceeds as follows:
                <t>
                  <list style="symbols">
                    <t>
                      If an operator is already present in the current metadata
                      parameter policy, the values of the subordinate operator
                      MUST be merged, as described in
                      <xref target="metadata_policy_operators"/> and in
                      accordance with the operator specification. If an operator
                      value merge is not allowed or otherwise unsuccessful this
                      MUST produce a policy error.
                    </t>
                    <t>
                      Subordinate operators that are not present in the current
                      metadata parameter policy MUST be copied to it.
                    </t>
                  </list>
                </t>
              </t>

              <t>
                If no further Subordinate Statements with a
                <spanx style="verb">metadata_policy</spanx> Claim are found, the
                current metadata policy becomes the resolved one for the Trust Chain.
              </t>

            </section>

            <section title="Application" anchor="metadata_policy_application">

              <t>
                If the Subordinate Statement about the Trust Chain subject
                contains a <spanx style="verb">metadata</spanx> Claim, this MUST
                first be applied, as described in the Claim definition in
                <xref target="common-claims"/>, and only then it can be
                proceeded with applying the Resolved Metadata policy.
              </t>

              <t>
                If the process described in
                <xref target="metadata_policy_resolution"/> found no Subordinate
                Statements in the Trust Chain with a
                <spanx style="verb">metadata_policy</spanx> Claim, the metadata
                of the Trust Chain subject resolves simply to the
                <spanx style="verb">metadata</spanx> found in its Entity
                Configuration, with any <spanx style="verb">metadata</spanx>
                parameters provided by the Immediate Superior applied to it.
              </t>

              <t>
                If a metadata policy was resolved for the Trust Chain, for every
                Entity Type metadata and metadata parameter for which a
                corresponding metadata parameter policy is present, the included
                policy operators MUST be applied as described in
                <xref target="metadata_policy_operators"/> and in accordance with
                the specifications of the operators. The operators MUST be
                applied to the metadata parameter in a sequence that is
                determined by the absolute or relative order specified for each
                operator.
              </t>

              <t>
                If the application of metadata policies results in illegal or
                otherwise incorrect Resolved Metadata, then the metadata MUST be regarded
                as broken and MUST NOT be used.
              </t>

              <t>
                The Trust Chain subject is responsible to verify that it is
                able to support and comply with the Resolved Metadata that results from
                the application of federation metadata policies. For instance,
                this may involve a check that cryptographic algorithms required
                by the resulting Resolved Metadata are supported.
		Likewise, the Trust Chain subject MUST verify that
		all the required metadata parameters for its Entity Types are present
		and all the metadata values in the Resolved Metadata are valid.
		When metadata policies
                change, Trust Chain subjects may need to reevaluate their
                support and compliance.
              </t>

            </section>

          </section>

        <section title="Metadata Policy Example" anchor="metadata-policy-example">
          <t>
            The following is a non-normative example of resolving and applying
            Trust Chain metadata policies for an OpenID relying party.
          </t>
          <figure>
            <preamble>
              We start with a federation Trust Anchor's
              <spanx style="verb">metadata_policy</spanx> for RPs:
            </preamble>
            <name>
              Example Metadata Policy of a Trust Anchor for RPs
            </name>
            <artwork><![CDATA[
"metadata_policy": {
  "openid_relying_party": {
    "grant_types": {
       "default": [
        "authorization_code"
      ],
      "subset_of": [
        "authorization_code",
        "refresh_token"
      ],
      "superset_of": [
        "authorization_code"
      ]
    },
    "token_endpoint_auth_method": {
      "one_of": [
        "private_key_jwt",
        "self_signed_tls_client_auth"
      ],
      "essential": true
    },
    "token_endpoint_auth_signing_alg" : {
      "one_of": [
        "PS256",
        "ES256"
      ]
    },
    "subject_type": {
      "value": "pairwise"
    },
    "contacts": {
      "add": [
        "helpdesk@federation.example.org"
      ]
    }
  }
}
]]></artwork>
          </figure>
          <figure>
            <preamble>
              Next, we have an Intermediate organization's
              <spanx style="verb">metadata_policy</spanx> for Subordinate RPs
              together with <spanx style="verb">metadata</spanx> values for its
              Immediate Subordinate RPs:
            </preamble>
            <name>
              Example Metadata Policy and Metadata Values of an Intermediate
              Entity for RPs
            </name>
            <artwork><![CDATA[
{
  "metadata_policy": {
    "openid_relying_party": {
      "grant_types": {
        "subset_of": [
          "authorization_code"
        ]
      },
      "token_endpoint_auth_method": {
        "one_of": [
          "self_signed_tls_client_auth"
        ]
      },
      "contacts": {
        "add": [
          "helpdesk@org.example.org"
        ]
      }
    }
  },
  "metadata": {
    "openid_relying_party": {
      "sector_identifier_uri": "https://org.example.org/sector-ids.json",
      "policy_uri": "https://org.example.org/policy.html"
    }
  }
}
]]></artwork>
          </figure>
          <figure>
            <preamble>
              Merging the example RP metadata policy of the Intermediate Entity
              into the RP metadata policy of the Trust Anchor produces the
              following policy for the Trust Chain:
            </preamble>
            <name>
              Example Merged Metadata Policy for RPs
            </name>
            <artwork><![CDATA[
{
  "grant_types": {
    "default": [
      "authorization_code"
    ],
    "superset_of": [
      "authorization_code"
    ],
    "subset_of": [
      "authorization_code"
    ]
  },
  "token_endpoint_auth_method": {
    "one_of": [
      "self_signed_tls_client_auth"
    ],
    "essential": true
  },
  "token_endpoint_auth_signing_alg": {
    "one_of": [
      "PS256",
      "ES256"
    ]
  },
  "subject_type": {
    "value": "pairwise"
  },
  "contacts": {
    "add": [
      "helpdesk@federation.example.org",
      "helpdesk@org.example.org"
    ]
  }
}
]]></artwork>
          </figure>
          <figure>
            <preamble>
              The Trust Chain subject is a Leaf Entity, which publishes the
              following RP metadata in its Entity Configuration:
            </preamble>
            <name>
              Example Entity Configuration RP Metadata
            </name>
            <artwork><![CDATA[
"metadata": {
  "openid_relying_party": {
    "redirect_uris": [
      "https://rp.example.org/callback"
    ],
    "response_types": [
      "code"
    ],
    "token_endpoint_auth_method": "self_signed_tls_client_auth",
    "contacts": [
      "rp_admins@rp.example.org"
    ]
  }
}
]]></artwork>
          </figure>
          <figure>
            <preamble>
              The <spanx style="verb">metadata</spanx> values specified by the
              Intermediate Entity for its Immediate Subordinates are applied to
              the Trust Chain subject <spanx style="verb">metadata</spanx>.
              After that, the merged metadata policy is applied, to produce the
              following resulting RP Resolved Metadata:
            </preamble>
            <name>
              The Resulting RP Resolved Metadata for the Trust Chain Subject
            </name>
            <artwork><![CDATA[
{
  "redirect_uris": [
    "https://rp.example.org/callback"
  ],
  "grant_types": [
    "authorization_code"
  ],
  "response_types": [
    "code"
  ],
  "token_endpoint_auth_method": "self_signed_tls_client_auth",
  "subject_type": "pairwise",
  "sector_identifier_uri": "https://org.example.org/sector-ids.json",
  "policy_uri": "https://org.example.org/policy.html",
  "contacts": [
    "rp_admins@rp.example.org",
    "helpdesk@federation.example.org",
    "helpdesk@org.example.org"
  ]
}
]]></artwork>
          </figure>
        </section>
      </section>

      <section title="Constraints" anchor="chain_constraints">
	<t>
      Trust Anchors and Intermediate Entities MAY define constraining criteria
      that apply to their Subordinates. They are expressed in the
      <spanx style="verb">constraints</spanx> Claim of a Subordinate Statement,
      as described in <xref target="ss-specific"/>.
	</t>
	<t>
	  The following constraint parameters are defined:
	</t>
        <t>
          <list style="hanging">
            <t hangText="max_path_length">
              <vspace/>
              OPTIONAL. Integer specifying the maximum number of Intermediate
              Entities between the Entity setting the constraint and the Trust
              Chain subject.
            </t>
            <t hangText="naming_constraints">
              <vspace/>
              OPTIONAL. JSON object specifying restrictions on the URIs of the
	          Entity Identifiers of Subordinate Entities. Restrictions are
              defined in terms of permitted and excluded URI name subtrees.
            </t>
            <t hangText="allowed_entity_types">
              <vspace/>
              OPTIONAL. Array of string Entity Type Identifiers.
              Entity Type Identifiers are defined in <xref target="entity_types"/>.
              This constraint specifies the Entity Types and hence the metadata
              that Subordinate Entities are allowed to have.
            </t>
          </list>
        </t>
	<t>
	  Additional constraint parameters MAY be defined and used.
	  If they are not understood, they MUST be ignored.
	</t>
        <figure>
	  <preamble>
	    The following is a non-normative example of a set of constraints:
	  </preamble>
	  <name>
            Example Set of Constraints
          </name>
          <artwork><![CDATA[
{
  "max_path_length": 2,
  "naming_constraints": {
    "permitted": [
      ".example.com"
    ],
    "excluded": [
      "east.example.com"
    ]
  },
  "allowed_entity_types": [
    "openid_provider",
    "openid_relying_party"
  ]
}
]]></artwork>
        </figure>
        <t>
          When resolving the Trust Chain for an Entity the
          <spanx style="verb">constraints</spanx> Claim in each Subordinate
          Statement MUST be independently applied, if present. If any of the
          <spanx style="verb">constraints</spanx> checks fails, the Trust Chain
          MUST be considered invalid.
        </t>

        <section title="Max Path Length Constraint" anchor="max_path_length">
          <t>
            The <spanx style="verb">max_path_length</spanx> constraint specifies
            the maximum allowed number of Intermediate Entities in a Trust Chain
            between a Trust Anchor or Intermediate that sets the constraint and
            the Trust Chain subject.
          </t>
          <t>
            A <spanx style="verb">max_path_length</spanx> constraint of zero
            indicates that no Intermediates MAY appear between this Entity and
            the Trust Chain subject. The
            <spanx style="verb">max_path_length</spanx> constraint MUST have a
            value greater than or equal to zero.
          </t>
          <t>
            Omitting the <spanx style="verb">max_path_length</spanx> constraint
            means that there are no additional constraints apart from those
            already in effect.
          </t>
          <t>
            Assuming that we have a Trust Chain with four Entity Statements:
            <list style="numbers">
              <t>Entity Configuration of a Leaf Entity (LE)</t>
              <t>Subordinate Statement by an Intermediate 1 (I1) about LE</t>
              <t>Subordinate Statement by an Intermediate 2 (I2) about I1</t>
              <t>Subordinate Statement by a Trust Anchor (TA) about I2</t>
            </list>
          </t>
          <t>
            Then the Trust Chain fulfills the constraints if, for instance:
            <list style="symbols">
              <t>
                The TA specifies a <spanx style="verb">max_path_length</spanx>
                that is greater than or equal to 2.
              </t>
              <t>
                TA specifies a <spanx style="verb">max_path_length</spanx> of 2,
                I2 specifies a <spanx style="verb">max_path_length</spanx> of 1,
                and I1 omits the <spanx style="verb">max_path_length</spanx>
                constraint.
              </t>
              <t>
                Neither TA nor I2 specifies any
                <spanx style="verb">max_path_length</spanx> constraint while I1
                sets <spanx style="verb">max_path_length</spanx> to 0.
              </t>
            </list>
          </t>
          <t>
            The Trust Chain does not fulfill the constraints if, for instance,
            the:
            <list style="symbols">
              <t>
                The TA sets the <spanx style="verb">max_path_length</spanx> to 1.
              </t>
            </list>
          </t>
        </section>

        <section title="Naming Constraints" anchor="naming_constraints">
          <t>
            The <spanx style="verb">naming_constraints</spanx> member specifies
            a URI namespace within which the Entity Identifiers of Subordinate
            Entities in a Trust Chain MUST be located.
          </t>
          <t>
	    Restrictions are defined in terms of URI name subtrees,
	    using <spanx style="verb">permitted</spanx> and/or
	    <spanx style="verb">excluded</spanx> members within the
	    <spanx style="verb">naming_constraints</spanx> member,
	    each of which contains an array of names to be permitted or excluded.
	    Any name matching a restriction in the excluded list is invalid,
	    regardless of the information appearing in the permitted list.
          </t>
          <t>
	    This specification uses the syntax of domain name constraints
	    specified in Section 4.2.1.10 of <xref target="RFC5280"/>.
            As stated there, a domain name constraint MUST be specified as a fully qualified domain name
            and MAY specify a host or a domain. Examples are
            "host.example.com" and ".example.com". When the domain name constraint begins
            with a period, it MAY be expanded with one or more labels.
            That is, the domain name constraint ".example.com" is satisfied by both
            host.example.com and my.host.example.com. However, the domain name constraint
            ".example.com" is not satisfied by "example.com". When the
            domain name constraint does not begin with a period, it specifies a host.
	    As in RFC 5280, domain name constraints apply to the host part of the URI.
          </t>
        </section>

        <section title="Entity Type Constraints"
                 anchor="entity_type_constraints">
          <t>
            The <spanx style="verb">allowed_entity_types</spanx> constraint
            specifies the acceptable metadata Entity Types of Subordinate Entities in a
            Trust Chain. If there is no
            <spanx style="verb">allowed_entity_types</spanx> constraint, it
            means that any Entity Type is allowed. The
            <spanx style="verb">federation_entity</spanx> Entity Type
            Identifier, specified in <xref target="federation_entity"/>, is
            always allowed and MUST NOT be included in the constraint. If the
            constraint is the empty array <spanx style="verb">[]</spanx>, it
            means that only the <spanx style="verb">federation_entity</spanx>
            Entity Type is allowed.
          </t>
            <t>
                To apply the <spanx style="verb">allowed_entity_types</spanx> constraint during Trust Chain Resolution
                all Entity Types that are not listed in the <spanx style="verb">allowed_entity_types</spanx> constraint
                MUST be removed from the metadata Claim in the subject's Entity Configuration.
                The <spanx style="verb">federation_entity</spanx> Entity Type MUST NOT be removed.
                This MUST be done before applying Metadata Policies but after applying Metadata from a direct
                superior's Subordinate Statement.
            </t>
        </section>
      </section>
    </section>

      <section title="Trust Marks" anchor="trust_marks">
	<t>
	  Per the definition in <xref target="Terminology"/>,
	  Trust Marks are statements of conformance to sets of criteria
	  determined by an accreditation authority.
	  Trust Marks used by this specification are signed JWTs.
	  Entity Statements MAY include Trust Marks,
	  as described in the <spanx style="verb">trust_marks</spanx>
	  Claim definition in <xref target="ec-specific"/>.
        </t>
        <t>
          Trust Marks are signed by a federation-accredited
          authority called a Trust Mark Issuer.
	  All Trust Mark Issuers MUST be represented in the
          federation by an Entity. The fact that a Trust Mark Issuer is
          accepted by the federation is expressed in the
          <spanx style="verb">trust_mark_issuers</spanx> Claim of the
          Trust Anchor's Entity Configuration.
        </t>
        <t>
          The key used by the Trust Mark
          issuer to sign its Trust Marks MUST be one of the private keys
          in its set of
          Federation Entity Keys.
	</t>
	<t>
	  Trust Mark JWTs MUST include the
	  <spanx style="verb">kid</spanx> (Key ID) header parameter
	  with its value being the Key ID of the signing key used.
        </t>
        <t>
          Note that a federation MAY allow an Entity to self-sign
          Trust Marks.
        </t>
        <t>
          Trust Mark JWTs MUST be explicitly typed by using the
          <spanx style="verb">typ</spanx> header parameter to prevent
          cross-JWT confusion, per Section 3.11 of <xref target="RFC8725"/>.
          The <spanx style="verb">typ</spanx> header parameter value MUST be
          <spanx style="verb">trust-mark+jwt</spanx>
          unless the trust framework in use defines a more specific
          media type value for the particular kind of Trust Mark.
	  Trust Marks without a <spanx style="verb">typ</spanx> header parameter
	  or an unrecognized <spanx style="verb">typ</spanx> value MUST be rejected.
        </t>

        <figure>
          <preamble>
            The following is a non-normative example of
            a <spanx style="verb">trust_mark_issuers</spanx> Claim:
          </preamble>
          <name>
            Example <spanx style="verb">trust_mark_issuers</spanx> Claim
          </name>
          <artwork><![CDATA[
"trust_mark_issuers":
{
  "https://openid.net/certification/op": [],
  "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf":
    ["https://swamid.se"]
}
]]></artwork>
        </figure>

        <section title="Trust Mark Claims" anchor="trust_mark_claims">
          <t>
	    The Claims in a Trust Mark are:
	  </t>
          <t>
            <list style="hanging">
              <t hangText="iss">
                <vspace/>
                REQUIRED. String. The Entity Identifier of the issuer of the Trust Mark.
              </t>
              <t hangText="sub">
                <vspace/>
                REQUIRED. String. The Entity Identifier of the Entity this Trust Mark applies to.
              </t>
              <t hangText="trust_mark_type">
                <vspace/>
		REQUIRED.
		The <spanx style="verb">trust_mark_type</spanx> Claim
		is used in Trust Marks
		to provide the identifier of the type of the Trust Mark.
                The Trust Mark type identifier
                MUST be collision-resistant
                across multiple federations.
                It is RECOMMENDED that the
		identifier
                value is built
                using a URL that uniquely identifies the federation
                or the trust framework
                within which it was issued. This is required to prevent
                Trust Marks issued in different federations
                from having colliding identifiers.
              </t>
              <t hangText="iat">
                <vspace/>
                REQUIRED. Number. Time when this Trust Mark was issued.
                This is expressed as Seconds Since the Epoch, per
                <xref target="RFC7519"/>.
              </t>
              <t hangText="logo_uri">
                <vspace/>
                OPTIONAL. String. URL that references a logo for the issued Trust Mark.
		The value of this field MUST point to a valid image file.
              </t>
              <t hangText="exp">
                <vspace/>
                OPTIONAL. Number. Time when this Trust Mark is no longer valid.
                This is expressed as Seconds Since the Epoch, per <xref target="RFC7519"/>.
                If not present, it means that the Trust Mark does not expire.
              </t>
              <t hangText="ref">
                <vspace/>
		OPTIONAL.
		The <spanx style="verb">ref</spanx> (reference) Claim
		defined in <xref target="refClaim"/> is used in Trust Marks
		to provide a URL referring to human-readable information
		about the issuance of the Trust Mark.
              </t>
              <t hangText="delegation">
                <vspace/>
		OPTIONAL.
		The <spanx style="verb">delegation</spanx> Claim
		defined in <xref target="delegationClaim"/> is used in Trust Marks
		to delegate the right to issue Trust Marks
		with a particular identifier.
		Its value is a Trust Mark delegation JWT,
		as defined in <xref target="delegation_jwt"/>.
              </t>
            </list>
          </t>
          <t>
            Additional Claims MAY be defined and used in conjunction with the Claims above.
          </t>
        </section>

        <section title="Trust Mark Delegation" anchor="trust_mark_delegation">
          <t>
            There will be cases where the owner of a Trust Mark for some reason
            does not match the Trust Mark Issuer due to administrative or
            technical requirements. Take as an example vehicle
            inspection. Vehicle inspection is a procedure mandated by national
            or subnational governments in many countries, in which a vehicle is
            inspected to ensure that it conforms to regulations governing
            safety, emissions, or both. The body that mandates the inspections
            does not perform them; instead, there may be commercial companies
            performing the inspections, after which they issue the Trust Mark.
          </t>
          <t>
            The fact that a Trust Mark is issued by a Trust Mark Issuer that is
            not the owner of the Trust Mark is expressed by including
	    a <spanx style="verb">delegation</spanx> Claim in the Trust Mark,
	    whose value is a Trust Mark delegation JWT,
	    as defined in <xref target="delegation_jwt"/>.
          </t>
          <t>
            If the Federation Operator knows that Trust Marks with a
            certain Trust Mark type identifier may legitimately be issued by Trust Mark Issuers
            that are not the owner of the Trust Mark type identifier, then information
            about the owner and the Trust Mark type identifier MUST be included in the
            <spanx style="verb">trust_mark_owners</spanx> Claim in
	    the Trust Anchor's Entity Configuration.
          </t>

        <figure>
          <preamble>
            The following is a non-normative example of
            a <spanx style="verb">trust_mark_owners</spanx> Claim:
          </preamble>
          <name>
            Example <spanx style="verb">trust_mark_owners</spanx> Claim
          </name>
          <artwork><![CDATA[
"trust_mark_owners":
{
  "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf":
  {
    "sub": "https://refeds.org/sirtfi",
    "jwks" : {
      "keys": [
        {
          "alg": "RS256",
          "e": "AQAB",
          "kid": "Jlob6qNFuSHj3sfuntz9C_9s...",
          "kty": "RSA",
          "n": "_LioMsSeycE4pELlpPYgZluB...",
          "use": "sig"
        }
      ]
    }
  }
}
]]></artwork>
        </figure>

	  <section title="Trust Mark Delegation JWT" anchor="delegation_jwt">
	    <t>
	      A Trust Mark Delegation JWT is a signed JWT
	      issued by a Trust Mark Owner
	      that identifies a legitimate delegated issuer of Trust Marks
	      with a particular identifier.
	    </t>
	  <t>
            A Trust Mark delegation JWT MUST be explicitly typed, by setting the
            <spanx style="verb">typ</spanx> header parameter to
            <spanx style="verb">trust-mark-delegation+jwt</spanx> to prevent
            cross-JWT confusion, per Section 3.11 of <xref target="RFC8725"/>.
	    Trust Mark delegation JWTs without a <spanx style="verb">typ</spanx> header parameter
	    or with a different <spanx style="verb">typ</spanx> value MUST be rejected.
	    It is signed with a Federation Entity Key.
          </t>
	  <t>
	    Trust Mark delegation JWTs MUST include the
	    <spanx style="verb">kid</spanx> (Key ID) header parameter
	    with its value being the Key ID of the signing key used.
	  </t>
          <t>
            The Claims in a Trust Mark delegation JWT are:
          </t>
          <t>
            <list style="hanging">
              <t hangText="iss">
                <vspace/>
                REQUIRED. String. The owner of the Trust Mark.
              </t>
              <t hangText="sub">
                <vspace/>
                REQUIRED. String. The Entity this delegation applies to.
              </t>
              <t hangText="trust_mark_type">
                <vspace/>
                REQUIRED. String. The identifier for the type of the Trust Mark.
              </t>
              <t hangText="iat">
                <vspace/>
                REQUIRED. Number. Time when this delegation was issued.
                This is expressed as Seconds Since the Epoch, per
                <xref target="RFC7519"/>.
              </t>
              <t hangText="exp">
                <vspace/>
                OPTIONAL. Number. Time when this delegation stops being valid.
                This is expressed as Seconds Since the Epoch, per <xref target="RFC7519"/>.
                If not present, it means that the delegation does not expire.
              </t>
              <t hangText="ref">
                <vspace/>
                OPTIONAL. String. URL that points to human-readable information
                connected to the Trust Mark.
              </t>
            </list>
          </t>
	  <t>
	    Additional Claims MAY be defined and used in conjunction with the Claims above.
	  </t>
	  </section>
            <section title="Validating a Trust Mark Delegation" anchor="trust-mark-delegation-validation">
                <t>
                    Validating a Trust Mark Delegation means validating a Trust Mark Delegation instance represented
                    by a specific signed JWT.
                </t>
                <t>Henceforth, "delegation" is used as a shorthand for a Trust Mark Delegation JWT.
                    The Trust Anchor referenced below is a Trust Anchor that has been successfully used when
                    establishing trust in the Trust Mark Issuer.
                </t>
                <t>
                    To validate a delegation, the following validation steps MUST be performed.
                    Please note that if any of these validation checks fail, the entire validation
                    process fails and the delegation is considered invalid.
        <list style="numbers">
            <t>The delegation MUST be a signed JWT</t>
            <t>The delegation MUST have a <spanx style="verb">typ</spanx> header with the value
                <spanx style="verb">trust-mark-delegation+jwt</spanx>
            </t>
            <t>The delegation MUST have an <spanx style="verb">alg</spanx> (algorithm) header parameter with a value
                that is an acceptable JWS signing algorithm; it MUST NOT be <spanx style="verb">none</spanx>
            </t>
            <t>The Entity Identifier of the Trust Mark Issuer MUST match the value of <spanx style="verb">sub</spanx>
                in the delegation</t>
            <t>The Entity Identifier of the Trust Mark Owner MUST match the value of <spanx style="verb">iss</spanx>
                in the delegation.</t>
            <t>The current time MUST be after the time represented by the iat (issued at) Claim in the delegation
                (possibly allowing for some small leeway to account for clock skew).</t>
            <t>If the <spanx style="verb">exp</spanx> (expiration) Claim is present in the delegation,
                the current time MUST be before the time it represents
                (possibly allowing for some small leeway to account for clock skew).</t>
            <t>
                The value of the Claim <spanx style="verb">trust_mark_type</spanx> in the delegation MUST be the same
                as the value of the Claim <spanx style="verb">trust_mark_type</spanx> in the Trust Mark.
            </t>
            <t>The delegation's signature MUST validate using one of the Trust Mark Owner's keys
                identified by the value of the header parameter <spanx style="verb">kid</spanx>.
                The Trust Mark Owner's keys can be found in the <spanx style="verb">trust_mark_owners</spanx> Claim in
                the Trust Anchor's Entity Configuration.
            </t>
        </list>
      </t>
            </section>
        </section>
        <section title="Validating a Trust Mark" anchor="trust-mark-validation">
          <t>
            Validating a Trust Mark means validating a Trust Mark instance
            represented by a specific signed JWT.
            It is NOT about validating whether a Trust Mark of a particular kind
            can exist or not.
          </t>
          <t>
	    The trust in the Trust Mark Issuer comes before the trust in the trust mark.
              If the Trust Mark Issuer is not trusted then the trust mark cannot be trusted.
              An Entity MUST therefore establish trust in the Trust Mark Issuer by following the procedure defined in
              <xref target="resolving_trust"/> prior to starting the Trust Mark validation process defined below.
	  </t>
      <t>
        Henceforth, "instance" is used as a shorthand for Trust Mark instance.
          The Trust Anchor referenced below is a Trust Anchor that
          has been successfully used when establishing trust in the Trust Mark Issuer.
      </t><t>
        To validate an instance, the following validation steps MUST be performed.
        Please note that if any of these validation checks fail, the entire validation
        process fails and the instance is considered invalid.
        <list style="numbers">
             <t>The instance MUST be a signed JWT</t>
            <t>The instance MUST have a <spanx style="verb">typ</spanx> header with the value
                <spanx style="verb">trust-mark+jwt</spanx>
            </t>
            <t>The instance MUST have an <spanx style="verb">alg</spanx> (algorithm) header parameter with a value
                that is an acceptable JWS signing algorithm; it MUST NOT be <spanx style="verb">none</spanx>.
            </t>
            <t>The Entity Identifier of the Entity whose Entity Configuration contains the instance MUST
                match the value of the Claim <spanx style="verb">sub</spanx> in the Trust Mark.</t>
            <t>The current time MUST be after the time represented by the <spanx style="verb">iat</spanx> (issued at) Claim
                (possibly allowing for some small leeway to account for clock skew).</t>
            <t>The current time MUST be before the time represented by the <spanx style="verb">exp</spanx> (expiration) Claim
                (possibly allowing for some small leeway to account for clock skew).</t>
            <t>The instance's signature MUST validate using the Trust Mark issuer's key
                identified by the <spanx style="verb">kid</spanx> value.
            </t>
            <t>If the <spanx style="verb">trust_mark_type</spanx> of the instance appears in the
                <spanx style="verb">trust_mark_owners</spanx> Claim in the Trust Anchor's
                Entity Configuration, then the instance MUST contain a
                <spanx style="verb">delegation</spanx> Claim.</t>
            <t>If there is a <spanx style="verb">delegation</spanx> Claim in the instance, the value of that
            Claim MUST be validated according to <xref target="trust-mark-delegation-validation"/>.</t>
        </list>
      </t>
	  <t>
	    If Trust Marks are issued without an expiration time,
	    it is RECOMMENDED that a mechanism be provided to validate them,
	    such as the Trust Mark Status endpoint
	    and/or the Trust Marked Entities Listing endpoint.
	  </t>
	  <t>
	    As an alternative to the above procedure for validating Trust Marks,
	    implementations MAY use the Trust Mark Status endpoint to verify that the
	    Trust Mark is valid and still active, as described in <xref target="status_endpoint"/>.
	  </t>
        </section>
        <section title="Trust Mark Examples" anchor="trust_example">
          <figure>
            <preamble>
              A non-normative example of a <spanx style="verb">trust_marks</spanx>
	      Claim in the JWT Claims Set for an Entity Configuration is:
            </preamble>
	    <name>
	      Trust Mark in an Entity Configuration JWT Claims Set
	    </name>
            <artwork><![CDATA[
{
  "iss": "https://rp.example.it/spid",
  "sub": "https://rp.example.it/spid",
  "iat": 1516239022,
  "exp": 1516843822,
  "trust_marks": [
    {
     "trust_mark_type": "https://www.spid.gov.it/certification/rp",
     "trust_mark":
       "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoia29
        zR20yd3VaaDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9.
        eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8
        vcnAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYX
        JrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL
        3JwIiwibG9nb191cmkiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMv
        Y3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl
        hLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3ZlcnNpb25lLWNvcnJlbn
        RlLyJ9.
        L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJW
        QBdZpjxnHBBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzS
        an5nOmkxuAtMinU8k_-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0Y
        AvbMlq2pPWO5OWKdZhiFRMSprwh0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2f
        XShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nIkp6W-V4jCBOpxp7Yo8LZ30o_xpE
        OzGTIECGWVR86azOAlwVC8XSiAA"
    }
  ],
  "metadata": {
    "openid_relying_party": {
      "application_type": "web",
      "client_registration_types": ["automatic"],
      "client_name": "https://rp.example.it/spid",
      "contacts": [
        "ops@rp.example.it"
      ]
    }
  }
}
]]></artwork>
          </figure>

          <figure>
            <preamble>
              An example of a decoded Trust Mark payload issued to an RP,
              attesting to conformance to a national
              public service profile:
            </preamble>
	    <name>
	      Trust Mark for a National Profile
	    </name>
            <artwork><![CDATA[
{
  "trust_mark_type": "https://mushrooms.federation.example.com/openid_relying_party/public/",
  "iss": "https://epigeo.tm-issuer.example.it",
  "sub": "https://porcino.example.com/rp",
  "iat": 1579621160,
  "organization_name": "Porcino Mushrooms & Co.",
  "policy_uri": "https://porcino.example.com/privacy_policy",
  "tos_uri": "https://porcino.example.com/info_policy",
  "service_documentation": "https://porcino.example.com/api/v1/get/services",
  "ref": "https://porcino.example.com/documentation/manuale_operativo.pdf"
}

]]></artwork>
          </figure>

          <figure>
            <preamble>
              An example of a decoded Trust Mark payload issued to an RP,
              attesting to its conformance to the rules for
              data management of underage users:
            </preamble>
	    <name>
	      Trust Mark Issued to an RP
	    </name>
            <artwork><![CDATA[
{
  "trust_mark_type": "https://mushrooms.federation.example.com/openid_relying_party/private/under-age",
  "iss": "https://trustissuer.pinarolo.example.it",
  "sub": "https://vavuso.example.com/rp",
  "iat": 1579621160,
  "organization_name": "Pinarolo Suillus luteus",
  "policy_uri": "https://vavuso.example.com/policy",
  "tos_uri": "https://vavuso.example.com/tos"
}

]]></artwork>
          </figure>

          <figure>
            <preamble>
              An example of a decoded Trust Mark payload attesting a stipulation of an
              agreement between two organization's Entities:
	    </preamble>
	    <name>
	      Trust Mark Attesting to an Agreement Between Entities
	    </name>
            <artwork><![CDATA[
{
  "trust_mark_type": "https://mushrooms.federation.example.com/arrosto/agreements",
  "iss": "https://agaricaceae.example.it",
  "sub": "https://coppolino.example.com",
  "iat": 1579621160,
  "logo_uri": "https://coppolino.example.com/sgd-cmyk-150dpi-90mm.svg",
  "organization_type": "public",
  "id_code": "123456",
  "email": "info@coppolino.example.com",
  "organization_name#it": "Mazza di Tamburo",
  "policy_uri#it": "https://coppolino.example.com/privacy_policy",
  "tos_uri#it": "https://coppolino.example.com/info_policy",
  "service_documentation": "https://coppolino.example.com/api/v1/get/services",
  "ref": "https://agaricaceae.example.it/documentation/agaricaceae.pdf"
}
]]></artwork>
          </figure>
          <figure>
            <preamble>
              An example of a decoded Trust Mark payload asserting
              conformance to a security profile:
            </preamble>
            <name>
              Trust Mark Asserting Conformance to a Security Profile
            </name>
            <artwork><![CDATA[
{
  "trust_mark_type": "https://mushrooms.federation.example.com/ottimo/commestibile",
  "iss": "https://cantharellus.cibarius.example.org",
  "sub": "https://gallinaccio.example.com/op",
  "iat": 1579621160,
  "logo_uri": "https://cantharellus.cibarius/static/images/cantharellus-cibarius.svg",
  "ref": "https://cantharellus.cibarius/cantharellus/cibarius"
}
]]></artwork>
          </figure>

          <figure>
            <preamble>An example of a decoded self-signed Trust Mark:</preamble>
            <name>
	      Self-Signed Trust Mark
	    </name>
            <artwork><![CDATA[
{
  "trust_mark_type": "https://mushrooms.federation.example.com/trust-marks/self-signed",
  "iss": "https://amanita.muscaria.example.com",
  "sub": "https://amanita.muscaria.example.com",
  "iat": 1579621160,
  "logo_uri": "https://amanita.muscaria.example.com/img/amanita-mus.svg",
  "ref": "https://amanita.muscaria.example.com/uploads/cookbook.zip"
}
]]></artwork>
          </figure>

          <figure>
            <preamble>
	      An example of a third-party accreditation authority for Trust Marks:
            </preamble>
            <name>
	      Third-Party Accreditation Authority for Trust Marks
            </name>
            <artwork><![CDATA[
{
  "iss": "https://swamid.se",
  "sub": "https://umu.se/op",
  "iat": 1577833200,
  "exp": 1609369200,
  "trust_mark_type": "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf"
}
]]></artwork>
          </figure>
        </section>
        <section title="Trust Mark Delegation Example" anchor="trust_delegation_example">
          <figure>
            <preamble>
              A non-normative example of a <spanx style="verb">trust_marks</spanx>
	          Claim in the JWT Claims Set for an Entity Configuration in which the
              Trust Mark is issued by an Entity that issues Trust Marks on behalf of
              another Entity.
              The fact that a Trust Mark is issued by a Trust Mark Issuer that is not
              the owner of the Trust Mark is expressed by including a
              <spanx style="verb">delegation</spanx> Claim
              in the Trust Mark, whose value is a signed JWT.
            </preamble>
	    <name>
	      Example JWT Claims Set of a Trust Mark using Delegation
	    </name>
            <artwork><![CDATA[
{
  "delegation":
    "eyJ0eXAiOiJ0cnVzdC1tYXJrLWRlbGVnYXRpb24rand0IiwiYWxnIjoiUl
    MyNTYiLCJraWQiOiJrb3NHbTJ3dVpoOURHbU54QXRrdU80MHBQanBMMy1qQ
    2YxTi1xUE8tWWVVIn0.
    eyJzdWIiOiJodHRwczovL3RtaS5leGFtcGxlLm9yZyIsInRydXN0X21hcmt
    fdHlwZSI6Imh0dHBzOi8vcmVmZWRzLm9yZy9zaXJ0ZmkiLCJpc3MiOiJodH
    RwczovL3RtX293bmVyLmV4YW1wbGUub3JnIiwiaWF0IjoxNzI1MTc2MzAyfQ.
    ao0rWGpVjEgpNyFxsKawps8q71eYnp78TzRdY4P52
    CT8QX6etXt-2L2Z1Vw5A6jx2mhjpPwWi_sOxfiOSA5TugJfN0Gbwj7teTzM
    0IMciuasCWgnLrKyLZjS147ZE50I9e9P8Ot8UQwhmXcLiuwsbDxSdqM4pVp
    75lfWnmzPH0L2pDZG5COFgIgSOAlK3TVMBOR8fziF-VmWNPzAfB0lSc-hjH
    -7q66GyT43o3Exnm6DsoLxyB8bxG99BQltLxURDT90CzM6szGcF3OG64Rbe
    0I4lT_LAOfvhlrRbT56eK4sJNCsbVbGnDBfFmyfB_HIeBMGP0L7T5JPMOUU
    9bjIlA",
  "iat": 1725176302,
  "trust_mark_type": "https://refeds.org/sirtfi",
  "sub": "https://entity.example.org",
  "exp": 1727768302,
  "iss": "https://tmi.example.org"
}
]]></artwork>
          </figure>
          <figure>
            <preamble>
              JWS Header Parameters for the Trust Mark delegation JWT in
              the "delegation" Claim above:
            </preamble>
	    <name>
	      Trust Mark Delegation JWT JWS Header Parameters
	    </name>
            <artwork><![CDATA[
{
  "typ": "trust-mark-delegation+jwt",
  "alg": "RS256",
  "kid": "kosGm2wuZh9DGmNxAtkuO40pPjpL3-jCf1N-qPO-YeU"
}
            ]]></artwork>
          </figure>
	  <figure>
	    <preamble>
	      JWT Claims Set of the Trust Mark delegation JWT in the "delegation" Claim above:
	    </preamble>
	    <name>
	      Trust Mark Delegation JWT Claim Set
	    </name>
            <artwork><![CDATA[
{
  "sub": "https://tmi.example.org",
  "trust_mark_type": "https://refeds.org/sirtfi",
  "iss": "https://tm_owner.example.org",
  "iat": 1725176302
}
]]></artwork>

	  </figure>
        </section>
      </section>
    <section title="Federation Endpoints" anchor="federation_endpoints">
      <t>
        The federation endpoints of an Entity can be found in the
        configuration response as described in
        <xref target="federation_configuration"/>
        or by other means.
      </t>
      <t>
	For all federation endpoints, additional request parameters
	beyond those initially specified MAY be defined and used.
	If they are not understood, they MUST be ignored.
      </t>

      <section title="Fetching a Subordinate Statement" anchor="fetch_endpoint">
        <t>
	  The fetch endpoint is used to collect Subordinate Statements
          one-by-one when assembling Trust Chains.
	  An Entity with Subordinates MUST expose a fetch endpoint.
	  An Entity MUST publish Subordinate Statements about its
	  Immediate Subordinates via its fetch endpoint.
	</t>
	<t>
	  The fetch endpoint location is published in
	  the Entity's <spanx style="verb">federation_entity</spanx> metadata
	  in the <spanx style="verb">federation_fetch_endpoint</spanx> parameter
	  defined in <xref target="federation_entity"/>.
	  Since this endpoint is used when building and validating Trust Chains,
	  its location MUST be available before metadata and metadata policies
	  from Superiors can be applied.
	  Therefore, this endpoint MUST be published directly in Entity Configuration
	  metadata and not in Subordinate Statements.
        </t>
        <t>
          To fetch a Subordinate Statement, one needs to know the
          identifier of the Entity to ask (the issuer), the fetch
          endpoint of that Entity, and the Entity Identifier of the
          subject of the Subordinate Statement.
	  The issuer is normally the Immediate Superior of the
          subject of the Subordinate Statement.
        </t>

        <section title="Fetch Subordinate Statement Request"
                 anchor="fetch_statement">
          <t>
	    When client authentication is not used,
            the request MUST be an HTTP request using the GET method
            to a fetch endpoint with the
            following query parameter, encoded in
            <spanx style="verb">application/x-www-form-urlencoded</spanx> format.
	    The request is made to the fetch endpoint of the specified issuer.
          </t>
          <t>
            <list style="hanging">
              <t hangText="sub">
                <vspace/>
                REQUIRED. The Entity Identifier of the subject
                for which the Subordinate Statement is being requested.
              </t>
            </list>
          </t>
	  <t>
	    When client authentication is used,
	    the request MUST be an HTTP request using the POST method,
	    with the parameters passed in the POST body.
	  </t>
          <figure>
            <preamble>
              The following is a non-normative example of an HTTP GET request for
	      a Subordinate Statement from edugain.org about https://sunet.se:
            </preamble>
            <name>
	      API Request for a Subordinate Statement
            </name>
            <artwork><![CDATA[
GET /federation_fetch_endpoint?
sub=https%3A%2F%2Fsunet%2Ese HTTP/1.1
Host: edugain.org
]]></artwork>
          </figure>
        </section>

        <section anchor="fetch-response" title="Fetch Subordinate Statement Response">
          <t>
            A successful response MUST use the HTTP status code 200
            with the content type
            <spanx style="verb">application/entity-statement+jwt</spanx>,
            to make it clear that the response contains an Entity Statement.
            If it is an error response, it will be a JSON object and the
            content type MUST be
            <spanx style="verb">application/json</spanx>.
	    If the fetch endpoint cannot provide data for the requested
	    <spanx style="verb">sub</spanx> parameter, returning the
	    <spanx style="verb">not_found</spanx> error code is RECOMMENDED.
	    If the <spanx style="verb">sub</spanx> parameter references the Entity
	    Identifier of the Issuing Entity, returning the
	    <spanx style="verb">invalid_request</spanx> error code is RECOMMENDED.
            See more about error responses in <xref target="error_response"/>.
          </t>
          <figure>
            <preamble>
              The following is a non-normative example of the JWT Claims Set for a fetch response:
            </preamble>
            <name>
	      Fetch Response JWT Claims Set
            </name>
            <artwork><![CDATA[
{
  "iss": "https://edugain.org",
  "sub": "https://sunet.se",
  "exp": 1568397247,
  "iat": 1568310847,
  "source_endpoint": "https://edugain.org/federation_fetch_endpoint",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
        "kty": "RSA",
        "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
      }
    ]
  },
  "metadata":{
    "federation_entity": {
        "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"
        ]
      }
    }
  }
}
]]></artwork>
          </figure>
        </section>
      </section>

      <section title="Subordinate Listing" anchor="entity_listing">
        <t>
	  The listing endpoint is exposed by Federation Entities
	  acting as a Trust Anchor, Intermediate, or Trust Mark Issuer.
	  The endpoint lists the Immediate Subordinates about which
          the Trust Anchor, Intermediate, or Trust Mark Issuer
	  issues Entity Statements.
        </t>
        <t>
	  As a Trust Mark Issuer,
          the endpoint MAY list the Immediate Subordinates for which Trust Marks
          have been issued and are still valid, if the issuer
          exposing this endpoint supports Trust Mark filtering, as
          defined below.
        </t>
        <t>
          In both cases, the list contained in the result
          MAY be a very large list.
        </t>
	<t>
	  The list endpoint location is published in
	  the Entity's <spanx style="verb">federation_entity</spanx> metadata
	  in the <spanx style="verb">federation_list_endpoint</spanx> parameter
	  defined in <xref target="federation_entity"/>.
	  This endpoint MUST be published directly in Entity Configuration
	  metadata and not in Subordinate Statements.
	</t>

        <t>
	  <figure>
	    <preamble>
	      The following example shows a tree of Entities belonging to the
          same federation including the Trust Anchor, Intermediate Entities,
          and Leaf Entities, discovered and collected through the Subordinate
          listing endpoints:
	    </preamble>
            <name>
	      Tree of Entities in a Federation Collected through
          Subordinate Listing Endpoints
            </name>
<!--
  NOTE: this figure was made with ASCIIflow and its editable sources
  are available at the following link:
  https://asciiflow.com/#/share/eJyrVspLzE1VslLKySwuycxLV8jITC1KLErOqFTSUcpJrEwtAspVxyhVxChZWRpb6sQoVQJZRuaGQFZJakUJkBOjpIAdPJqyhyooJiYPtw0gKiQoNDhEwdHP2cM%2FCC6BVxeV3UWGZoXg0qT8opTMvMSS1GIFWOhT5AQaeRPDVHyWYkYOTslRY%2FAa82hKz6MpDeho2h4sgiA0AaGZAJpGSqyT6gqww5vAWn1SE9OgZjShedvTL8Q1yNfVxdMxxBUtPLDpBhs6BYeVWNEM5NAgXhsuhHAcaa7AWgYRXxY04dJPklvwhwBON%2BJIljRWS9XkizU%2F4kx7mO6gVsJBM7kJZ3xjUz0FFonIiKQohucHtFhBjgwsEUOWatzRtgsjbpDFsMcgwViHWokoLpCMhwsiDEMWwutaLCmJsCpC8bAnRqlWqRYAUXBqQQ%3D%3D)
-->
            <artwork><![CDATA[
                       +----------------------+
                       |    Trust Anchor      |
                       +----------------------+
       +---------------+ Subordinate Listing  +--------------+
       |               +----------+-----------+              |
       |                          |                          |
       |                          |                          |
       |                          |                          |
       |                          |                          |
       |                          |                          |
+------v-------+       +----------v-----------+       +------v-------+
|     Leaf     |       |     Intermediate     |       |     Leaf     |
+--------------+       +----------------------+       +--------------+
                  +----+ Subordinate Listing  |
                  |    +------------+---------+
                  |                 |
                  |                 |
                  |                 |
       +----------v-----------+     |
       |     Intermediate     |     |
       +----------------------+     |
       | Subordinate Listing  |     |
       +-+---------+----------+     |
         |         |                |
         |         |                |
 +-------v--+     +v--------+    +--v------+
 |  Leaf    |     |  Leaf   |    |  Leaf   |
 +----------+     +---------+    +---------+
]]></artwork>
          </figure>

        </t>

        <section anchor="subordinate-request" title="Subordinate Listing Request">
          <t>
	    When client authentication is not used,
            the request MUST be an HTTP request using the GET method
            to a list endpoint with the
            following query parameters, encoded in
            <spanx style="verb">application/x-www-form-urlencoded</spanx> format.
          </t>
          <t>
            <list style="hanging">
              <t hangText="entity_type">
                <vspace/>
                OPTIONAL. The value of this parameter is an Entity Type Identifier.
                If the responder knows the Entity Types of its Immediate Subordinates, the result MUST be
                filtered to include only those that include the specified Entity Type. When
                multiple <spanx style="verb">entity_type</spanx>
                parameters are present, for example
                <spanx style="verb">entity_type=openid_provider&amp;entity_type=openid_relying_party</spanx>,
                the result MUST be filtered to include all specified Entity Types.

                If the responder does not support this feature, it MUST
                use the HTTP status code 400 and the content type
                <spanx style="verb">application/json</spanx>, with
                the error code
                <spanx style="verb">unsupported_parameter</spanx>.
              </t>
              <t hangText="trust_marked">
		<vspace/>
                OPTIONAL. Boolean.

                If the parameter
                <spanx style="verb">trust_marked</spanx> is present and
                set to <spanx style="verb">true</spanx>,
                the result contains only the Immediate Subordinates for which
                at least one Trust Mark has been issued and is still valid.

                If the responder does not support this feature, it MUST
                use the HTTP status code 400 and set the content type to
                <spanx style="verb">application/json</spanx>, with
                the error code
                <spanx style="verb">unsupported_parameter</spanx>.
	      </t>
              <t hangText="trust_mark_type">
                <vspace/>
                OPTIONAL. The value of this parameter is the identifier for the type of the Trust Mark.
		If the responder has issued Trust Marks with the
                specified Trust Mark type identifier,
                the list in the response is filtered to include only
                the Immediate Subordinates for which that Trust Mark type identifier has been
                issued and is still valid.
                If the responder does not support this feature, it MUST
                use the HTTP status code 400 and set the content type to
                <spanx style="verb">application/json</spanx>, with
                the error code
                <spanx style="verb">unsupported_parameter</spanx>.
              </t>
              <t hangText="intermediate">
                <vspace/>
                OPTIONAL. Boolean. If the parameter
                <spanx style="verb">intermediate</spanx> is present and set to
                <spanx style="verb">true</spanx>, then if the responder knows
                whether its Immediate Subordinates are Intermediates or not,
                the result MUST be filtered accordingly.
                If the responder does not support this feature, it MUST
                use the HTTP status code 400 and the content type
                <spanx style="verb">application/json</spanx>, with
                the error code
                <spanx style="verb">unsupported_parameter</spanx>.
              </t>
            </list>
          </t>
	  <t>
	    When client authentication is used,
	    the request MUST be an HTTP request using the POST method,
	    with the parameters passed in the POST body.
	  </t>
          <figure>
            <preamble>
              The following is a non-normative example of an HTTP GET
              request for a list of Immediate Subordinates:
            </preamble>
            <name>
              Subordinate Listing Request
            </name>
            <artwork><![CDATA[
GET /list HTTP/1.1
Host: sunet.se
]]></artwork>
          </figure>
        </section>

        <section anchor="subordinate-response" title="Subordinate Listing Response">
          <t>
            A successful response MUST use the HTTP status code 200
            with the content type <spanx style="verb">application/json</spanx>,
            containing a JSON array with the known Entity Identifiers.
          </t>

          <t>
            An error response
            is as defined in
            <xref target="error_response"/>.
          </t>

          <figure>
            <preamble>
              The following is a non-normative example of a response containing
              the Immediate Subordinate Entities:
            </preamble>
            <name>
              Subordinate Listing Response
            </name>
            <artwork><![CDATA[
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"
]
]]></artwork>
          </figure>
        </section>
      </section>

      <section title="Resolve Entity" anchor="resolve">
        <t>
          An Entity MAY use a resolve endpoint to fetch
          Resolved Metadata, the Trust Chain used, and Trust Marks for an Entity.
          The resolver fetches the subject's
          Entity Configuration, assembles a Trust Chain that starts
          with the subject's Entity Configuration and ends with the specified
          Trust Anchor's Entity Configuration, verifies the Trust Chain, and then applies all the
          policies present in the Trust Chain to the subject's
          metadata.
	</t>
	<t>
	  The resolver MUST verify that all present
          Trust Marks with identifiers recognized within
          the Federation are active.
          The response set MUST include only verified Trust Marks.
        </t>
	<t>
	  The resolve endpoint location is published in
	  the Entity's <spanx style="verb">federation_entity</spanx> metadata
	  in the <spanx style="verb">federation_resolve_endpoint</spanx> parameter
	  defined in <xref target="federation_entity"/>.
	</t>

        <section anchor="resolve-request" title="Resolve Request">
          <t>
	    When client authentication is not used,
            the request MUST be an HTTP request using the GET method
            to a resolve endpoint with the
            following query parameters, encoded in
            <spanx style="verb">application/x-www-form-urlencoded</spanx> format.
          </t>
          <t>
            <list style="hanging">
              <t hangText="sub">
                <vspace/>
                REQUIRED. The Entity Identifier of the
                Entity whose resolved data is requested.
              </t>
              <t hangText="trust_anchor">
                <vspace/>
                REQUIRED. The Trust Anchor that the resolve endpoint
                MUST use when resolving the metadata.
		The value is an Entity Identifier.
		<vspace blankLine="1"/>
		The <spanx style="verb">trust_anchor</spanx> request parameter
		MAY occur multiple times, in which case,
		the resolver MAY return a successful resolve response
		using any of the Trust Anchor values provided.
              </t>
              <t hangText="entity_type">
                <vspace/>
                OPTIONAL. A specific Entity Type to resolve.
                Its value is an Entity Type Identifier, as specified in
                <xref target="entity_types"/>.
                If this parameter is not present, then all Entity Types are returned.
		<vspace blankLine="1"/>
		The <spanx style="verb">entity_type</spanx> request parameter
		MAY occur multiple times, in which case, data for each Entity Type
		whose Entity Type Identifier is in an <spanx style="verb">entity_type</spanx>
		parameter value is returned.
              </t>
            </list>
          </t>
	  <t>
	    When client authentication is used,
	    the request MUST be an HTTP request using the POST method,
	    with the parameters passed in the POST body.
	  </t>
          <figure>
            <preamble>
              The following is a non-normative example of a Resolve Request:
            </preamble>
            <name>
              Resolve Request
            </name>
            <artwork><![CDATA[
GET /resolve?
sub=https%3A%2F%2Fop.example.it%2Fspid&
entity_type=openid_provider&
trust_anchor=https%3A%2F%2Fswamid.se HTTP/1.1
Host: sunet.se
]]></artwork>
          </figure>
        </section>

        <section anchor="resolve-response" title="Resolve Response">
          <t>
            A successful response MUST use the HTTP status code 200
            with the content type
            <spanx style="verb">application/resolve-response+jwt</spanx>,
            containing Resolved Metadata and
            verified Trust Marks.
          </t>
          <t>
            The response is a signed JWT that is explicitly typed by setting the
            <spanx style="verb">typ</spanx> header parameter to
            <spanx style="verb">resolve-response+jwt</spanx> to prevent
            cross-JWT confusion, per Section 3.11 of <xref target="RFC8725"/>.
	    Resolve responses without a <spanx style="verb">typ</spanx> header parameter
	    or with a different <spanx style="verb">typ</spanx> value MUST be rejected.
	    It is signed with a Federation Entity Key.
          </t>
	  <t>
	    The resolve response JWT MUST include the
	    <spanx style="verb">kid</spanx> (Key ID) header parameter
	    with its value being the Key ID of the signing key used.
	  </t>
          <t>
            The resolve response JWT MUST return the Trust Chain
	    from the subject to the Trust Anchor
	    in its <spanx style="verb">trust_chain</spanx> parameter.
	  </t>
          <t>
            The resolve response MAY also return the Trust Chain
            from its issuer to the Trust Anchor
            in the <spanx style="verb">trust_chain</spanx> JWS header parameter,
            as specified in <xref target="trust_chain_head_param"/>.
            When this is present, the Trust Anchor in the Trust Chain
            MUST match the Trust Anchor requested in the
            related request in the <spanx style="verb">trust_anchor</spanx> parameter.
	  </t>
	  <t>
            An issuer that provides its Trust Chain within the resolve
            response makes it evident that it is part of the same
            federation as the subject of the response. Thus,
            when the Trust Chains of both the issuer and the subject
            are available and the Federation Historical Keys endpoint is
            provided by the Trust Anchor, the resolve response becomes a long-lived
            attestation; it can be always verified, even
            when the Federation Keys change in the future.
          </t>
	  <t>
            The response SHOULD contain the
            <spanx style="verb">aud</spanx> Claim only
            if the requesting party is authenticated
	    as described in <xref target="ClientAuthentication"/>,
	    in which case, the value MUST be the Entity Identifier
	    of the requesting party
	    and MUST NOT include any other values.
          </t>
          <t>
	    The Claims in a resolve response are:
	  </t>
          <t>
            <list style="hanging">
              <t hangText="iss">
                <vspace/>
                REQUIRED. String.
                Entity Identifier
                of the issuer of the resolve response.
              </t>
              <t hangText="sub">
                <vspace/>
                REQUIRED. String.
                Entity Identifier
                of the subject of the resolve response.
              </t>
              <t hangText="iat">
                <vspace/>
                REQUIRED. Number. Time when this resolution was issued.
                This is expressed as Seconds Since the Epoch, per
                <xref target="RFC7519"/>.
              </t>
              <t hangText="exp">
                <vspace/>
                REQUIRED. Number. Time when this resolution is no longer valid.
                This is expressed as Seconds Since the Epoch, per <xref target="RFC7519"/>.
                It MUST be the minimum of the <spanx style="verb">exp</spanx> value of
                the Trust Chain from which the resolve response was derived,
                as well as any Trust Mark included in the response.
              </t>
              <t hangText="metadata">
                <vspace/>
                REQUIRED. JSON object containing the subject's Resolved Metadata,
                according to the requested <spanx style="verb">type</spanx>
                and expressed in the <spanx style="verb">metadata</spanx> format
                defined in <xref target="common-claims"/>.
              </t>
              <t hangText="trust_chain">
                <vspace/>
                REQUIRED. Array containing the sequence of Entity Statements
                that compose the Trust Chain, starting with the subject and
                ending with the selected Trust Anchor.
              </t>
              <t hangText="trust_marks">
                <vspace/>
                OPTIONAL. Array of objects, each representing a Trust Mark,
                as defined in <xref target="ec-specific"/>.
		Only valid Trust Marks that have been issued by Trust Mark
                issuers trusted by the Trust Anchor to issue such Trust Marks
		MAY appear in the resolver response.
              </t>
            </list>
          </t>

          <t>
            Additional Claims MAY be defined and used in conjunction with the Claims above.
          </t>
          <t>
            An error response
            is as defined in
            <xref target="error_response"/>.
          </t>

          <figure>
            <preamble>
              The following is a non-normative example of the JWT Claims Set for a resolve response:
            </preamble>
            <name>
              Resolve Response JWT Claims Set
            </name>
            <artwork><![CDATA[
{
  "iss": "https://resolver.spid.gov.it",
  "sub": "https://op.example.it/spid",
  "iat": 1516239022,
  "exp": 1516843822,
  "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",
        "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": [
    {"trust_mark_type": "https://www.spid.gov.it/certification/op/",
     "trust_mark":
       "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiOH
        hzdUtXaVZmd1NnSG9mMVRlNE9VZGN5NHE3ZEpyS2ZGUmxPNXhoSElhMCJ9.
        eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi
        8vb3AuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9t
        YXJrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW
        9uL29wLyIsImxvZ29fdXJpIjoiaHR0cHM6Ly93d3cuYWdpZC5nb3YuaXQvdGhl
        bWVzL2N1c3RvbS9hZ2lkL2xvZ28uc3ZnIiwicmVmIjoiaHR0cHM6Ly9kb2NzLm
        l0YWxpYS5pdC9pdGFsaWEvc3BpZC9zcGlkLXJlZ29sZS10ZWNuaWNoZS1vaWRj
        L2l0L3N0YWJpbGUvaW5kZXguaHRtbCJ9.
        xyz-PDQ_..."
    }
  ],
  "trust_chain" : [
    "eyJhbGciOiJSUzI1NiIsImtpZCI6Ims1NEhRdERpYnlHY3M5WldWTWZ2aUhm ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ..."
  ]
}
]]></artwork>
          </figure>
        </section>

        <section anchor="trust-considerations" title="Trust Considerations">
          <t>
            The basic assumption of this specification is that an Entity
            should have direct trust in no party except the Trust Anchor
            and its own capabilities.
            However, Entities MAY establish a kind of
            transitive trust in other Entities. For example, the
            Trust Anchor states who its Immediate Subordinates are,
            and Entities MAY choose to trust them.
            If a party uses the resolve service of another Entity
            to obtain federation data, it is trusting
            the resolver to perform validation of the cryptographically
            protected metadata correctly and to provide it with authentic results.
          </t>
        </section>
      </section>

      <section title="Trust Mark Status" anchor="status_endpoint">
        <t>
          This enables determining whether a Trust Mark Instance that has been issued to
          an Entity is still active. The query MUST be sent to the Trust Mark Issuer.
        </t>
	<t>
	  The Trust Mark Status endpoint location is published in
	  the Entity's <spanx style="verb">federation_entity</spanx> metadata
	  in the <spanx style="verb">federation_trust_mark_status_endpoint</spanx> parameter
	  defined in <xref target="federation_entity"/>.
	  This endpoint MUST be published directly in Entity Configuration
	  metadata and not in Subordinate Statements.
	</t>

        <section anchor="tm-status-request" title="Trust Mark Status Request">
          <t>
            The request MUST be an HTTP request using the POST method
            to a Trust Mark Status endpoint
            with the following parameter, encoded in
            <spanx style="verb">application/x-www-form-urlencoded</spanx> format.
          </t>
          <t>
            <list style="hanging">
              <t hangText="trust_mark">
                <vspace/>
                REQUIRED. The Trust Mark to be validated.
              </t>
            </list>
          </t>
	  <t>
	    When client authentication is used,
	    the request MUST be an HTTP request using the POST method,
	    with the parameters passed in the POST body.
	  </t>
            <figure>
              <preamble>
                The following is a non-normative example of a Trust Mark Status request:
              </preamble>
	      <name>
		Trust Mark Status Request
	      </name>
              <artwork><![CDATA[
POST /federation_trust_mark_status_endpoint HTTP/1.1
Host: op.example.org
Content-Type: application/x-www-form-urlencoded

trust_mark=eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6 ...
]]></artwork>
            </figure>
        </section>

        <section anchor="tm-status-response" title="Trust Mark Status Response">
          <t>
            A successful response MUST use the HTTP status code 200
            with the content type
            <spanx style="verb">application/trust-mark-status-response+jwt</spanx>,
	    containing a signed JWT that is a Trust Mark Status Response.
	  </t>
	  <t>
            The Trust Mark Status Response is a signed JWT that is explicitly typed by setting the
            <spanx style="verb">typ</spanx> header parameter to
            <spanx style="verb">trust-mark-status-response+jwt</spanx> to prevent
            cross-JWT confusion, per Section 3.11 of <xref target="RFC8725"/>.
	    Trust Mark Status Responses without a <spanx style="verb">typ</spanx> header parameter
	    or with a different <spanx style="verb">typ</spanx> value MUST be rejected.
	    It is signed with a Federation Entity Key.
          </t>
	  <t>
	    The Trust Mark Status Response JWT MUST include the
	    <spanx style="verb">kid</spanx> (Key ID) header parameter
	    with its value being the Key ID of the signing key used.
	  </t>
          <t>
	    The JWT Claims Set of the Trust Mark Status JWT
	    is a JSON object containing the following Claims:
          </t>
          <t>
            <list style="hanging">
              <t hangText="iss">
                <vspace/>
                REQUIRED. String.
                Entity Identifier of the issuer of the Trust Mark Status JWT.
              </t>
              <t hangText="iat">
                <vspace/>
                REQUIRED. Number. Time when this Trust Mark Status JWT was issued.
                This is expressed as Seconds Since the Epoch, per
                <xref target="RFC7519"/>.
              </t>
              <t hangText="trust_mark">
                <vspace/>
                REQUIRED. String.
                The Trust Mark JWT that this status response is about.
              </t>
              <t hangText="status">
                <vspace/>
                REQUIRED. Case-sensitive string value indicating the status of the Trust Mark.
		Values defined by this specification are:

		<list style="hanging">
		  <t hangText="active">
		    <vspace/>
		    The Trust Mark is active
		  </t>
		  <t hangText="expired">
		    <vspace/>
		    The Trust Mark has expired
		  </t>
		  <t hangText="revoked">
		    <vspace/>
		    The Trust Mark was revoked
		  </t>
		  <t hangText="invalid">
		    <vspace/>
		    Signature validation failed or another error was detected
		  </t>
		</list>
	      </t>
	      <t>
		Additional status values MAY be defined and used
		in addition to those above.
	      </t>
	    </list>
	  </t>
	  <t>
	    Additional Trust Mark Status JWT Claims MAY be defined and used
	    in addition to those listed above.
	  </t>

          <t>
            <figure>
              <preamble>
                The following is a non-normative example of the JWT Claims Set for
		a response with the status <spanx style="verb">active</spanx>:
              </preamble>
	      <name>
		Active Trust Mark Status Response JWT Claims Set
	      </name>
              <artwork><![CDATA[
{
  "iss": "https://www.agid.gov.it",
  "trust_mark": "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2
    lkIjoia29zR20yd3VaaDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9.
    eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8
    vcnAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYX
    JrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL
    3JwIiwibG9nb191cmkiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMv
    Y3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl
    hLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3ZlcnNpb25lLWNvcnJlbn
    RlLyJ9.
    L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJW
    QBdZpjxnHBBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzS
    an5nOmkxuAtMinU8k_-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0Y
    AvbMlq2pPWO5OWKdZhiFRMSprwh0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2f
    XShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nIkp6W-V4jCBOpxp7Yo8LZ30o_xpE
    OzGTIECGWVR86azOAlwVC8XSiAA",
  "iat": 1759897995,
  "status": "active"
}
]]></artwork>
            </figure>
          </t>

          <t>
            <figure>
              <preamble>
                The following is a non-normative example of the JWT Claims Set for
		a response with the status <spanx style="verb">revoked</spanx>:
              </preamble>
	      <name>
		Revoked Trust Mark Status Response JWT Claims Set
	      </name>
              <artwork><![CDATA[
{
  "iss": "https://www.agid.gov.it",
  "trust_mark": "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2
    lkIjoia29zR20yd3VaaDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9.
    eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8
    vcnAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYX
    JrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL
    3JwIiwibG9nb191cmkiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMv
    Y3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl
    hLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3ZlcnNpb25lLWNvcnJlbn
    RlLyJ9.
    L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJW
    QBdZpjxnHBBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzS
    an5nOmkxuAtMinU8k_-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0Y
    AvbMlq2pPWO5OWKdZhiFRMSprwh0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2f
    XShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nIkp6W-V4jCBOpxp7Yo8LZ30o_xpE
    OzGTIECGWVR86azOAlwVC8XSiAA",
  "iat": 1759898057,
  "status": "revoked"
}
]]></artwork>
            </figure>
          </t>

          <t>
            An error response to a Trust Mark Status request
            is as defined in
            <xref target="error_response"/>.
          </t>
	  <t>
	    If the Trust Mark Issuer receives a request about the status of an unknown Trust Mark, something it did not issue or is not aware of,
	    it MUST respond with an HTTP status code 404 (Not found).
	  </t>
        </section>
      </section>

     <section title="Trust Marked Entities Listing" anchor="tm_listing">
        <t>
	  The Trust Marked Entities Listing endpoint is exposed by
          Trust Mark Issuers
          and lists all the Entities for which Trust Marks
          have been issued and are still valid.
        </t>
	<t>
	  The Trust Marked Entities Listing endpoint location is published in
	  the Entity's <spanx style="verb">federation_entity</spanx> metadata
	  in the <spanx style="verb">federation_trust_mark_list_endpoint</spanx> parameter
	  defined in <xref target="federation_entity"/>.
	</t>

        <section anchor="tm-listing-request" title="Trust Marked Entities Listing Request">
          <t>
	    When client authentication is not used,
            the request MUST be an HTTP request using the GET method
            to a list endpoint with the
            following query parameters, encoded in
            <spanx style="verb">application/x-www-form-urlencoded</spanx> format.
          </t>
          <t>
            <list style="hanging">
              <t hangText="trust_mark_type">
                <vspace/>
                REQUIRED. Identifier for the type of the Trust Mark.
                If the responder has issued Trust Marks with the
                specified Trust Mark type identifier,
                the list in the response is filtered to include only
                the Entities for which that Trust Mark type identifier has been
                issued and is still valid.
              </t>
              <t hangText="sub">
                <vspace/>
                OPTIONAL. The Entity Identifier of the Entity to which the Trust Mark
                was issued. The list obtained in the response MUST be filtered to only
                the Entity matching this value.
              </t>
            </list>
          </t>
	  <t>
	    When client authentication is used,
	    the request MUST be an HTTP request using the POST method,
	    with the parameters passed in the POST body.
	  </t>
          <figure>
            <preamble>
              The following is a non-normative example of an HTTP GET
              request for a list of Trust Marked Entities:
            </preamble>
            <name>
              Trust Marked Entities Listing Request
            </name>
            <artwork><![CDATA[
GET /trust_marked_list?trust_mark_type=https%3A%2F%2Ffederation.example.org%2Fopenid_relying_party%2Fprivate%2Funder-age HTTP/1.1
Host: trust-mark-issuer.example.org
]]></artwork>
          </figure>
        </section>

        <section anchor="tm-listing-response" title="Trust Marked Entities Listing Response">
          <t>
            A successful response MUST use the HTTP status code 200
            with the content type <spanx style="verb">application/json</spanx>,
            containing a JSON array with Entity Identifiers.
          </t>

          <t>
            An error response
            is as defined in
            <xref target="error_response"/>.
          </t>

          <figure>
            <preamble>
              The following is a non-normative example of a response, containing
              the Trust Marked Entities:
            </preamble>
            <name>
              Trust Marked Entities Listing Response
            </name>
            <artwork><![CDATA[
200 OK
Content-Type: application/json

[
  "https://blackboard.ntnu.no/openid/rp",
  "https://that-rp.example.org"
]
]]></artwork>
          </figure>
        </section>
      </section>

     <section title="Trust Mark Endpoint" anchor="tm_endpoint">
        <t>
          The Trust Mark endpoint is
          exposed by a Trust Mark Issuer
          to provide Trust Marks to subjects.
        </t>
	<t>
	  The Trust Mark endpoint location is published in
	  the Entity's <spanx style="verb">federation_entity</spanx> metadata
	  in the <spanx style="verb">federation_trust_mark_endpoint</spanx> parameter
	  defined in <xref target="federation_entity"/>.
	</t>

        <section anchor="tm-request" title="Trust Mark Request">
          <t>
	    When client authentication is not used,
            the request MUST be an HTTP request using the GET method
            with the following query parameters, encoded in
            <spanx style="verb">application/x-www-form-urlencoded</spanx> format.
          </t>
          <t>
            <list style="hanging">
              <t hangText="trust_mark_type">
                <vspace/>
                REQUIRED. Identifier for the type of the Trust Mark.
              </t>
              <t hangText="sub">
                <vspace/>
                REQUIRED. The Entity Identifier of the Entity to which the
                Trust Mark is issued.
              </t>
            </list>
          </t>
	  <t>
	    When client authentication is used,
	    the request MUST be an HTTP request using the POST method,
	    with the parameters passed in the POST body.
        The Trust Mark endpoint MAY choose to allow authenticated requests from
        clients that are not the Trust Mark subject, as indicated by the
        <spanx style="verb">sub</spanx> parameter. An example use case is to
        let a Federation Entity retrieve the Trust Mark for another Entity.
	  </t>
          <figure>
            <preamble>
              The following is a non-normative example of an HTTP
              request for a Trust Mark with a specific Trust Mark type identifier and subject:
            </preamble>
            <name>
              Trust Mark Request
            </name>
            <artwork><![CDATA[
GET /trust_mark?trust_mark_type=https%3A%2F%2Fwww.spid.gov.it%2Fcertification%2Frp&sub=https%3A%2F%2Frp.example.it%2Fspid HTTP/1.1
Host: tuber.cert.example.org
]]></artwork>
          </figure>
        </section>

        <section anchor="tm-response" title="Trust Mark Response">
          <t>
            A successful response MUST use the HTTP status code 200
            with the content type
            <spanx style="verb">application/trust-mark+jwt</spanx>,
            containing the Trust Mark.
          </t>

          <t>
            If the specified Entity does not have
            the specified Trust Mark, the
            response is an error response and
            MUST use the HTTP status code 404.
          </t>

          <figure>
            <preamble>
              The following is a non-normative example of a response, containing
              the Trust Mark for the specified Entity
	      (with line wraps within values for display purposes only):
            </preamble>
            <name>
              Trust Mark Response
            </name>
            <artwork><![CDATA[
200 OK
Content-Type: application/trust-mark+jwt

eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoia29zR20yd3Va
aDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9.
eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8vcnAuZXhh
bXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYXJrX3R5cGUiOiJodHRw
czovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL3JwIiwibG9nb191cmkiOiJodHRw
czovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMvY3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYi
OiJodHRwczovL2RvY3MuaXRhbGlhLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3Zl
cnNpb25lLWNvcnJlbnRlLyJ9.
L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJWQBdZpjxnH
BBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzSan5nOmkxuAtMinU8k_
-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0YAvbMlq2pPWO5OWKdZhiFRMSprwh
0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2fXShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nI
kp6W-V4jCBOpxp7Yo8LZ30o_xpEOzGTIECGWVR86azOAlwVC8XSiAA
]]></artwork>
          </figure>
        </section>
      </section>

      <section anchor="historical_keys" title="Federation Historical Keys Endpoint">
        <t>
          Each Federation Entity MAY publish its previously used
	  Federation Entity Keys at the historical keys endpoint
	  defined in <xref target="federation_entity"/>.
          The purpose of this endpoint is to provide
          the list of keys previously used by the Federation Entity
          to provide non-repudiation of statements signed by
          it after key rotation. This endpoint also discloses the
          reason for the retraction of the keys and whether they were
          expired or revoked, including the reason for the revocation.
        </t>
        <t>
          Note that an expired key can be later additionally marked as
          revoked, to indicate a key compromise event discovered
          after the expiration of the key.
        </t>
        <t>
          The publishing of the historical keys guarantees that Trust Chains
          will remain verifiable and usable as inputs to trust decisions
          after the key expiration, unless the key becomes revoked
          for a security reason.
        </t>

        <section anchor="hist-keys-request" title="Federation Historical Keys Request">
          <t>
	    When client authentication is not used,
            the request MUST be an HTTP request using the GET method to
	    the federation historical keys endpoint.
          </t>
	  <t>
	    When client authentication is used,
	    the request MUST be an HTTP request using the POST method,
	    with the client authentication parameters passed in the POST body.
	  </t>
          <figure>
            <preamble>
              The following is a non-normative example of a
              historical keys request:
            </preamble>
            <name>
              Federation Historical Keys Request
            </name>
            <artwork><![CDATA[
GET /federation_historical_keys HTTP/1.1
Host: trust-anchor.example.com
]]></artwork>
          </figure>
        </section>

        <section anchor="HistKeysResp" title="Federation Historical Keys Response">
          <t>
	    The response is a signed JWK Set containing the historical keys.
	    It is signed with a Federation Entity Key.
	    A signed JWK Set is a signed JWT with a
	    JWK Set <xref target="RFC7517"/> as its payload.
            A successful response MUST use the HTTP status code 200
            with the content type
            <spanx style="verb">application/jwk-set+jwt</spanx>.
	  </t>
	  <t>
	    Historical keys JWTs are explicitly typed by setting the
            <spanx style="verb">typ</spanx> header parameter to
            <spanx style="verb">jwk-set+jwt</spanx> to prevent
            cross-JWT confusion, per Section 3.11 of <xref target="RFC8725"/>.
	    Historical keys JWTs without a <spanx style="verb">typ</spanx> header parameter
	    or with a different <spanx style="verb">typ</spanx> value MUST be rejected.
	  </t>
	  <t>
	    Historical keys JWTs MUST include the
	    <spanx style="verb">kid</spanx> (Key ID) header parameter
	    with its value being the Key ID of the signing key used.
	  </t>
	  <t>
            The Claims in a historical keys JWT are:
          </t>
          <t>
            <list style="hanging">
              <t hangText="iss">
                <vspace/>
                REQUIRED. String.
                The Entity's Entity Identifier.
              </t>
              <t hangText="iat">
                <vspace/>
                REQUIRED. Number. Time when this historical keys JWT was issued.
                This is expressed as Seconds Since the Epoch, per
                <xref target="RFC7519"/>.
              </t>
              <t hangText="keys">
                <vspace/>
                REQUIRED. Array of JSON objects
                containing the signing keys for the Entity in JWK format.

                <t>
                  JWKs in the <spanx style="verb">keys</spanx>
                  Claim use the following parameters:
                </t>

                <t>
                  <list style="hanging">
                    <t hangText="kid">
                      <vspace/>
                      REQUIRED. Parameter used to match a specific key.
                      It is RECOMMENDED that the Key ID be the
                      JWK Thumbprint <xref target="RFC7638"/> of the key
		      using the SHA-256 hash function.
                    </t>
                    <t hangText="iat">
                      <vspace/>
                      OPTIONAL. Number. Time when this key was issued.
                      This is expressed as Seconds Since the Epoch, per
                      <xref target="RFC7519"/>.
                    </t>
                    <t hangText="exp">
                      <vspace/>
                      REQUIRED. Number. Expiration time for the key.
                      This is expressed as Seconds Since the Epoch, per
                      <xref target="RFC7519"/>,
                      After this time the key MUST NOT be considered valid.
                    </t>
                    <t hangText="revoked">
                      <vspace/>
                      OPTIONAL. JSON object that contains the
                      properties of the revocation, as defined below:
                      <t>
                      <list style="hanging">
                        <t hangText="revoked_at">
                          <vspace/>
                          REQUIRED. Time when the key was revoked
                          or must be considered revoked,
                          using the time format defined for the
                          <spanx style="verb">iat</spanx> Claim in
                      <xref target="RFC7519"/>.
                        </t>

                        <t hangText="reason">
                          <vspace/>
                          OPTIONAL. String
                          that identifies the reason
                          for the key revocation, as defined in
                          <xref target="hist-keys-reasons"/>.
                        </t>

                      </list>
                        Additional members of the <spanx style="verb">revoked</spanx>
                        object MAY be defined and used.
                      </t>

                    </t>
                  </list>
                </t>

              </t>
            </list>
          </t>
	  <t>
	    Additional Claims MAY be defined and used in conjunction with the Claims above.
	  </t>

	  <t>
	    JWKs in the <spanx style="verb">keys</spanx> Claim MAY also contain the
	    <spanx style="verb">nbf</spanx> parameter.  For use in Historical Keys,
	    <spanx style="verb">iat</spanx> and <spanx style="verb">exp</spanx>
	    are sufficient to establish the key lifetime,
	    making <spanx style="verb">nbf</spanx> typically superfluous;
	    however, it is registered for use by profiles that may choose to
	    issue keys that do not immediately become valid at the time of issuance.
	    Its definition is:
	  </t>
          <t>
            <list style="hanging">
              <t hangText="nbf">
                <vspace/>
		OPTIONAL. Time before which the key is not valid,
		using the time format defined for the
		<spanx style="verb">nbf</spanx> Claim in
		<xref target="RFC7519"/>.
	      </t>
	    </list>
	  </t>

          <figure>
            <preamble>
              The following is a non-normative example of the JWT Claims Set for a historical keys response:
            </preamble>
	    <name>
              Federation Historical Keys Response JWT Claims Set
            </name>
            <artwork><![CDATA[
{
    "iss": "https://trust-anchor.federation.example.com",
    "iat": 1666335600,
    "keys":
        [
            {
                "kty": "RSA",
                "n": "5s4qi ...",
                "e": "AQAB",
                "kid": "2HnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
                "iat": 1661151600,
                "exp": 1677052800
            },
            {
                "kty": "RSA",
                "n": "ng5jr ...",
                "e": "AQAB",
                "kid": "8KnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMJJr",
                "iat": 1647932400,
                "exp": 1663830000,
                "revoked": {
                  "revoked_at": 1661151600,
                  "reason": "compromised",
                }
            }
        ]
}
]]></artwork>
          </figure>

        </section>

        <section anchor="hist-keys-reasons" title="Federation Historical Keys Revocation Reasons">

          <t>
            Federation Entities are strongly encouraged to use a meaningful
            <spanx style="verb">reason</spanx> value when indicating the revocation reason
            for a Federation Entity Key. The <spanx style="verb">reason</spanx>
            MAY be omitted
            instead of using the <spanx style="verb">unspecified</spanx> value.
          </t>

          <t>
            Below is the definition of the reason values.
          </t>

          <table>
          <preamble>
            The following table defines Federation Entity Keys revocation reasons.
            These reasons are inspired by Section 5.3.1 of <xref target="RFC5280"/>.
          </preamble>
          <name>
            Federation Entity Keys Revocation Reasons.
          </name>
          <thead>
            <tr>
              <td>Reason</td>
              <td>Description</td>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>unspecified</td>
              <td>General or unspecified reason for the JWK status change.</td>
            </tr>
            <tr>
              <td>compromised</td>
              <td>The private key is believed to have been compromised.</td>
            </tr>
            <tr>
              <td>superseded</td>
              <td>The JWK is no longer active.</td>
            </tr>
          </tbody>
        </table>

            <t>
                A federation MAY specify and utilize additional reasons depending
                on the trust or security framework in use.
            </t>

        </section>

        <section anchor="hist-keys-rationale" title="Rationale for the Federation Historical Keys Endpoint">
          <!--
            introduce the problem
          -->
          <t>
            The Federation Historical Keys endpoint
            solves the problem of verifying historical
            Trust Chains when the Federation Entity Keys
            have changed, either due to expiration or revocation.
          </t>

          <!--
            describe the concept
          -->
          <t>
            The Federation Historical Keys endpoint
            publishes the list of public keys used in the past by the Entity.
            These keys are needed
            to verify Trust Chains created in the past with
            Entity keys no longer published in the Entity's
            Entity Configuration.
          </t>

          <!--
            give the technical details.
          -->
          <t>
            The Federation Historical Keys endpoint response contains a signed JWT
            that attests to all the expired and revoked Entity keys.
          </t>

          <!--
            more technical details.
          -->
          <t>
            Based on the attributes contained in the Entity Statements
            that form a Trust Chain, it MAY also be possible to verify
            the non-federation public keys used in the past by Leaf Entities for
            signature operations for OpenID Connect
            requests and responses.
            For example, an Entity Statement issued for a Leaf
            MAY also include the
            <spanx style="verb">jwks</spanx> Claim for the Leaf's Entity Types,
	    in its
            <spanx style="verb">metadata</spanx> or
            <spanx style="verb">metadata_policy</spanx> Claims.
	  </t>
            <t>
              A simple example: In the following Trust Chain, the
              Federation Intermediate attests to the Leaf's OpenID Connect RP
	      <spanx style="verb">jwks</spanx>
              in the Subordinate Statement issued about the Leaf. The result is
              a Trust Chain that contains the Leaf's OpenID Connect RP JWK Set,
              needed to verify historical signature on
              Request Objects and any other signed JWT issued by the Leaf as an RP.
	      This example Trust Chain contains:
              <list style="numbers">
                <t>
                  an Entity Configuration about the RP published by the RP,
                </t>
                <t>
                  a Subordinate Statement about the RP published by Organization A,
                  with the Claim <spanx style="verb">jwks</spanx> contained in
                  <spanx style="verb">metadata</spanx> or
                  <spanx style="verb">metadata_policy</spanx> attesting the
                  Leaf's OpenID Connect RP <spanx style="verb">jwks</spanx>, and
                </t>
                <t>
                  a Subordinate Statement about Organization A published by Federation F.
                </t>
              </list>
            </t>
        </section>

      </section>

      <section title="Client Authentication at Federation Endpoints"
	       anchor="ClientAuthentication">
	<t>
	  Client authentication is not used at any of the federation endpoints,
	  by default.
	  Federations can choose to make client authentication OPTIONAL, REQUIRED,
	  and/or not allowed at particular federation endpoints.
	</t>
	<t>
	  Client authentication with <spanx style="verb">private_key_jwt</spanx>
	  is the default client authentication method to federation endpoints
	  when client authentication is supported.
	  This client authentication method is described in Section 9 of
	  <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>.
	  The client authentication JWT MUST be signed with a Federation Entity Key.
	  The audience of the JWT MUST be the Entity Identifier
	  of the Entity whose federation endpoint is being authenticated to.
	  The endpoint MUST NOT accept JWTs containing audience values
	  other than its Entity Identifier.
	  When client authentication is used,
	  the request MUST be an HTTP request using the POST method,
	  with the client authentication and endpoint request parameters passed in the POST body.
	  Federations can choose to also use other client authentication methods.
	</t>

	<section title="Client Authentication Metadata for Federation Endpoints"
		 anchor="ClientAuthenticationMetadata">
	  <t>
	    Like other OAuth and OpenID endpoints supporting client authentication,
	    this specification defines metadata parameters saying which
	    client authentication methods are supported for each endpoint.
	    These largely parallel the
	    <spanx style="verb">token_endpoint_auth_methods_supported</spanx>
	    metadata value defined in Section 3 of
	    <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref>.
	  </t>
	  <t>
	    Specifically, for each of the federation endpoints defined in
	    <xref target="federation_entity"/>, parameters named
	    <spanx style="verb">*_auth_methods</spanx>
	    are defined, where the <spanx style="verb">*</spanx> represents the
	    federation endpoint names
	    <spanx style="verb">federation_fetch_endpoint</spanx>,
	    <spanx style="verb">federation_list_endpoint</spanx>, ...,
	    <spanx style="verb">federation_historical_keys_endpoint</spanx>.
	  </t>
	  <t>
	    The <spanx style="verb">*_auth_methods</spanx>
	    metadata parameters list supported client authentication methods
	    for these endpoints, just as
	    <spanx style="verb">token_endpoint_auth_methods_supported</spanx>
	    does for the Token Endpoint.
	    In addition, the value <spanx style="verb">none</spanx> MAY be used
	    to indicate that client authentication is not required at the endpoint.
	  </t>
          <figure>
            <preamble>
	      So, for instance, this metadata declaration states that
	      requests authenticated with
	      <spanx style="verb">private_key_jwt</spanx>
	      are REQUIRED at the
	      <spanx style="verb">federation_trust_mark_endpoint</spanx>:
            </preamble>
            <name>
              Declaring that Client Authentication is REQUIRED at an Endpoint
            </name>
            <artwork><![CDATA[
"federation_trust_mark_endpoint_auth_methods": ["private_key_jwt"]
]]></artwork>
          </figure>
	  <t>
	    If omitted, the default value for these methods is
	    <spanx style="verb">["none"]</spanx>,
	    indicating that only unauthenticated requests are accepted.
	  </t>
	  <t>
	    The <spanx style="verb">endpoint_auth_signing_alg_values_supported</spanx>
	    metadata parameter lists supported client authentication
	    signing algorithms supported for these endpoints, just as
	    <spanx style="verb">token_endpoint_auth_signing_alg_values_supported</spanx>
	    does for the Token Endpoint.
	  </t>
	</section>

      </section>

      <section title="Error Responses" anchor="error_response">
        <t>
          If the request was malformed or an error occurred during
          the processing of the request,
          the response body SHOULD be a JSON object with the content type
          <spanx style="verb">application/json</spanx>.
          In compliance with
          <xref target="RFC6749"/>, the following
          standardized error format SHOULD be used:
        </t>

        <t>
          <list style="hanging">
            <t hangText="error">
              <vspace/>
	      REQUIRED.
	      Error codes in the IANA "OAuth Extensions Error Registry"
	      <xref target="IANA.OAuth.Parameters"/> MAY be used.
	      In particular, these existing error codes are used by this specification:
	      <list style="hanging">
		<t hangText="invalid_request">
		  <vspace/>
		  The request is incomplete or does
		  not comply with current specifications.
		  The HTTP response status code SHOULD be 400 (Bad Request).
		</t>
		<t hangText="server_error">
		  <vspace/>
		  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).
		</t>
		<t hangText="temporarily_unavailable">
		  <vspace/>
		  The server hosting the federation endpoint
		  is currently unable to handle
		  the request due to temporary overloading or maintenance.
		  The HTTP response status code SHOULD be 503 (Service Unavailable).
		</t>
	      </list>

	      This specification also defines the following error codes:

              <list style="hanging">
                <t hangText="invalid_client">
                  <vspace/>
                  The Client cannot be authorized or is not
                  a valid participant of the federation.
                  The HTTP response status code SHOULD be 401 (Unauthorized).
                </t>
		<t hangText="invalid_issuer">
                  <vspace/>
                  The endpoint cannot serve the requested issuer.
                  The HTTP response status code SHOULD be 404 (Not Found).
                </t>
		<t hangText="invalid_subject">
		  <vspace/>
		  The endpoint cannot serve the requested subject.
		  The HTTP response status code SHOULD be 404 (Not Found).
		</t>
		<t hangText="invalid_trust_anchor">
		  <vspace/>
		  The Trust Anchor cannot be found or used.
		  The HTTP response status code SHOULD be 404 (Not Found).
		</t>
		<t hangText="invalid_trust_chain">
		  <vspace/>
		  The Trust Chain cannot be validated.
		  The HTTP response status code SHOULD be 400 (Bad Request).
		</t>
		<t hangText="invalid_metadata">
		  <vspace/>
		  Metadata or Metadata Policy values are invalid or conflict.
		  The HTTP response status code SHOULD be 400 (Bad Request).
		</t>
                <t hangText="not_found">
                  <vspace/>
                  The requested Entity Identifier cannot be found.
                  The HTTP response status code SHOULD be 404 (Not Found).
                </t>
                <t hangText="unsupported_parameter">
                  <vspace/>
                  The server does not support the requested parameter.
                  The HTTP response status code SHOULD be 400 (Bad Request).
                </t>
              </list>
            </t>

            <t hangText="error_description">
              <vspace/>
	      REQUIRED. Human-readable text providing additional information
	      used to assist the developer in understanding the error that occurred.
            </t>
          </list>
        </t>

        <figure>
          <preamble>
            The following is a non-normative example of an error response:
          </preamble>
          <name>
            Example Error Response
          </name>
          <artwork><![CDATA[
400 Bad request
Content-Type: application/json

{
  "error": "invalid_request",
  "error_description":
    "Required request parameter [sub] was missing."
}
]]></artwork>
        </figure>
      </section>
    </section>

    <section
            title="Obtaining Federation Entity Configuration Information"
            anchor="federation_configuration">
      <t>
	The Entity Configuration of all Trust Anchor and Intermediate
	Federation Entities MUST be published
	at their configuration endpoint
	and the Entity Configuration for Leaf Entities SHOULD be published there.
	Its location is determined by concatenating the string
	<spanx style="verb">/.well-known/openid-federation</spanx>
	to the Entity Identifier
	(which MUST use the <spanx style="verb">https</spanx> scheme and
	contain a host component
	and MAY also contain port and path components).
	For instance, the configuration endpoint for the Entity Identifier
	<spanx style="verb">https://entity.example</spanx> is the URL
	<spanx style="verb">https://entity.example/.well-known/openid-federation</spanx>.
	If the Entity Identifier contains a trailing "/" character,
	it MUST be removed before concatenating
	<spanx style="verb">/.well-known/openid-federation</spanx>.
      </t>
      <t>
	Furthermore, any Entity Configuration including the Entity Type Identifier
	<spanx style="verb">federation_entity</spanx> MUST be published
	at its configuration endpoint.
      </t>
      <t>
        While Leaf Federation Entities SHOULD make an Entity Configuration document
        available at their configuration endpoints,
	an exception to this requirement is that
	clients that use a client registration method that results in
	the server having the client's Entity Configuration
	MAY omit doing so.
	For instance, since an RP using Explicit Registration
	posts its Entity Configuration to the OP during client
        registration, the OP has everything it needs from the RP.
	Profiles of this specification MAY define other exceptions for Leaf Entities
	that do not use the Entity Type Identifier <spanx style="verb">federation_entity</spanx>
	and processing rules that accompany them.
      </t>

      <section anchor="ec-request" title="Federation Entity Configuration Request">
        <t>
          An Entity Configuration document MUST be queried using an
          HTTP GET request at the previously specified path.
        </t>
        <t>
          <figure>
	    <preamble>
	      In this example, the requesting party would make the following request to the Entity
	      <spanx style="verb">https://op.sunet.se</spanx>
	      to obtain its Entity Configuration:
	    </preamble>
            <name>
	      Request for Entity Configuration
            </name>
            <artwork><![CDATA[
  GET /.well-known/openid-federation HTTP/1.1
  Host: op.sunet.se
]]></artwork>
          </figure>
        </t>
      </section>

      <section anchor="ec-response" title="Federation Entity Configuration Response">
        <t>
	  The response is an Entity Configuration.
          If the Entity is an Intermediate Entity or a Trust Anchor, the
          response MUST contain metadata for a Federation Entity
          (<spanx style="verb">federation_entity</spanx>).
        </t>
        <t>
          A successful response MUST use the HTTP status code 200
          with the content type
          <spanx style="verb">application/entity-statement+jwt</spanx>,
          to make it clear that the response contains an Entity Statement.
          In case of an error, the response
          is as defined in
          <xref target="error_response"/>.
        </t>
        <t>
          <figure>
	    <preamble>
	      The following is a non-normative example JWT Claims Set for a response from an
	      Intermediate Entity:
	    </preamble>
            <name>
	      Entity Configuration Response JWT Claims Set for an Intermediate
            </name>
            <artwork><![CDATA[
{
  "iss": "https://sunet.se",
  "sub": "https://sunet.se",
  "iat": 1516239022,
  "exp": 1516843822,
  "metadata": {
    "federation_entity": {
      "contacts": ["ops@sunet.se"],
      "federation_fetch_endpoint": "https://sunet.se/fetch",
      "organization_uri": "https://www.sunet.se",
      "organization_name": "SUNET"
    },
  "jwks": {
    "keys": [
      {
        "alg": "RS256",
        "e": "AQAB",
        "kid": "O-wFRGNsy0-4SR2jbXYwDHy6...",
        "kty": "RSA",
        "n": "Qo3n0N0Gv7L8T9I_2sAMc0I4...",
        "use": "sig"
      }
    ]
  },
  "authority_hints": [
    "https://edugain.org"
  ]
}
]]></artwork>
          </figure>
        </t>
        <t>
          <figure>
	    <preamble>
	      The following is a non-normative example JWT Claims Set for a response from an
	      OpenID Provider Entity:
	    </preamble>
            <name>
	      Entity Configuration Response JWT Claims Set for an OP
            </name>
            <artwork><![CDATA[
{
  "iss": "https://op.sunet.se",
  "sub": "https://op.sunet.se",
  "iat": 1516239022,
  "exp": 1516843822,
  "metadata": {
    "openid_provider": {
      "issuer": "https://op.sunet.se",
      "signed_jwks_uri": "https://op.sunet.se/jwks.jose",
      "authorization_endpoint":
        "https://op.sunet.se/authorization",
      "client_registration_types_supported": [
        "automatic",
        "explicit"
      ],
      "grant_types_supported": [
        "authorization_code"
      ],
      "id_token_signing_alg_values_supported": [
        "ES256", "RS256"
      ],
      "contacts": ["ops@sunet.se"],
      "organization_uri": "https://www.sunet.se",
      "organization_name": "SUNET"
      "logo_uri":
        "https://www.sunet.se/sunet/images/32x32.png",
      "op_policy_uri":
        "https://www.sunet.se/en/website/legal-information/",
      "response_types_supported": [
        "code"
      ],
      "subject_types_supported": [
        "pairwise",
        "public"
      ],
      "token_endpoint": "https://op.sunet.se/token",
      "federation_registration_endpoint":
        "https://op.sunet.se/fedreg",
      "token_endpoint_auth_methods_supported": [
        "private_key_jwt"
      ]
    }
  },
  "jwks": {
    "keys": [
      {
        "alg": "RS256",
        "e": "AQAB",
        "kid": "yHozfrAd5G-pnmG4e1jCXpfc...",
        "kty": "RSA",
        "n": "HIoSq4wkZiEkJDTPHiv7torK...",
        "use": "sig"
      }
    ]
  },
  "authority_hints": [
    "https://sunet.se"
  ]
}
]]></artwork>
          </figure>
        </t>
      </section>
    </section>

    <section anchor="resolving_trust"
             title="Resolving the Trust Chain and Metadata">
      <t>
        An Entity (Party A) that wants to establish trust with
        another Entity (Party B) MUST have Party B's Entity Identifier and a list of
        Entity Identifiers of Trust Anchors and their public signing keys.
        Party A will first have to fetch
        sufficient Entity Statements to establish at least one chain of trust
        from Party B to one or more of the Trust Anchors.
        After that, Party A MUST validate the Trust Chains independently,
        and if there are multiple valid Trust Chains and if the
        application demands it, choose one to use.
      </t>

      <t>
        To delegate the Trust Chain evaluation to a trusted third party,
        the Entity (Party A) that wants to establish trust with
        another Entity (Party B) MAY use
        a resolve endpoint, as defined in <xref target="resolve"/>.
      </t>

      <section anchor="fetching-es"
               title="Fetching Entity Statements to Establish a Trust Chain">
        <t>
          Depending on the circumstances, Party A MAY be
          handed Party B'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 <xref target="federation_configuration"/>
          based on the Entity Identifier of Party B.
        </t>
        <t>
          The next step is to iterate through the list of
          Intermediates listed in
          <spanx style="verb">authority_hints</spanx>, 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.
        </t>
        <t>
          With the list of all Intermediates and the Trust Anchor, the respective
          fetch endpoints, as defined in <xref target="fetch_endpoint"/>, are used to fetch
          Entity Statements about the Intermediates and Party B.
        </t>
        <t>
          Federation participants MUST NOT attempt to fetch
          Entity Statements they already have obtained during this
          process to prevent loops.
          If a loop is detected, the authority hint that led to it MUST NOT be used.
        </t>
        <t>
          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.
        </t>
        <t>
          If there is no path from Party B to at least one of the
          trusted Trust Anchors, then the list will be empty and there is no
          way of establishing trust in Party B's information.
          How Party A deals with this is out of scope for this specification.
        </t>

      <figure>
        <preamble>
	  The following sequence diagram represents the interactions between the RP,
	  the OP, and the Trust Anchor during a trust evaluation made by the OP
	  about the RP.
	  Relating this to the preceding description, in this diagram,
	  Party A is the OP and Party B is the RP.
        </preamble>
	<name>
          Resolving Trust Chain and Metadata from the Perspective of an OP
	</name>
<!--
  NOTE: this figure was made with ASCIIflow and its editable sources
  are available at the following link:
  https://asciiflow.com/#/share/eJztVt9rwjAQ%2FldCXvagvjg2NhkDce5tKOpjYUSbrYGadMm1KNb%2FfVemE5G0NbXbcN5Df%2BSuH9fvu0tuRSWbc9qhk16bNmnIllzj28qjCddGKOnRTrvp0QXe729v8GmZrdxd4xPwBeCLRxutzBrEZkX%2BXcy3NTxPpmQ0JCS1fpKSQa7%2FK2aiYwOkK2eB0iRF2JqyJUWpFPsPArewfQkClqSn5Jt4jzUDFIaM%2BEfM8decYR9aueacbbnoo2EtJJhIScOdYfM5ePxrJBRF9xMWxgy4ISwGrHhk7DUQEkwlWDtB1bIt6TkS1l7X9WRrCSwtWW5zu8Lm1%2FVhgf8yCRvL7%2FETVsK%2B%2FRESBlNgQhryzGEWEC79SGHrVoUt1QsO2ZZcPo1k9WRrDywLu%2B3TcTxV2hcSt14yBrzOOSrHpiqGbIr5F81bwMGZN%2B%2Fu5IWAb6bOXoD9XAnW%2FtvVsi3pOe%2BTtxtFoUDBXjgwnwEjQxWKWbZSBfYi2Q9IhhOCAc0OJ1sn2ItkNUr2xLVINtviaHhlsnlOhQn3d33nAGuXbJ%2BNk5OQusCWOMv2Yemarj8BIeAYEw%3D%3D)
-->
        <artwork><![CDATA[
+-----+                         +-----+                             +--------------+
| RP  |                         | OP  |                             | Trust Anchor |
+-----+                         +-----+                             +--------------+
   |                               |                                        |
   | Entity Configuration Request  |                                        |
   |<------------------------------|                                        |
   |                               |                                        |
   | Entity Configuration Response |                                        |
   |------------------------------>|                                        |
   |                               |                                        |
   |                               | Evaluates authority_hints              |
   |                               |--------------------------              |
   |                               |                         |              |
   |                               |<-------------------------              |
   |                               |                                        |
   |                               | Entity Configuration Request           |
   |                               |--------------------------------------->|
   |                               |                                        |
   |                               |        Entity Configuration Response   |
   |                               |<---------------------------------------|
   |                               |                                        |
   |                               | Obtains Fetch Endpoint                 |
   |                               |-----------------------                 |
   |                               |                      |                 |
   |                               |<----------------------                 |
   |                               |                                        |
   |                               | Request Subordinate Statement about RP |
   |                               |--------------------------------------->|
   |                               |                                        |
   |                               |        Subordinate Statement about RP  |
   |                               |<---------------------------------------|
   |                               |                                        |
   |                               | Evaluates the Trust Chain              |
   |                               |--------------------------              |
   |                               |                         |              |
   |                               |<-------------------------              |
   |                               |                                        |
   |                               | Applies Metadata Policies              |
   |                               |--------------------------              |
   |                               |                         |              |
   |                               |<-------------------------              |
   |                               |                                        |
   |                               | Applies Constraints                    |
   |                               |--------------------                    |
   |                               |                   |                    |
   |                               |<-------------------                    |
   |                               |                                        |
   |                               | Derives the RP's Resolved Metadata     |
   |                               |-----------------------------------     |
   |                               |                                  |     |
   |                               |<----------------------------------     |
]]></artwork>
	</figure>
      </section>

      <section title="Validating a Trust Chain" anchor="trust_chain_validation">
        <t>
          As described in <xref target="trust_chain"/>,
          a Trust Chain consists of an ordered list of Entity Statements.
          So however Party A 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.
        </t>
        <t>
	  Let us refer to the Entity Statements in the Trust Chain as
	  ES[j], where j = 0,...,i,
	  with 0 being the index of the first Entity Statement
	  and i being the zero-based index of the last.
	  To validate the Trust Chain, the following MUST be done:
        </t>
        <t>
          <list style="symbols">
            <t>
              For each Entity Statement ES[j], where j = 0,..,i:
              <list style="symbols">
                <t>
                  Verify that the statement contains all the required Claims.
                </t>
                <t>
                  Verify that <spanx style="verb">iat</spanx> has a value in the
                  past.
                </t>
                <t>
                  Verify that <spanx style="verb">exp</spanx> has a value that
                  is in the future.
                </t>
              </list>
            </t>
            <t>
              For ES[0] (the Entity Configuration of the Trust Chain subject), verify that
	      <spanx style="verb">iss</spanx> == <spanx style="verb">sub</spanx>.
            </t>
            <t>
              For ES[0], verify that its signature validates with a public key
	      in ES[0]["jwks"].
            </t>
            <t>
              For each j = 0,...,i-1, verify that ES[j]["iss"] == ES[j+1]["sub"].
            </t>
            <t>
              For each j = 0,...,i-1, verify that the signature of ES[j] validates with a public
              key in ES[j+1]["jwks"].
            </t>
            <t>
              For ES[i] (the Trust Anchor's Entity Configuration), verify that
	      the issuer matches the Entity Identifier of the Trust Anchor.
	    </t>
	    <t>
	      For ES[i], verify that
	      its signature validates with a public key of the Trust Anchor.
            </t>
          </list>
        </t>
        <t>
          Verifying the signature is a much more expensive
          operation than verifying the correctness of the statement and the
          timestamps. An implementer MAY therefore choose not to verify the
          signatures until all the other checks have been done.
        </t>
        <t>
	  Federation participants MAY cache Entity Statements and signature verification
          results until they expire, per
          <xref target="trust_lifetime"/>.
        </t>
        <t>
          After the preceding validation, metadata MUST be resolved to the subject
          of the Trust Chain, as described in <xref target="metadata_policy_enforcement"/>.
          Furthermore, constraints MUST be enforced for each Subordinate Statement of the Trust Chain,
          as explained in <xref target="chain_constraints"/>.
        </t>
      </section>

      <section anchor="choosing-chain" title="Choosing One of the Valid Trust Chains">
        <t>
          If multiple valid Trust Chains are found, Party A will
          need to decide on which one to use.
	  One simple rule would be to prefer a shorter chain over a longer one.
	  Federation participants MAY follow other rules according to local policy.
	</t>
      </section>

      <section anchor="trust_lifetime"
               title="Calculating the Expiration Time of a Trust Chain">
        <t>
          Each Entity Statement in a Trust Chain is signed and MUST have an
          expiration time (<spanx style="verb">exp</spanx>).
          The expiration time of the whole Trust Chain is the minimum
          (<spanx style="verb">exp</spanx>) value within the Trust Chain.
        </t>
      </section>

      <section title="Transient Trust Chain Validation Errors"
               anchor="transient_trust_chain_validation_errors">
        <t>
          If the federation topology is being updated, for example, when a set
          of Leaf Entities is moved to a new Intermediate Entity, the Trust Chain
          validation may fail in a transient manner. Retrying after a period of
          time may resolve the situation.
        </t>
      </section>

      <section title="Resolving the Trust Chain and Metadata with a Resolver"
	       anchor="ResolvingWithResolver">
	<t>
	  Note that an alternative method for resolving a Trust Chain
	  for an Entity (Party B) using the methods described above
	  is to use a resolve endpoint, as described in <xref target="resolve"/>.
	  This lets the resolver do the work that otherwise the Entity (Party A)
	  wanting to establish trust would have to do for itself.
	</t>
      </section>

    </section>

    <section anchor="updating-metadata" title="Updating Metadata, Key Rollover, and Revocation">
      <t>
        This specification facilitates smoothly updating metadata
        and public keys.
      </t>
      <t>
        As described in <xref target="trust_lifetime"/>,
        each Trust Chain has an expiration time.
        Federation participants MUST support
        refreshing a Trust Chain when it expires.
        How often a participant reevaluates the Trust Chain depends on
        how quickly it wants to find out that something has changed.
      </t>

      <section anchor="key-rollover" title="Federation Key Rollover">
        <t>
	  The expiration time (<spanx style="verb">exp</spanx>)
	  of an Entity Configuration is used to control how often it
	  needs to be retrieved to fetch an updated set of Federation Keys
	  from its <spanx style="verb">jwks</spanx> member.
        </t>
      </section>

      <section title="Key Rollover for a Trust Anchor"
               anchor="key_rollover_anchor">
        <t>
          A Trust Anchor MUST publish an Entity Configuration about itself.
          The expiration time (<spanx style="verb">exp</spanx>) set on this Entity Configuration should be chosen
          such that it ensures that federation participants re-fetch it at reasonable intervals.
          When a Trust Anchor rolls over its signing keys, it needs to:
        </t>
        <t>
          <list style="numbers">
            <t>
              Add the new keys to the <spanx style="verb">jwks</spanx> representing
              the Trust Anchor's signing keys in its Entity Configuration.
            </t>
            <t>
              Keep signing the Entity Configuration and the Entity Statements using
              the old keys for a long enough time period to allow all
              Subordinates to have obtained the new keys.
            </t>
            <t>
              Switch to signing with the new keys.
            </t>
            <t>
              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.
            </t>
          </list>
        </t>
      </section>

      <section title="Redundant Retrieval of Trust Anchor Keys" anchor="TrustAnchorKeys">
        <t>
          It is RECOMMENDED that Federation Operators provide a means of retrieving the public keys
          for the Trust Anchors it administers that is independent of those Trust Anchors' Entity Configurations.
          This is intended to provide redundancy in the eventuality of the compromise of
          the Web PKI <xref target="RFC9525"/> infrastructure underlying retrieval of public keys from Entity Configurations.
        </t>
        <t>
          The keys retrieved via the independent mechanism specified by the Federation Operator
          SHOULD be compared to those retrieved via the Trust Anchor's Entity Configuration.
          If they do not match, both SHOULD be retrieved again.
          If they still do not match, it is indicative of a security or configuration problem.
          The appropriate remediation steps in that eventuality SHOULD be specified by the Federation Operator.
        </t>
      </section>

      <section anchor="revocation" title="Revocation">
        <t>
          Since the participants in federations are expected to check the Trust Chain on a regular
          frequent basis, this specification does not define a
          revocation process. Specific federations MAY make a
          different choice and will then have to define their own revocation process.
        </t>
      </section>
    </section>

    <section title="OpenID Connect Client Registration" anchor="client_registration">
      <t>
        This section describes how the mechanisms defined in this specification
        can be used to establish trust between an RP and an OP that have no
        prior explicit configuration or registration between them. It defines
        two client registration methods, Automatic Registration and Explicit
        Registration, that use Trust Chains, per <xref target="resolving_trust"/>.
        Federations can use other appropriate methods for client registration.
      </t>
      <t>
        Federations with OpenID Connect Entities SHOULD agree on the supported
        client registration methods.
      </t>
      <t>
	Note that both Automatic Registration and Explicit Registration
	can also be used for OAuth 2.0 profiles other than OpenID Connect.
	To do so, rather than using the Entity Type Identifiers
	<spanx style="verb">openid_relying_party</spanx> and
	<spanx style="verb">openid_provider</spanx>,
	one would instead use the Entity Type Identifiers
	<spanx style="verb">oauth_client</spanx> and
	<spanx style="verb">oauth_authorization_server</spanx>,
	or possibly other Entity Type Identifiers defined for the specific
	OAuth 2.0 profile being used.
      </t>
      <t>
	When using both methods, <spanx style="verb">trust_anchor_hints</spanx>
	values can be used to determine Trust Anchors that the RP and OP share.
	When building Trust Chains, RPs SHOULD choose a Trust Anchor
	in common with the OP, when possible.
      </t>

      <section title="Automatic Registration" anchor="automatic">
        <t>
          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 <xref target="resolving_trust"/>.
        </t>
          <t>
              The RP MUST perform Trust Chain and metadata resolution for the OP, as specified in
              <xref target="resolving_trust"/> before it sends the Authentication Request. If the resolution is not
              successful, the RP MUST NOT attempt further interactions with the OP.
          </t>
        <t>
          Automatic Registration has the following characteristics:
          <list style="symbols">
            <t>
              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 the URL derived from the Entity Identifier, as
              described in <xref target="federation_configuration"/>.
            </t>
            <t>
              Since there is no registration step prior to the Authentication Request,
	      asymmetric cryptography MUST be used to authenticate requests
	      when using Automatic Registration.
	      Asymmetric cryptography is used to authenticate requests;
	      therefore, the OP neither assigns a Client Secret to the RP
	      nor returns it as a result of the registration process.
            </t>
          </list>
        </t>
        <t>
          An OP that supports Automatic Registration MUST include the
          <spanx style="verb">automatic</spanx> keyword in its
          <spanx style="verb">client_registration_types_supported</spanx>
          metadata parameter.
	</t>

        <section anchor="authn-request" title="Authentication Request">
          <t>
            The Authentication Request is performed by passing a
            Request Object by value or by reference, as described in Section 6 of
            <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>
	    and <xref target="RFC9101">The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)</xref>,
            or using a pushed authorization request, as described in
            <xref target="RFC9126">Pushed Authorization Requests</xref>.
	  </t>
	  <t>
	    Authentication requests MUST demonstrate that the requesting Entity
	    controls the Entity's RP keys, using one of the methods described below.
	    Attempted authentication requests that do not do so MUST be rejected.
          </t>
	  <t>
	    Deployments MAY choose not to support passing the request object
	    by reference
	    (using the <spanx style="verb">request_uri</spanx> request parameter)
	    because allowing this would make it easier for attackers
	    to mount denial of service attacks against
	    OAuth 2.0 Authorization Servers or OpenID Providers.
	    They can do this by using the
	    <spanx style="verb">request_uri_parameter_supported</spanx>
	    OP metadata parameter with the value <spanx style="verb">false</spanx>.
	    If the request parameters are too large to practically
	    be passed by value as query parameters,
	    the request parameters can instead be sent via HTTP POST or
	    a <xref target="RFC9126">Pushed Authorization Request</xref>,
	    as described in <xref target="using-par"/>.
	  </t>

          <section title="Using a Request Object" anchor="UsingAuthzRequestObject">

            <t>
              When a Request Object is used at the Authorization Endpoint
	      or the Pushed Authorization Request Endpoint,
	      the value of the <spanx style="verb">request</spanx>
              parameter is a JWT whose Claims are the request parameters
              specified in Section 3.1.2 in
              <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>.
              The JWT MUST be signed and MAY be encrypted.
              The following parameters are used in the Request Object:

              <list style="hanging">
                <t hangText="aud">
                  <vspace/>
		  REQUIRED. The "aud" (audience) value MUST be
		  the Entity Identifier of the OP
		  and MUST NOT include any other values.
                </t>
                <t hangText="client_id">
                  <vspace/>
                  REQUIRED. The <spanx style="verb">client_id</spanx>
                  value MUST be the RP's Entity Identifier.
                </t>
                <t hangText="iss">
                  <vspace/>
                  REQUIRED. The <spanx style="verb">iss</spanx>
                  value MUST be the RP's Entity Identifier.
                </t>
                <t hangText="sub">
                  <vspace/>
                  MUST NOT be present.
                  This prevents reuse of the statement for
                  <spanx style="verb">private_key_jwt</spanx>
                  client authentication.
                </t>
                <t hangText="jti">
                  <vspace/>
                  REQUIRED. JWT ID. A unique identifier for the JWT, which can
                  be used to prevent reuse of the Request Object.
                  A Request Object MUST only
                  be used once, unless conditions for reuse were negotiated
                  between the parties; any such negotiation is beyond the scope
                  of this specification.
                </t>
                <t hangText="exp">
                  <vspace/>
                  REQUIRED. Number. Expiration time after which the JWT MUST
                  NOT be accepted for processing. This is expressed as Seconds
                  Since the Epoch, per <xref target="RFC7519"/>.
                </t>
                <t hangText="iat">
                  <vspace/>
                  OPTIONAL. Number. Time when this Request Object was issued.
                  This is expressed as Seconds Since the Epoch, per
                  <xref target="RFC7519"/>.
                </t>
                <t hangText="trust_chain" anchor="trust_chain-param">
                  <vspace/>
                  OPTIONAL. Array containing the sequence of Entity Statements
                  that comprise the Trust Chain between the RP making
                  the request and the selected Trust Anchor.
                  When the RP and the OP are part of the same federation,
                  the RP MUST select a Trust Anchor that it has in common
                  with the OP; otherwise, the RP is free to select the
                  Trust Anchor to use.
		  <vspace blankLine="1"/>

		  NOTE: The use of the
		  <spanx style="verb">trust_chain</spanx> header parameter,
		  as specified in <xref target="trust_chain_head_param"/>,
		  is RECOMMENDED over the use of this parameter;
		  it is retained for historical reasons.
                </t>
              </list>
            </t>

            <section title="Authorization Request with a Trust Chain" anchor="trust_chain_authz">
              <t>
              When the <spanx style="verb">trust_chain</spanx>
              header parameter
              is used in the authentication request, the Relying Party
              informs the OP of the sequence of Entity Statements
              that proves the trust relationship between it
              and the selected Trust Anchor.
              </t>
              <t>
              Due to the large size of a Trust Chain, it may be necessary
              to use the HTTP POST method,
	      a <spanx style="verb">request_uri</spanx>, or
              a <xref target="RFC9126">Pushed Authorization Request</xref>
              for the request.
              </t>

            <figure>
              <preamble>
                The following is a non-normative example of the
		header parameters and JWT Claims Set in a
                Request Object:
              </preamble>
	      <name>
		Request Object JWT Claims Set
	      </name>
              <artwork><![CDATA[
{
  "typ": "oauth-authz-req+jwt",
  "alg": "RS256",
  "kid": "kid-that-points-to-a-jwk-contained-in-the-trust-chain",
  "trust_chain" : [
    "eyJhbGciOiJSUzI1NiIsImtpZCI6Ims1NEhRdERpYnlHY3M5WldWTWZ2aUhm ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ..."
  ]
}
.
{
  "aud": "https://op.example.org",
  "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"
}
]]></artwork>
            </figure>
            <figure>
              <preamble>
                The following is a non-normative example of an Authentication
                Request using the <spanx style="verb">request</spanx> parameter
                (with line wraps within values for display purposes only):
              </preamble>
	      <name>
		Authentication Request using Request Object
	      </name>
              <artwork><![CDATA[
Host: server.example.com
GET /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=eyJ0eXAiOiJvYXV0aC1hdXRoei1yZXErand0IiwiYWxnIjoiUlMyNTYiLCJ
        raWQiOiJOX19EOThJdkI4TmFlLWt3QTZuck90LWlwVGhqSGtEeDM3bmljRE1IM04
        0In0.
        eyJhdWQiOiJodHRwczovL29wLmV4YW1wbGUub3JnIiwiY2xpZW50X2lkIjoiaHR0
        cHM6Ly9ycC5leGFtcGxlLmNvbSIsImV4cCI6MTU4OTY5OTE2MiwiaWF0IjoxNTg5
        Njk5MTAyLCJpc3MiOiJodHRwczovL3JwLmV4YW1wbGUuY29tIiwianRpIjoiNGQz
        ZWMwZjgxZjEzNGVlOWE5N2UwNDQ5YmU2ZDMyYmUiLCJub25jZSI6IjRMWDBtRk14
        ZEJqa0dtdHg3YThXSU9uQiIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vcnAuZXhh
        bXBsZS5jb20vYXV0aHpfY2IiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInNjb3Bl
        Ijoib3BlbmlkIHByb2ZpbGUgZW1haWwgYWRkcmVzcyBwaG9uZSIsInN0YXRlIjoi
        WW1YOFBNOUk3V2JOb01ubmllS0tCaXB0Vlcwc1AyT1oiLCJ0cnVzdF9jaGFpbiI6
        WyJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2SW1zMU5FaFJkRVJwWW5sSFkz
        TTVXbGRXVFdaMmFVaG0gLi4uIiwiZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJ
        NklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUJZMEpTIC4uLiIsImV5SmhiR2Np
        T2lKU1V6STFOaUlzSW10cFpDSTZJa0pZZG1aeWJHNW9RVTExU0ZJd04yRnFWVzFC
        WTBKUyAuLi4iXX0.
        Rv0isfuku0FcRFintgxgKDk7EnhFkpQRg3Tm6N6fCHAHEKFxVVdjy4
        9JboJtxKcQVZKN9TKn3lEYM1wtF1e9PQrNt4HZ21ICfnzxXuNx1F5SY1GXCU2n2y
        FVKtz3N0YkAFbTStzy-sPRTXB0stLBJH74RoPiLs2c6dDvrwEv__GA7oGkg2gWt6
        VDvnfDpnvFi3ZEUR1J8MOeW_VFsayrT9sNjyjsz62Po4LzvQKQMKxq0dNwPNYuuS
        fUmb-YvmFguxDb3weYl8WS-
        48EIkP1h4b_KGU9x9n7a1fUOHrS02ATQZmaL8jUil7yLJqx5MiCsPr4pCAXV0doA
        4pwhs_FIw HTTP/1.1

]]></artwork>
            </figure>
	    <t>
	      When the <spanx style="verb">trust_chain</spanx> header parameter
	      is included,
	      the <spanx style="verb">peer_trust_chain</spanx> header parameter
	      MAY also be included to provide a Trust Chain between the OP
	      and the Trust Anchor the RP selected.
	      The Peer Trust Chain contains metadata and policy values
	      that the RP has chosen for the OP to use during the registration.
	      The Trust Anchors selected in both Trust Chains MUST be the same.
	      Inclusion of both Trust Chains enables achieving
	      the Federation Integrity and Metadata Integrity properties,
	      as defined in <xref target="App-Fed-Linkage"/>.
	    </t>
            </section>

            <section title="Processing the Authentication Request" anchor="AuthzRequestProcessing">
              <t>
                When the OP receives an incoming Authentication Request,
                the OP supports OpenID Federation, the incoming
                Client ID
                is a valid URL, and the OP does not have the Client ID
                registered as a known
                client, then the OP SHOULD resolve the Trust Chains
                related to the requestor.
              </t>
              <t>
                An RP MAY include a Trust Chain from itself
		to the Trust Anchor that it selected
		in the Request Object using the
                <spanx style="verb">trust_chain</spanx> header parameter
		defined in <xref target="trust_chain_head_param"/>.
                If the OP does not have a valid registration for the RP or
                its registration has expired, the OP MAY use the received
                Trust Chain as a hint for which path to take from the
                RP's Entity to the Trust Anchor.
                The OP MAY evaluate the statements in the
                provided Trust Chain
                to make its Federation Entity Discovery procedure more efficient,
                especially if the RP contains multiple authority hints in
                its Entity Configuration.
		If the OP already has a valid registration for the RP, it MAY
		use the received Trust Chain to update the RP's registration.
	      </t>
	      <t>
                A Trust Chain may be relied upon by the OP because it has validated
                all of its statements. This is true whether these statements
                are retrieved from their URLs or whether they
                are provided via the <spanx style="verb">trust_chain</spanx>
                request parameter in the Request Object.
		In both cases, the OP MUST fully verify the Trust Chain
		including every Entity Statement contained in it.
              </t>
	      <t>
		The RP MAY likewise include a Trust Chain from the OP
		to the Trust Anchor that the RP selected
		in the Request Object using the
                <spanx style="verb">peer_trust_chain</spanx> header parameter
		defined in <xref target="peer_trust_chain_head_param"/>.
		The OP SHOULD use the metadata and policy values
		that the RP has chosen during the registration.
		Inclusion of both Trust Chains enables achieving
		the Federation Integrity and Metadata Integrity properties,
		as defined in <xref target="App-Fed-Linkage"/>.
	      </t>
              <t>
                If the RP does not include the
                <spanx style="verb">trust_chain</spanx>
                header parameter in the Request Object,
		the OP for some reason decides not to use the provided Trust Chain,
                or the OP does not support this feature, it then MUST
                validate the possible Trust Chains, starting with the RP's Entity Configuration,
                as described in <xref target="fetching-es"/>,
                and resolve the RP metadata with Entity Type
                <spanx style="verb">openid_relying_party</spanx>.
              </t>
              <t>
                The OP SHOULD furthermore verify that the Resolved Metadata of the RP
                complies with the client metadata specification
                <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>.
              </t>
              <t>
                Once the OP has the RP's metadata, it MUST verify that the client
                was actually the one sending the Authentication Request by
                verifying the signature of the Request Object using the key
                material the client published in its metadata for the
                <spanx style="verb">openid_relying_party</spanx> Entity Type.
		If the signature does not verify, the OP MUST reject the request.
              </t>
            </section>
          </section>

          <section anchor="using-par" title="Using Pushed Authorization">
            <t>
              <xref target="RFC9126">Pushed Authorization Requests</xref>
              provide an
              interoperable way to push authentication request parameters
              directly to the AS in exchange for a one-time-use
              <spanx style="verb">request_uri</spanx>.
	      The standard PAR metadata parameters are used in the
	      RP and OP metadata to indicate its use.
            </t>
	    <t>
	      When using PAR with Automatic Registration,
	      either a Request Object MUST be used as a PAR parameter,
	      with the Request Object being as described in
	      <xref target="UsingAuthzRequestObject"/>, or
	      a client authentication method for the PAR endpoint
	      MUST be used that proves possession of one of the RP's private keys.
	      Furthermore, the corresponding public key MUST be in the
	      Entity's RP JWK Set <xref target="RFC7517"/>.
	    </t>
            <t>
              The two applicable PAR client authentication methods are:
              <list style="symbols">
                <t>
		  JWT Client authentication, as described
                  for <spanx style="verb">private_key_jwt</spanx> in Section 9 of
                  <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>.
		  In this case, the audience of the client authentication JWT
		  MUST be the Entity Identifier of the OP
		  and MUST NOT include any other values.
                </t>
                <t>
                  mTLS using self-signed certificates,
		  as described in Section 2.2 of <xref target="RFC8705"/>.
                  In this case, the self-signed certificate MUST be present as
                  the value of an <spanx style="verb">x5c</spanx>
                  Claim for a key in the Entity's RP JWK Set.
		  In this case, the server MUST omit certificate chain validation.
                </t>
              </list>
            </t>
            <figure>
            <preamble>
	      A Pushed Authorization Request to the OP could look like this:
	    </preamble>
	    <name>
	      Pushed Authorization Request to the OP
	    </name>
              <artwork><![CDATA[
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.
  eyJzdWIiOiAiaHR0cHM6Ly9ycC5leGFtcGxlLmNvbSIsICJpc3M
  iOiAiaHR0cHM6Ly9ycC5leGFtcGxlLmNvbSIsICJpYXQiOiAxNT
  g5NzA0NzAxLCAiZXhwIjogMTU4OTcwNDc2MSwgImF1ZCI6ICJod
  HRwczovL29wLmV4YW1wbGUub3JnIiwgImp0aSI6ICIzOWQ1YWU1
  NTJkOWM0OGYwYjkxMmRjNTU2OGVkNTBkNiJ9.
  oUt9Knx_lxb4V2S0tyNFH
  CNZeP7sImBy5XDsFxv1cUpGkAojNXSy2dnU5HEzscMgNW4wguz6
  KDkC01aq5OfN04SuVItS66bsx0h4Gs7grKAp_51bClzreBVzU4g
  _-dFTgF15T9VLIgM_juFNPA_g4Lx7Eb5r37rWTUrzXdmfxeou0X
  FC2p9BIqItU3m9gmH0ojdBCUX5Up0iDsys6_npYomqitAcvaBRD
  PiuUBa5Iar9HVR-H7FMAr7aq7s-dH5gx2CHIfM3-qlc2-_Apsy0
  BrQl6VePR6j-3q6JCWvNw7l4_F2UpHeanHb31fLKQbK-1yoXDNz
  DwA7B0ZqmuSmMFQ
]]></artwork>
            </figure>

            <section anchor="par-processing" title="Processing the Pushed Authentication Request">
              <t>
                The requirements specified in
                <xref target="AuthzRequestProcessing"/>
                also apply to <xref target="RFC9126">Pushed Authorization Requests</xref>.
              </t>
              <t>
                Once the OP has the RP's metadata, it MUST verify the client
		is using the keys published for the
		<spanx style="verb">openid_relying_party</spanx>
		Entity Type Identifier.
		If the RP does not verify, the OP MUST reject the request.
	      </t>
	      <t>
                The means of verification depends on the client authentication method used:
                <list style="hanging">
                  <t hangText="private_key_jwt">
                    <vspace/>
                    If this method is used, then the OP verifies 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 valid.
		    The audience of the signed JWT MUST be
		    the Authorization Server's Entity Identifier
		    and MUST NOT include any other values.
                  </t>
                  <t hangText="self_signed_tls_client_auth">
                    <vspace/>
                    If mTLS is used with a self-signed certificate,
		    then the certificate MUST be present as the
                    value of an <spanx style="verb">x5c</spanx>
                    Claim for a key in the JWK Set containing the RP's keys.
                  </t>
                </list>
              </t>
            </section>
          </section>
        </section>

	<section title="Successful Authentication Response" anchor="AuthenticationResponse">
	  <t>
	    The response to a successful authentication request
	    when using Automatic Registration is the same as the
	    successful authentication responses defined in <xref target="OpenID.Core"/>.
	    It is a successful OAuth 2.0 authorization response
	    sent to the Client's redirection URI.
	  </t>
	</section>

        <section title="Authentication Error Response" anchor="AuthenticationError">
          <t>
	    The error response to an unsuccessful authentication request
	    when using Automatic Registration is the same as the
	    error authentication responses defined in <xref target="OpenID.Core"/>.
	    It is an OAuth 2.0 authorization error response
	    sent to the Client's redirection URI,
	    unless a <xref target="RFC9126">Pushed Authorization Request</xref>
	    was used for the request.
	  </t>
	  <t>
	    However, as in both <xref target="OpenID.Core"/> and <xref target="RFC6749"/>,
	    if the redirection URI is invalid, redirection MUST NOT be performed,
	    and instead the Authorization Server SHOULD inform the End-User
	    of the error in the user interface.
	    The Authorization Server MAY also choose to do this if it
	    has reason to believe that the redirection URI might be being used
	    as a component of an open redirector.
	  </t>
	  <t>
	    If the OP fails to establish trust with the RP or
	    finds the RP metadata to be invalid or in conflict with metadata policy,
	    it MUST treat the redirection URI as invalid
	    and not perform redirection.
	    This means that the error codes
	    <spanx style="verb">invalid_trust_anchor</spanx>,
	    <spanx style="verb">invalid_trust_chain</spanx>, and
	    <spanx style="verb">invalid_metadata</spanx>,
	    which are about reasons trust failed to be established,
	    SHOULD only be returned in
	    <xref target="RFC9126">Pushed Authorization Request</xref>
	    error responses, and not to the Client's redirection URI.
          </t>
          <t>
            In addition to the error codes contained in the
	    IANA "OAuth Extensions Error Registry" registry <xref target="IANA.OAuth.Parameters"/>,
	    this specification also defines the error codes
	    in <xref target="error_response"/>,
	    which MAY also be used.
          </t>
          <figure>
            <preamble>
              The following is a non-normative example authentication error response:
            </preamble>
          <name>
            Authentication Error Response
          </name>
            <artwork><![CDATA[
HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    error=consent_required
    &error_description=
      Consent%20by%20the%20End-User%20required
    &state=af0ifjsldkj
]]></artwork>
          </figure>
        </section>

	<section title="Automatic Registration and Client Authentication"
		 anchor="AutoClientAuth">
	  <t>
	    Note that when using Automatic Registration,
	    the client authentication methods that the client can use
	    are declared to the OP using RP Metadata parameters: either the
	    <spanx style="verb">token_endpoint_auth_methods_supported</spanx>
	    parameter defined in <xref target="OpenID.RP.Choices"/> or the
	    <spanx style="verb">token_endpoint_auth_method</spanx> parameter.
	    Those that the OP can use are likewise
	    declared to the RP using OP Metadata parameters.
	    However, if there are multiple methods supported by both
	    the RP and the OP, the OP does not know which one the RP will pick
	    in advance of it being used,
	    since this is not declared at the time the Automatic Registration occurs.
	  </t>
	  <t>
	    OPs SHOULD accept any client authentication method that is mutually supported
	    and RPs MUST only use mutually supported methods.
	    Because some OPs may be coded in such a way that
	    they expect the RP to always use the same client authentication method
	    for subsequent interactions, note that
	    interoperability may be improved by the RP doing so.
	  </t>
	</section>

        <section title="Possible Other Uses of Automatic Registration" anchor="AutomaticRegistrationOtherUses">
          <t>
            Automatic Registration is designed to be able to be
            employed for OAuth 2.0 use cases beyond OpenID Connect,
	    as noted in <xref target="client_registration"/>.
            For instance, ecosystems using
            bare <xref target="RFC6749">OAuth 2.0</xref> or
            <xref target="FAPI">FAPI</xref> can utilize Automatic Registration.
          </t>
	  <t>
	    Also note that Client ID values that are Entity Identifiers
	    could be used to identify clients using Automatic Registration
	    at endpoints other than the Authorization Endpoint and Token Endpoint
	    in OAuth 2.0 deployments, such as
	    the Pushed Authorization Request (PAR) Endpoint
	    and Introspection Endpoint.
	    Describing particular such scenarios is beyond the scope of this specification.
	  </t>
        </section>

      </section>

      <section title="Explicit Registration" anchor="explicit">
        <t>
          Using this method, the RP establishes its client registration with the
          OP by means of a dedicated registration request, similar to
          <xref target="OpenID.Registration"/>, but instead of its metadata, the
          RP submits its Entity Configuration or an entire Trust Chain. When
          the Explicit Registration is completed, the RP can proceed to
          make regular OpenID authentication requests to the OP.
        </t>

        <t>
          An OP that supports Explicit Registration MUST include the
          <spanx style="verb">explicit</spanx> keyword in its
          <spanx style="verb">client_registration_types_supported</spanx>
          metadata parameter and set the
          <spanx style="verb">federation_registration_endpoint</spanx> metadata
          parameter to the URL at which it receives Explicit Registration requests.
        </t>

        <t>
          Explicit Registration is suitable for implementation on top of the
          <xref target="OpenID.Registration">OpenID Connect Dynamic Client
          Registration 1.0</xref> endpoint of an OP deployment. In contrast to
          Automatic Registration, it enables an OP to provision a Client ID,
	  potentially a Client Secret, and other metadata parameters.
        </t>

        <t>An example of an Explicit Registration is provided in
          <xref target="ExplicitRegExample"/>.
        </t>

          <section anchor="Cliregreq" title="Explicit Client Registration Request">
            <t>
              The RP performs Explicit Client Registration as follows:
            </t>
            <t>
              <list style="numbers">

                <t>
                  Once the RP has determined a set of Trust Anchors it has in common with the OP,
                  it chooses the subset it wants to proceed with. This
                  may be a single Trust Anchor, or it can also be more than one.
                  The RP MUST perform Trust Chain and metadata resolution for
                  the OP, as specified in <xref target="resolving_trust"/>. If
                  the resolution is not successful, the RP MUST abort the
                  request.
                </t>
                <t>
                  Using this subset of Trust Anchors, the RP chooses a set of
                  <spanx style="verb">authority_hints</spanx>
                  from the hints that are available to it. Each hint MUST,
                  when used as a starting point for Trust Chain collection,
                  lead to at least one of the Trust Anchors in the subset.
                  If the RP has more than one Trust Anchor in common with the
                  OP it MUST select a subset of Trust Anchors to proceed with.
                  The subset may be as small as a single Trust Anchor, or
                  include multiple ones.
                </t>
                <t>
                  The RP will then construct its Entity Configuration,
                  where the metadata statement chosen is influenced by the OP's
                  metadata and where the
                  <spanx style="verb">authority_hints</spanx>
                  included are picked by the process described above.
                  From its Immediate Superiors, the RP MUST select
                  one or more <spanx style="verb">authority_hints</spanx> so
                  that every hint, when used as the starting point for a Trust Chain
                  collection, leads to at least one of the Trust Anchors
                  in the subset selected above.
                </t>
                <t>
                  The RP MAY include its Entity Configuration
                  in a Trust Chain regarding itself.
                  There are two ways to do this.
		  The first way is for the Registration Request to contain an
                  array with the sequence of
                  Entity Statements that compose the Trust Chain
                  between the RP that is making the request and the
                  selected Trust Anchor.
		  The second way is to use the
		  <spanx style="verb">trust_chain</spanx> header parameter,
		  as specified in <xref target="trust_chain_head_param"/>.
		  <vspace blankLine="1"/>

		  NOTE: The use of the
		  <spanx style="verb">trust_chain</spanx> header parameter
		  in the request JWT is RECOMMENDED over the first syntax;
		  it is retained for historical reasons.
		</t>
		<t>
                  The RP MUST include its
                  metadata in its Entity Configuration and use the
                  <spanx style="verb">authority_hints</spanx> selected above.
                  <vspace blankLine="1"/>

                  The RP SHOULD select its metadata parameters to comply with
                  the OP's Resolved Metadata and thus ensure a successful
                  registration with the OP. Note that if the submitted RP
                  metadata is not compliant with the metadata of the OP, the
                  OP may choose to modify it to make it compliant
                  rather than reject the request with an error response.
                </t>

                <t>
                  The Entity Configuration, or the entire Trust Chain,
                  is sent, using HTTP POST, to the
                  <spanx style="verb">federation_registration_endpoint</spanx>.
                  The Entity Configuration or Trust Chain is the entire POST body.
                  The RP MUST sign its Entity Configuration with a current
                  Federation Entity Key in its possession.
                </t>
                <t>
                  The content type of the Registration Request MUST be
                  <spanx style="verb">application/entity-statement+jwt</spanx>
                  when it is the Entity Configuration of the requestor.
                  Otherwise, when it is a Trust Chain, the
                  content type of the Registration Request MUST be
                  <spanx style="verb">application/trust-chain+json</spanx>.
                  The RP MAY include its Entity Configuration in a Trust Chain
                  that leads to the RP. In this case, the registration request
                  will contain an array consisting of the sequence of
                  statements that make up the Trust Chain between the RP and
                  the Trust Anchor the RP selected.
                </t>
		<t>
		  The <spanx style="verb">trust_chain</spanx> header parameter
		  MAY be included to provide a Trust Chain between the RP
		  and the Trust Anchor the RP selected
		  when the request is the Entity Configuration of the RP.
		  This is equivalent to providing the Trust Chain as the request body.
		  When the <spanx style="verb">trust_chain</spanx> header parameter
		  is included,
		  the <spanx style="verb">peer_trust_chain</spanx> header parameter
		  MAY also be included to provide a Trust Chain between the OP
		  and the Trust Anchor the RP selected.
		  The Peer Trust Chain contains metadata and policy values
		  that the RP has chosen for the OP to use during the registration.
		  The <spanx style="verb">peer_trust_chain</spanx> header parameter
		  MUST NOT be used when the request body is a Trust Chain.
		  The Trust Anchors selected in both Trust Chains MUST be the same.
		  Inclusion of both Trust Chains enables achieving
		  the Federation Integrity and Metadata Integrity properties,
		  as defined in <xref target="App-Fed-Linkage"/>.
		</t>
              </list>
            </t>
            <t>
              The following Entity Configuration Claims are specified for use
              in Explicit Registration requests. Their full descriptions are in
              <xref target="entity-statement"/>.
            </t>
            <t>
              <list style="hanging">
                <t hangText="iss">
                  <vspace/>
                  REQUIRED.
                  Its value MUST be the Entity Identifier of the RP.
                </t>
                <t hangText="sub">
                  <vspace/>
                  REQUIRED.
                  Its value MUST be the Entity Identifier of the RP.
                </t>
                <t hangText="iat">
                  <vspace/>
                  REQUIRED.
                </t>
                <t hangText="exp">
                  <vspace/>
                  REQUIRED.
                </t>
                <t hangText="jwks">
                  <vspace/>
                  REQUIRED.
                </t>
                <t hangText="aud">
                  <vspace/>
                  REQUIRED.
		  The "aud" (audience) value MUST be the Entity Identifier of the OP
		  and MUST NOT include any other values.
                  This Claim is used in Explicit Registration requests;
		  it is not a general Entity Statement Claim.
                </t>
                <t hangText="authority_hints">
                  <vspace/>
                  REQUIRED.
                </t>
                <t hangText="metadata">
                  <vspace/>
                  REQUIRED.
                  It MUST contain the RP metadata under the
		  <spanx style="verb">openid_relying_party</spanx>
		  Entity Type Identifier.
                </t>
                <t hangText="crit">
                  <vspace/>
                  OPTIONAL.
                </t>
                <t hangText="trust_marks">
                  <vspace/>
                  OPTIONAL.
                </t>
              </list>
            </t>
            <t>
              The request MUST be an HTTP request to the
              <spanx style="verb">federation_registration_endpoint</spanx> of
              the OP, using the POST method.
            </t>
            <t>
              When the RP submits an Entity Configuration the content type of
              the request MUST be
              <spanx style="verb">application/entity-statement+jwt</spanx>.
              When the RP submits a Trust Chain, the content type MUST be
              <spanx style="verb">application/trust-chain+json</spanx>.
            </t>
          </section>

            <section anchor="ExplicitRegOP" title="Processing Explicit Client Registration Request by OP">
              <t>
                The OP processes the request as follows:
              </t>
              <t>
                <list style="numbers">
                  <t>
                    Upon receiving a registration request, the OP MUST inspect
                    the content type to determine whether it contains an Entity Configuration
                    or an entire Trust Chain.
                  </t>
		  <t>
		    The OP MUST validate the RP's explicit registration request JWT.
		    All the normal Entity Statement validation rules apply.
		    In addition, if the <spanx style="verb">aud</spanx> (audience)
		    Claim Value is not the Entity Identifier of the OP,
		    then the request MUST be rejected.
		  </t>
                  <t>
                    If no Trust Chain is provided from the RP to the Trust Anchor
		    in the request, the OP MUST use the provided Entity Configuration
		    to complete the Federation Entity Discovery by
                    collecting and evaluating the Trust Chains that start with
                    the <spanx style="verb">authority_hints</spanx> in the
                    Entity Configuration of the RP. After validating at least
                    one Trust Chain, the OP MUST verify the signature of the
                    received Entity Configuration. If the OP finds more than
                    one acceptable Trust Chain, it MUST choose one Trust Chain
                    from among them as the one to proceed with.
                  </t>
                  <t>
                    If the request body is a Trust Chain, the OP MAY evaluate
                    the statements in the Trust Chain to save the HTTP calls
                    that are necessary to perform the Federation Entity Discovery,
                    especially if the RP included more than one
                    authority hint in its Entity Configuration. Otherwise, the
                    OP MUST extract the RP's Entity Configuration from the Trust Chain
                    and proceed according to Step 3,
		    as if only an Entity Configuration was received.
		  </t>
		  <t>
		    When a Trust Chain is provided using the
		    <spanx style="verb">trust_chain</spanx> header parameter
		    in the request's Entity Configuration,
		    the OP MAY likewise evaluate
		    the statements in the Trust Chain to save the HTTP calls
		    that are necessary to perform the Federation Entity Discovery.
		    Note that in this case, the RP's Entity Configuration
		    in the Trust Chain is only used to establish that
		    there is a path from the RP to the Trust Anchor;
		    it is the metadata, etc. in the request Entity Configuration,
		    which may be tailored by the RP for the OP,
		    that is used when processing the registration request.
		    If the provided Trust Chain is not used,
		    the OP MUST proceed according to Step 3,
		    using the request Entity Configuration.
		  </t>
		  <t>
		    If the request uses
		    the <spanx style="verb">peer_trust_chain</spanx> header parameter
		    to include a Trust Chain from the OP
		    to the Trust Anchor that the RP selected,
		    verify that it begins at the OP.
		    Furthermore, verify that it ends at the same Trust Anchor
		    as any provided Trust chain from the RP to the Trust Anchor.
		    The OP SHOULD use the metadata and policy values
		    that the RP has chosen during the registration.
		  </t>
                  <t>
                    At this point, if the OP finds that it already has an
                    existing client registration for the requesting RP, then
                    that registration MUST be invalidated. The precise time of
                    the invalidation is at the OP's discretion, as the OP may
                    want to ensure the completion of concurrent OpenID
                    authentication requests initiated by the RP while the
                    registration request is being processed.
                    <vspace blankLine="1"/>

                    The OP MAY retain client credentials and key material from
                    the invalidated registration in order to verify past RP
                    signatures and perform other cryptographic operations on
                    past RP data.
                  </t>
                  <t>
                    The OP uses the Resolved Metadata for the RP to create a client
                    registration compliant with its own OP metadata and other
                    applicable policies.
                    <vspace blankLine="1"/>

                    The OP MAY provision the RP with a
                    <spanx style="verb">client_id</spanx> other than the RP's
                    Entity Identifier. This enables Explicit Registration to be
                    implemented on top of the
                    <xref target="OpenID.Registration">OpenID Connect Dynamic
                    Client Registration 1.0</xref> endpoint of an OP.
                    <vspace blankLine="1"/>

                    If the RP is provisioned with a
                    <spanx style="verb">client_secret</spanx> it MUST NOT
                    expire before the expiration of the registration Entity Statement
                    that will be returned to the RP.
                    <vspace blankLine="1"/>

                    The OP SHOULD NOT provision the RP with a
                    <spanx style="verb">registration_access_token</spanx> and a
                    <spanx style="verb">registration_client_uri</spanx>
                    because the expected way for the RP to update its
                    registration is to make a new Explicit Registration
                    request. If the RP is provisioned with a
                    <spanx style="verb">registration_access_token</spanx> for
                    some purpose, for example, to let it independently check its
                    registered metadata, the token MUST NOT allow modification
                    of the registration.
                    <vspace blankLine="1"/>

                    The OP MAY modify the received RP metadata, for example, by
                    substituting an invalid or unsupported parameter,
                    to make it compliant with its own OP metadata and other
                    policies. If the OP does not accept the RP metadata or is
                    unwilling to modify it to make it compliant, it
                    MUST return a client registration error response, with an
                    appropriate error, such as
                    <spanx style="verb">invalid_client_metadata</spanx> or
                    <spanx style="verb">invalid_redirect_uri</spanx>, as
                    specified in Section 3.3 of
                    <xref target="OpenID.Registration"/>.
                  </t>
                  <t>
                    The OP MUST assign an expiration time to the created
                    registration. This time MUST NOT exceed the expiration time
                    of the Trust Chain that the OP selected to process the request.
                  </t>
                </list>
	      </t>
	    </section>

          <section anchor="cliregresp" title="Successful Explicit Client Registration Response">
                  <t>
                    If the OP created a client registration for the RP, it MUST
                    then construct a success response in the form of an Entity Statement.
		  </t>
		  <t>
                    The OP MUST set the <spanx style="verb">trust_anchor</spanx>
                    Claim of the Entity Statement to the Trust Anchor it
                    selected to process the request. The
                    <spanx style="verb">authority_hints</spanx> Claim MUST be
                    set to the RP's Immediate Superior in the
                    selected Trust Chain.
		  </t>
		  <t>
                    The OP MUST set the <spanx style="verb">exp</spanx> Claim
                    to the expiration time of the created registration. The OP
                    MAY choose to invalidate the registration before that, as
                    explained in <xref target="AfterExplicitReg"/>.
		  </t>
		  <t>
                    The OP MUST express the client registration it created for
                    the RP by means of the <spanx style="verb">metadata</spanx>
                    Claim, by placing the metadata parameters under the
		    <spanx style="verb">openid_relying_party</spanx>
		    Entity Type Identifier.
		    The parameters MUST include the
                    <spanx style="verb">client_id</spanx> that was provisioned
                    for the RP. If the RP was provisioned with credentials,
                    for example, a <spanx style="verb">client_secret</spanx>,
                    these MUST be included as well.
		  </t>
		  <t>
                    The OP SHOULD include metadata parameters that have a
                    default value, for example
                    <spanx style="verb">token_endpoint_auth_method</spanx>
                    which has a default value of
                    <spanx style="verb">client_secret_basic</spanx>,
                    to simplify the processing of the response by the RP.
                  </t>
                  <t>
                    The OP MUST sign the registration Entity Statement with a
                    current Federation Entity Key in its possession.
                  </t>
              <t>
		The following Entity Statement Claims
		are used in Explicit Registration responses,
		as specified in <xref target="entity-statement"/>:
              </t>
              <t>
                <list style="hanging">
                  <t hangText="iss">
                    <vspace/>
                    REQUIRED.
                    Its value MUST be the Entity Identifier of the OP.
                  </t>
                  <t hangText="sub">
                    <vspace/>
                    REQUIRED.
                    Its value MUST be the Entity Identifier of the RP.
                  </t>
                  <t hangText="iat">
                    <vspace/>
                    REQUIRED.
		    Time when this statement was issued.
                  </t>
                  <t hangText="exp">
                    <vspace/>
                    REQUIRED.
		    Expiration time after which the statement MUST NOT be
		    accepted for processing.
                  </t>
                  <t hangText="jwks">
                    <vspace/>
                    OPTIONAL.
		    If present, it MUST be a verbatim copy of the
		    <spanx style="verb">jwks</spanx> Entity Statement Claim
                    from the received Entity Configuration of the RP.
		    Note that this is distinct from the identically named RP metadata parameter.
                  </t>
                  <t hangText="aud">
                    <vspace/>
                    REQUIRED.
                    The "aud" (audience) value MUST be the Entity Identifier of the RP
		    and MUST NOT include any other values.
		    This Claim is used in Explicit Registration responses;
		    it is not a general Entity Statement Claim.
                  </t>
                  <t hangText="trust_anchor" anchor="trust_anchor-claim">
                    <vspace/>
                    REQUIRED.
                    Its value MUST be the Entity Identifier of the Trust Anchor
                    that the OP selected to process the Explicit Registration request.
		    If complete Trust Chains to the Trust Anchor selected by the RP
		    were provided in the request and/or by using the
		    <spanx style="verb">peer_trust_chain</spanx> header parameter,
		    this MUST match the Trust Anchors at the roots of those Trust Chains.
		    This Claim is specific to Explicit Registration responses;
		    it is not a general Entity Statement Claim.
                  </t>
                  <t hangText="authority_hints">
                    <vspace/>
                    REQUIRED.
                    It MUST be a single-element array, whose value references
                    the Immediate Superior of the RP in the Trust Chain
                    that the OP selected to process the request.
                  </t>
                  <t hangText="metadata">
                    <vspace/>
                    REQUIRED.
                    It MUST contain the registered RP metadata under the
                    <spanx style="verb">openid_relying_party</spanx>
		    Entity Type Identifier.
                  </t>
                  <t hangText="crit">
                    <vspace/>
                    OPTIONAL.
		    Set of Claims that MUST be understood and processed,
		    as specified in <xref target="common-claims"/>.
                  </t>
                </list>
              </t>
              <t>
                A successful response MUST have an HTTP status code 200 and
                the content type
                <spanx style="verb">application/explicit-registration-response+jwt</spanx>.
		Furthermore, the <spanx style="verb">typ</spanx> header parameter
		value in the response MUST be
		<spanx style="verb">explicit-registration-response+jwt</spanx>
		(and not <spanx style="verb">entity-statement+jwt</spanx>)
		to prevent cross-JWT confusion between the Explicit Registration response
		and other kinds of Entity Statements,
		per Section 3.11 of <xref target="RFC8725"/>.
              </t>
	    </section>

	    <section anchor="ExplicitError" title="Explicit Client Registration Error Response">
              <t>
                For a client registration error, the response is as defined in
                <xref target="error_response"/> and MAY use errors defined there and in
                Section 3.3 of <xref target="OpenID.Registration"/> and
		Section 3.2.2 of <xref target="RFC7591"/>.
              </t>
            </section>

            <section anchor="ExplicitRegRP" title="Processing Explicit Client Registration Response by RP">
              <t>
                <list style="numbers">
                  <t>
                    If the response indicates success, the RP MUST verify that
                    its content is a valid Entity Statement and issued by the OP.
                    <vspace blankLine="1"/>

                    The RP MUST ensure the signing Federation Entity Key used
                    by the OP is present in the
                    <spanx style="verb">jwks</spanx> Claim of the Subordinate Statement
                    issued by the OP's Immediate Superior
                    in a Trust Chain that the RP successfully resolved for the
                    OP when it prepared the Explicit Registration request.
                  </t>
                  <t>
                    The RP MUST verify that the <spanx style="verb">aud</spanx> (audience)
                    Claim Value is its Entity Identifier.
                  </t>
                  <t>
                    The RP MUST verify that the
                    <spanx style="verb">trust_anchor</spanx> represents one
                    of its own Trust Anchors.
		    If complete Trust Chains to the Trust Anchor selected by the RP
		    were provided in the request and/or by using the
		    <spanx style="verb">peer_trust_chain</spanx> header parameter,
		    the RP MUST verify that this matches
		    the Trust Anchors at the root of those Trust Chains.
                  </t>
                  <t>
                    The RP MUST verify that at least one of the
                    <spanx style="verb">authority_hints</spanx> it specified in
                    the Explicit Registration request leads to the Trust Anchor
                    that the OP set in the
                    <spanx style="verb">trust_anchor</spanx> Claim.
                  </t>
                  <t>
                    The RP MUST first ensure that the information it was registered with
                    at the OP contains the same set of Entity Types as the request does.
                    After having collected a Trust Chain using the response Claim
                    <spanx style="verb">trust_anchor</spanx> as the
                    Entity Identifier for the Trust Anchor and
                    <spanx style="verb">authority_hints</spanx> as starting points
                    for the Trust Chain collection,
                    the RP SHOULD verify that the response metadata for each entity type is valid
                    by applying the resolved policies to the received metadata, as
                    specified in <xref target="metadata_policy_resolution"/>.
                  </t>
                  <t>
                    If the received registration Entity Statement does not pass the above
                    checks, the RP MUST reject it. The RP MAY choose to retry
                    the Explicit Registration request to work around a
                    transient exception, for example, due to a recent change of
                    Entity metadata or metadata policy causing temporary
                    misalignment of metadata.
                  </t>
                </list>
              </t>
            </section>

        <section title="Explicit Client Registration Lifetime" anchor="AfterExplicitReg">
          <t>
            An RP can utilize the <spanx style="verb">exp</spanx> Claim of the
            registration Entity Statement to devise a suitable strategy for
            renewing its client registration. RP implementers should note that
            if the RP's registration has expired at the OP,
	    this can cause OpenID Connect authentication requests, token requests,
	    and/or UserInfo requests to fail. Renewing the RP's registration
            prior to its expiration can prevent such errors from
            occurring and ensure the end-user experience is not disrupted.
          </t>
          <t>
            An OP MAY invalidate a client registration before the expiration
            that is indicated in the registration Entity Statement for the RP.
            An example reason could be the OP leaving the federation that was
            used to register the RP.
          </t>
        </section>

      </section>

      <section title="Registration Validity and Trust Reevaluation" anchor="client_reg_trust_re_eval">
        <t>
          The validity of an Automatic or Explicit Registration at an OP MUST
          NOT exceed the lifetime of the Trust Chain the OP used to create the
          registration. An OP MAY choose to expire the registration at some
          earlier time, or choose to perform additional periodic reevaluations
          of the Trust Chain for the registered RP before the Trust Chain
          reaches its expiration time.
        </t>
        <t>
          Similarly, an RP that obtained an Automatic or Explicit Registration
          MUST NOT use it past the expiration of the Trust Chain the RP used to
          establish trust in the OP. For an RP using Automatic Registration, the
          trust in the OP MUST be successfully reevaluated before continuing to
          make requests to the OP. For an RP using Explicit Registration, the RP
          MUST successfully renew its registration. An RP MAY choose to perform
          additional periodic reevaluations of the Trust Chain for the OP
          before the Trust Chain reaches its expiration time.
        </t>
      </section>

      <section title="Differences between Automatic Registration and Explicit Registration" anchor="AutomaticVsExplicit">
        <t>
          The primary differences between Automatic Registration and Explicit Registration are:
          <list style="symbols">
            <t>
              With Automatic Registration, there is no registration step prior to the Authentication Request,
              whereas with Explicit Registration, there is.
              (<xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>
              and <xref target="RFC7591">OAuth 2.0 Dynamic Client Registration</xref>
              also employ a prior registration step.)
            </t>
            <t>
              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.
            </t>
            <t>
	      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.
	      Whereas with Explicit Registration, a broader set of options
	      is available for authenticating the Client,
	      including the use of a Client Secret.
            </t>
          </list>
        </t>
      </section>

      <section title="Rationale for Trust Chains in the Request" anchor="TrustChainRationale">
        <t>
          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 provides the following benefits:
          <list style="symbols">

          <t>
            It solves the problem of OPs using RP metadata that has become stale.
            This stale data may occur when the OP uses cached RP metadata from a Trust Chain
            that has not reached its expiration time yet.
            The RP MAY notify the OP that a change has taken place by including
            the <spanx style="verb">trust_chain</spanx> header parameter
            or the <spanx style="verb">trust_chain</spanx> request parameter
	    in the request,
            thus letting the OP update its Client Registration
	    and preventing potential temporary faults due to stale metadata.
          </t>

          <t>
            It enables the RP to pass a verifiable hint for which trust path to
            take to build the Trust Chain. This can reduce the costs
            of RP Federation Entity Discovery for OPs in complex federations where the
            RP has multiple Trust Anchors or the Trust Chain resolution may
            result in dead-ends.
          </t>

          <t>
            It enables direct passing of the Entity Configuration, including
            any present Trust Marks, thus saving the OP from having to make
            an HTTP request to the RP
            <spanx style="verb">/.well-known/openid-federation</spanx>
            endpoint.
          </t>

	  </list>
        </t>
	<t>
	  Both also support the submission of the Peer Trust Chain,
	  which provides a Trust Chain between the OP
	  and the Trust Anchor the RP selected.
	  As described in <xref target="peer_trust_chain_head_param"/>,
	  inclusion of both Trust Chains enables achieving
	  the Federation Integrity and Metadata Integrity properties,
	  as defined in <xref target="App-Fed-Linkage"/>.
	</t>
      </section>

    </section>

    <section anchor="GeneralPurposeClaims" title="General-Purpose JWT Claims">
      <t>
	This section defines general-purpose JWT Claims designed to be used
	by many different JWT profiles.
	They are also used in specific kinds of JWTs defined by this specification.
      </t>

      <section anchor="jwksClaim" title='"jwks" (JSON Web Key Set) Claim'>
	<t>
	  The <spanx style="verb">jwks</spanx> (JSON Web Key Set) Claim
	  value is a JWK Set, as defined in <xref target="RFC7517"/>.
	  It is used to convey a set of cryptographic keys.
	  Use of this Claim is OPTIONAL.
	</t>
	<t>
	  For instance, the <spanx style="verb">jwks</spanx> (JSON Web Key Set) Claim
	  might be used to represent a set of signing keys for an application.
	  This Claim is used in this specification as specified in <xref target="common-claims"/>
	  to represent the public keys used to sign the Entity Statement.
	</t>
      </section>

      <section anchor="metadataClaim" title='"metadata" Claim'>
	<t>
	  The <spanx style="verb">metadata</spanx> Claim
	  is used for conveying metadata pertaining to the JWT.
	  Its value is a JSON object.
	  The details of the metadata contained are application-specific.
	  Use of this Claim is OPTIONAL.
	</t>
	<t>
	  For instance, the <spanx style="verb">metadata</spanx> Claim
	  might be used to represent a set of endpoint URLs
	  and algorithm identifiers in an API description.
	  This Claim is used in this specification as specified in <xref target="common-claims"/>
	  to represent metadata about the Entity.
	</t>
      </section>

      <section anchor="constraintsClaim" title='"constraints" Claim'>
	<t>
	  The <spanx style="verb">constraints</spanx> Claim
	  is used for conveying constraints pertaining to the JWT.
	  Its value is a JSON object.
	  The details of the constraints contained are application-specific.
	  Use of this Claim is OPTIONAL.
	</t>
	<t>
	  For instance,
	  this Claim is used in this specification as specified in <xref target="ss-specific"/>
	  to represent constraints on the Trust Chain for the Entity.
	</t>
      </section>

      <section anchor="critClaim" title='"crit" (Critical) Claim'>
	<t>
	  The <spanx style="verb">crit</spanx> (critical) Claim
	  indicates that extensions to the set of Claims
	  specified for use in this type of JWT are being used
	  that MUST be understood and processed.
	  It is used in the same way that
	  the <spanx style="verb">crit</spanx> header parameter
	  is used for extension JOSE header parameters
	  that MUST be understood and processed.
	  Its value is an array listing the Claim Names
	  present in the JWT that use those extensions.
	  If any of the listed Claims are not
	  understood and supported by the recipient, then the JWT is invalid.
	  Producers MUST NOT include Claim Names already
	  specified for use in this type of JWT,
	  duplicate names, or
	  names that do not occur as Claim Names in the JWT
	  in the <spanx style="verb">crit</spanx> list.
	  Producers MUST NOT use the empty array
	  <spanx style="verb">[]</spanx>
	  as the <spanx style="verb">crit</spanx> value.
	  Use of this Claim is OPTIONAL.
	</t>
	<t>
	  Section 4 of <xref target="RFC7519"/> states that
	  "Specific applications of JWTs will require implementations
	  to understand and process some claims in particular ways.
	  However, in the absence of such requirements, all claims
	  that are not understood by implementations MUST be ignored."
	  Thus, for the <spanx style="verb">crit</spanx> (critical) Claim to be effective,
	  the definition for the particular kind of JWT using it MUST
	  specify that <spanx style="verb">crit</spanx> MUST be
	  understood and processed, as allowed in the statement above.
	</t>
	<t>
	  This Claim is used in this specification as specified in <xref target="common-claims"/>
	  to identify Claims not defined by this specification
	  that MUST be understood and processed
	  when used in Entity Statements.
	</t>
      </section>

      <section anchor="refClaim" title='"ref" (Reference) Claim'>
	<t>
	  The <spanx style="verb">ref</spanx> (reference) Claim
	  is used for conveying the URI for a resource pertaining to the JWT.
	  It plays a similar role in a JWT as
	  the <spanx style="verb">href</spanx> property does in HTML.
	  The nature of the content at the referenced resource
	  is generally application specific.
	  The <spanx style="verb">ref</spanx> value is a case-sensitive string
	  containing a URI value.
	  Use of this Claim is OPTIONAL.
	</t>
	<t>
	  For instance, a JWT referring to a contract between two parties might use
	  the <spanx style="verb">ref</spanx> (reference) Claim
	  to refer to a resource at which the contract terms can be read.
	  This Claim is used in this specification as specified in <xref target="trust_mark_claims"/>
	  to provide a URL referring to human-readable information
	  about the issuance of the Trust Mark.
	</t>
      </section>

      <section anchor="delegationClaim" title='"delegation" Claim'>
	<t>
	  The <spanx style="verb">delegation</spanx> Claim expresses that
	  authority is being delegated to the party referenced in the Claim Value.
	  The <spanx style="verb">delegation</spanx> value is a case-sensitive string
	  containing a StringOrURI value.
	  Use of this Claim is OPTIONAL.
	</t>
	<t>
	  For instance, the <spanx style="verb">delegation</spanx> Claim
	  might be used to express that the referenced party may sign
	  a legal document on behalf of the subject.
	  This Claim is used in this specification as specified in <xref target="trust_mark_claims"/>
	  to represent delegation of the right to issue Trust Marks
	  with a particular identifier.
	</t>
	<t>
	  Note that the <spanx style="verb">delegation</spanx> Claim is both
	  syntactically and semantically distinct from the existing
	  <spanx style="verb">act</spanx> Claim <xref target="IANA.JWT.Claims"/>.
	  <spanx style="verb">act</spanx> is a JSON object whereas
	  <spanx style="verb">delegation</spanx> is a StringOrURI.
	  Semantically, the Delegation JWT defined in <xref target="delegation_jwt"/>
	  carries a signature by an issuer cryptographically proving
	  the right to delegate to the party.
	  The <spanx style="verb">act</spanx> Claim, carrying no signature,
	  cannot achieve this.
	</t>
      </section>

      <section anchor="logo_uriClaim" title='"logo_uri" (Logo URI) Claim'>
	<t>
	  The <spanx style="verb">logo_uri</spanx> Claim
	  value is a URI that references a logo pertaining to the JWT.
	  Use of this Claim is OPTIONAL.
	</t>
	<t>
	  For instance, the <spanx style="verb">logo_uri</spanx> Claim
	  might be used to represent the location from which to retrieve
	  the logo of an organization to display in a user interface.
	  This Claim is used in this specification as specified in <xref target="trust_mark_claims"/>
	  to convey a URL that references a logo for the Entity.
	</t>
      </section>
    </section>

    <section anchor="ClaimsLanguagesAndScripts" title="Claims Languages and Scripts">
      <t>
        Human-readable Claim Values and Claim Values that reference human-readable values
        MAY be represented in multiple languages and scripts.
        This specification enables such representations in the same manner as defined in
        Section 5.2 of <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>.
      </t>
      <t>
        As described in OpenID Connect Core,
	to specify the languages and scripts, <xref
              target="RFC5646">BCP47</xref> language tags are added to member names,
        delimited by a <spanx style="verb">#</spanx> character.  For example,
        <spanx style="verb">family_name#ja-Kana-JP</spanx> expresses the
        Family Name in Katakana in Japanese, which is commonly used to index
        and represent the phonetics of the Kanji representation of the same name
        represented as <spanx style="verb">family_name#ja-Hani-JP</spanx>.
      </t>
      <t>
	Language tags can be used in any data structures
	containing or referencing human-readable values,
	including metadata parameters and Trust Mark parameters.
	For instance, both <spanx style="verb">organization_name</spanx> and
	<spanx style="verb">organization_name#de</spanx> might occur together in metadata.
      </t>
    </section>

    <section anchor="MediaTypes" title="Media Types">
      <t>
	These media types <xref target="RFC2046"/> are defined by this specification.
      </t>

      <section anchor="entity-statement+jwt"
	       title='"application/entity-statement+jwt" Media Type'>
	<t>
	  The <spanx style="verb">application/entity-statement+jwt</spanx>
	  media type is used to specify that the associated content is
	  an Entity Statement, as defined in <xref target="entity-statement"/>.
	  No parameters are used with this media type.
	</t>
      </section>

      <section anchor="trust-mark+jwt"
	       title='"application/trust-mark+jwt" Media Type'>
	<t>
	  The <spanx style="verb">application/trust-mark+jwt</spanx>
	  media type is used to specify that the associated content is
	  a Trust Mark, as defined in <xref target="trust_marks"/>.
	  No parameters are used with this media type.
	</t>
      </section>

      <section anchor="resolve-response+jwt"
	       title='"application/resolve-response+jwt" Media Type'>
	<t>
	  The <spanx style="verb">application/resolve-response+jwt</spanx>
	  media type is used to specify that the associated content is
	  a Resolve Response, as defined in <xref target="resolve-response"/>.
	  No parameters are used with this media type.
	</t>
      </section>

      <section anchor="trust-chain+json"
	       title='"application/trust-chain+json" Media Type'>
	<t>
	  The <spanx style="verb">application/trust-chain+json</spanx>
	  media type is used to specify that the associated content is
	  a JSON array representing a Trust Chain, as defined in <xref target="trust_chain"/>.
	  No parameters are used with this media type.
	</t>
      </section>

      <section anchor="trust-mark-delegation+jwt"
	       title='"application/trust-mark-delegation+jwt" Media Type'>
	<t>
	  The <spanx style="verb">application/trust-mark-delegation+jwt</spanx>
	  media type is used to specify that the associated content is
	  a Trust Mark delegation, as defined in <xref target="delegation_jwt"/>.
	  No parameters are used with this media type.
	</t>
      </section>

      <section anchor="jwk-set+jwt"
	       title='"application/jwk-set+jwt" Media Type'>
	<t>
	  The <spanx style="verb">application/jwk-set+jwt</spanx>
	  media type is used to specify that the associated content is
	  a signed JWK Set, as defined in <xref target="HistKeysResp"/>.
	  No parameters are used with this media type.
	</t>
      </section>

      <section anchor="trust-mark-status-response+jwt"
	       title='"application/trust-mark-status-response+jwt" Media Type'>
	<t>
	  The <spanx style="verb">application/trust-mark-status-response+jwt</spanx>
	  media type is used to specify that the associated content is
	  a Trust Mark Status Response,
	  as defined in <xref target="tm-status-response"/>.
	  No parameters are used with this media type.
	</t>
      </section>

      <section anchor="explicit-registration-response+jwt"
	       title='"application/explicit-registration-response+jwt" Media Type'>
	<t>
	  The <spanx style="verb">application/explicit-registration-response+jwt</spanx>
	  media type is used to specify that the associated content is
	  an Explicit Registration response, as defined in <xref target="cliregresp"/>.
	  No parameters are used with this media type.
	</t>
      </section>

    </section>

    <section anchor="StringOps" title="String Operations">
      <t>
	Processing some OpenID Federation messages requires comparing
	values in the messages to other values.
	For example, the Entity Identifier in
	an <spanx style="verb">iss</spanx> Claim might be compared to
	the Entity Identifier in a <spanx style="verb">sub</spanx> Claim.
	Comparing Unicode <xref target="UNICODE"/> strings,
	however, has significant security implications.
      </t>
      <t>
	Therefore, comparisons between JSON strings and other Unicode
	strings MUST be performed as specified below:

	<list style="numbers">
	  <t>
	    Remove any JSON applied escaping to produce an array of
	    Unicode code points.
	  </t>
	  <t>
	    Unicode Normalization <xref target="USA15"/> MUST NOT
	    be applied at any point to either the JSON string or to
	    the string it is to be compared against.
	  </t>
	  <t>
	    Comparisons between the two strings MUST be performed as a
	    Unicode code point to code point equality comparison.
	  </t>
	</list>
      </t>
      <t>
	Note that this is the same comparison procedure as specified in
	Section 14 of <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>.
      </t>
    </section>

    <section anchor="Implementation" title="Implementation Considerations">
      <t>
	This section provides guidance to implementers and deployers of Federations
	on situations and properties that they should consider for their Federations.
      </t>

      <section anchor="Topologies" title="Federation Topologies">
	<t>
	  It is possible to construct Federation topologies that have
	  multiple trust paths between Entities.
	  The specification does not disallow this, but it can create
	  ambiguities that deployers need to be aware of.
	</t>
	<figure>
	  <preamble>
	    Consider the following Federation topology:
	  </preamble>
	  <name>
	    Example Topology with Multiple Trust Paths between Entities
	  </name>
	  <artwork><![CDATA[
              .--------------.
              | Trust Anchor |
              '--.---.-----.-'
                 |   |     |
              .--'   '--.  '---------------.
              |         |                  |
.-------------v--.   .--v-------------.    |
| Intermediate 1 |   | Intermediate 2 |    |
'-------------.--'   '--.-------------'    |
              |         |                .-v--.
              |         |                | OP |
           .--v---------v---.            '----'
           | Intermediate 3 |
           '-------.--------'
                   |
                   |
                 .-v--.
                 | RP |
                 '----'
]]></artwork>
	</figure>
	<t>
	  In this topology, there are multiple trust paths between
	  the RP and the Trust Anchor, meaning that
	  multiple different Trust Chains could be built between them.
	  If the metadata policies of Intermediate 1 and Intermediate 2 are different,
	  this could result in the Resolved Metadata for the RP differing,
	  depending upon which Intermediate is used when building the Trust Chain.
	  Some such differences will be innocuous and some can cause failures.
	</t>
	<t>
	  It is the job of the Federation architects to deploy topologies and
	  metadata policies that work as intended, no matter which trust path
	  is chosen when building a Trust Chain.
	  Of course, one way to avoid potential ambiguities is to only use
	  topologies that are trees, without multiple paths between two Entities.
	  Topologies that are not trees are permitted,
	  but should be used consciously and with care.
	</t>
	<t>
	  Even when a Federation topology contains loops, Trust Chains built from them MUST NOT contain loops,
          as mandated in <xref target="fetching-es"/>.
	</t>
      </section>

      <section title="Federation Discovery and Trust Chain Resolution Patterns" anchor="discovery_patterns">
	<t>
	  This section describes different patterns that implementations may use for discovering
	  entities within a federation and for resolving Trust Chains. It is important to distinguish
	  between two related but distinct concepts:
	  <list style="symbols">
	    <t>
	      <strong>Discovery</strong>: The process of finding entities that are part of a federation,
	      typically to build directories or catalogs of available service providers.
	    </t>
	    <t>
	      <strong>Trust Chain Resolution</strong>: The process of building and validating a Trust Chain
	      from a known entity to a Trust Anchor, as described in <xref target="resolving_trust"/>.
	      This process is also known as Federation Entity Discovery in this specification
	      (per the definition in <xref target="Terminology"/>).
	    </t>
	  </list>
	</t>

	<t>
	  While these patterns may involve both discovery and Trust Chain resolution, they serve different
	  purposes and may be used independently, depending on the use case. For example, a discovery service
	  building a directory of OpenID Providers may collect entity identifiers without necessarily
	  resolving Trust Chains for all discovered entities, since the actual Trust Chain resolution
	  may occur later on, for example, when an RP and OP engage in an authentication transaction,
          and use the Trust Chain resolution process described in <xref target="resolving_trust"/>.
	</t>

	<t>
	  Implementations may support one or more of the following patterns:
	  <list style="symbols">
	    <t>
	      <xref target="bottom_up_discovery">Bottom-Up Trust Chain Resolution</xref>: Resolving Trust Chains
	      starting from a known entity identifier, as described in <xref target="resolving_trust"/>.
	    </t>
	    <t>
	      <xref target="top_down_discovery">Top-Down Discovery</xref>: Finding entities within a federation
	      by starting from a Trust Anchor and traversing down the hierarchy.
	    </t>
	    <t>
	      <xref target="single_point_discovery">Single Point of Trust Resolution</xref>: Delegating Trust Chain
	      resolution to a trusted resolver implementing the Resolve Endpoint.
	    </t>
	  </list>
	</t>

	<t>
	  Federation operators may choose to support multiple patterns to accommodate different use cases
	  and integration scenarios. The choice of supported patterns affects the federation's usability
	  and the types of applications that can effectively integrate with it.
	</t>

	<section title="Bottom-Up Trust Chain Resolution" anchor="bottom_up_discovery">
	  <t>
	    Bottom-up Trust Chain resolution is the process described in <xref target="resolving_trust"/>,
	    also known as Federation Entity Discovery (see the definition in the Terminology section).
	    This process starts with a known Entity Identifier and builds a Trust Chain by traversing up the
	    federation hierarchy until reaching a Trust Anchor. This pattern is not discovery in the sense of
	    finding unknown entities, but rather trust resolution for a known entity.
	  </t>

	  <t>
	    This pattern is used when an entity needs to verify the trustworthiness of another entity whose
	    Entity Identifier is already known. This is typically used for:
	    <list style="symbols">
	      <t>OpenID Providers verifying Relying Parties during authentication requests,</t>
	      <t>Resource servers verifying Client trustworthiness,</t>
	      <t>Any Entity validating incoming requests from known parties, and</t>
	      <t>Dynamic trust establishment in federated environments.</t>
	    </list>
	  </t>

	  <t>
	    The bottom-up Trust Chain resolution process follows these steps, as described in <xref target="resolving_trust"/>:
	    <list style="numbers">
	      <t>Start with the subject entity's Entity Configuration (provided or fetched using the process defined in <xref target="federation_configuration"/>).</t>
	      <t>Use <spanx style="verb">authority_hints</spanx> to identify immediate superior entities.</t>
	      <t>Fetch Entity Configuration for each Superior Entity.</t>
	      <t>Use Fetch Endpoints (as defined in <xref target="fetch_statement"/>) to obtain Subordinate Statements about the subject entity.</t>
	      <t>Recursively traverse up the hierarchy until reaching a Trust Anchor.</t>
	      <t>Build and validate the complete Trust Chain.</t>
	      <t>Apply federation policies to derive Resolved Metadata.</t>
	    </list>
	  </t>
	</section>

	<section title="Top-Down Discovery" anchor="top_down_discovery">
	  <t>
	    Top-down discovery is the process of finding entities that are part of a federation by starting
	    from a known Trust Anchor and traversing down the federation hierarchy. This pattern is used
	    when the goal is to discover available entities, particularly entities of specific Entity Types,
	    without necessarily knowing their Entity Identifiers in advance.
	  </t>

	  <t>
	    This pattern is particularly useful for:
	    <list style="symbols">
	      <t>Service discovery by Relying Parties looking for OpenID Providers,</t>
	      <t>Resource discovery by Clients looking for specific service types,</t>
	      <t>Federation browsing and exploration, and</t>
	      <t>Building provider directories and catalogs (e.g., WAYF services, Seamless Access).</t>
	    </list>
	  </t>

	  <t>
	    The top-down discovery process follows these steps:
	    <list style="numbers">
	      <t>Start with a known Trust Anchor that the discovering entity trusts.</t>
	      <t>Use the list endpoint (as defined in <xref target="entity_listing"/>) to discover Immediate Subordinate entities.</t>
	      <t>Filter by <spanx style="verb">entity_type</spanx> parameter to find protocol-specific providers (e.g., <spanx style="verb">openid_provider</spanx>).</t>
	      <t>For Intermediate entities, recursively traverse their Subordinates.</t>
	      <t>Collect Entity Identifiers and optionally Entity Configurations for discovered entities.</t>
	    </list>
	  </t>

	  <t>
	    Note that top-down discovery may or may not include Trust Chain resolution, depending on the use case.
	    For example, when building a directory of OpenID Providers for user selection at login time, the discovery
	    service may collect entity identifiers and basic metadata without resolving Trust Chains for all discovered
	    entities. However, if the discovery service needs to verify that entities
	    are properly registered in the federation before including them in the directory, it may choose to perform Trust Chain resolution as part of the discovery process.
	  </t>

	</section>

	<section title="Single Point of Trust Resolution" anchor="single_point_discovery">
	  <t>
	    Single point of trust resolution delegates the entire Trust Chain resolution process to a trusted
	    resolver implementing the Resolve Endpoint defined in <xref target="resolve"/>. This pattern allows
	    entities to offload the complexity of Trust Chain resolution to a specialized service.
	  </t>

	  <t>
	    This pattern is useful for:
	    <list style="symbols">
	      <t>Entities that want to offload Trust Chain resolution complexity,</t>
	      <t>Centralized trust evaluation services,</t>
	      <t>Performance optimization by caching Resolved Metadata, and</t>
	      <t>Simplified integration for lightweight clients.</t>
	    </list>
	  </t>

	  <t>
	    Note that this pattern requires the Entity Identifier of the subject entity to be known in advance.
	    It does not provide discovery functionality in the sense of finding unknown entities within a federation.
	  </t>

	  <t>
	    The single point of trust resolution process follows these steps:
	    <list style="numbers">
	      <t>Identify a trusted resolver with a Resolve Endpoint.</t>
	      <t>Submit the subject Entity Identifier and Trust Anchor to the resolver.</t>
	      <t>The resolver performs complete Trust Chain resolution internally (following the bottom-up pattern).</t>
	      <t>The resolver returns Resolved Metadata and Trust Marks.</t>
	      <t>Optionally verify the resolver's own Trust Chain.</t>
	      <t>Use Resolved Metadata for protocol operations.</t>
	    </list>
	  </t>
	</section>
      </section>

      <section anchor="anchor_resolver" title="Trust Anchors and Resolvers Go Together">
        <t>
        If only one resolver is present in a federation, that entity should be
        both Trust Anchor and Resolver. If so, users of the resolver will not have to
        collect and evaluate Trust Chains for the Resolver. The Trust Anchor is by definition trusted
        and if the entity also serves as Resolver, that service will be implicitly trusted.
        </t>
      </section>
    <section anchor="one_service" title="One Entity, One Service">
        <t>
        Apart from letting an entity provide both the Trust Anchor and Resolver services, there is a good reason for
        having each entity only do one thing. The reason is that, later in time, it will be much easier to share specific services
        between federations.
        </t>
    </section>
    <section anchor="trust_mark_policy" title="Trust Mark Policies">
        <t>
            When validating trust marks in an Entity Statement, it can be split into three parts.
            <list style="hanging">
                <t hangText="Validating Trust Marks in the Context of Validating an Entity Statement">
                    <vspace/>
                    According to the text on Entity Statement Validation in <xref target="ESValidation"/>, validating a
                    Trust Mark is confined to validating the syntax of the Claim Value,
                    including that the <spanx style="verb">trust_mark_type</spanx> value is consistent.
                </t>
                <t hangText="Validating a Specific Trust Mark">
                    <vspace/>
                    This is what is described in <xref target="trust-mark-validation"/>.
                    In order to validate a Trust Mark, the entity must find a Trust Chain for the Trust Mark Issuer to a
                    Trust Anchor the Entity trusts. This has nothing to do with which federation that will later
                    be used for the application protocol.
                </t>
                <t hangText="Deciding which Trust Marks to Use">
                    <vspace/>
                    A federation MAY have a policy that states that only Trust Marks that
                    match certain criteria SHOULD be used.
                    <vspace/>
                    An example of such criteria could be that the Trust Mark's
                    <spanx style="verb">trust_mark_type</spanx> must be
                    listed in the Trust Anchor's <spanx style="verb">trust_mark_issuers</spanx>,
                    and if so, that the instance's <spanx style="verb">iss</spanx> appears in the corresponding list of
                    Entity Identifiers. Note that the list may be an empty list, which signifies that anyone can issue
                    a Trust Mark with the <spanx style="verb">trust_mark_type</spanx> in question.
                    Such Trust Marks can appear for various reasons, such as the Entity Configuration including Trust Marks
                    associated with another federation, or Trust Marks intended for specific
                    purposes or Entity audiences.
                    <vspace/>
                    An Entity MAY also choose, at its own discretion, to utilize Trust Marks presented to it that are not
                    recognized within the federation, and where the accreditation authority is established by an
                    out-of-band mechanism.
                </t>
            </list>
        </t>
    </section>

      <section anchor="RelatedSpecs" title="Related Specifications">
	<t>
	  These related specifications refactor the functionality defined in this specification
	  into separate protocol-independent and protocol-specific specifications.
	  The two specifications together are equivalent to this specification;
	  no new functionality is added and none is removed.
	  They can therefore be used interchangeably with this specification.

	  <list style="symbols">
	    <t>
	      <xref target="OpenID.Federation-1.1">OpenID Federation 1.1</xref>
	      contains the protocol-independent functionality defined in this specification.
	      This includes Entity Statements, Trust Chains, Metadata, Policies, Trust Marks, and Federation Endpoints.
	    </t>
	    <t>
	      <xref target="OpenID.Federation.Connect-1.1">OpenID Federation for OpenID Connect 1.1</xref>
	      contains the protocol-specific functionality defined in this specification.
	      This includes Entity Type Identifiers and Metadata for OpenID Connect and OAuth 2.0 Entities and Client Registration flows.
	    </t>
	  </list>
	</t>

      </section>

    </section>

    <section anchor="Security" title="Security Considerations">
      <section title="Denial-of-Service Attack Prevention" anchor="DoS">
        <t>
          Some of the interfaces defined in this specification could be used for
          Denial-of-Service attacks (DoS), most notably, the resolve endpoint
          (<xref target="resolve"/>), Explicit Client Registration
          (<xref target="explicit"/>), and
          Automatic Client Registration (<xref target="automatic"/>) can
          be exploited as vectors of HTTP propagation attacks.
          Below is an explanation of how such an attack can occur and
          the countermeasures to prevent it.
        </t>
        <t>
          An adversary, providing hundreds of fake
          <spanx style="verb">authority_hints</spanx>
          in its Entity Configuration,
          could exploit the Federation Entity Discovery mechanism
          to propagate many HTTP requests.
          Imagine an adversary controlling an RP that sends an authorization
          request to an OP. For each request crafted
          by the adversary, the OP produces one request for
          the adversary's Entity Configuration and another one
          for each URL found in the <spanx style="verb">authority_hints</spanx>.
        </t>
        <t>
          If these endpoints are provided, some adequate defense methods are required,
          such as those described below and in
          <xref target="RFC4732"/>.
        </t>
        <t>
          Implementations should set a limit on the number of
          <spanx style="verb">authority_hints</spanx>
          they are willing to inspect. This is to protect against attacks
          where an adversary might define a large count of false
          <spanx style="verb">authority_hints</spanx>
          in their Entity Configuration.
        </t>
        <t>
          Entities may be required to include a
          Trust Chain
          in their requests, as explained in <xref target="UsingAuthzRequestObject"/>.
          The static Trust Chain gives a predefined trust path,
          meaning that Federation Entity Discovery need not be performed.
          In this case, the propagation attacks will
          be prevented since the Trust Chain can be statically validated with
          a public key of the Trust Anchor.
        </t>
        <t>
          A Trust Mark can be statically validated using the public key of its issuer.
          The static validation of the Trust Marks represents a
          filter against propagation attacks.
          If the OpenID Provider (OP) discovers at least one valid Trust Mark
          within an Entity Configuration, this may serve as evidence of
          the reliability of the Relying Party that initiated the request.
          Given that the Trust Mark is optional, the decision to require
          one is at the discretion of the federation implementation,
          where a federation may define and require Trust Marks
          according to specific needs.
        </t>
        <t>
          If Client authentication is not required at the resolve endpoint,
          then incoming requests should not automatically trigger the collection
          (Federation Entity Discovery process) and assessment of Trust Chains.
          Instead, the resolve endpoint should only respond to unauthenticated
          Client requests with cached information about Entities that have
          already been evaluated and deemed trustworthy. The initiation of
          the Federation Entity Discovery process should not be the default
          action for the resolve endpoint in this case.
        </t>
	<t>
	  Passing request objects by reference (using the
	  <spanx style="verb">request_uri</spanx> request parameter)
	  may not be supported by some deployments,
	  as described in <xref target="authn-request"/>, to eliminate a mechanism
	  by which an attacker could otherwise require OPs
	  to retrieve arbitrary content under the control of the attacker.
	</t>
      </section>
      <section title="Unsigned Error Messages" anchor="UnsignedError">
        <t>
          One of the fundamental design goals of this protocol is to
          protect messages end-to-end. This cannot be accomplished by demanding
          TLS since TLS, in lots of cases, is not end-to-end but ends in an HTTPS
          to HTTP Reverse Proxy.
          Allowing unsigned error messages therefore opens an attack
          vector for someone who wants to run a Denial-of-Service attack.
          This is not specific to OpenID Federation but equally valid for
          other protocols when HTTPS to HTTP reverse proxies are used.
        </t>
      </section>
    </section>

    <section anchor="privacy" title="Privacy Considerations">
      <t>
        Implementers should be aware of these privacy considerations.
      </t>
      <section title="Entity Statement Privacy Considerations"
	       anchor="Entity-Statement-privacy">
	<t>
            Entity Statements are designed to establish trust relationships between organizational entities within a federation, rather than between individuals or for specific business applications. Trust and reputation assessments for individuals or legal entities, such as those required for Know Your Customer and Anti-Money Laundering processes, should be managed through specialized platforms tailored for those purposes. Given that Entity Statements facilitate trust relationships using a public infrastructure, they should be limited to the essential information necessary for federation operations and organizational trust establishment.
	</t>
      </section>

      <section title="Trust Mark Status Privacy Considerations"
	       anchor="Trust-Mark-Status-privacy">
	<t>
	    The Trust Mark Status endpoint enables querying the status
	    of Trust Marks in real time.
	    Similar to the Fetch endpoint,
	    in cases where the Trust Mark Status endpoint is not protected
	    by any client authentication method,
	    requests to validate Trust Marks may not necessarily indicate
	    an actual interaction or relationship between Entities, as they could
	    simply be part of routine network inspection or discovery processes.
	    This could potentially enable Trust Mark issuers to track Entities
	    evaluating Trust Marks about other Entities
	    through standard network diagnostic tools like
	    IPv4/IPv6 addresses and DNS Whois entries.
	    To mitigate tracking risks, implementations can use short-lived Trust Marks,
	    or use the Trust Marked Entities Listing (<xref target="tm_listing"/>)
	    with only the <spanx style="verb">trust_mark_type</spanx> parameter
	    and not the <spanx style="verb">sub</spanx> parameter,
	    reducing the need to use the Trust Mark Status endpoint.
	</t>
      </section>

      <section title="Fetch Endpoint Privacy Considerations"
	       anchor="Fetch-privacy">
	<t>
	  The Fetch endpoint enables querying Subordinate Statements in real time.
	  Similar to Trust Mark Status validation, in the cases where the federation infrastructure is public and widely browsable and endpoints are not protected by any client authentication method, requests to fetch Subordinate Statements may not necessarily indicate an actual interaction or relationship between Entities, as they could simply be part of routine network inspection or discovery processes.
	  However, this could potentially enable Trust Anchors or Intermediates to track Entities evaluating trust relationships with other Entities through standard network diagnostic tools like IPv4/IPv6 addresses and DNS Whois entries.
	  To mitigate tracking risks around Entities inspecting and interacting with other Entities, implementers should consider using static and short-lived Trust Chains where appropriate, which can reduce the need for real-time fetching of Subordinate Statements.
	</t>
      </section>

    </section>


    <section anchor="IANA" title="IANA Considerations">

      <section anchor="DynRegRegistrations" title="OAuth Dynamic Client Registration Metadata Registration">
        <t>
          This specification registers the following client metadata entries
          in the IANA "OAuth Dynamic Client Registration Metadata" registry
          <xref target="IANA.OAuth.Parameters"/>
          established by <xref target="RFC7591"/>.
        </t>
          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Client Metadata Name: <spanx style="verb">client_registration_types</spanx>
              </t>
              <t>
                Client Metadata Description:
                An array of strings specifying the client registration types the RP wants to use
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="RP_metadata"/> of this specification
              </t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>
                Client Metadata Name: <spanx style="verb">signed_jwks_uri</spanx>
              </t>
              <t>
                Client Metadata Description:
                URL referencing a signed JWT having the client's JWK Set document as its payload
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="jwks_metadata"/> of this specification
              </t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>
                Client Metadata Name: <spanx style="verb">organization_name</spanx>
              </t>
              <t>
                Client Metadata Description:
                Human-readable name representing the organization owning this client
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="informational_metadata"/> of this specification
              </t>
            </list>
          </t>
	  <t>
	    <list style="symbols">
	      <t>
		Client Metadata Name: <spanx style="verb">description</spanx>
	      </t>
	      <t>
		Client Metadata Description:
		Human-readable brief description of this client presentable to the End-User
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Client Metadata Name: <spanx style="verb">keywords</spanx>
	      </t>
	      <t>
		Client Metadata Description:
		JSON array with one or more strings representing search keywords, tags, categories, or labels that apply to this client
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Client Metadata Name: <spanx style="verb">information_uri</spanx>
	      </t>
	      <t>
		Client Metadata Description:
		URL for documentation of additional information about this client viewable by the End-User
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
          <t>
            <list style='symbols'>
              <t>
                Client Metadata Name: <spanx style="verb">organization_uri</spanx>
              </t>
              <t>
                Client Metadata Description:
		URL of a Web page for the organization owning this client
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="informational_metadata"/> of this specification
              </t>
            </list>
          </t>
        <?rfc subcompact="no"?>
      </section>

      <section anchor="MetadataRegistry" title="OAuth Authorization Server Metadata Registration">
        <t>
          This specification registers the following metadata entries in the
          IANA "OAuth Authorization Server Metadata" registry <xref target="IANA.OAuth.Parameters"/>
          established by <xref target="RFC8414"/>.
        </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>
                Metadata Name:
                <spanx style="verb">client_registration_types_supported</spanx>
              </t>
              <t>
                Metadata Description: Client Registration Types Supported
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="OP_metadata"/> of this specification
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">federation_registration_endpoint</spanx>
              </t>
              <t>
                Metadata Description:
                Federation Registration Endpoint
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="OP_metadata"/> of this specification
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">signed_jwks_uri</spanx>
              </t>
              <t>
                Metadata Description:
                URL referencing a signed JWT having this authorization server's JWK Set document as its payload
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="jwks_metadata"/> of this specification
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">jwks</spanx>
              </t>
              <t>
                Metadata Description:
                JSON Web Key Set document, passed by value
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="jwks_metadata"/> of this specification
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">organization_name</spanx>
              </t>
              <t>
                Metadata Description:
                Human-readable name representing the organization owning this authorization server
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="informational_metadata"/> of this specification
              </t>
            </list>
          </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">display_name</spanx>
	      </t>
	      <t>
		Metadata Description:
		Human-readable name of the authorization server to be presented to the End-User
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">description</spanx>
	      </t>
	      <t>
		Metadata Description:
		Human-readable brief description of this authorization server presentable to the End-User
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">keywords</spanx>
	      </t>
	      <t>
		Metadata Description:
		JSON array with one or more strings representing search keywords, tags, categories, or labels that apply to this authorization server
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">contacts</spanx>
              </t>
              <t>
                Metadata Description:
                Array of strings representing ways to contact people responsible for this authorization server, typically email addresses
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="informational_metadata"/> of this specification
              </t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">logo_uri</spanx>
              </t>
              <t>
                Metadata Description:
		URL that references a logo for the organization owning this authorization server
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="informational_metadata"/> of this specification
              </t>
            </list>
          </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">information_uri</spanx>
	      </t>
	      <t>
		Metadata Description:
		URL for documentation of additional information about this authorization server viewable by the End-User
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
          <t>
            <list style='symbols'>
              <t>
                Metadata Name: <spanx style="verb">organization_uri</spanx>
              </t>
              <t>
                Metadata Description:
		URL of a Web page for the organization owning this authorization server
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="informational_metadata"/> of this specification
              </t>
            </list>
          </t>
        <?rfc subcompact="no"?>

      </section>

      <section anchor="ResourceRegistrations" title="OAuth Protected Resource Metadata Registration">
	<t>
	  This specification registers the following protected resource metadata entries
	  in the IANA "OAuth Protected Resource Metadata" registry
	  <xref target="IANA.OAuth.Parameters"/>
	  established by <xref target="RFC9728"/>.
	</t>
	  <t>
	    <?rfc subcompact="yes"?>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">signed_jwks_uri</spanx>
	      </t>
	      <t>
		Metadata Description:
		URL referencing a signed JWT having the protected resource's JWK Set document as its payload
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="jwks_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">jwks</spanx>
	      </t>
	      <t>
		Metadata Description:
		JSON Web Key Set document, passed by value
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="jwks_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">organization_name</spanx>
	      </t>
	      <t>
		Metadata Description:
		Human-readable name representing the organization owning this protected resource
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">description</spanx>
	      </t>
	      <t>
		Metadata Description:
		Human-readable brief description of this protected resource presentable to the End-User
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">keywords</spanx>
	      </t>
	      <t>
		Metadata Description:
		JSON array with one or more strings representing search keywords, tags, categories, or labels that apply to this protected resource
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">contacts</spanx>
	      </t>
	      <t>
		Metadata Description:
		Array of strings representing ways to contact people responsible for this protected resource, typically email addresses
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">logo_uri</spanx>
	      </t>
	      <t>
		Metadata Description:
		URL that references a logo for the organization owning this protected resource
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Metadata Name: <spanx style="verb">organization_uri</spanx>
	      </t>
	      <t>
		Metadata Description:
		URL of a Web page for the organization owning this protected resource
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="informational_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	<?rfc subcompact="no"?>
      </section>

      <section anchor="ParameterRegistry" title="OAuth Parameters Registration">
        <t>
          This specification registers the following parameter in the IANA "OAuth
          Parameters" registry <xref target="IANA.OAuth.Parameters"/> established
          by <xref target="RFC6749"/>.
        </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>
                Parameter Name:
                <spanx style="verb">trust_chain</spanx>
              </t>
              <t>
                Parameter Usage Location: authorization request
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="trust_chain-param"/> of this specification
              </t>
            </list>
          </t>
	<?rfc subcompact="no"?>

      </section>

      <section anchor="ErrorReg" title="OAuth Extensions Error Registration">

        <t>
          This specification registers the following values in the
          IANA "OAuth Extensions Error Registry" registry
          <xref target="IANA.OAuth.Parameters"/>
          established by <xref target="RFC6749"/>.
        </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>Name: invalid_client</t>
              <t>Usage Location: authorization endpoint</t>
              <t>Protocol Extension: OpenID Federation</t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>Reference: <xref target="error_response"/> of this specification</t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>Name: invalid_issuer</t>
              <t>Usage Location: authorization endpoint</t>
              <t>Protocol Extension: OpenID Federation</t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>Reference: <xref target="error_response"/> of this specification</t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>Name: invalid_subject</t>
              <t>Usage Location: authorization endpoint</t>
              <t>Protocol Extension: OpenID Federation</t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>Reference: <xref target="error_response"/> of this specification</t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>Name: invalid_trust_anchor</t>
              <t>Usage Location: authorization endpoint</t>
              <t>Protocol Extension: OpenID Federation</t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>Reference: <xref target="error_response"/> of this specification</t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>Name: invalid_trust_chain</t>
              <t>Usage Location: authorization endpoint</t>
              <t>Protocol Extension: OpenID Federation</t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>Reference: <xref target="error_response"/> of this specification</t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>Name: invalid_metadata</t>
              <t>Usage Location: authorization endpoint</t>
              <t>Protocol Extension: OpenID Federation</t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>Reference: <xref target="error_response"/> of this specification</t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>Name: not_found</t>
              <t>Usage Location: authorization endpoint</t>
              <t>Protocol Extension: OpenID Federation</t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>Reference: <xref target="error_response"/> of this specification</t>
            </list>
          </t>
          <t>
            <list style="symbols">
              <t>Name: unsupported_parameter</t>
              <t>Usage Location: authorization endpoint</t>
              <t>Protocol Extension: OpenID Federation</t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>Reference: <xref target="error_response"/> of this specification</t>
            </list>
          </t>
        <?rfc subcompact="no"?>
      </section>

      <section anchor="JwsHeaderRegistry" title="JSON Web Signature and Encryption Header Parameters Registration">
        <t>
	  This specification registers the following JWS header parameters in
	  the IANA "JSON Web Signature and Encryption Header Parameters" registry <xref target="IANA.JOSE"/>
	  established by <xref target="RFC7515"/>.
        </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>
                Header Parameter Name:
                <spanx style="verb">trust_chain</spanx>
              </t>
              <t>
                Header Parameter Description: OpenID Federation Trust Chain
              </t>
              <t>
                Header Parameter Usage Location: JWS
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="trust_chain_head_param"/> of this specification
              </t>
	    </list>
	  </t>
	  <t>
            <list style='symbols'>
              <t>
                Header Parameter Name:
                <spanx style="verb">peer_trust_chain</spanx>
              </t>
              <t>
                Header Parameter Description: OpenID Federation Peer Trust Chain
              </t>
              <t>
                Header Parameter Usage Location: JWS
              </t>
              <t>
                Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Specification Document(s): <xref target="peer_trust_chain_head_param"/> of this specification
              </t>
            </list>
          </t>
	<?rfc subcompact="no"?>

      </section>

      <section title="JSON Web Key Parameters Registration" anchor="JWKParamReg">
	<t>
	  This specification registers the following parameters in
	  the IANA "JSON Web Key Parameters" registry <xref target="IANA.JOSE"/>
	  established by <xref target="RFC7517"/>.
	</t>

	  <t> <?rfc subcompact="yes"?>
	  <list style='symbols'>
	    <t>
	      Parameter Name: <spanx style="verb">iat</spanx>
	    </t>
	    <t>
	      Parameter Description: Issued At, as defined in RFC 7519
	    </t>
	    <t>
	      Used with "kty" Value(s): *
	    </t>
	    <t>
	      Parameter Information Class: Public
	    </t>
	    <t>
	      Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	    </t>
	    <t>
	      Specification Document(s): <xref target="HistKeysResp" /> of this specification
	    </t>
	  </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Parameter Name: <spanx style="verb">nbf</spanx>
	      </t>
	      <t>
		Parameter Description: Not Before, as defined in RFC 7519
	      </t>
	      <t>
		Used with "kty" Value(s): *
	      </t>
	      <t>
		Parameter Information Class: Public
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="HistKeysResp" /> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Parameter Name: <spanx style="verb">exp</spanx>
	      </t>
	      <t>
		Parameter Description: Expiration Time, as defined in RFC 7519
	      </t>
	      <t>
		Used with "kty" Value(s): *
	      </t>
	      <t>
		Parameter Information Class: Public
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="HistKeysResp" /> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Parameter Name: <spanx style="verb">revoked</spanx>
	      </t>
	      <t>
		Parameter Description: Revoked Key Properties
	      </t>
	      <t>
		Used with "kty" Value(s): *
	      </t>
	      <t>
		Parameter Information Class: Public
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="HistKeysResp" /> of this specification
	      </t>
	    </list>
	  </t>
	<?rfc subcompact="no"?>
      </section>

      <section anchor="ClaimsRegistry" title="JSON Web Token Claims Registration">
	<t>
	  This specification registers the following Claims in
	  the IANA "JSON Web Token Claims" registry <xref target="IANA.JWT.Claims"/>
	  established by <xref target="RFC7519"/>.
	</t>

	  <t>
	    <?rfc subcompact="yes"?>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">jwks</spanx>
	      </t>
	      <t>
		Claim Description: JSON Web Key Set
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="jwksClaim"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">metadata</spanx>
	      </t>
	      <t>
		Claim Description: Metadata object
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="metadataClaim"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">constraints</spanx>
	      </t>
	      <t>
		Claim Description: Constraints object
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="constraintsClaim"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">crit</spanx>
	      </t>
	      <t>
		Claim Description: List of Claims in this JWT defined by extensions to this kind of JWT that MUST be understood and processed
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="critClaim"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">ref</spanx>
	      </t>
	      <t>
		Claim Description: Reference
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="refClaim"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">delegation</spanx>
	      </t>
	      <t>
		Claim Description: Delegation
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="delegationClaim"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">logo_uri</spanx>
	      </t>
	      <t>
		Claim Description: URI referencing a logo
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="logo_uriClaim"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">authority_hints</spanx>
	      </t>
	      <t>
		Claim Description: Authority Hints
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="ec-specific"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">trust_anchor_hints</spanx>
	      </t>
	      <t>
		Claim Description: Trust Anchor Hints
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="ec-specific"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">trust_marks</spanx>
	      </t>
	      <t>
		Claim Description: Trust Marks
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="ec-specific"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">trust_mark_issuers</spanx>
	      </t>
	      <t>
		Claim Description: Trust Mark Issuers
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="ec-specific"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">trust_mark_owners</spanx>
	      </t>
	      <t>
		Claim Description: Trust Mark Owners
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="ec-specific"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">metadata_policy</spanx>
	      </t>
	      <t>
		Claim Description: Metadata Policy object
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="ss-specific"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">metadata_policy_crit</spanx>
	      </t>
	      <t>
		Claim Description: Critical Metadata Policy Operators
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="ss-specific"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">source_endpoint</spanx>
	      </t>
	      <t>
		Claim Description: Source Endpoint URL
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="ss-specific"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">keys</spanx>
	      </t>
	      <t>
		Claim Description: Array of JWK values in a JWK Set
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="jwks_metadata"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">trust_mark_type</spanx>
	      </t>
	      <t>
		Claim Description: Trust Mark Type Identifier
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="trust_mark_claims"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">trust_chain</spanx>
	      </t>
	      <t>
		Claim Description: Trust Chain
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="resolve-response"/> of this specification
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>
		Claim Name: <spanx style="verb">trust_anchor</spanx>
	      </t>
	      <t>
		Claim Description: Trust Anchor ID
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="trust_anchor-claim"/> of this specification
	      </t>
	    </list>
	  </t>
	<?rfc subcompact="no"?>
      </section>

      <section anchor="WellKnownRegistry" title="Well-Known URI Registration">
	<t>
	  This specification registers the following well-known URI in the IANA
	  "Well-Known URIs" registry <xref target="IANA.well-known"/>
	  established by <xref target="RFC5785"/>.
	</t>

	  <t>
	  <?rfc subcompact="yes"?>
	  <list style='symbols'>
	    <t>
	      URI suffix: <spanx style="verb">openid-federation</spanx>
	    </t>
	    <t>
	      Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	    </t>
	    <t>
	      Specification document: <xref target="federation_configuration"/> of this specification
	    </t>
	    <t>
	      Related information: (none)
	    </t>
	  </list>
	  </t>
	<?rfc subcompact="no"?>
      </section>

      <section title="Media Type Registration" anchor="MediaReg">
        <t>
          This specification registers the following media types <xref target="RFC2046"/>
          in the IANA "Media Types" registry <xref target="IANA.MediaTypes"/>
          in the manner described in <xref target="RFC6838"/>.
        </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: entity-statement+jwt
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                An Entity Statement is a JWT;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="entity-statement+jwt"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: trust-mark+jwt
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                A Trust Mark is a JWT;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="trust-mark+jwt"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: resolve-response+jwt
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                An Entity Resolve Response is a signed JWT;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="resolve-response+jwt"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: trust-chain+json
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                A Trust Chain is a JSON array of JWTs;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="trust-chain+json"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: trust-mark-delegation+jwt
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                A Trust Mark delegation is a signed JWT;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="trust-mark-delegation+jwt"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Roland Hedberg, roland@catalogix.se
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Roland Hedberg, roland@catalogix.se
              </t>
              <t>
                Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: jwk-set+jwt
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                A signed JWK Set is a signed JWT;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="jwk-set+jwt"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: trust-mark-status-response+jwt
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                A Trust Mark Status Response is a signed JWT;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="trust-mark-status-response+jwt"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>

          <t>
            <?rfc subcompact="yes"?>
            <list style="symbols">
              <t>
                Type name: application
              </t>
              <t>
                Subtype name: explicit-registration-response+jwt
              </t>
              <t>
                Required parameters: n/a
              </t>
              <t>
                Optional parameters: n/a
              </t>
              <t>
                Encoding considerations: binary;
                An Explicit Registration response is a signed JWT;
                JWT values are encoded as a
                series of base64url-encoded values (some of which may be the
                empty string) separated by period ('.') characters.
              </t>
              <t>
                Security considerations: See <xref target="Security"/> of this specification
              </t>
              <t>
                Interoperability considerations: n/a
              </t>
              <t>
                Published specification: <xref target="explicit-registration-response+jwt"/> of this specification
              </t>
              <t>
                Applications that use this media type:
                Applications that use this specification
              </t>
              <t>
                Fragment identifier considerations: n/a
              </t>
              <t>
                Additional information:<list style="empty">
                <t>Magic number(s): n/a</t>
                <t>File extension(s): n/a</t>
                <t>Macintosh file type code(s): n/a </t></list>
                <vspace/>
              </t>
              <t>
                Person &amp; email address to contact for further information:
                <vspace/>
                Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Intended usage: COMMON
              </t>
              <t>
                Restrictions on usage: none
              </t>
              <t>
                Author: Michael B. Jones, michael_b_jones@hotmail.com
              </t>
              <t>
                Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
              </t>
              <t>
                Provisional registration? No
              </t>
            </list>
            <?rfc subcompact="no"?>
          </t>
      </section>

    </section>
  </middle>

  <back>

    <references title="Normative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4732.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5646.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7591.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7638.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8705.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9101.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9126.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9728.xml"/>

      <reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect-core-1_0.html">
        <front>
          <title>OpenID Connect Core 1.0</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
          </author>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Self-Issued Consulting (was at Microsoft)">Self-Issued Consulting</organization>
          </author>

          <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
            <organization abbrev="Google">Google</organization>
          </author>

	  <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
	    <organization abbrev="Disney (was at Salesforce)">Disney</organization>
	  </author>

          <date day="15" month="December" year="2023"/>
        </front>
      </reference>

      <reference anchor="OpenID.Discovery" target="https://openid.net/specs/openid-connect-discovery-1_0.html">
	<front>
	  <title>OpenID Connect Discovery 1.0</title>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Self-Issued Consulting (was at Microsoft)">Self-Issued Consulting</organization>
	  </author>

	  <author fullname="Edmund Jay" initials="E." surname="Jay">
	    <organization abbrev="Illumila">Illumila</organization>
	  </author>

          <date day="15" month="December" year="2023"/>
	</front>
      </reference>

      <reference anchor="OpenID.Registration" target="https://openid.net/specs/openid-connect-registration-1_0.html">
	<front>
	  <title>OpenID Connect Dynamic Client Registration 1.0</title>

	  <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	    <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Self-Issued Consulting (was at Microsoft)">Self-Issued Consulting</organization>
	  </author>

          <date day="15" month="December" year="2023"/>
	</front>
      </reference>

      <reference anchor="OpenID.RP.Choices" target="https://openid.net/specs/openid-connect-rp-metadata-choices-1_0.html">
	<front>
	  <title>OpenID Connect Relying Party Metadata Choices 1.0</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization abbrev="Self-Issued Consulting">Self-Issued Consulting</organization>
	    <address>
	      <email>michael_b_jones@hotmail.com</email>
	      <uri>https://self-issued.info/</uri>
	    </address>
	  </author>

	  <author fullname="Roland Hedberg" initials="R." surname="Hedberg">
	    <organization>independent</organization>
	    <address>
	      <email>roland@catalogix.se</email>
	    </address>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico">Yubico</organization>
	    <address>
	      <email>ve7jtb@ve7jtb.com</email>
	      <uri>https://www.linkedin.com/in/ve7jtb/</uri>
	    </address>
	  </author>

	  <author fullname="Filip Skokan" initials="F." surname="Skokan">
	    <organization>Okta</organization>
	    <address>
	      <email>panva.ip@gmail.com</email>
	    </address>
	  </author>

          <date day="8" month="January" year="2026" />
	</front>
      </reference>

      <reference anchor="UNICODE" target="http://www.unicode.org/versions/latest/">
	<front>
	  <title abbrev="Unicode">The Unicode Standard</title>
	  <author>
	    <organization>The Unicode Consortium</organization>
	    <address />
	  </author>
	  <date />
	</front>
      </reference>

      <reference anchor="USA15" target="https://www.unicode.org/reports/tr15/">
	<front>
	  <title>Unicode Normalization Forms</title>

	  <author fullname="Ken Whistler" initials="K." surname="Whistler">
	  </author>

	  <date day="30" month="July" year="2025" />
	</front>

	<seriesInfo name="Unicode Standard Annex" value="15" />
      </reference>

    </references>

    <references title="Informative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5785.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9525.xml"/>

      <reference anchor="FAPI"
                 target="https://openid.net/specs/openid-financial-api-part-2-1_0.html">
        <front>
          <title>Financial-grade API Security Profile 1.0 - Part 2: Advanced</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization>Nat Consulting</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Yubico">Yubico</organization>
          </author>

          <author fullname="Edmund Jay" initials="E." surname="Jay">
            <organization abbrev="Illumila">Illumila</organization>
          </author>

          <date day="12" month="March" year="2021"/>
        </front>
      </reference>

      <reference anchor="IANA.OAuth.Parameters" target="https://www.iana.org/assignments/oauth-parameters">
        <front>
          <title>OAuth Parameters</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date/>
        </front>
      </reference>

      <reference anchor="IANA.MediaTypes" target="https://www.iana.org/assignments/media-types">
        <front>
          <title>Media Types</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date/>
        </front>
      </reference>

      <reference anchor="IANA.JOSE" target="https://www.iana.org/assignments/jose">
        <front>
          <title>JSON Object Signing and Encryption (JOSE)</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date/>
        </front>
      </reference>

      <reference anchor="IANA.JWT.Claims" target="https://www.iana.org/assignments/jwt">
        <front>
          <title>JSON Web Token Claims</title>
          <author>
            <organization>IANA</organization>
          </author>
	  <date/>
        </front>
      </reference>

      <reference anchor="IANA.well-known" target="https://www.iana.org/assignments/well-known-uris">
        <front>
          <title>Well-Known URIs</title>
          <author>
            <organization>IANA</organization>
          </author>
	  <date/>
        </front>
      </reference>

      <reference anchor="App-Fed-Linkage"
		 target="https://connect2id.com/blog/how-to-link-an-app-protocol-to-an-openid-federation-trust-layer">
	<front>
	  <title>How to link an application protocol to an OpenID Federation 1.0 trust layer</title>

	  <author fullname="Vladimir Dzhuvinov" initials="V." surname="Dzhuvinov">
	    <organization>Connect2id</organization>
	  </author>

	  <date day="4" month="December" year="2024"/>
	</front>
      </reference>

      <reference anchor="OpenID.Federation-1.1" target="https://openid.net/specs/openid-federation-1_1.html">
        <front>
          <title>OpenID Federation 1.1</title>

	  <author fullname="Roland Hedberg" initials="R." surname="Hedberg">
	    <organization>independent</organization>
	    <address>
	      <email>roland@catalogix.se</email>
	    </address>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones" role="editor">
	    <organization abbrev="Self-Issued Consulting">Self-Issued Consulting</organization>
	    <address>
	      <email>michael_b_jones@hotmail.com</email>
	      <uri>https://self-issued.info/</uri>
	    </address>
	  </author>

	  <author fullname="Giuseppe De Marco" initials="G." surname="De Marco">
	    <organization>independent</organization>
	    <address>
	      <email>demarcog83@gmail.com</email>
	      <uri>https://www.linkedin.com/in/giuseppe-de-marco-bb054245/</uri>
	    </address>
	  </author>

	  <author fullname="Andreas Åkre Solberg" initials="A.Å."
		  surname="Solberg">
	    <organization>Sikt</organization>
	    <address>
	      <email>Andreas.Solberg@sikt.no</email>
	      <uri>https://www.linkedin.com/in/andreassolberg/</uri>
	    </address>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico">Yubico</organization>
	    <address>
	      <email>ve7jtb@ve7jtb.com</email>
	      <uri>https://www.linkedin.com/in/ve7jtb/</uri>
	    </address>
	  </author>

	  <author fullname="Vladimir Dzhuvinov" initials="V." surname="Dzhuvinov">
	    <organization>Connect2id</organization>
	    <address>
	      <email>vladimir@connect2id.com</email>
	      <uri>https://twitter.com/dzhuvi</uri>
	    </address>
	  </author>

          <date day="17" month="February" year="2026"/>
        </front>
      </reference>

      <reference anchor="OpenID.Federation.Connect-1.1" target="https://openid.net/specs/openid-federation-connect-1_1.html">
        <front>
          <title>OpenID Federation for OpenID Connect 1.1</title>

	  <author fullname="Roland Hedberg" initials="R." surname="Hedberg">
	    <organization>independent</organization>
	    <address>
	      <email>roland@catalogix.se</email>
	    </address>
	  </author>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones" role="editor">
	    <organization abbrev="Self-Issued Consulting">Self-Issued Consulting</organization>
	    <address>
	      <email>michael_b_jones@hotmail.com</email>
	      <uri>https://self-issued.info/</uri>
	    </address>
	  </author>

	  <author fullname="Giuseppe De Marco" initials="G." surname="De Marco">
	    <organization>independent</organization>
	    <address>
	      <email>demarcog83@gmail.com</email>
	      <uri>https://www.linkedin.com/in/giuseppe-de-marco-bb054245/</uri>
	    </address>
	  </author>

	  <author fullname="Andreas Åkre Solberg" initials="A.Å."
		  surname="Solberg">
	    <organization>Sikt</organization>
	    <address>
	      <email>Andreas.Solberg@sikt.no</email>
	      <uri>https://www.linkedin.com/in/andreassolberg/</uri>
	    </address>
	  </author>

	  <author fullname="John Bradley" initials="J." surname="Bradley">
	    <organization abbrev="Yubico">Yubico</organization>
	    <address>
	      <email>ve7jtb@ve7jtb.com</email>
	      <uri>https://www.linkedin.com/in/ve7jtb/</uri>
	    </address>
	  </author>

	  <author fullname="Vladimir Dzhuvinov" initials="V." surname="Dzhuvinov">
	    <organization>Connect2id</organization>
	    <address>
	      <email>vladimir@connect2id.com</email>
	      <uri>https://twitter.com/dzhuvi</uri>
	    </address>
	  </author>

          <date day="17" month="February" year="2026"/>
        </front>
      </reference>

    </references>

    <section anchor="FederationExamples" title="Examples Building and Using Trust Chains">
      <t>
        Let us assume the following: The project LIGO would like to offer access
        to its wiki to all OPs in eduGAIN. LIGO is registered with the InCommon
        federation.
      </t>

      <figure>
        <preamble>
	  The following depicts a federation under the eduGAIN Trust Anchor:
        </preamble>
	<name>
          Participants in the eduGAIN Federation
	</name>
        <artwork><![CDATA[
                       eduGAIN
                          |
       +------------------+------------------+
       |                                     |
    SWAMID                               InCommon
       |                                     |
     umu.se                                  |
       |                                     |
   op.umu.se                           wiki.ligo.org
]]></artwork>
      </figure>
      <t>
        Both SWAMID and InCommon are identity federations in their own right.
        They also have in common that they are both members of
        the eduGAIN federation.
      </t>
      <t>
        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.
      </t>
      <t>
        Let us assume a researcher from Umeå University would like to
        login to
        the LIGO Wiki. At the Wiki, the researcher will use some kind of
        discovery service to find the home identity provider (op.umu.se).
      </t>
      <t>
        Once the RP part of the Wiki knows which OP it SHOULD talk to, it has
        to find out a few things about the OP. All those things
        can be found in the metadata. But finding the metadata is not enough;
        the RP also has to trust the metadata.
      </t>
      <t>
        Let us make a detour and start with what it takes to build a federation.
      </t>

      <section title="Setting Up a Federation" anchor="federation_intro">
        <t>
          These are the steps to set up a federation infrastructure:
          <list style="symbols">
            <t>
              Generation of Trust Anchor signing keys. These MUST be public/private key pairs.
            </t>
            <t>
              Set up a signing service that can sign JWTs/Entity Statements
              using the Federation Entity Keys.
            </t>
            <t>
              Set up web services that can publish signed Entity Statements,
              one for the URL corresponding to the federation's Entity Identifier returning
              an Entity Configuration and the other one providing the fetch endpoint,
	      as described in <xref target="fetch_statement"/>.
            </t>
          </list>
        </t>
        <t>
          Once these requirements have been satisfied, a Federation Operator
          can add Entities to the federation.
          Adding an Entity comes down to:
          <list style="symbols">
            <t>
              Providing the Entity with the
              federation's Entity Identifier and the public part of the key pairs used
              by the federation operator for signing Entity Statements.
            </t>
            <t>
              Getting the Entity's Entity Identifier and the JWK Set that the Entity
              plans to publish in its Entity Configuration.
            </t>
          </list>
        </t>
        <t>
          Before the federation operator starts adding Entities, there must
          be policies on who can be part of the federation and the
          layout of the federation. Is it supposed to be a one-layer federation
          like InCommon, a two-layer one like the SWAMID federation,
          or a multi-layer federation?
          The federation may also want to consider implementing other
          policies using the federation policy framework,
          as described in <xref target="federation_policy"/>.
        </t>
        <t>
          With the federation in place, things can start happening.
        </t>
      </section>

      <section title="The LIGO Wiki Discovers the OP's Metadata"
               anchor="op_discovery">
        <t>
          Federation Entity Discovery is a sequence of steps that starts with the RP
          fetching the Entity Configuration of the OP's Entity (in this case,
          https://op.umu.se) using the process defined in
          <xref target="federation_configuration"/>.
          What follows that is this sequence of steps:
          <list style="numbers">
            <t>
	      Pick out the Immediate Superior Entities using the authority hints.
            </t>
            <t>
              Fetch the Entity Configuration for each such Entity. This uses the
              process defined in
              <xref target="federation_configuration"/>.
            </t>
            <t>
              Use the fetch endpoint of each Immediate Superior to
              obtain Subordinate Statements about the Immediate Subordinate Entity,
              per <xref target="fetch_statement"/>.
            </t>
          </list>
        </t>
        <t>
          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.
        </t>
        <t>
          When building the Trust Chain, the Subordinate Statements issued
          by each Immediate Superior about their Immediate Subordinates are used together with the
          Entity Configuration of the Trust Chain subject.
        </t>
        <t>
          The Entity Configurations of Intermediates are not
          part of the Trust Chain.
        </t>

        <section anchor="ec-for-op" title="Entity Configuration for https://op.umu.se">
          <t>The LIGO WIKI RP fetches the Entity Configuration from the
            OP (op.umu.se)
            using the process defined in <xref
                    target="federation_configuration"/>.
          </t>
          <figure>
            <preamble>The result is this Entity Configuration:</preamble>
          <name>
             Entity Configuration Issued by https://op.umu.se
          </name>
            <artwork><![CDATA[
{
  "authority_hints": [
    "https://umu.se"
  ],
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://op.umu.se",
  "sub": "https://op.umu.se",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
        "kty": "RSA",
        "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
      }
    ]
  },
  "metadata": {
    "openid_provider": {
      "issuer": "https://op.umu.se",
      "signed_jwks_uri": "https://op.umu.se/jwks.jose",
      "authorization_endpoint":
        "https://op.umu.se/authorization",
      "client_registration_types_supported": [
        "automatic",
        "explicit"
      ],
      "request_parameter_supported": true,
      "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/token",
      "federation_registration_endpoint":
        "https://op.umu.se/fedreg",
      "token_endpoint_auth_methods_supported": [
        "client_secret_post",
        "client_secret_basic",
        "client_secret_jwt",
        "private_key_jwt"
      ]
    }
  }
}
]]></artwork>
          </figure>
          <t>
            The <spanx style="verb">authority_hints</spanx> points to the
            Intermediate Entity <spanx style="verb">https://umu.se</spanx>.
            So that is the next step.
          </t>
          <t>
            This Entity Configuration is the first link in the Trust Chain.
          </t>
        </section>

        <section anchor="ec-for-umu" title="Entity Configuration for https://umu.se">
          <t>The LIGO RP fetches the Entity Configuration from
            https://umu.se using the process defined in
            <xref target="federation_configuration"/>.
          </t>
          <figure>
	    <preamble>
	      The request will look like this:
	    </preamble>
	    <name>
	      Entity Configuration Issued by https://umu.se
	    </name>
            <artwork><![CDATA[
GET /.well-known/openid-federation HTTP/1.1
Host: umu.se
]]></artwork>
          </figure>
          <figure>
	    <preamble>
	      And the GET will return:
	    </preamble>
	    <name>
	      Entity Configuration JWT Claims Set
	    </name>
            <artwork><![CDATA[
{
  "authority_hints": [
    "https://swamid.se"
  ],
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://umu.se",
  "sub": "https://umu.se",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "endwNUZrNTJsX2NyQlp4bjhVcTFTTVltR2gxV2RV...",
        "kty": "RSA",
        "n": "vXdXzZwQo0hxRSmZEcDIsnpg-CMEkor50SOG-1XUlM..."
      }
    ]
  },
  "metadata": {
    "federation_entity": {
      "contacts": ["ops@umu.se"],
      "federation_fetch_endpoint": "https://umu.se/openid/fedapi",
      "organization_uri": "https://www.umu.se",
      "organization_name": "UmU"
    }
  }
}
]]></artwork>
          </figure>
          <t>
            The only piece of information that is used from this Entity Configuration
            in this process is
            the <spanx style="verb">federation_fetch_endpoint</spanx>,
            which is used in the next step.
          </t>
        </section>

        <section anchor="ss-about-op"
                title="Subordinate Statement Published by https://umu.se about https://op.umu.se">
          <t>
            The RP uses the fetch endpoint provided by https://umu.se,
            as defined in <xref target="fetch_statement"/>,
            to fetch information about
            https://op.umu.se.
          </t>
          <figure>
	    <preamble>
	      The request will look like this:
	    </preamble>
	    <name>
	      Request Subordinate Statement from https://umu.se about https://op.umu.se
	    </name>
            <artwork><![CDATA[
GET /openid/fedapi?sub=https%3A%2F%2Fop.umu.se&
iss=https%3A%2F%2Fumu.se HTTP/1.1
Host: umu.se
]]></artwork>
          </figure>
          <figure>
	    <preamble>
	      And the result is this:
	    </preamble>
	    <name>
	      Subordinate Statement Issued by https://umu.se about https://op.umu.se
	    </name>
            <artwork><![CDATA[
{
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://umu.se",
  "sub": "https://op.umu.se",
  "source_endpoint": "https://umu.se/openid/fedapi",
  "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å"
      },
      "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"
        ]
      }
    }
  }
}
]]></artwork>
          </figure>
          <t>
            This Subordinate Statement is the second link in the Trust Chain.
          </t>
        </section>

        <section anchor="ec-for-swamid" title="Entity Configuration for https://swamid.se">
          <t>The LIGO Wiki RP fetches the Entity Configuration from
            https://swamid.se using the process defined in
            <xref target="federation_configuration"/>.
          </t>
          <figure>
	    <preamble>
	      The request will look like this:
	    </preamble>
	    <name>
	      Request Entity Configuration from https://swamid.se
	    </name>
            <artwork><![CDATA[
GET /.well-known/openid-federation HTTP/1.1
Host: swamid.se
]]></artwork>
          </figure>
          <figure>
	    <preamble>
	      And the GET will return:
	    </preamble>
	    <name>
	      Entity Configuration Issued by https://swamid.se
	    </name>
            <artwork><![CDATA[
{
  "authority_hints": [
    "https://edugain.geant.org"
  ],
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://swamid.se",
  "sub": "https://swamid.se",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "N1pQTzFxUXZ1RXVsUkVuMG5uMnVDSURGRVdhUzdO...",
        "kty": "RSA",
        "n": "3EQc6cR_GSBq9km9-WCHY_lWJZWkcn0M05TGtH6D9S..."
      }
    ]
  },
  "metadata": {
    "federation_entity": {
      "contacts": ["ops@swamid.se"],
      "federation_fetch_endpoint":
        "https://swamid.se/fedapi",
      "organization_uri": "https://www.sunet.se/swamid/",
      "organization_name": "SWAMID"
    }
  }
}
]]></artwork>
          </figure>
          <t>
            The only piece of information that is used from this Entity Configuration
            in this process is
            the <spanx style="verb">federation_fetch_endpoint</spanx>,
            which is used in the next step.
          </t>
        </section>

        <section anchor="ss-about-umu"
                title="Subordinate Statement Published by https://swamid.se about https://umu.se">
          <t>
            The LIGO Wiki RP uses the fetch endpoint provided by
            https://swamid.se as defined in
            <xref target="fetch_statement"/>
            to fetch information about
            https://umu.se.
          </t>
          <figure>
	    <preamble>
	      The request will look like this:
	    </preamble>
	    <name>
	      Request to https://swamid.se for Subordinate Statement about https://umu.se
	    </name>
            <artwork><![CDATA[
GET /fedapi?sub=https%3A%2F%2Fumu.se&
iss=https%3A%2F%2Fswamid.se HTTP/1.1
Host: swamid.se
]]></artwork>
          </figure>

          <figure>
	    <preamble>
	      And the result is this:
	    </preamble>
	    <name>
	      Subordinate Statement Issued by https://swamid.se about https://umu.se
	    </name>
            <artwork><![CDATA[
{
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://swamid.se",
  "sub": "https://umu.se",
  "source_endpoint": "https://swamid.se/fedapi",
  "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"
        ]
      }
    }
  }
}
]]></artwork>
          </figure>
          <t>
            This Subordinate Statement is the third link in the Trust Chain.
          </t>
          <t>
            If we assume that the issuer of this Subordinate Statement is not in the
            list of Trust Anchors the LIGO Wiki RP has access to, we have to go
            one step further.
          </t>
        </section>

        <section anchor="ec-for-edugain" title="Entity Configuration for https://edugain.geant.org">
          <t>The RP fetches the Entity Configuration from
            https://edugain.geant.org using the process defined in
            <xref target="federation_configuration"/>.
          </t>
          <figure>
	    <preamble>
	      The request will look like this:
	    </preamble>
	    <name>
	      Entity Configuration Requested from https://edugain.geant.org
	    </name>
            <artwork><![CDATA[
GET /.well-known/openid-federation HTTP/1.1
Host: edugain.geant.org
]]></artwork>
          </figure>
          <figure>
	    <preamble>
	      And the GET will return:
	    </preamble>
	    <name>
	      Entity Configuration issued by https://edugain.geant.org
	    </name>
            <artwork><![CDATA[
{
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://edugain.geant.org",
  "sub": "https://edugain.geant.org",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "Sl9DcjFxR3hrRGdabUNIR21KT3dvdWMyc2VUM2Fr...",
        "kty": "RSA",
        "n": "xKlwocDXUw-mrvDSO4oRrTRrVuTwotoBFpozvlq-1q..."
      }
    ]
  },
  "metadata": {
    "federation_entity": {
      "federation_fetch_endpoint": "https://geant.org/edugain/api"
    }
  }
}
]]></artwork>
          </figure>
          <t>
            Within the Trust Anchor Entity Configuration, the Relying Party
            looks for the <spanx style="verb">federation_fetch_endpoint</spanx>
            and gets the updated Federation Entity Keys of the Trust Anchor.
            Each Entity within a
            Federation may change their Federation Entity Keys,
            or any other attributes, at any time. See
            <xref target="key_rollover_anchor"/> for further details.
          </t>
        </section>

        <section anchor="ss-about-swamid" title="Subordinate Statement Published by https://edugain.geant.org about https://swamid.se">
          <t>
            The LIGO Wiki RP uses the fetch endpoint of
            https://edugain.geant.org as
            defined in <xref target="fetch_statement"/>
            to fetch information about
            "https://swamid.se".
          </t>
          <figure>
          <preamble>
	    The request will look like this:
	  </preamble>
          <name>
             Request to https://edugain.geant.org for Subordinate Statement about https://swamid.se
          </name>
            <artwork><![CDATA[
GET /edugain/api?sub=https%3A%2F%2Fswamid.se&
iss=https%3A%2F%2Fedugain.geant.org HTTP/1.1
Host: geant.org
]]></artwork>
          </figure>
          <figure>
	    <preamble>
	      And the result is this:
	    </preamble>
	    <name>
	      Subordinate Statement issued by https://edugain.geant.org about https://swamid.se
	    </name>
            <artwork><![CDATA[
{
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://edugain.geant.org",
  "sub": "https://swamid.se",
  "source_endpoint": "https://edugain.geant.org/edugain/api",
  "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"]
      }
    }
  }
}
]]></artwork>
          </figure>
          <t>
            If we assume that the issuer of this statement appears in the list
            of Trust Anchors the LIGO Wiki RP has access to,
	    this Subordinate Statement would be the fourth link in the Trust Chain.
	    The Trust Anchor's Entity Configuration MAY also be included in
	    the Trust Chain; in this case, it would be the fifth and final link.
          </t>
          <t>
	    We have now retrieved all the members of the Trust Chain.
	    Recapping, these Entity Statements were obtained:
            <list style="symbols">
              <t>
		Entity Configuration for the Leaf Entity https://op.umu.se
		- the first link in the Trust Chain
	      </t>
              <t>
		Entity Configuration for https://umu.se
		- not included in the Trust Chain
	      </t>
              <t>
		Subordinate Statement issued by https://umu.se about https://op.umu.se
		- the second link in the Trust Chain
	      </t>
              <t>
		Entity Configuration for https://swamid.se
		- not included in the Trust Chain
	      </t>
              <t>
		Subordinate Statement issued by https://swamid.se about https://umu.se
		- the third link in the Trust Chain
	      </t>
              <t>
		Entity Configuration for https://edugain.geant.org
		- optionally, the fifth and last link in the Trust Chain
	      </t>
              <t>
		Subordinate Statement issued by https://edugain.geant.org about https://swamid.se
		- the fourth link in the Trust Chain
	      </t>
            </list>
          </t>
          <t>
            Using the public keys of the Trust Anchor that the LIGO Wiki RP has
            been
            provided within some secure out-of-band way, it can now verify the
            Trust Chain as described in
            <xref target="trust_chain_validation"/>.
          </t>
        </section>

        <section anchor="metadata-for-op" title="OP Resolved Metadata for https://op.umu.se">
          <t>Having verified the chain, the LIGO Wiki RP can proceed with the
            next step.
          </t>
          <figure>
	    <preamble>
	      Combining the metadata policies from the three Subordinate Statements we
	      have by
	      Immediate Superiors about their Immediate Subordinates and applying the combined policy
	      to the
	      metadata statement that the Leaf Entity presented, we get
	      the following Resolved Metadata for the
	      <spanx style="verb">openid_provider</spanx> Entity Type:
	    </preamble>
	    <name>
	      OP Resolved Metadata Derived from Trust Chain by Applying Metadata Policies
	    </name>
            <artwork><![CDATA[
{
  "authorization_endpoint":
    "https://op.umu.se/authorization",
  "contacts": [
    "ops@swamid.se",
    "ops@edugain.geant.org"
  ],
  "federation_registration_endpoint":
    "https://op.umu.se/fedreg",
  "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": [
    "RS256",
    "ES256"
  ],
  "issuer": "https://op.umu.se",
  "signed_jwks_uri": "https://op.umu.se/jwks.jose",
  "logo_uri":
    "https://www.umu.se/img/umu-logo-left-neg-SE.svg",
  "organization_name": "University of Umeå",
  "op_policy_uri":
    "https://www.umu.se/en/website/legal-information/",
  "request_parameter_supported": true,
  "response_types_supported": [
    "code",
    "code id_token",
    "token"
  ],
  "subject_types_supported": [
    "pairwise"
  ],
  "token_endpoint": "https://op.umu.se/token",
  "token_endpoint_auth_methods_supported": [
    "private_key_jwt",
    "client_secret_jwt"
  ]
}

]]></artwork>
          </figure>
          <t>
            We have now reached the end of the Provider Discovery process.
          </t>
        </section>
      </section>

      <section anchor="ClientRegExample" title="Client Registration Method Examples">
        <t>
          <xref target="client_registration"/> defines
          two methods for performing client registration:
          <list style="hanging">
            <t hangText="Automatic">
              <vspace/>
              No negotiation between the RP and the OP is made regarding
              what features the client SHOULD use in future communication occurs.
              The RP's published metadata filtered by the chosen Trust Chain's
              metadata policies defines the metadata that is to be used.
            </t>
            <t hangText="Explicit">
              <vspace/>
              The RP will access the
              <spanx style="verb">federation_registration_endpoint</spanx>,
              which provides the RP's metadata. The OP MAY return a
              metadata policy that adds restrictions over and above what the
              Trust Chain already has defined.
            </t>
          </list>
        </t>

        <section title="RP Sends Authentication Request (Automatic Client Registration)" anchor="AutomaticRegExample">
          <t>
            The LIGO Wiki RP does not do any registration but goes directly to
            sending an Authentication Request.
          </t>
          <figure>
	    <preamble>
	      Here is an example of such an Authentication Request:
	    </preamble>
	    <name>
	      Authentication Request using Automatic Client Registration
	    </name>
            <artwork><![CDATA[
GET /openid/authorization?
  request=eyJ0eXAiOiJvYXV0aC1hdXRoei1yZXErand0IiwiYWxnIjoiU
    lMyNTYiLCJraWQiOiJkVU4yYTAxd1JraGtTV3BsUVRodmNWQklOVUl3
    VFVkT1VGVTJUbVZyU21oRVFYZ3paWGxwVHpkUU5BIn0.
    eyJyZXNwb25zZV90eXBlIjogImNvZGUiLCAic2NvcGUiOiAib3Blbml
    kIHByb2ZpbGUgZW1haWwiLCAiY2xpZW50X2lkIjogImh0dHBzOi8vd2
    lraS5saWdvLm9yZyIsICJzdGF0ZSI6ICIyZmY3ZTU4OS0zODQ4LTQ2Z
    GEtYTNkMi05NDllMTIzNWU2NzEiLCAibm9uY2UiOiAiZjU4MWExODYt
    YWNhNC00NmIzLTk0ZmMtODA0ODQwODNlYjJjIiwgInJlZGlyZWN0X3V
    yaSI6ICJodHRwczovL3dpa2kubGlnby5vcmcvb3BlbmlkL2NhbGxiYW
    NrIiwgImlzcyI6ICJodHRwczovL3dpa2kubGlnby5vcmciLCAiaWF0I
    jogMTU5MzU4ODA4NSwgImF1ZCI6ICJodHRwczovL29wLnVtdS5zZSJ9
    .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
]]></artwork>
          </figure>
          <t>
            The OP receiving this Authentication Request will, unless the
            RP is already registered, start to dynamically fetch
            and
            establish trust with the RP.
          </t>

          <section anchor="op-fetches-ess" title="OP Fetches Entity Statements">
            <t>
              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:
              <list style="symbols">
                <t>https://edugain.geant.org</t>
                <t>https://swamid.se</t>
              </list>
            </t>
            <t>
              The OP starts to resolve metadata for the Client Identifier
              https://wiki.ligo.org by fetching the Entity Configuration
              using
              the process described in <xref target="federation_configuration"/>.
            </t>
            <t>
              The process is the same as described in
              <xref target="op_discovery"/>
              and will result in a Trust Chain with the following Entity Statements:
              <list style="numbers">
                <t>Entity Configuration for the Leaf Entity
                  https://wiki.ligo.org
                </t>
                <t>Subordinate Statement issued by https://incommon.org about
                  https://wiki.ligo.org
                </t>
                <t>Subordinate Statement issued by https://edugain.geant.org about
                  https://incommon.org
                </t>
              </list>
            </t>
          </section>

          <section title="OP Evaluates the RP Metadata"
                   anchor="rp_metadata_eval">
            <t>
              Using the public keys of the Trust Anchor that the LIGO Wiki RP
              has
              been
              provided within some secure out-of-band way, it can now verify
              the
              Trust Chain as described in
              <xref target="trust_chain_validation"/>.
            </t>
            <t>
              We will not list the complete Entity Statements but only the
              <spanx style="verb">metadata</spanx>
              and <spanx style="verb">metadata_policy</spanx> parts.
              There are two metadata policies:
              <list style="hanging">
                <t hangText="edugain.geant.org:">
                  <figure>
		    <name>
		      Metadata Policies Related to Multiple Metadata Types
		    </name>
                    <artwork><![CDATA[
"metadata_policy": {
  "openid_provider": {
    "contacts": {
      "add": ["ops@edugain.geant.org"]
    }
  },
  "openid_relying_party": {
    "contacts": {
      "add": ["ops@edugain.geant.org"]
    }
  }
}
]]></artwork>
                  </figure>
                </t>
              </list>
            </t>
            <t>
              <list style="hanging">
                <t hangText="incommon.org:">
                  <figure>
		    <name>
		      Metadata Policy Related to the RP
		    </name>
                    <artwork><![CDATA[
"metadata_policy": {
  "openid_relying_party": {
    "application_type": {
      "one_of": [
        "web",
        "native"
      ]
    },
    "contacts": {
      "add": ["ops@incommon.org"]
    },
    "grant_types": {
      "subset_of": [
        "authorization_code",
        "refresh_token"
      ]
    }
  }
}
]]></artwork>
                  </figure>
                </t>
              </list>
            </t>
            <figure>
	      <preamble>
		Next, combine these and apply them to the metadata for wiki.ligo.org:
	      </preamble>
	      <name>
		Combined Metadata with Metadata Policy Yet to be Applied
	      </name>
              <artwork><![CDATA[
"metadata": {
  "openid_relying_party": {
    "application_type": "web",
    "client_name": "LIGO Wiki",
    "contacts": [
      "ops@ligo.org"
    ],
    "grant_types": [
      "authorization_code",
      "refresh_token"
    ],
    "id_token_signing_alg_values_supported":
      ["ES256", "PS256", "RS256"],
    "signed_jwks_uri": "https://wiki.ligo.org/jwks.jose",
    "redirect_uris": [
      "https://wiki.ligo.org/openid/callback"
    ],
    "response_types": [
      "code"
    ],
    "subject_type": "public",
    "token_endpoint_auth_method": "private_key_jwt"
  }
}
]]></artwork>
            </figure>
            <figure>
	      <preamble>
		The final result is:
	      </preamble>
	      <name>
		Resolved Metadata After Metadata Policy has been Applied
	      </name>
              <artwork><![CDATA[
"metadata": {
  "openid_relying_party": {
    "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":
      ["ES256", "PS256", "RS256"],
    "signed_jwks_uri": "https://wiki.ligo.org/jwks.jose",
    "redirect_uris": [
      "https://wiki.ligo.org/openid/callback"
    ],
    "response_types": [
      "code"
    ],
    "subject_type": "public",
    "token_endpoint_auth_method": "private_key_jwt"
  }
}
]]></artwork>
            </figure>
            <t>
              Once the Trust Chain and the final Relying Party metadata
              have been obtained, the OpenID Provider has
              everything needed to validate the signature of the
              Request Object in the Authentication Request, using the
              public keys made available at the
              <spanx style="verb">signed_jwks_uri</spanx> endpoint.
            </t>
          </section>
        </section>

        <section title="RP Starts with Client Registration (Explicit Client Registration)" anchor="ExplicitRegExample">
          <t>
            Here the LIGO Wiki RP sends an Explicit Registration request to the
            <spanx style="verb">federation_registration_endpoint</spanx>
            of the OP (op.umu.se). The request contains the RP's Entity Configuration.
          </t>
	  <figure>
	    <preamble>
	      An example JWT Claims Set for the RP's Entity Configuration is:
	    </preamble>
	    <name>
	      RP's Entity Configuration JWT Claims Set
	    </name>
	    <artwork><![CDATA[
{
  "iss": "https://wiki.ligo.org",
  "sub": "https://wiki.ligo.org",
  "iat": 1676045527,
  "exp": 1676063610,
  "aud": "https://op.umu.se",
  "metadata": {
    "openid_relying_party": {
      "application_type": "web",
      "client_name": "LIGO Wiki",
      "contacts": ["ops@ligo.org"],
      "grant_types": ["authorization_code"],
      "id_token_signed_response_alg": "RS256",
      "signed_jwks_uri": "https://wiki.ligo.org/jwks.jose",
      "redirect_uris": [
        "https://wiki.ligo.org/openid/callback"
      ],
      "response_types": ["code"],
      "subject_type": "public"
    }
  },
  "jwks": {
    "keys": [
      {
        "kty": "RSA",
        "use": "sig",
        "kid": "U2JTWHY0VFg0a2FEVVdTaHptVDJsNDNiSDk5MXRBVEtNSFVkeXZwb",
        "e": "AQAB",
        "n": "4AZjgqFwMhTVSLrpzzNcwaCyVD88C_Hb3Bmor97vH-2AzldhuVb8K..."
      }
    ]
  },
  "authority_hints": ["https://incommon.org"]
}
]]></artwork>
	  </figure>
          <t>
            The OP receives the RP's Entity Configuration and proceeds with the
            sequence of steps laid out in <xref target="op_discovery"/>.
          </t>
          <t>
            The OP successfully resolves the same RP metadata described in
            <xref target="rp_metadata_eval"/>. It then registers the RP in
            compliance with its own OP metadata and returns the result in a
            registration Entity Statement.
          </t>
          <t>
            Assuming the OP does not support refresh tokens it will register
            the RP for the <spanx style="verb">authorization_code</spanx> grant
            type only. This is reflected in the metadata returned to the RP.
          </t>
          <t>The returned metadata also includes the
            <spanx style="verb">client_id</spanx>, the
            <spanx style="verb">client_secret</spanx> and other parameters that
            the OP provisioned for the RP.
          </t>
          <figure>
	    <preamble>
	      Here is an example JWT Claims Set of the registration Entity Statement returned
	      by the OP to the RP after successful explicit client registration:
	    </preamble>
	    <name>
	      JWT Claims Set of Registration Entity Statement Returned by OP to RP after Explicit Client Registration
	    </name>
            <artwork><![CDATA[
{
  "iss": "https://op.umu.se",
  "sub": "https://wiki.ligo.org",
  "aud": "https://wiki.ligo.org",
  "iat": 1601457619,
  "exp": 1601544019,
  "trust_anchor": "https://edugain.geant.org",
  "metadata": {
    "openid_relying_party": {
      "client_id": "m3GyHw",
      "client_secret_expires_at": 1604049619,
      "client_secret":
        "cb44eed577f3b5edf3e08362d47a0dc44630b3dc6ea99f7a79205",
      "client_id_issued_at": 1601457619,
      "application_type": "web",
      "client_name": "LIGO Wiki",
      "contacts": [
        "ops@edugain.geant.org",
        "ops@incommon.org",
        "ops@ligo.org"
      ],
      "grant_types": [
        "authorization_code"
      ],
      "id_token_signed_response_alg": "RS256",
      "signed_jwks_uri": "https://wiki.ligo.org/jwks.jose",
      "redirect_uris": [
        "https://wiki.ligo.org/openid/callback"
      ],
      "response_types": [
        "code"
      ],
      "subject_type": "public"
    }
  },
  "authority_hints": [
    "https://incommon.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"
      }
    ]
  }
}
]]></artwork>
          </figure>
        </section>
      </section>
    </section>

    <section anchor="Notices" title="Notices">
      <t>
        Copyright (c) 2026 The OpenID Foundation.
      </t>
      <t>
        The OpenID Foundation (OIDF) grants to any Contributor, developer,
        implementer, or other interested party a non-exclusive, royalty free,
        worldwide copyright license to reproduce, prepare derivative works from,
        distribute, perform and display, this Implementers Draft, Final
        Specification, or Final Specification Incorporating Errata Corrections
        solely for the purposes of (i) developing specifications,
        and (ii) implementing Implementers Drafts, Final Specifications,
        and Final Specification Incorporating Errata Corrections based
        on such documents, provided that attribution be made to the OIDF as the
        source of the material, but that such attribution does not indicate an
        endorsement by the OIDF.
      </t>
      <t>
        The technology described in this specification was made available
        from contributions from various sources, including members of the OpenID
        Foundation and others. Although the OpenID Foundation has taken steps to
        help ensure that the technology is available for distribution, it takes
        no position regarding the validity or scope of any intellectual property
        or other rights that might be claimed to pertain to the implementation
        or use of the technology described in this specification or the extent
        to which any license under such rights might or might not be available;
        neither does it represent that it has made any independent effort to
        identify any such rights. The OpenID Foundation and the contributors to
        this specification make no (and hereby expressly disclaim any)
        warranties (express, implied, or otherwise), including implied
        warranties of merchantability, non-infringement, fitness for a
        particular purpose, or title, related to this specification, and the
        entire risk as to implementing this specification is assumed by the
        implementer. The OpenID Intellectual Property Rights policy
        (found at openid.net) requires
        contributors to offer a patent promise not to assert certain patent
        claims against other contributors and against implementers.
        OpenID invites any interested party to bring to its attention any
        copyrights, patents, patent applications, or other proprietary rights
        that may cover technology that may be required to practice this
        specification.
      </t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
      <t>
	The authors wish to acknowledge the contributions of the following
	individuals and organizations to this specification:
	Marcus Almgren,
	Patrick Amrein,
	Pål Axelsson,
	Pasquale Barbaro,
	Ralph Bragg,
	Peter Brand,
	Brian Campbell,
	David Chadwick,
	Michele D'Amico,
	Kushal Das,
	Andrii Deinega,
	Erick Domingues,
	Heather Flanagan,
	Michael Fraser,
	Samuel Gulliksson,
	Joseph Heenan,
	Pedram Hosseyni,
	Marko Ivančić,
	Łukasz Jaromin,
	Leif Johansson,
	Takahiko Kawasaki,
	Ralf Küsters,
	Torsten Lodderstedt,
	Josh Mandel,
	Francesco Marino,
	John Melati,
	Alexey Melnikov,
	Henri Mikkonen,
	Aaron Parecki,
	Eduardo Perottoni,
	Chris Phillips,
	Roberto Polli,
	Justin Richer,
	Jouke Roorda,
	Nat Sakimura,
	Mischa Sallé,
	Stefan Santesson,
	Marcos Sanz,
	Michael Schwartz,
	Giada Sciarretta,
	Amir Sharif,
	Yaron Sheffer,
	Sean Turner,
	Davide Vaghetti,
	Niels van Dijk,
	Luiky Vasconcelos,
	Elaine Wooton,
	Tim Würtele,
	Kristina Yasuda,
	Gabriel Zachmann,
	the JRA3T3 task force of GEANT4-2,
	and
	the SIROS Foundation.
      </t>
    </section>

  </back>
</rfc>