<?xml version="1.0" encoding="us-ascii"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<!-- [rfced] updated by Chris /08/06/19 -->

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="std" consensus="yes" number="XXXX" ipr="trust200902"> number="8693" ipr="trust200902"
     docName="draft-ietf-oauth-token-exchange-19" obsoletes="" updates=""
     xml:lang="en" tocInclude="true" tocDepth="4"
     symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.37.1 -->
  <front>
    <title abbrev="OAuth 2.0 Token Exchange">OAuth 2.0 Token Exchange</title>
                                          <!-- An STS for the REST of Us -->
    <seriesInfo name="RFC" value="8693"/>
    <author fullname="Michael B. Jones" initials="M.B." initials="M." surname="Jones">
      <organization>Microsoft</organization>
      <address>
        <email>mbj@microsoft.com</email>
        <uri>http://self-issued.info/</uri>
        <uri>https://self-issued.info/</uri>
      </address>
    </author>
    <author fullname="Anthony Nadalin" initials="A." surname="Nadalin">
      <organization>Microsoft</organization>
      <address>
        <email>tonynad@microsoft.com</email>
      </address>
    </author>
    <author fullname="Brian Campbell" initials="B." surname="Campbell" role="editor">
      <organization>Ping Identity</organization>
      <address><email>brian.d.campbell@gmail.com</email></address>
      <address>
        <email>brian.d.campbell@gmail.com</email>
      </address>
    </author>
    <author fullname="John Bradley" initials="J." surname="Bradley">
      <organization>Yubico</organization>
      <address><email>ve7jtb@ve7jtb.com</email></address>
      <address>
        <email>ve7jtb@ve7jtb.com</email>
      </address>
    </author>
    <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
      <organization abbrev="Salesforce">Salesforce</organization> abbrev="Visa">Visa</organization>
      <address>
        <email>cmortimore@salesforce.com</email>
        <email>chuck.mortimore@visa.com</email>
      </address>
    </author>
    <date year="2019" month="August"/> year="2020" month="January"/>
    <area>Security</area>
    <workgroup>OAuth Working Group</workgroup>

    <keyword>RFC</keyword>
    <keyword>Request for Comments</keyword>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>JSON
    <keyword>
    JSON Web Token</keyword>
    <keyword>JWT</keyword>
    <keyword>Delegation</keyword>
    <keyword>Impersonation</keyword>
    <keyword>STS</keyword>
    <keyword>Security Token Service</keyword>
    <keyword>Exchange</keyword>
    <keyword>Token</keyword>
    <keyword>OAuth</keyword> Token, JWT, Delegation, Impersonation, STS, Security Token
    Service, Exchange, Token, OAuth
    </keyword>

    <abstract>
      <t>
	This specification defines a protocol for an HTTP- and JSON- based JSON-based
	Security Token Service (STS) by defining how to request and obtain
	security tokens from OAuth 2.0 authorization servers,
	including security tokens employing impersonation and delegation.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
  A security token is a set of information that facilitates the sharing of
  identity and security information in heterogeneous environments or across
  security domains.  Examples of security tokens include JSON Web Tokens
  (JWTs) <xref target="JWT"/> target="RFC7519" format="default"/> and
  SAML Security Assertion Markup Language (SAML)
  2.0 Assertions assertions <xref target="OASIS.saml-core-2.0-os"/>. target="OASIS.saml-core-2.0-os" format="default"/>.  Security tokens are
  typically signed to achieve integrity and sometimes also encrypted to
  achieve confidentiality.  Security tokens are also sometimes described as Assertions,
  assertions, such as in <xref target="RFC7521"/>. target="RFC7521" format="default"/>.
</t>
      <t>
  A Security Token Service (STS) is a service capable of validating
  security tokens provided to it and issuing new security tokens in
  response, which enables clients to obtain appropriate
  access credentials for resources in heterogeneous environments or across security
  domains.
  Web Service clients have used WS-Trust <xref target="WS-Trust">WS-Trust</xref> target="WS-Trust" format="default"></xref>
  as the protocol to interact with an STS for token exchange.
  While WS-Trust
  uses XML and SOAP, the trend in modern Web development
  has been towards RESTful (Representational State Transfer) patterns and JSON.
  <xref target="RFC6749">The
  The OAuth 2.0 Authorization Framework</xref>
  and Framework <xref target="RFC6750">OAuth target="RFC6749" format="default"></xref>
  and OAuth 2.0 Bearer Tokens</xref> Tokens <xref target="RFC6750" format="default"></xref>
  have emerged as popular standards for authorizing third-party
  applications' access to HTTP and RESTful resources.
  The conventional OAuth 2.0 interaction involves the exchange of some
  representation of resource owner authorization for an access token,
  which has proven to be an extremely useful pattern in practice. However,
  its input and output are somewhat too constrained as is to fully
  accommodate a security token exchange framework.
</t>
      <t>
  This specification defines a protocol extending OAuth 2.0 that enables
  clients to request and obtain security tokens from authorization servers acting in
  the role of an STS.
  Similar to OAuth 2.0, this specification focuses on client developer simplicity and
  requires only an HTTP client and JSON parser, which are nearly universally available
  in modern development environments. The STS protocol defined in this specification
  is not itself RESTful (an STS doesn't lend itself particularly well to a REST
  approach) but does utilize communication patterns and data formats that should be
  familiar to developers accustomed to working with RESTful systems.
</t>
      <t>
  A new grant type for a token exchange request and the associated specific parameters for
  such a request to the token endpoint are defined by this specification.
  A token exchange response is a normal OAuth 2.0 response from the token endpoint
  with a few additional parameters defined herein to provide information to the client.
</t>
      <t>
  The entity that makes the request to exchange tokens is considered the client in the
  context of the token exchange interaction. However, that does not restrict
  usage of this profile to traditional OAuth clients. An OAuth resource server, for example, might assume
  the role of the client during token exchange in order to trade an
  access token that it received in a protected resource request for
  a new token that is appropriate to include in a call to a backend
  service. The new token might be an access token that is more
  narrowly scoped for the downstream service or it could be an entirely different kind
  of token.
</t>
      <t>
  The scope of this specification is limited to the definition of a
  basic request-and-response protocol for an STS-style token exchange utilizing OAuth 2.0.
  Although a few new JWT claims are defined that enable delegation semantics to be expressed,
  the specific syntax, semantics semantics, and security characteristics of the tokens themselves
  (both those presented to the authorization server and those obtained by the client)
  are explicitly out of scope scope, and no requirements are placed on the trust model in
  which an implementation might be deployed. Additional profiles may provide
  more detailed requirements around the specific nature of the parties and trust involved,
  such as whether signing and/or encryption of tokens is needed or if proof-of-possession style proof-of-possession-style
  tokens will be required or issued; however, issued. However, such details
  will often be policy decisions made with respect to the specific needs of individual
  deployments and will be configured or implemented accordingly.
</t>
      <t>
  The security tokens obtained may be used in a number of contexts,
  the specifics of which are also beyond the scope of this specification.
</t>
      <section anchor="DelegationImpersonation" title="Delegation numbered="true" toc="default">
        <name>Delegation vs. Impersonation Semantics"> Semantics</name>
        <t>
    One common use case for an STS (as alluded to in the previous section)
    is to allow a resource server A to make calls to a backend service C on
    behalf of the requesting user B.  Depending on the local site policy and
    authorization infrastructure, it may be desirable for A to use its own
    credentials to access C along with an annotation of some form that A is
    acting on behalf of B ("delegation"), ("delegation") or for A to be granted a limited access
    credential to C but that continues to identify B as the authorized
    entity ("impersonation").  Delegation and impersonation can be useful
    concepts in other scenarios involving multiple participants as well.
        </t>
        <t>
    When principal A impersonates principal B, A is given all
    the rights that B has within some defined rights context
    and is indistinguishable from B in that context.
    Thus, when principal A impersonates principal B, then insofar
    as any entity receiving such a token is concerned, they are
    actually dealing with B. It is true that some members of the
    identity system might have awareness that impersonation is
    going on, but it is not a requirement.
    For all intents and purposes, when A is impersonating B, A is B within the
    context of the rights authorized by the token. A's ability to impersonate B could
    be limited in scope or time, or even with a one-time-use restriction,
    whether via the contents of the token or an out-of-band mechanism.
        </t>
        <t>
    Delegation semantics are different than
    impersonation semantics, though the two are closely related.
    With delegation semantics, principal A still has its own identity
    separate from B B, and it is explicitly understood that while B
    may have delegated some of its rights to A, any actions taken are
    being taken by A representing B. In a sense, A is an agent for B.
        </t>
        <t>
    Delegation and impersonation are not inclusive of all situations.
    When a principal is acting directly on its own behalf, for example,
    neither delegation nor impersonation are in play. They are, however,
    the more common semantics operating for token exchange and, as such, are
    given more direct treatment in this specification.
        </t>
        <t>
    Delegation semantics are typically expressed in a token by including information about both the
    primary subject of the token as well as the actor to whom that subject has delegated some of its rights.
    Such a token is sometimes referred to as a composite token because it is composed of information
    about multiple subjects. Typically, in the request, the <spanx style="verb">subject_token</spanx> <tt>subject_token</tt>
    represents the identity of the party on
    behalf of whom the token is being requested while the <spanx style="verb">actor_token</spanx> <tt>actor_token</tt> represents
    the identity of the party to whom the access rights of the issued token are being delegated.
    A composite token issued by the authorization server will contain information about both parties.
    When and if a composite token is issued is at the discretion of the authorization server and
    applicable policy and configuration.
        </t>
        <t>
    The specifics of representing a composite token and even whether or not
    such a token will be issued depend on the details of the implementation
    and the kind of token.  The representations of composite tokens that are
    not JWTs are beyond the scope of this specification.  The <spanx style="verb">actor_token</spanx> <tt>actor_token</tt> request parameter, however, does provide
    a means for providing information about the desired actor actor, and the JWT <spanx style="verb">act</spanx>
    <tt>act</tt> claim can provide a representation of a
    chain of delegation.
        </t>
      </section>
      <section anchor="RNC" title="Requirements numbered="true" toc="default">
        <name>Requirements Notation and Conventions"> Conventions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
  BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
      <section anchor="Terminology" title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>
	  This specification uses the terms
	  "access token type", "authorization server", "client", "client identifier",
	  "resource server", "token endpoint", "token request", and "token response"
	  defined by OAuth 2.0 <xref target="RFC6749">OAuth 2.0</xref>, target="RFC6749" format="default"></xref>,
	  and the terms "Base64url Encoding", "Claim", and "JWT Claims Set" defined by
	  <xref target="JWT">JSON
	  JSON Web Token (JWT)</xref>. (JWT) <xref target="RFC7519" format="default"></xref>.
        </t>
      </section>
    </section>
    <section anchor="Messages" title="Token numbered="true" toc="default">
      <name>Token Exchange Request and Response"> Response</name>
      <section title="Request" anchor="Request"> anchor="Request" numbered="true" toc="default">
        <name>Request</name>
        <t>
  A client requests a security token by making a token request to the authorization
  server's token endpoint using the extension grant type mechanism defined
  in Section 4.5 of <xref target="RFC6749"/>. target="RFC6749" sectionFormat="of" section="4.5"/>.
</t>
        <t>
  Client authentication to the authorization server is done using the normal
  mechanisms provided by OAuth 2.0.
  Section 2.3.1 of
  <xref target="RFC6749"/> target="RFC6749" sectionFormat="of" section="2.3.1"/>
  defines password-based authentication of the client,
  however, client authentication is extensible and other mechanisms are possible.
  For example, <xref target="RFC7523"/> target="RFC7523" format="default"/> defines client authentication using bearer
  JSON Web Tokens (JWTs) <xref target="JWT"/>. target="RFC7519" format="default"/>.
  The supported methods of client authentication and whether or not to allow
  unauthenticated or unidentified clients are deployment decisions that are
  at the discretion of the authorization server.
  Note that omitting client authentication allows
  for a compromised token to be leveraged via an STS into other tokens by
  anyone possessing the compromised token. Thus Thus, client
  authentication allows for additional authorization checks by the STS as to which
  entities are permitted to impersonate or receive delegations from other
  entities.
</t>
        <t>
  The client makes a token exchange request to the token endpoint with an extension
  grant type using the HTTP <spanx style='verb'>POST</spanx> <tt>POST</tt> method. The
  following parameters are included in the HTTP request entity-body
  using the <spanx style='verb'>application/x-www-form-urlencoded</spanx> <tt>application/x-www-form-urlencoded</tt>
  format with a character encoding of UTF-8 as described in
  Appendix B of RFC6749
  <xref target="RFC6749"/>.
</t>
<t>
<list style="hanging">

  <t hangText="grant_type">
    <vspace/>
    REQUIRED. target="RFC6749" sectionFormat="of" section="B"/>.
</t>
        <dl newline="true" spacing="normal">
          <dt>grant_type</dt>
          <dd>
    <bcp14>REQUIRED</bcp14>. The value
    <spanx style='verb'>urn:ietf:params:oauth:grant-type:token-exchange</spanx>
    <tt>urn:ietf:params:oauth:grant-type:token-exchange</tt>
    indicates that a token exchange is being performed.
  </t>

  <t hangText="resource">
    <vspace/>
    OPTIONAL.
  </dd>
          <dt>resource</dt>
          <dd>
    <bcp14>OPTIONAL</bcp14>.
    A URI that indicates the target service or resource where the client intends to use
    the requested security token. This enables the authorization server to apply policy as appropriate
    for the target, such as determining the type and content of the token to be issued or if and how
    the token is to be encrypted.
    In many cases, a client will not have knowledge of the logical organization of the systems with
    which it interacts and will only know a URI of the service where it intends to use the token.
    The <spanx style="verb">resource</spanx> <tt>resource</tt> parameter allows the client to indicate to the authorization server
    where it intends to use the issued token by providing the location, typically as an https URL, in the
    token exchange request in the same form that will be used to access that resource.
    The authorization server will typically have the capability to map from a resource URI value to
    an appropriate policy. The value of the <spanx style="verb">resource</spanx> <tt>resource</tt> parameter MUST <bcp14>MUST</bcp14> be an
    absolute URI, as specified by Section 4.3 of <xref target="RFC3986"/>,
    which MAY target="RFC3986"
    sectionFormat="of" section="4.3"/>,
    that <bcp14>MAY</bcp14> include a query component and MUST NOT <bcp14>MUST NOT</bcp14> include a fragment component.
    Multiple <spanx style="verb">resource</spanx> <tt>resource</tt> parameters may be used to indicate
    that the issued token is intended to be used at the multiple resources listed.
    See <xref target="OAUTH-RESOURCE"/> target="I-D.ietf-oauth-resource-indicators" format="default"/> for additional
    background and uses of the <spanx style="verb">resource</spanx> <tt>resource</tt> parameter.
  </t>

  <t hangText="audience">
    <vspace/>
    OPTIONAL.
  </dd>
          <dt>audience</dt>
          <dd>
    <bcp14>OPTIONAL</bcp14>.  The logical name of the target service where the client intends
    to use the requested security token. This serves a purpose similar to the
    <spanx style="verb">resource</spanx> parameter,
    <tt>resource</tt> parameter but with the client
    providing a logical name for the target service. Interpretation of the
    name requires that the value be something that both the client and the
    authorization server understand. An OAuth client identifier, a SAML entity
    identifier <xref target="OASIS.saml-core-2.0-os"/>, target="OASIS.saml-core-2.0-os" format="default"/>, and an OpenID Connect
    Issuer Identifier <xref target="OpenID.Core"/>, target="OpenID.Core" format="default"/> are examples of things that
    might be used as <spanx style="verb">audience</spanx> <tt>audience</tt> parameter values.
    However, <spanx style="verb">audience</spanx> <tt>audience</tt> values used with a given
    authorization server must be unique within that server, server to ensure that
    they are properly interpreted as the intended type of value.  Multiple <spanx style="verb">audience</spanx>
    <tt>audience</tt> parameters may be used to indicate
    that the issued token is intended to be used at the multiple audiences
    listed.  The <spanx style="verb">audience</spanx> <tt>audience</tt> and <spanx style="verb">resource</spanx> <tt>resource</tt> parameters may be used together to indicate
    multiple target services with a mix of logical names and resource URIs.
  </t>

  <t hangText="scope">
    <vspace/>
    OPTIONAL.
  </dd>
          <dt>scope</dt>
          <dd>
    <bcp14>OPTIONAL</bcp14>.  A list of space-delimited, case-sensitive
    strings, as defined in Section 3.3 of <xref target="RFC6749"/>, target="RFC6749"
    sectionFormat="of" section="3.3"/>, that allow the client to specify the desired scope of
    the requested security token in the context of the service or resource
    where the token will be used. The values and associated semantics of scope
    are service specific and expected to be described in the relevant service documentation.</t>

  <t hangText="requested_token_type">
    <vspace/>
    OPTIONAL.
    documentation.</dd>
          <dt>requested_token_type</dt>
          <dd>
    <bcp14>OPTIONAL</bcp14>.
    An identifier, as described in <xref target="TokenTypeIdentifiers"/>, target="TokenTypeIdentifiers" format="default"/>, for the type of the requested security token.
    If the requested type is unspecified, the issued token type is at
    the discretion of the authorization server and may be dictated by
    knowledge of the requirements of the service or resource
    indicated by the <spanx style='verb'>resource</spanx> <tt>resource</tt> or
    <spanx style="verb">audience</spanx>
    <tt>audience</tt> parameter.
  </t>

  <t hangText="subject_token">
    <vspace/>
    REQUIRED.
  </dd>
          <dt>subject_token</dt>
          <dd>
    <bcp14>REQUIRED</bcp14>.
    A security token that represents the
    identity of the party on behalf of whom the request is being made.
    Typically, the subject of this token will be the subject of
    the security token issued in response to the request.
  </t>

  <t hangText="subject_token_type">
    <vspace/>
    REQUIRED.
  </dd>
          <dt>subject_token_type</dt>
          <dd>
    <bcp14>REQUIRED</bcp14>.
    An identifier, as described in <xref target="TokenTypeIdentifiers"/>, target="TokenTypeIdentifiers" format="default"/>, that indicates the type of the security token in
    the <spanx style="verb">subject_token</spanx> <tt>subject_token</tt> parameter.
  </t>

  <t hangText="actor_token">
    <vspace/>
    OPTIONAL.
  </dd>
          <dt>actor_token</dt>
          <dd>
    <bcp14>OPTIONAL</bcp14>.
    A security token that represents
    the identity of the acting party. Typically, this will be the party that is authorized to use the requested security token and act on behalf of the subject.
  </t>

  <t hangText="actor_token_type">
    <vspace/>
  </dd>
          <dt>actor_token_type</dt>
          <dd>
    An identifier, as described in <xref target="TokenTypeIdentifiers"/>, target="TokenTypeIdentifiers" format="default"/>, that indicates the type of the security token in the
    <spanx style="verb">actor_token</spanx>
    <tt>actor_token</tt> parameter.
    This is REQUIRED <bcp14>REQUIRED</bcp14> when the <spanx style="verb">actor_token</spanx> <tt>actor_token</tt> parameter
    is present in the request but MUST NOT <bcp14>MUST NOT</bcp14> be included otherwise.
  </t>
</list>
</t>
  </dd>
        </dl>
        <t>
  In processing the request, the authorization server MUST <bcp14>MUST</bcp14> perform the appropriate validation procedures for the indicated token
  type and, if the actor token is present, also
  perform the appropriate validation procedures for its indicated token type.
  The validity criteria and details of any particular token are beyond the scope of
  this document and are specific to the respective type of token and its content.
</t>
        <t>
  In the absence of one-time-use or other semantics specific to the token type, the act of performing
  a token exchange has no impact on the validity of the subject token or actor token.
  Furthermore, the exchange is a one-time event and does not create a tight linkage
  between the input and output tokens, so that (for example) while the expiration
  time of the output token may be influenced by that of the input token,
  renewal or extension of the input token is not expected to be reflected in
  the output token's properties.  It may still be appropriate or desirable to propagate
  token revocation
  token-revocation events. However, doing so is not a general property of the STS
  protocol and would be specific to a particular implementation, token type type, or deployment.
</t>
        <section title="Relationship Between numbered="true" toc="default">
          <name>Relationship between Resource, Audience Audience, and Scope"> Scope</name>
          <t>
          When requesting a token, the client can indicate the desired target
          service(s) where it intends to use that token by way of the <spanx style="verb">audience</spanx> <tt>audience</tt> and <spanx style="verb">resource</spanx>
          parameters, <tt>resource</tt> parameters as well as indicating indicate the
          desired scope of the requested token using the <spanx style="verb">scope</spanx> <tt>scope</tt> parameter.

          The semantics of such a request are that the client is asking for a token with the requested
          scope that is usable at all the requested target services. Effectively, the requested access rights of
          the token are the cartesian Cartesian product of all the scopes at all the target services.
          </t>
          <t>
          An authorization server may be unwilling or unable to fulfill any token request request, but the likelihood
          of an unfulfillable request is significantly higher when very broad access rights are being solicited.
          As such, in the absence of specific knowledge about the relationship of systems in a deployment,
          clients should exercise discretion in the breadth of the access requested, particularly the
          number of target services. An authorization server can use the <spanx style="verb">invalid_target</spanx> <tt>invalid_target</tt>
          error code, defined in <xref target="ErrorResponse"/>, target="ErrorResponse" format="default"/>, to inform a client that it requested access to
          too many target services simultaneously.
          </t>
        </section>
      </section>
      <section title="Response" anchor="Response"> anchor="Response" numbered="true" toc="default">
        <name>Response</name>
        <t>
  The authorization server responds to a token exchange request with a normal
  OAuth 2.0 response from the token endpoint, as specified in
  Section 5 of
  <xref target="RFC6749"/>. target="RFC6749" sectionFormat="of" section="5"/>. Additional details and
  explanation are provided in the following subsections.
</t>
        <section title="Successful Response" anchor="SuccessfulResponse"> anchor="SuccessfulResponse" numbered="true" toc="default">
          <name>Successful Response</name>
          <t>
  If the request is valid and meets all policy and other criteria of the authorization server,
  a successful token response is constructed by adding the following parameters
  to the entity-body of the HTTP response using the "application/json"
  media type, as specified by <xref target="RFC8259"/>, target="RFC8259" format="default"/>, and an HTTP 200 status code.  The
  parameters are serialized into a JavaScript Object Notation (JSON)
  structure by adding each parameter at the top level.
  Parameter names and string values are included as JSON strings.
  Numerical values are included as JSON numbers.  The order of
  parameters does not matter and can vary.
</t>
        <t>
          <list style="hanging">

<t hangText="access_token">
  <vspace/>
  REQUIRED.
          <dl newline="true" spacing="normal">
            <dt>access_token</dt>
            <dd>
  <bcp14>REQUIRED</bcp14>. The security token issued by the authorization server in response
  to the token exchange request.
  The <spanx style="verb">access_token</spanx> <tt>access_token</tt> parameter from
  Section 5.1 of
  <xref target="RFC6749"/> target="RFC6749" sectionFormat="of" section="5.1"/> is used here to carry the requested
  token, which allows this token exchange protocol to use the existing OAuth 2.0 request
  and response constructs defined for the token endpoint.
  The identifier <spanx style="verb">access_token</spanx> <tt>access_token</tt> is used for historical
  reasons and the issued token need not be an OAuth access token.
</t>

<t hangText="issued_token_type">
  <vspace/>
  REQUIRED.
</dd>
            <dt>issued_token_type</dt>
            <dd>
  <bcp14>REQUIRED</bcp14>.  An identifier, as described in <xref target="TokenTypeIdentifiers"/>, target="TokenTypeIdentifiers" format="default"/>,
  for the representation of the issued security token.
</t>

<t hangText="token_type">
  <vspace/>
  REQUIRED.
</dd>

            <dt>token_type</dt>
            <dd>
  <bcp14>REQUIRED</bcp14>.  A case-insensitive value specifying the method of using the
  access token issued, as specified in Section 7.1 of <xref target="RFC6749"/>. target="RFC6749"
  sectionFormat="of" section="7.1"/>.
  It provides the client with information about how to utilize the access
  token to access protected resources.  For example, a value of <spanx style="verb">Bearer</spanx>, <tt>Bearer</tt>, as specified in <xref target="RFC6750"/>, target="RFC6750" format="default"/>,
  indicates that the issued security token is a bearer token and the client
  can simply present it as is without any additional proof of eligibility
  beyond the contents of the token itself.  Note that the meaning of this
  parameter is different from the meaning of the <spanx style="verb">issued_token_type</spanx> <tt>issued_token_type</tt> parameter, which declares the
  representation of the issued security token; the term "token type" is more
  typically used with the aforementioned meaning as to mean the structural or syntactical representation of the security token, as it is in all <spanx style="verb">*_token_type</spanx> <tt>*_token_type</tt> parameters in this specification.  If the
  issued token is not an access token or usable as an access token, then the <spanx style="verb">token_type</spanx>
  <tt>token_type</tt> value <spanx style="verb">N_A</spanx> <tt>N_A</tt>
  is used to indicate that an OAuth 2.0
  <spanx style="verb">token_type</spanx> <tt>token_type</tt>
  identifier is not applicable in that context.
</t>

<t hangText="expires_in">
  <vspace/>
  RECOMMENDED.
</dd>
            <dt>expires_in</dt>
            <dd>
  <bcp14>RECOMMENDED</bcp14>.  The validity lifetime, in seconds, of the token issued by the
  authorization server. Oftentimes Oftentimes, the client will not have the inclination or capability
  to inspect the content of the token token, and this parameter provides a consistent and token-type-agnostic
  indication of how long the token can be expected to be valid.
  For example, the value 1800 denotes that the token will
  expire in thirty minutes from the time the response was generated.
</t>

<t hangText="scope">
  <vspace/>
  OPTIONAL,
</dd>
            <dt>scope</dt>
            <dd>
  <bcp14>OPTIONAL</bcp14> if the scope of the issued security token is identical to the scope requested by the client;
  otherwise, REQUIRED.
</t>

<t hangText="refresh_token">
  <vspace/>
  OPTIONAL. it is <bcp14>REQUIRED</bcp14>.
</dd>
            <dt>refresh_token</dt>
            <dd>
  <bcp14>OPTIONAL</bcp14>.
  A refresh token will typically not be issued when the exchange is of one temporary
  credential (the subject_token) for a different temporary credential (the issued token)
  for use in some other context.
  A refresh token can be issued in cases where the client of the token exchange needs the
  ability to access a resource even when the original credential is no longer valid
  (e.g., user-not-present or offline scenarios where there is no longer any user entertaining
  an active session with the client).
  Profiles or deployments of this specification should clearly document the conditions
  under which a client should expect a refresh token in response to
  <spanx style="verb">urn:ietf:params:oauth:grant-type:token-exchange</spanx>
  <tt>urn:ietf:params:oauth:grant-type:token-exchange</tt>
  grant type requests.
</t>

        </list>
        </t>
</dd>
          </dl>
        </section>
        <section anchor="ErrorResponse" title="Error Response"> numbered="true" toc="default">
          <name>Error Response</name>
          <t>
    If the request itself is not valid or if either the <spanx style="verb">subject_token</spanx> <tt>subject_token</tt> or <spanx style="verb">actor_token</spanx> <tt>actor_token</tt> are invalid for any reason, or are
    unacceptable based on policy, the authorization server
    MUST <bcp14>MUST</bcp14> construct an
    error response, as specified in Section 5.2 of <xref target="RFC6749"/>. target="RFC6749"
    sectionFormat="of" section="5.2"/>.
    The value of the <spanx style='verb'>error</spanx> <tt>error</tt> parameter MUST <bcp14>MUST</bcp14> be the <spanx style='verb'>invalid_request</spanx>
    <tt>invalid_request</tt> error code.
          </t>
          <t>
    If the authorization server is unwilling or unable to issue a token for any target service
    indicated by the <spanx style="verb">resource</spanx> <tt>resource</tt> or <spanx style="verb">audience</spanx> <tt>audience</tt> parameters,
    the <spanx style="verb">invalid_target</spanx> <tt>invalid_target</tt> error code SHOULD <bcp14>SHOULD</bcp14> be used in the error response.
          </t>
          <t>
    The authorization
    server MAY <bcp14>MAY</bcp14> include additional information regarding the reasons for the error
    using the <spanx style='verb'>error_description</spanx> <tt>error_description</tt> as discussed in Section 5.2 of <xref target="RFC6749"/>.
    target="RFC6749" sectionFormat="of" section="5.2"/>.
          </t>
          <t>
    Other error codes may also be used, as appropriate.
          </t>
        </section>
      </section>
      <section title="Example anchor="MainExample" numbered="true" toc="default">
        <name>Example Token Exchange" anchor="MainExample"> Exchange</name>
        <t>
  The following example demonstrates a hypothetical token exchange in which
  an OAuth resource server
  assumes the role of the client during the exchange. It
  trades an access token, which it received in a protected resource request, for a new
  token that it will use to call to a backend service
  (extra line breaks and indentation in the examples are for display purposes only).
</t>
        <t>
  <xref target="main-prr"/> target="main-prr" format="default"/> shows the resource server receiving a protected resource request containing
  an OAuth access token in the Authorization header, as specified in
  Section 2.1 of
  <xref target="RFC6750"/>. target="RFC6750" sectionFormat="of" section="2.1"/>.
</t>
        <figure title="Protected Resource Request" anchor="main-prr">
  <artwork><![CDATA[
          <name>Protected Resource Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 GET /resource HTTP/1.1
 Host: frontend.example.com
 Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
]]></artwork>
        </figure>
        <t>
  In <xref target="main-tereq"/>, target="main-tereq" format="default"/>, the resource server assumes the role of
  client for the token exchange exchange, and the access token from the request in
  <xref target="main-prr"/> target="main-prr" format="default"/> is sent to the authorization server using a
  request as specified in <xref target="Request"/>. target="Request" format="default"/>.  The value of the <spanx style="verb">subject_token</spanx> <tt>subject_token</tt> parameter carries the access token token, and
  the value of the <spanx style="verb">subject_token_type</spanx> <tt>subject_token_type</tt> parameter
  indicates that it is an OAuth 2.0 access token.  The resource server, acting
  in the role of the client, uses its identifier and secret to authenticate to
  the authorization server using the HTTP Basic authentication scheme.  The <spanx style="verb">resource</spanx>
  <tt>resource</tt> parameter indicates the location of the
  backend service, https://backend.example.com/api, &lt;https://backend.example.com/api&gt;, where the issued token
  will be used.
</t>
        <figure title="Token Exchange Request" anchor="main-tereq">
  <artwork><![CDATA[
          <name>Token Exchange Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 POST /as/token.oauth2 HTTP/1.1
 Host: as.example.com
 Authorization: Basic cnMwODpsb25nLXNlY3VyZS1yYW5kb20tc2VjcmV0
 Content-Type: application/x-www-form-urlencoded

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &resource=https%3A%2F%2Fbackend.example.com%2Fapi
 &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
 &subject_token_type=
  urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
]]></artwork>
        </figure>
        <t>
  The authorization server validates the client credentials and the
  <spanx style="verb">subject_token</spanx>
  <tt>subject_token</tt> presented in the token
  exchange request. From the <spanx style="verb">resource</spanx> <tt>resource</tt>
  parameter, the authorization server is able to determine the
  appropriate policy to apply to the request and issues a token
  suitable for use at https://backend.example.com. &lt;https://backend.example.com&gt;.
  The <spanx style="verb">access_token</spanx> <tt>access_token</tt> parameter of the
  response shown in <xref target="main-teresp"/> target="main-teresp" format="default"/> contains the new token, which is itself a bearer OAuth
  access token that is valid for one minute. The token happens to be
  a JWT; however, its structure and format are opaque to
  the client client, so the <spanx style="verb">issued_token_type</spanx> <tt>issued_token_type</tt>
  indicates only that it is an access token.
</t>
        <figure title="Token Exchange Response" anchor="main-teresp">
    <artwork><![CDATA[
          <name>Token Exchange Response</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQiOiJo
    dHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2FzLmV
    4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1MzMsIn
    N1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQedw6rx
    f59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIWvmDCM
    y5-kdXjwhw",
  "issued_token_type":
      "urn:ietf:params:oauth:token-type:access_token",
  "token_type":"Bearer",
  "expires_in":60
 }
]]></artwork>
        </figure>
        <t>
  The resource server can then use the newly acquired access token in making
  a request to the backend server as illustrated in <xref target="main-beprr"/>. target="main-beprr" format="default"/>.
</t>
        <figure title="Backend anchor="main-beprr">
          <name>Backend Protected Resource Request" anchor="main-beprr">
        <artwork><![CDATA[ Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 GET /api HTTP/1.1
 Host: backend.example.com
 Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ
    iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2
    FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M
    zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe
    dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW
    vmDCMy5-kdXjwhw
]]></artwork>
        </figure>

  <!--    JWT signing key
  {"kty":"EC","kid":"9er","use":"sig","alg":"ES256",
  "x":"5yoR9FjZHn7kJDALhDzhZ8i8F06mc12YswUMTBv4BoA",
  "y":"4uxuIItWj5Duzspth5mUbpLXWrPFzFPQkOCeAGGI6KM",
  "crv":"P-256",
  "d":"LncS7zrx6c8X5qZRxoSN18ZEYDeI2wfKfUvX_DgwRH8"}
  -->
        <t>
    Additional examples can be found in <xref target="AdditionalExamples"/>. target="AdditionalExamples" format="default"/>.
        </t>
      </section>
    </section>
    <section anchor="TokenTypeIdentifiers" title="Token numbered="true" toc="default">
      <name>Token Type Identifiers"> Identifiers</name>
      <t>
  Several parameters in this specification utilize an identifier as the value to
  describe the token in question.
  Specifically, they are the
  <spanx style="verb">requested_token_type</spanx>,
  <spanx style="verb">subject_token_type</spanx>, <spanx style="verb">actor_token_type</spanx>
  <tt>requested_token_type</tt>,
  <tt>subject_token_type</tt>, and <tt>actor_token_type</tt>
  parameters of the request and the <spanx style="verb">issued_token_type</spanx> <tt>issued_token_type</tt> member of the response.
  Token type identifiers are URIs.
  Token Exchange exchange can work with both tokens issued by other parties and tokens from
  the given authorization server. For the former former, the token type identifier indicates
  the syntax (e.g., JWT or SAML 2.0) so the authorization server can parse it; for the latter latter, it indicates
  what the given authorization server issued it for (e.g., access_token <tt>access_token</tt> or refresh_token). <tt>refresh_token</tt>).
</t>
      <t>
  The following token type identifiers are defined by this specification.
  Other URIs MAY <bcp14>MAY</bcp14> be used to indicate other token types.
</t>
<t>
  <list style="hanging">

  <t hangText="urn:ietf:params:oauth:token-type:access_token">
    <vspace/>
      <dl newline="true" spacing="normal">
        <dt>urn:ietf:params:oauth:token-type:access_token</dt>
        <dd>
    Indicates that the token is an OAuth 2.0 access token issued by the given authorization server.
  </t>

  <t hangText="urn:ietf:params:oauth:token-type:refresh_token">
    <vspace/>
  </dd>
        <dt>urn:ietf:params:oauth:token-type:refresh_token</dt>
        <dd>
    Indicates that the token is an OAuth 2.0 refresh token issued by the given authorization server.
  </t>

  <t hangText="urn:ietf:params:oauth:token-type:id_token">
    <vspace/>
  </dd>
        <dt>urn:ietf:params:oauth:token-type:id_token</dt>
        <dd>
    Indicates that the token is an ID Token, Token as defined in Section 2 of <xref target="OpenID.Core"/>.
  </t>

  <t hangText="urn:ietf:params:oauth:token-type:saml1">
    <vspace/>
    target="OpenID.Core" format="default"/>.
  </dd>
        <dt>urn:ietf:params:oauth:token-type:saml1</dt>
        <dd>
    Indicates that the token is a base64url-encoded SAML 1.1 <xref target="OASIS.saml-core-1.1"/> target="OASIS.saml-core-1.1" format="default"/> assertion.
  </t>

  <t hangText="urn:ietf:params:oauth:token-type:saml2">
    <vspace/>
  </dd>
        <dt>urn:ietf:params:oauth:token-type:saml2</dt>
        <dd>
    Indicates that the token is a base64url-encoded SAML 2.0 <xref target="OASIS.saml-core-2.0-os"/> target="OASIS.saml-core-2.0-os" format="default"/> assertion.
  </t>
  </list>
</t>
  </dd>
      </dl>
      <t>
  The value <spanx style="verb">urn:ietf:params:oauth:token-type:jwt</spanx>, <tt>urn:ietf:params:oauth:token-type:jwt</tt>, which is defined in
  Section 9 of
  <xref target="JWT"/>, target="RFC7519" sectionFormat="of" section="9"/>, indicates that the token is a JWT.
</t>
      <t>
  The distinction between an access token and a JWT is subtle.
  An access token represents a delegated authorization decision, whereas JWT is a token format.
  An access token can be formatted as a JWT but doesn't necessarily have to be. And a
  JWT might well be an access token token, but not all JWTs are access tokens.

  The intent of this specification is that <spanx style="verb">urn:ietf:params:oauth:token-type:access_token</spanx> <tt>urn:ietf:params:oauth:token-type:access_token</tt>
  be an indicator that the token is a typical OAuth access token issued by the authorization server in question, opaque to the client,
  and usable the same manner as any other access token obtained from that authorization server.
  (It could well be a JWT, but the client isn't and needn't be aware of that fact.)
  Whereas, <spanx style="verb">urn:ietf:params:oauth:token-type:jwt</spanx> <tt>urn:ietf:params:oauth:token-type:jwt</tt> is to indicate specifically that a JWT is
  being requested or sent (perhaps in a cross-domain use-case use case where the JWT is used as an authorization grant to
  obtain an access token from a different authorization server as is facilitated by <xref target="RFC7523"/>). target="RFC7523" format="default"/>).
</t>
      <t>
  Note that for tokens which that are binary in nature, the URI used for conveying them
  needs to be associated with the semantics of a base64 or other
  encoding suitable for usage with HTTP and OAuth.
</t>
    </section>
    <section title="JSON anchor="JWTClaims" numbered="true" toc="default">
      <name>JSON Web Token Claims and Introspection Response Parameters" anchor="JWTClaims"> Parameters</name>
      <t>
   It is useful to have defined mechanisms to express delegation within a
   token as well as to express authorization to delegate or
   impersonate. Although the token exchange protocol described herein can be
   used with any type of token, this section defines claims to express such
   semantics specifically for JWTs and in an <xref target="RFC7662">OAuth OAuth 2.0 Token Introspection</xref> Introspection <xref target="RFC7662"
   format="default"></xref> response.  Similar
   definitions for other types of tokens are possible but beyond the scope of
   this specification.
      </t>
      <t>
   Note that the claims not established herein but used in examples and descriptions,
   such as <spanx style="verb">iss</spanx>, <spanx style="verb">sub</spanx>,
   <spanx style="verb">exp</spanx>, <tt>iss</tt>, <tt>sub</tt>,
   <tt>exp</tt>, etc., are defined by <xref target="JWT"/>. target="RFC7519" format="default"/>.
      </t>
      <section title='"act" anchor="actor" numbered="true" toc="default">
        <name>"act" (Actor) Claim' anchor="actor"> Claim</name>
        <t>
      The <spanx style="verb">act</spanx> <tt>act</tt> (actor) claim provides a means
      within a JWT to express that delegation has occurred and identify the
      acting party to whom authority has been delegated.  The <spanx style="verb">act</spanx> <tt>act</tt> claim value is a JSON object object, and members in
      the JSON object are claims that identify the actor.  The claims that
      make up the <spanx style="verb">act</spanx> <tt>act</tt> claim identify and possibly
      provide additional information about the actor.  For example, the
      combination of the two claims <spanx style="verb">iss</spanx> <tt>iss</tt> and <spanx style="verb">sub</spanx> <tt>sub</tt> might be necessary to uniquely identify an
      actor.
        </t>
        <t>
      However, claims within the <spanx style="verb">act</spanx> <tt>act</tt> claim pertain only to the identity of the actor
      and are not relevant to the validity of the containing JWT in the same manner as the top-level claims.
      Consequently, non-identity claims (e.g., <spanx style="verb">exp</spanx>, <spanx style="verb">nbf</spanx>, <tt>exp</tt>, <tt>nbf</tt>,
      and <spanx style="verb">aud</spanx>) <tt>aud</tt>) are not meaningful when used within an
      <spanx style="verb">act</spanx> claim,
      <tt>act</tt> claim and therefore are therefore not used.
        </t>

    <figure title="Actor Claim" anchor="act-ex">
      <preamble>
        <xref target="act-ex"/>
        <t><xref target="act-ex" format="default"/> illustrates the <spanx style="verb">act</spanx> <tt>act</tt> (actor) claim within a JWT Claims Set.  The
        claims of the token itself are about user@example.com while the <spanx style="verb">act</spanx> <tt>act</tt> claim indicates that admin@example.com is the
        current actor.
      </preamble>
    <artwork><![CDATA[
        </t>
        <figure anchor="act-ex">
          <name>Actor Claim</name>
<sourcecode type="json"><![CDATA[
 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"user@example.com",
   "act":
   {
     "sub":"admin@example.com"
   }
 }
]]></artwork>
    </figure>
 }]]></sourcecode></figure>
        <t>
      A chain of delegation can be expressed by nesting one <spanx style="verb">act</spanx> <tt>act</tt> claim within
      another. The outermost <spanx style="verb">act</spanx> <tt>act</tt> claim represents the current actor while nested
      <spanx style="verb">act</spanx>
      <tt>act</tt> claims represent prior actors. The least recent actor is the most deeply
      nested. The nested <spanx style="verb">act</spanx> <tt>act</tt> claims
      serve as a history trail that connects the initial request and subject
      through the various delegation steps undertaken before reaching the
      current actor.  In this sense, the current actor is considered to
      include the entire authorization/delegation history, leading naturally
      to the nested structure described here.
        </t>
        <t>
      For the purpose of applying access control policy, the consumer of a token MUST <bcp14>MUST</bcp14> only consider the token's
      top-level claims and the party identified as the current actor by the <spanx style="verb">act</spanx> <tt>act</tt>
      claim. Prior actors identified by any nested <spanx style="verb">act</spanx> <tt>act</tt> claims are
      informational only and are not to be considered in access control decisions.
        </t>
    <figure title="Nested Actor Claim" anchor="acts-ex">
      <preamble>
        <t>
        The following example in <xref target="acts-ex"/> target="acts-ex" format="default"/> illustrates nested <spanx style="verb">act</spanx> <tt>act</tt> (actor) claims within a JWT Claims Set.
        The claims of the token itself are about user@example.com while the <spanx style="verb">act</spanx> <tt>act</tt> claim indicates
        that the system https://service16.example.com &lt;https://service16.example.com&gt; is the current actor and https://service77.example.com &lt;https://service77.example.com&gt; was a prior actor.
        Such a token might come about as the result of service16 receiving a token in a call from service77
        and exchanging it for a token suitable to call service26 while the authorization server
        notes the situation in the newly issued token.
      </preamble>
      <artwork><![CDATA[
        </t>
        <figure anchor="acts-ex">
          <name>Nested Actor Claim</name>
          <sourcecode type="json"><![CDATA[
 {
   "aud":"https://service26.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904100,
   "nbf":1443904000,
   "sub":"user@example.com",
   "act":
   {
     "sub":"https://service16.example.com",
     "act":
     {
       "sub":"https://service77.example.com"
     }
   }
 }
]]></artwork>
]]></sourcecode>
        </figure>
        <t>
      When included as a top-level member of an OAuth token introspection response, <spanx style="verb">act</spanx> <tt>act</tt>
      has the same semantics and format as the claim of the same name.
        </t>
      </section>
      <section title='"scope" anchor="scopes" numbered="true" toc="default">
        <name>"scope" (Scopes) Claim' anchor="scopes"> Claim</name>
        <t>
      The value of the <spanx style="verb">scope</spanx> <tt>scope</tt> claim is a
      JSON string containing a space-separated list of
      scopes associated with the token, in the format described in
      Section 3.3 of <xref target="RFC6749"/>.
    </t>
    <figure title="Scopes Claim" anchor="scope-ex">
      <preamble>
      <xref target="scope-ex"/> target="RFC6749" sectionFormat="of" section="3.3"/>.
        </t>
        <t><xref target="scope-ex" format="default"/> illustrates the <spanx style="verb">scope</spanx> <tt>scope</tt> claim within a JWT Claims Set.
      </preamble>
      <artwork><![CDATA[
        </t>
        <figure anchor="scope-ex">
          <name>Scopes Claim</name>
          <sourcecode type="json"><![CDATA[
 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"dgaf4mvfs75Fci_FL3heQA",
   "scope":"email profile phone address"
 }
]]></artwork>
]]></sourcecode>
        </figure>
        <t>
      <xref target="RFC7662">OAuth target="RFC7662" format="default">OAuth 2.0 Token Introspection</xref> already defines the <spanx style="verb">scope</spanx> <tt>scope</tt>
      parameter to convey the scopes associated with the token.
        </t>
      </section>
      <section title='"client_id" anchor="client_id" numbered="true" toc="default">
        <name>"client_id" (Client Identifier) Claim' anchor="client_id"> Claim</name>
        <t>
      The <spanx style="verb">client_id</spanx> <tt>client_id</tt> claim carries the
      client identifier of the <xref target="RFC6749">OAuth target="RFC6749" format="default">OAuth 2.0</xref> client that
      requested the token.
        </t>

    <figure title="Client Identifier Claim" anchor="client_id-ex">
      <preamble>
        <t>
        The following example in <xref target="client_id-ex"/> target="client_id-ex" format="default"/> illustrates the <spanx style="verb">client_id</spanx> <tt>client_id</tt> claim within a JWT Claims Set
        indicating an OAuth 2.0 client with "s6BhdRkqt3" as its identifier.
      </preamble>
      <artwork><![CDATA[
        </t>
        <figure anchor="client_id-ex">
          <name>Client Identifier Claim</name>
          <sourcecode type="json"><![CDATA[
 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "sub":"user@example.com",
   "client_id":"s6BhdRkqt3"
 }
]]></artwork>
]]></sourcecode>
        </figure>
        <t>
      <xref target="RFC7662">OAuth target="RFC7662" format="default">OAuth 2.0 Token Introspection</xref> already defines the <spanx style="verb">client_id</spanx> <tt>client_id</tt>
      parameter as the client identifier for the OAuth 2.0 client that requested the token.
        </t>
      </section>
      <section title='"may_act" anchor="may_act" numbered="true" toc="default">
        <name>"may_act" (Authorized Actor) Claim' anchor="may_act"> Claim</name>
        <t>
      The <spanx style="verb">may_act</spanx> <tt>may_act</tt> claim makes a statement that one party is authorized to
      become the actor and act on behalf of another party.
      The claim might be used, for example, when a <spanx style="verb">subject_token</spanx> <tt>subject_token</tt> is
      presented to the token endpoint in a token exchange request and
      <spanx style="verb">may_act</spanx>
      <tt>may_act</tt> claim in the subject token can be used by the authorization
      server to determine whether the client (or party identified in the
      <spanx style="verb">actor_token</spanx>)
      <tt>actor_token</tt>) is authorized to engage in the requested delegation or
      impersonation.
      The claim value is a JSON object object, and members in the JSON object are claims that identify the party that
      is asserted as being eligible to act for the party identified by
      the JWT containing the claim.
      The claims that make up the <spanx style="verb">may_act</spanx> <tt>may_act</tt>
      claim identify and possibly provide additional information about the authorized actor.
      For example, the combination of the two claims <spanx style="verb">iss</spanx> <tt>iss</tt>
      and <spanx style="verb">sub</spanx> <tt>sub</tt> are sometimes necessary to uniquely identify an authorized actor,
      while the <spanx style="verb">email</spanx> <tt>email</tt> claim might be used to provide additional useful information about
      that party.
        </t>
        <t>
      However, claims within the <spanx style="verb">may_act</spanx> <tt>may_act</tt> claim pertain only to the identity of that party
      and are not relevant to the validity of the containing JWT
      in the same manner as top-level claims.
      Consequently, claims such as <spanx style="verb">exp</spanx>, <spanx style="verb">nbf</spanx>, <tt>exp</tt>, <tt>nbf</tt>, and
      <spanx style="verb">aud</spanx>
      <tt>aud</tt> are not meaningful when used within a <spanx style="verb">may_act</spanx>
      claim, <tt>may_act</tt>
      claim and therefore are therefore not used.
        </t>
<t>

</t>
    <figure title="Authorized Actor Claim" anchor="may_act-ex">
      <preamble>
        <xref target="may_act-ex"/>

        <t><xref target="may_act-ex" format="default"/> illustrates the <spanx style="verb">may_act</spanx> <tt>may_act</tt> claim within a JWT Claims Set.
        The claims of the token itself are about user@example.com while the <spanx style="verb">may_act</spanx> <tt>may_act</tt> claim indicates
        that admin@example.com is authorized to act on behalf of user@example.com.
      </preamble>
      <artwork><![CDATA[
        </t>
        <figure anchor="may_act-ex">
          <name>Authorized Actor Claim</name>
          <sourcecode type="json"><![CDATA[
 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"user@example.com",
   "may_act":
   {
     "sub":"admin@example.com"
   }
 }
]]></artwork>
]]></sourcecode>
        </figure>
        <t>
      When included as a top-level member of an OAuth token introspection response, <spanx style="verb">may_act</spanx> <tt>may_act</tt>
      has the same semantics and format as the claim of the same name.
        </t>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        Much of the guidance from Section 10 of <xref target="RFC6749"/>, target="RFC6749"
	sectionFormat="of" section="10"/>,
        the Security Considerations in The OAuth 2.0 Authorization Framework,
        is also applicable here.
        Furthermore, <xref target="RFC6819"/> target="RFC6819" format="default"/>
        provides additional security considerations for OAuth OAuth, and
        <xref target="OAUTH-SECURITY"/> target="I-D.ietf-oauth-security-topics" format="default"/>
        has updated security guidance based on deployment experience and new threats that have
        emerged since OAuth 2.0 was originally published.
      </t>
      <t>
        All of the normal security issues that are discussed in <xref target="JWT"/>, target="RFC7519" format="default"/>,
        especially in relationship to comparing URIs and dealing with unrecognized values,
        also apply here.
      </t>
      <t>
        In addition, both delegation and impersonation introduce unique
        security issues.  Any time one principal is delegated the rights of
        another principal, the potential for abuse is a concern.  The use of
        the <spanx style="verb">scope</spanx> <tt>scope</tt> claim (in addition to other
        typical constraints such as a limited token lifetime) is suggested to
        mitigate potential for such abuse, as it restricts the contexts in
        which the delegated rights can be exercised.
      </t>
    </section>
    <section anchor="Privacy" title="Privacy Considerations"> numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>
        Tokens employed in the context of the functionality described herein
        may contain privacy-sensitive information and, to prevent
        disclosure of such information to unintended parties, MUST <bcp14>MUST</bcp14> only be
        transmitted over encrypted channels, such as Transport Layer Security
        (TLS).  In cases where it is desirable to prevent disclosure of certain
        information to the client, the token MUST <bcp14>MUST</bcp14> be encrypted to its
        intended recipient. Deployments SHOULD <bcp14>SHOULD</bcp14> determine the minimally necessary
        amount of data and only include such information in issued tokens.
        In some cases, data minimization may include representing only an
        anonymous or pseudonymous user.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="URIReg" title="OAuth numbered="true" toc="default">
        <name>OAuth URI Registration"> Registration</name>
        <t>
	  This specification registers
	  IANA has registered the following values in the
	  IANA
	  "OAuth URI" subregistry of the "OAuth Parameters" registry
	  <xref target="IANA.OAuth.Parameters"/> target="IANA.OAuth.Parameters" format="default"/>. The "OAuth URI" subregistry was
	  established by <xref target="RFC6755"/>. target="RFC6755" format="default"/>.
        </t>

	<section title="Registry Contents" anchor="URIContents">

	  <t>
	    <?rfc subcompact="yes"?>
	    <list style="symbols">
	      <t>URN: urn:ietf:params:oauth:grant-type:token-exchange</t>
	      <t>Common
        <ul spacing="compact">
          <li>URN: urn:ietf:params:oauth:grant-type:token-exchange</li>
          <li>Common Name: Token exchange grant type for OAuth 2.0</t>
	      <t>Change controller: IESG</t>
	      <t>Specification 2.0</li>
          <li>Change Controller: IESG</li>
          <li>Specification Document: <xref target="Request"/> target="Request" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>URN: urn:ietf:params:oauth:token-type:access_token</t>
	      <t>Common RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>URN: urn:ietf:params:oauth:token-type:access_token</li>
          <li>Common Name: Token type URI for an OAuth 2.0 access token</t>
	      <t>Change controller: IESG</t>
	      <t>Specification token</li>
          <li>Change Controller: IESG</li>
          <li>Specification Document: <xref target="TokenTypeIdentifiers"/> target="TokenTypeIdentifiers" format="default"/> of [[this specification]]</t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>URN: urn:ietf:params:oauth:token-type:refresh_token</t>
	      <t>Common RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>URN: urn:ietf:params:oauth:token-type:refresh_token</li>
          <li>Common Name: Token type URI for an OAuth 2.0 refresh token</t>
	      <t>Change controller: IESG</t>
	      <t>Specification token</li>
          <li>Change Controller: IESG</li>
          <li>Specification Document: <xref target="TokenTypeIdentifiers"/> target="TokenTypeIdentifiers" format="default"/> of [[this specification]]</t>
	    </list>
	  </t>
	  <t>
	    <list style="symbols">
	      <t>URN: urn:ietf:params:oauth:token-type:id_token</t>
	      <t>Common RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>URN: urn:ietf:params:oauth:token-type:id_token</li>
          <li>Common Name: Token type URI for an ID Token</t>
	      <t>Change controller: IESG</t>
	      <t>Specification Token</li>
          <li>Change Controller: IESG</li>
          <li>Specification Document: <xref target="TokenTypeIdentifiers"/> target="TokenTypeIdentifiers" format="default"/> of [[this specification]]</t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>URN: urn:ietf:params:oauth:token-type:saml1</t>
	      <t>Common RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>URN: urn:ietf:params:oauth:token-type:saml1</li>
          <li>Common Name: Token type URI for a base64url-encoded SAML 1.1 assertion</t>
	      <t>Change assertion</li>
          <li>Change Controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification Document: <xref target="TokenTypeIdentifiers"/> target="TokenTypeIdentifiers" format="default"/> of [[this specification]]</t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>URN: urn:ietf:params:oauth:token-type:saml2</t>
	      <t>Common RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>URN: urn:ietf:params:oauth:token-type:saml2</li>
          <li>Common Name: Token type URI for a base64url-encoded SAML 2.0 assertion</t>
	      <t>Change assertion</li>
          <li>Change Controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification Document: <xref target="TokenTypeIdentifiers"/> target="TokenTypeIdentifiers" format="default"/> of [[this specification]]</t>
	    </list>
	  </t>
	  <?rfc subcompact="no"?>

	</section> RFC 8693</li>
        </ul>
      </section>
      <section anchor="OAuthParametersReg" title="OAuth numbered="true" toc="default">
        <name>OAuth Parameters Registration"> Registration</name>
        <t>
	  This specification registers
	  IANA has registered the following values
	  in the IANA "OAuth Parameters" subregistry of the "OAuth Parameters" registry
	  <xref target="IANA.OAuth.Parameters"/> target="IANA.OAuth.Parameters" format="default"/>. The "OAuth Parameters"
	  subregistry was
	  established by <xref target="RFC6749"/>.
	</t>

	<section anchor='ParametersContents' title='Registry Contents'>

	  <t>
	    <?rfc subcompact="yes"?>
	    <list style='symbols'>
	      <t>Parameter name: resource</t>
	      <t>Parameter usage location: token request</t>
	      <t>Change controller: IESG</t>
	      <t>Specification document(s): <xref target="Request"/> of [[ this specification ]]</t>
	    </list> target="RFC6749" format="default"/>.
        </t>
	  <t>
	    <list style='symbols'>
	      <t>Parameter

    <ul spacing="compact">
          <li>Parameter name: audience</t>
	      <t>Parameter audience</li>
          <li>Parameter usage location: token request</t>
	      <t>Change request</li>
          <li>Change controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification document(s): <xref target="Request"/> target="Request" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>Parameter RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Parameter name: requested_token_type</t>
	      <t>Parameter requested_token_type</li>
          <li>Parameter usage location: token request</t>
	      <t>Change request</li>
          <li>Change controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification document(s): <xref target="Request"/> target="Request" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>Parameter RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Parameter name: subject_token</t>
	      <t>Parameter subject_token</li>
          <li>Parameter usage location: token request</t>
	      <t>Change request</li>
          <li>Change controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification document(s): <xref target="Request"/> target="Request" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>Parameter RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Parameter name: subject_token_type</t>
	      <t>Parameter subject_token_type</li>
          <li>Parameter usage location: token request</t>
	      <t>Change request</li>
          <li>Change controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification document(s): <xref target="Request"/> target="Request" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>Parameter RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Parameter name: actor_token</t>
	      <t>Parameter actor_token</li>
          <li>Parameter usage location: token request</t>
	      <t>Change request</li>
          <li>Change controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification document(s): <xref target="Request"/> target="Request" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>Parameter RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Parameter name: actor_token_type</t>
	      <t>Parameter actor_token_type</li>
          <li>Parameter usage location: token request</t>
	      <t>Change request</li>
          <li>Change controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification document(s): <xref target="Request"/> target="Request" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>Parameter RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Parameter name: issued_token_type</t>
	      <t>Parameter issued_token_type</li>
          <li>Parameter usage location: token response</t>
	      <t>Change response</li>
          <li>Change controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification document(s): <xref target="SuccessfulResponse"/> target="SuccessfulResponse" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
	  <?rfc subcompact="no"?>

	</section> RFC 8693</li>
        </ul>
      </section>
      <section anchor="TokenTypeReg" title='OAuth numbered="true" toc="default">
        <name>OAuth Access Token Type Registration'> Registration</name>
        <t>
          This specification registers
          IANA has registered the following access token type
	  in the IANA "OAuth Access Token Types" subregistry of the "OAuth
	  Parameters" registry
	  <xref target="IANA.OAuth.Parameters"/> target="IANA.OAuth.Parameters" format="default"/>. The "OAuth Access Token
	  Types" subregistry was
	  established by <xref target="RFC6749"/>. target="RFC6749" format="default"/>.
        </t>

        <section anchor="TokenTypeContents" title='Registry Contents'>

          <t>
	    <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>Type
        <ul spacing="compact">
          <li>Type name: N_A</t>
              <t>Additional N_A</li>
          <li>Additional Token Endpoint Response Parameters: (none)</t>
              <t>HTTP none</li>
          <li>HTTP Authentication Scheme(s): (none)</t>
              <t>Change none</li>
          <li>Change controller: IESG</t>
              <t>Specification IESG</li>
          <li>Specification document(s): <xref target="SuccessfulResponse"/> target="SuccessfulResponse" format="default"/> of [[ this specification ]]</t>
            </list>
          </t>
	  <?rfc subcompact="no"?>

        </section> RFC 8693</li>
        </ul>
      </section>
      <section anchor="ClaimsReg" title="JSON numbered="true" toc="default">
        <name>JSON Web Token Claims Registration"> Registration</name>
        <t>
	  This specification registers
	  IANA has registered the following Claims
	  in the IANA "JSON Web Token Claims" subregistry of the "JSON Web Token
	  (JWT)" registry
	  <xref target="IANA.JWT.Claims"/> target="IANA.JWT" format="default"/>. The "JSON Web Token Claims"
	  subregistry was
	  established by <xref target="JWT"/>. target="RFC7519" format="default"/>.
        </t>

	<section anchor='ClaimsContents' title='Registry Contents'>

	  <t>
	    <?rfc subcompact="yes"?>
	    <list style='symbols'>
	      <t>Claim
        <ul spacing="compact">
          <li>Claim Name: <spanx style="verb">act</spanx></t>
	      <t>Claim act</li>
          <li>Claim Description: Actor</t>
	      <t>Change Actor</li>
          <li>Change Controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification Document(s): <xref target="actor"/> target="actor" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>Claim RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Claim Name: <spanx style="verb">scope</spanx></t>
	      <t>Claim scope</li>
          <li>Claim Description: Scope Values</t>
	      <t>Change Values</li>
          <li>Change Controller: IESG</t>
	      <t>Specification IESG</li>
          <li>Specification Document(s): <xref target="scopes"/> target="scopes" format="default"/> of [[ this specification ]]</t>
	    </list>
	  </t>
    <t>
      <list style='symbols'>
        <t>Claim RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Claim Name: <spanx style="verb">client_id</spanx></t>
        <t>Claim client_id</li>
          <li>Claim Description: Client Identifier</t>
        <t>Change Identifier</li>
          <li>Change Controller: IESG</t>
        <t>Specification IESG</li>
          <li>Specification Document(s): <xref target="client_id"/> target="client_id" format="default"/> of [[ this specification ]]</t>
      </list>
    </t>
    <t>
      <list style='symbols'>
        <t>Claim RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Claim Name: <spanx style="verb">may_act</spanx></t>
        <t>Claim may_act</li>
          <li>Claim Description: Authorized Actor - the party that is authorized to become the actor</t>
        <t>Change actor</li>
          <li>Change Controller: IESG</t>
        <t>Specification IESG</li>
          <li>Specification Document(s): <xref target="may_act"/> target="may_act" format="default"/> of [[ this specification ]]</t>
      </list>
    </t>
	  <?rfc subcompact="no"?>

	</section> RFC 8693</li>
        </ul>
      </section>
      <section anchor="IntrospectionReg" title="OAuth numbered="true" toc="default">
        <name>OAuth Token Introspection Response Registration"> Registration</name>
        <t>
          This specification registers
          IANA has registered the following values
          in the IANA "OAuth Token Introspection Response" registry of the "OAuth
	  Parameters" registry
          <xref target="IANA.OAuth.Parameters"/> target="IANA.OAuth.Parameters" format="default"/>. The "OAuth Token
	  Introspection Response" registry was
          established by <xref target="RFC7662"/>. target="RFC7662" format="default"/>.
        </t>

        <section anchor='IntrospectionContents' title='Registry Contents'>

          <t>
            <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>Claim Name: <spanx style="verb">act</spanx></t>
              <t>Claim Description: Actor</t>
              <t>Change
        <ul spacing="compact">
          <li>Name: act</li>
          <li>Description: Actor</li>
          <li>Change Controller: IESG</t>
              <t>Specification IESG</li>
          <li>Specification Document(s): <xref target="actor"/> target="actor" format="default"/> of [[ this specification ]]</t>
            </list>
          </t>
          <t>
            <list style='symbols'>
              <t>Claim Name: <spanx style="verb">may_act</spanx></t>
              <t>Claim Description: RFC 8693</li>
        </ul>
        <ul spacing="compact">
          <li>Name: may_act</li>
          <li>Description: Authorized Actor - the party that is authorized to become the actor</t>
              <t>Change Controller: IESG</t>
              <t>Specification Document(s): <xref target="may_act"/> of [[ this specification ]]</t>
            </list>
          </t>
          <?rfc subcompact="no"?>

        </section>
      </section>

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

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

        <section anchor='ErrorContents' title='Registry Contents'>

          <t>
            <?rfc subcompact="yes"?>
            <list style='symbols'>
              <t>Error Name: <spanx style="verb">invalid_target</spanx></t>
              <t>Error Usage Location: token error response</t>
              <t>Related Protocol Extension: OAuth 2.0 Token Exchange</t>
              <t>Change actor</li>
          <li>Change Controller: IETF</t>
              <t>Specification IESG</li>
          <li>Specification Document(s): <xref target="ErrorResponse"/> target="may_act" format="default"/> of [[ this specification ]]</t>
            </list>
          </t>
          <?rfc subcompact="no"?>

        </section> RFC 8693</li>
        </ul>
      </section>

    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml' ?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"?>

<displayreference target="RFC7519" to="JWT"/>

<displayreference target="I-D.ietf-oauth-security-topics" to="OAUTH-SECURITY"/>

<displayreference target="I-D.ietf-oauth-resource-indicators" to="OAUTH-RESOURCE"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <reference  anchor='JWT' target='https://www.rfc-editor.org/info/rfc7519'> anchor="IANA.JWT" target="https://www.iana.org/assignments/jwt">
          <front>
            <title>JSON Web Token (JWT)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></author>
<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization /></author>
<date year='2015' month='May' />
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>

<!-- [rfced] [IANA.JWT.Claims] This URL is correct -->

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

<!-- [rfced] [IANA.OAuth.Parameters] This URL is correct -->

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

    </references>

    <references title="Informative References">
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6755.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7521.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7523.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6819.xml' ?>

<!-- <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-security-topics.xml'?>; I-D Exists -->

<reference anchor='OAUTH-SECURITY'>
<front>
<title>OAuth 2.0 Security Best Current Practice</title>

<author initials='T' surname='Lodderstedt' fullname='Torsten Lodderstedt'>
    <organization />
</author>

<author initials='J' surname='Bradley' fullname='John Bradley'>
    <organization />
</author>

<author initials='A' surname='Labunets' fullname='Andrey Labunets'>
    <organization />
</author>

<author initials='D' surname='Fett' fullname='Daniel Fett'>
    <organization />
</author>

<date month='July' day='8' year='2019' />

<abstract><t>This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0.</t></abstract>

</front>

<seriesInfo name='Work in Progress,' value='draft-ietf-oauth-security-topics-13' />
</reference>

<!-- <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-resource-indicators.xml'?>; Waiting for Writeup -->

<reference anchor='OAUTH-RESOURCE'>
<front>
<title>Resource Indicators for OAuth 2.0</title>

<author initials='B' surname='Campbell' fullname='Brian Campbell'>
    <organization />
</author>

<author initials='J' surname='Bradley' fullname='John Bradley'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<date month='July' day='24' year='2019' />

<abstract><t>An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.</t></abstract>

</front>

<seriesInfo name='Work in Progress,' value='draft-ietf-oauth-resource-indicators-05' />
</reference>

<!-- <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml' ?>; inserted full entry from http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml -->

<reference anchor="OASIS.saml-core-2.0-os">
    <front>
        <title>Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </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>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6755.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7521.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7523.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6819.xml"/>

        <!-- I-D.ietf-oauth-security-topics; I-D Exists -->
    <xi:include
    href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.ietf-oauth-security-topics.xml"/>

        <!-- < I-D.ietf-oauth-resource-indicators; RFC-EDITOR state -->
    <xi:include
    href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.ietf-oauth-resource-indicators.xml"/>

        <reference anchor="OASIS.saml-core-2.0-os" target="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">
          <front>
            <title>Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0</title>
            <seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/>
            <author fullname="Scott Cantor" initials="S." surname="Cantor">
              <organization>Internet2</organization>
              <address>
                <email>cantor.2@osu.edu</email>
              </address>
            </author>
            <author fullname="John Kemp" initials="J." surname="Kemp">
              <organization>Nokia</organization>
              <address>
                <email>John.Kemp@nokia.com</email>
              </address>
            </author>
            <author fullname="Rob Philpott" initials="R." surname="Philpott">
              <organization>RSA Security</organization>
              <address>
                <email>rphilpott@rsasecurity.com</email>
              </address>
            </author>
            <author fullname="Eve Maler" initials="E." surname="Maler">
              <organization>Sun Microsystems</organization>
              <address>
                <email>eve.maler@sun.com</email>
              </address>
            </author>
            <date year="2005" month="March"/>
          </front>
    <seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/>
    <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf"/>
        </reference>

<!-- [rfced] [OASIS.saml-core-1.1] This URL is correct -->
        <reference anchor="OASIS.saml-core-1.1"> anchor="OASIS.saml-core-1.1" target="https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf">
          <front>
            <title>Assertions and Protocol for the OASIS Security Assertion Markup Language
	  (SAML) V1.1</title>
            <seriesInfo name="OASIS Standard" value="oasis-sstc-saml-core-1.1"/>
            <author fullname="Eve Maler" initials="E." surname="Maler">
              <organization>Sun Microsystems</organization>
              <address>
                <email>eve.maler@sun.com</email>
              </address>
            </author>
            <author fullname="Prateek Mishra" initials="P." surname="Mishra">
              <organization>Netegrity, Inc.</organization>
              <address>
                <email>pmishra@netegrity.com</email>
              </address>
            </author>
            <author fullname="Rob Philpott" initials="R." surname="Philpott">
              <organization>RSA Security</organization>
              <address>
                <email>rphilpott@rsasecurity.com</email>
              </address>
            </author>
            <date year="2003" month="September" day="2"/> month="September"/>
          </front>
	<seriesInfo name="OASIS Standard" value="oasis-sstc-saml-core-1.1"/>
	<format type="PDF" target="https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf"/>
        </reference>

<!-- [rfced] [WS-Trust] This URL is correct -->
        <reference anchor="WS-Trust" target="http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html"> target="https://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html">
          <front>
            <title>WS-Trust 1.4</title>
            <author fullname="Anthony Nadalin" initials="A." surname="Nadalin"/> surname="Nadalin" role="editor"/>
            <author fullname="Marc Goodner" initials="M." surname="Goodner"/> surname="Goodner" role="editor"/>
            <author fullname="Martin Gudgin" initials="M." surname="Gudgin"/> surname="Gudgin" role="editor"/>
            <author fullname="Abbie Barbir" initials="A." surname="Barbir"/> surname="Barbir" role="editor"/>
            <author fullname="Hans Granqvist" initials="H." surname="Granqvist"/> surname="Granqvist" role="editor"/>
            <date day="2" month="February" year="2012"/>
          </front>
        </reference>

<!-- <?rfc include='http://openid.net/bibxml/reference.OpenID.Core.xml' ?>; inserted full entry from http://openid.net/bibxml/reference.OpenID.Core.xml -->
        <reference anchor="OpenID.Core"
target="http://openid.net/specs/openid-connect-core-1_0.html"> target="https://openid.net/specs/openid-connect-core-1_0.html">
          <front>
            <title abbrev="OpenID Connect Core 1.0">OpenID Connect Core 1.0</title>
            <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
              <organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
              <address>
                <email>n-sakimura@nri.co.jp</email>
<uri>http://nat.sakimura.org/</uri>
                <uri>https://nat.sakimura.org/</uri>
              </address>
            </author>
            <author fullname="John Bradley" initials="J." surname="Bradley">
              <organization abbrev="Ping Identity">Ping Identity</organization>
              <address>
                <email>ve7jtb@ve7jtb.com</email>
                <uri>http://www.thread-safe.com/</uri>
              </address>
            </author>
            <author fullname="Michael B. Jones" initials="M.B." initials="M." surname="Jones">
              <organization abbrev="Microsoft">Microsoft</organization>
              <address>
                <email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
                <uri>https://self-issued.info/</uri>
              </address>
            </author>
            <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
              <organization abbrev="Google">Google</organization>
              <address>
                <email>breno@google.com</email>
<uri>http://stackoverflow.com/users/311376/breno</uri>
                <uri>https://stackoverflow.com/users/311376/breno</uri>
              </address>
            </author>
            <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
              <organization abbrev="Salesforce">Salesforce</organization> abbrev="Visa">Visa</organization>
              <address>
        <email>cmortimore@salesforce.com</email>
                <email>chuck.mortimore@visa.com</email>
                <uri>https://twitter.com/cmort</uri>
              </address>
            </author>
            <date day="8" month="November" year="2014" /> year="2014"/>
            <workgroup>OpenID Connect Working Group</workgroup>

    <abstract>
      <t>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
      protocol. It enables Clients to verify the identity of the End-User based
      on the authentication performed by an Authorization Server, as well as to
      obtain basic profile information about the End-User in an interoperable and
      REST-like manner.</t>

      <t>
This specification defines the core OpenID Connect functionality:
authentication built on top of OAuth 2.0 and
the use of Claims to communicate information about the End-User.
It also describes the security and privacy considerations for using OpenID
Connect.
      </t>
    </abstract>
  </front>
</reference>

    </references>

  <section title="Additional Token Exchange Examples" anchor="AdditionalExamples">
    <t>
      Two example token exchanges are provided in
          </front>
        </reference>
      </references>
    </references>
    <section anchor="AdditionalExamples" numbered="true" toc="default">
      <name>Additional Token Exchange Examples</name>
      <t>
      Two example token exchanges are provided in the following sections
      illustrating impersonation and delegation, respectively
      (with extra line breaks and indentation for display purposes only).
      </t>
      <section title="Impersonation anchor="ImpersonationExample" numbered="true" toc="default">
        <name>Impersonation Token Exchange Example" anchor="ImpersonationExample"> Example</name>
        <section anchor="ImpersonationRequest" title="Token numbered="true" toc="default">
          <name>Token Exchange Request"> Request</name>
          <t>
        In the following token exchange request, a client is requesting a token
        with impersonation semantics (with (delegation is impossible with only a <spanx style="verb">subject_token</spanx> <tt>subject_token</tt>
        and no <spanx style="verb">actor_token</spanx>, delegation is impossible). <tt>actor_token</tt>).
        The client tells the authorization server that it needs a token for use at
        the target service with the logical name
	<spanx style="verb">urn:example:cooperation-context</spanx>.
	<tt>urn:example:cooperation-context</tt>.
          </t>
          <figure title="Token Exchange Request" anchor="ImpersonationRequestEx">
      <artwork><![CDATA[
            <name>Token Exchange Request</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 POST /as/token.oauth2 HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &audience=urn%3Aexample%3Acooperation-context
 &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
   zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
   uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTA2MDAsIm5iZiI6MTQ0MTkwOTAwMCwic
   3ViIjoiYmRjQGV4YW1wbGUubmV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN
   0b3J5In0.PRBg-jXn4cJuj1gmYXFiGkZzRuzbXZ_sDxdE98ddW44ufsbWLKd3JJ1VZ
   hF64pbTtfjy4VXFVBDaQpKjn5JzAw
 &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
]]></artwork>
          </figure>
    <!-- JWT signing key for example.net
     {"kty":"EC","kid":"16","use":"sig","alg":"ES256",
     "x":"N_MqlYd_Iq0rfzTqXAX7TUC0r7fQSp3YQKh42tn7uSc",
     "y":"9tGuwMFkHYWPqkLa51f8GazZNQqdgMOVvJEd6fJ18PI",
     "crv":"P-256",
     "d":"cZ_4DqRSAWMMErQbKv6dCYqI9G1pi6lxvlvHU152Uts"}
    -->
        </section>
        <section anchor="ImpersonationSubjectClaims" title="Subject numbered="true" toc="default">
          <name>Subject Token Claims"> Claims</name>
          <t>
  The <spanx style="verb">subject_token</spanx> <tt>subject_token</tt> in the prior request is a JWT JWT, and
  the decoded JWT Claims Set is shown here. The JWT is
  intended for consumption by the authorization server within a specific time window.
  The subject of the JWT (<spanx style="verb">bdc@example.net</spanx>) (<tt>bdc@example.net</tt>) is
  the party on behalf of whom the new token is being requested.
</t>
          <figure title="Subject Token Claims" anchor="ImpersonationSubjectClaimsEx">
      <artwork><![CDATA[
            <name>Subject Token Claims</name>
            <sourcecode type="json"><![CDATA[
  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910600,
    "nbf":1441909000,
    "sub":"bdc@example.net",
    "scope":"orders profile history"
  }
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
        <section anchor="ImpersonationResponse" title="Token numbered="true" toc="default">
          <name>Token Exchange Response"> Response</name>
          <t>
  The <spanx style="verb">access_token</spanx> <tt>access_token</tt> parameter of the token exchange
  response shown below contains the new token that the client requested.
  The other parameters of the response indicate that the token is a bearer access token
  that expires in an hour.
</t>
          <figure title="Token Exchange Response" anchor="ImpersonationResponseEx">
      <artwork><![CDATA[
            <name>Token Exchange Response</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
    6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
    eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic3ViIjoiYmRjQGV4YW1wbGUub
    mV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN0b3J5In0.rMdWpSGNACTvnF
    uOL74sYZ6MVuld2Z2WkGLmQeR9ztj6w2OXraQlkJmGjyiCq24kcB7AI2VqVxl3wSW
    nVKh85A",
  "issued_token_type":
    "urn:ietf:params:oauth:token-type:access_token",
  "token_type":"Bearer",
  "expires_in":3600
 }
]]></artwork>
          </figure>
    <!-- JWT signing key for example.com
     {"kty":"EC","kid":"72","use":"sig","alg":"ES256",
     "x":"472aI8TvDdm2qfBRpXYw0uZ7feumuQOM-RPRkkTukSo",
     "y":"VNNStdPhuxY6q7XfVIeYSW7xh_a4z5W2MCtNmQDcILc",
     "crv":"P-256",
     "d":"dtJiut8QBJxACG6fcX8NYnzIsAN1muCJvaMiLSrOjIc"}

    -->
        </section>
        <section anchor="ImpersonationIssuedClaims" title="Issued numbered="true" toc="default">
          <name>Issued Token Claims"> Claims</name>
          <t>
  The decoded JWT Claims Set of the issued token is shown below. The new JWT is
  issued by the authorization server and intended for consumption by a system entity
  known by the logical name <spanx style="verb">urn:example:cooperation-context</spanx> <tt>urn:example:cooperation-context</tt>
  any time before its expiration.
  The subject (<spanx style="verb">sub</spanx>) (<tt>sub</tt>) of the JWT
  is the same as the subject the token used to make the request,
  which effectively enables the client to impersonate that subject
  at the system entity known by the logical name of
  <spanx style="verb">urn:example:cooperation-context</spanx>
  <tt>urn:example:cooperation-context</tt> by using the token.
</t>
          <figure anchor="ImpersonationIssuedClaimsEx" title="Issued anchor="ImpersonationIssuedClaimsEx">
            <name>Issued Token Claims">
      <artwork><![CDATA[ Claims</name>
            <sourcecode type="json"><![CDATA[
  {
    "aud":"urn:example:cooperation-context",
    "iss":"https://as.example.com",
    "exp":1441913610,
    "sub":"bdc@example.net",
    "scope":"orders profile history"
  }
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
      </section>
      <section title="Delegation anchor="DelegationExample" numbered="true" toc="default">
        <name>Delegation Token Exchange Example" anchor="DelegationExample"> Example</name>
        <section anchor="DelegationRequest" title="Token numbered="true" toc="default">
          <name>Token Exchange Request"> Request</name>
          <t>
        In the following token exchange request, a client is requesting a token
        and providing both a <spanx style="verb">subject_token</spanx> <tt>subject_token</tt> and an <spanx style="verb">actor_token</spanx>. <tt>actor_token</tt>.
        The client tells the authorization server that it needs a token for use at
        the target service with the logical name
	<spanx style="verb">urn:example:cooperation-context</spanx>.
	<tt>urn:example:cooperation-context</tt>. Policy at the
        authorization server dictates that the issued token be a composite.
          </t>
          <figure anchor="DelegationRequestEx" title="Token anchor="DelegationRequestEx">
            <name>Token Exchange Request">
        <artwork><![CDATA[ Request</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 POST /as/token.oauth2 HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &audience=urn%3Aexample%3Acooperation-context
 &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
   zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
   uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ
   WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1
   pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM
   xU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g
 &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
 &actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo
   vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ
   XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU
   ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ
   oUuDL2tEs6tqPlcBlMjiSzEjm3yBg
 &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
]]></artwork>
          </figure>
      <!-- JWT signing key for example.net
       {"kty":"EC","kid":"16","use":"sig","alg":"ES256",
       "x":"N_MqlYd_Iq0rfzTqXAX7TUC0r7fQSp3YQKh42tn7uSc",
       "y":"9tGuwMFkHYWPqkLa51f8GazZNQqdgMOVvJEd6fJ18PI",
       "crv":"P-256",
       "d":"cZ_4DqRSAWMMErQbKv6dCYqI9G1pi6lxvlvHU152Uts"}
      -->
        </section>
        <section anchor="DelegationSubjectClaims" title="Subject numbered="true" toc="default">
          <name>Subject Token Claims"> Claims</name>
          <t>
        The <spanx style="verb">subject_token</spanx> <tt>subject_token</tt> in the prior request is a JWT JWT, and
        the decoded JWT Claims Set is shown here. The JWT is
        intended for consumption by the authorization server
        before a specific expiration time.
	The subject of the JWT
	(<spanx style="verb">user@example.net</spanx>)
	(<tt>user@example.net</tt>) is
	the party on behalf of whom the new token is being requested.
          </t>
          <figure anchor="DelegationSubjectClaimsEx" title="Subject anchor="DelegationSubjectClaimsEx">
            <name>Subject Token Claims">
        <artwork><![CDATA[ Claims</name>
            <sourcecode type="json"><![CDATA[
  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910060,
    "scope":"status feed",
    "sub":"user@example.net",
    "may_act":
    {
      "sub":"admin@example.net"
    }
  }
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
        <section anchor="DelegationActorClaims" title="Actor numbered="true" toc="default">
          <name>Actor Token Claims"> Claims</name>
          <t>
        The <spanx style="verb">actor_token</spanx> <tt>actor_token</tt> in the prior request is a JWT JWT, and
        the decoded JWT Claims Set is shown here. This JWT is also
        intended for consumption by the authorization server
        before a specific expiration time.
	The subject of the JWT
	(<spanx style="verb">admin@example.net</spanx>)
	(<tt>admin@example.net</tt>) is
	the actor that will wield the security token being requested.
          </t>
          <figure anchor="DelegationActorClaimsEx" title="Actor anchor="DelegationActorClaimsEx">
            <name>Actor Token Claims">
        <artwork><![CDATA[ Claims</name>
            <sourcecode type="json"><![CDATA[
  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910060,
    "sub":"admin@example.net"
  }
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
        <section anchor="DelegationResponse" title="Token numbered="true" toc="default">
          <name>Token Exchange Response"> Response</name>
          <t>
        The <spanx style="verb">access_token</spanx> <tt>access_token</tt> parameter of the token exchange
        response shown below contains the new token that the client requested.
        The other parameters of the response indicate that the token is a JWT
	that expires in an hour and that the access token type is not applicable
	since the issued token is not an access token.
          </t>
          <figure anchor="DelegationResponseEx" title="Token anchor="DelegationResponseEx">
            <name>Token Exchange Response">
        <artwork><![CDATA[ Response</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
    6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
    eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NvcGUiOiJzdGF0dXMgZmVlZ
    CIsInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJhY3QiOnsic3ViIjoiYWRtaW5AZX
    hhbXBsZS5uZXQifX0.3paKl9UySKYB5ng6_cUtQ2qlO8Rc_y7Mea7IwEXTcYbNdwG
    9-G1EKCFe5fW3H0hwX-MSZ49Wpcb1SiAZaOQBtw",
  "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
  "token_type":"N_A",
  "expires_in":3600
 }
]]></artwork>
          </figure>
      <!-- JWT signing key for example.com
       {"kty":"EC","kid":"72","use":"sig","alg":"ES256",
       "x":"472aI8TvDdm2qfBRpXYw0uZ7feumuQOM-RPRkkTukSo",
       "y":"VNNStdPhuxY6q7XfVIeYSW7xh_a4z5W2MCtNmQDcILc",
       "crv":"P-256",
       "d":"dtJiut8QBJxACG6fcX8NYnzIsAN1muCJvaMiLSrOjIc"}

      -->
        </section>
        <section anchor="DelegationIssuedClaims" title="Issued numbered="true" toc="default">
          <name>Issued Token Claims"> Claims</name>
          <t>
        The decoded JWT Claims Set of the issued token is shown below. The new JWT is
        issued by the authorization server and intended for consumption by a system entity
        known by the logical name
	<spanx style="verb">urn:example:cooperation-context</spanx>
	<tt>urn:example:cooperation-context</tt>
	any time before its expiration.
        The subject (<spanx style="verb">sub</spanx>) (<tt>sub</tt>)
  of the JWT
	is the same as the subject of
	the <spanx style="verb">subject_token</spanx> <tt>subject_token</tt> used to make the request.
  The actor (<spanx style="verb">act</spanx>) (<tt>act</tt>) of the JWT is the same as the subject
	of the <spanx style="verb">actor_token</spanx> <tt>actor_token</tt> used to make the request.

        This indicates delegation and identifies
	<spanx style="verb">admin@example.net</spanx>
	<tt>admin@example.net</tt> as the current actor to whom authority
        has been delegated to act on behalf of <spanx style="verb">user@example.net</spanx>. <tt>user@example.net</tt>.
          </t>
          <figure anchor="DelegationIssuedClaimsEx" title="Issued anchor="DelegationIssuedClaimsEx">
            <name>Issued Token Claims">
        <artwork><![CDATA[ Claims</name>
            <sourcecode type="json"><![CDATA[
  {
    "aud":"urn:example:cooperation-context",
    "iss":"https://as.example.com",
    "exp":1441913610,
    "scope":"status feed",
    "sub":"user@example.net",
    "act":
    {
      "sub":"admin@example.net"
    }
  }
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
      </section>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
        This specification was developed within the OAuth Working Group, which
        includes dozens of active and dedicated participants.
        It was produced under the chairmanship of
        Hannes Tschofenig, Derek Atkins, and Rifaat Shekh-Yusef
        <contact fullname="Hannes Tschofenig"/>, <contact fullname="Derek
	Atkins"/>, and <contact fullname="Rifaat Shekh-Yusef"/>,
        with Kathleen Moriarty, Stephen Farrell, Eric Rescorla, Roman Danyliw, and Benjamin Kaduk <contact fullname="Kathleen Moriarty"/>, <contact fullname="Stephen
	Farrell"/>, <contact fullname="Eric Rescorla"/>, <contact fullname="Roman
	Danyliw"/>, and <contact fullname="Benjamin Kaduk"/> serving as
        Security Area Directors.
      </t>
      <t>
        The following individuals contributed ideas, feedback, and wording
	to this specification:
      </t>
      <t>
	Caleb Baker,
  Vittorio Bertocci,
        Mike Brown,
  Thomas Broyer,
        Roman Danyliw,
	William Denniss,
  Vladimir Dzhuvinov,
        Eric Fazendin,
	Phil Hunt,
  Benjamin Kaduk,
	Jason Keglovitz,
  Torsten Lodderstedt,
        Barry Leiba,
  Adam Lewis,
  James Manger,
  Nov Matake,
	Matt Miller,
        Hilarie Orman,
	Matthew Perry,
  Eric Rescorla,
	Justin Richer,
Adam Roach,
  Rifaat Shekh-Yusef,
	Scott Tomilson,
	<contact fullname="Caleb Baker"/>,
  <contact fullname="Vittorio Bertocci"/>,
        <contact fullname="Mike Brown"/>,
  <contact fullname="Thomas Broyer"/>,
        <contact fullname="Roman Danyliw"/>,
	<contact fullname="William Denniss"/>,
  <contact fullname="Vladimir Dzhuvinov"/>,
        <contact fullname="Eric Fazendin"/>,
	<contact fullname="Phil Hunt"/>,
  <contact fullname="Benjamin Kaduk"/>,
	<contact fullname="Jason Keglovitz"/>,
  <contact fullname="Torsten Lodderstedt"/>,
        <contact fullname="Barry Leiba"/>,
  <contact fullname="Adam Lewis"/>,
  <contact fullname="James Manger"/>,
  <contact fullname="Nov Matake"/>,
	<contact fullname="Matt Miller"/>,
        <contact fullname="Hilarie Orman"/>,
	<contact fullname="Matthew Perry"/>,
  <contact fullname="Eric Rescorla"/>,
	<contact fullname="Justin Richer"/>,
<contact fullname="Adam Roach"/>,
  <contact fullname="Rifaat Shekh-Yusef"/>,
	<contact fullname="Scott Tomilson"/>,
	and
        Hannes Tschofenig.
        <contact fullname="Hannes Tschofenig"/>.
      </t>
    </section>

    <section anchor="History" title="Document History">
      <?rfc subcompact="yes"?>
      <t>
	[[ to be removed by the RFC Editor before publication as an RFC ]]
      </t>
      <t>
        -19
        <list style='symbols'>
          <t>Fix-up changes introduced in -18.</t>
          <t>Fix invalid JSON in the Nested Actor Claim example.</t>
          <t>Reference figure numbers in text when introducing the examples in Section 2 and 4.</t>
          <t>Editorial updates from additional IESG evaluation comments.</t>
          <t>Add an informational reference to ietf-oauth-resource-indicators</t>
          <t>Update ietf-oauth-security-topics ref to 13</t>
        </list>
      </t>
      <t>
        -18
        <list style='symbols'>
          <t>Editorial updates based on a few more IESG evaluation comments.</t>
        </list>
      </t>
      <t>
        -17
        <list style='symbols'>
          <t>Editorial improvements and example fixes resulting from IESG evaluation comments.</t>
          <t>Added a pointer to RFC6749's Appendix B. on the
            "Use of application/x-www-form-urlencoded Media Type" as a way of
            providing a normative citation (by reference) for the media type.</t>
          <t>Strengthened some of the wording in the privacy considerations to bring it inline
            with RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8.</t>
        </list>
      </t>
      <t>
        -16
        <list style='symbols'>
          <t>Fixed typo and added an AD to Acknowledgements.</t>
        </list>
      </t>
      <t>
        -15
        <list style='symbols'>
          <t>Updated the nested actor claim example to (hopefully) be more straightforward.</t>
          <t>Reworked Privacy Considerations to say to use TLS in transit, minimize the amount of
            information in the token, and encrypt the token if disclosure of its information to the
            client is a concern per https://mailarchive.ietf.org/arch/msg/secdir/KJhx4aq_U5uk3k6zpYP-CEHbpVM
          </t>
          <t>Moved the Security and Privacy Considerations sections to before the IANA Considerations.</t>
        </list>
      </t>
  <t>
    -14
    <list style='symbols'>
      <t>Added text in <xref target="actor"/> about the "act" claim stating that only the top-level claims
        and the current actor are to be considered in applying access control decisions.</t>
    </list>
  </t>
  <t>
    -13
    <list style='symbols'>
      <t>Updated the claim name and value syntax for scope to be consistent with the treatment
        of scope in RFC 7662 OAuth 2.0 Token Introspection.</t>
      <t>Updated the client identifier claim name to be consistent with the treatment of client id
        in RFC 7662 OAuth 2.0 Token Introspection.</t>
    </list>
  </t>
      <t>
  -12
  <list style='symbols'>
    <t>Updated to use the boilerplate from RFC 8174.</t>
  </list>
      </t>
      <t>
  -11
  <list style='symbols'>
    <t>Added new WG chair and AD to the Acknowledgements.</t>
    <t>Applied clarifications suggested during AD review by EKR.</t>
  </list>
    </t>
      <t>
	-10
	<list style='symbols'>
	  <t>
	    Defined token type URIs for base64url-encoded SAML 1.1 and SAML 2.0 assertions.
	  </t>
	  <t>
	    Applied editorial fixes.
	  </t>
	</list>
      </t>
      <t>
  -09
  <list style='symbols'>
    <t>Changed "security tokens obtained could be used in a number of contexts" to
      "security tokens obtained may be used in a number of contexts" per a WGLC suggestion.</t>
    <t>Clarified that the validity of the subject or actor token have no impact on the validity
      of the issued token after the exchange has occurred per a WGLC comment.</t>
    <t>Changed use of invalid_target error code to a SHOULD per a WGLC comment.</t>
    <t>Clarified text about non-identity claims within the "act" claim being meaningless
      per a WGLC comment.</t>
    <t>Added brief Privacy Considerations section per WGLC comments.</t>
  </list>
      </t>
      <t>
  -08
  <list style='symbols'>
    <t>Use the bibxml reference for OpenID.Core rather than defining it inline.</t>
    <t>Added editor role for Campbell.</t>
    <t>Minor clarification of the text for actor_token.</t>
  </list>
      </t>
      <t>
-07
<list style='symbols'>
  <t>Fixed typo (desecration -> discretion).</t>
  <t>
    Added an explanation of the relationship between scope, audience and resource in the request
    and added an "invalid_target" error code enabling the AS to tell the client that the requested audiences/resources were too broad.
  </t>
</list>
      </t>
      <t>
-06
<list style='symbols'>
  <t>Drop "An STS for the REST of Us" from the title.</t>
  <t>Drop "heavyweight" and "lightweight" from the abstract and introduction.</t>
  <t>Clarifications on the language around xxxxxx_token_type.</t>
  <t>Remove the want_composite parameter.</t>
  <t>
    Add a short mention of proof-of-possession style tokens to the introduction
    and remove the respective open issue.
  </t>
</list>
      </t>
      <t>
-05
<list style='symbols'>
  <t>
    Defined the JWT claim <spanx style="verb">cid</spanx> to express
    the OAuth 2.0 client identifier of the client that requested the token.
  </t>
  <t>
    Defined and requested registration for <spanx style="verb">act</spanx> and
    <spanx style="verb">may_act</spanx> as Token introspection response parameters
    (in addition to being JWT claims).
  </t>
  <t>
    Loosen up the language about refresh_token in the response to OPTIONAL from NOT RECOMMENDED
    based on feedback form real world deployment experience.
  </t>
  <t>
    Add clarifying text about the distinction between JWT and access token URIs.
  </t>
  <t>
    Close out (remove) some of the Open Issues bullets that have been resolved.
  </t>
</list>
      </t>

      <t>
	-04
	<list style='symbols'>
	  <t>
	    Clarified that the "resource" and "audience" request parameters can be used at the same
	    time (via http://www.ietf.org/mail-archive/web/oauth/current/msg15335.html).
	  </t>
	  <t>
	    Clarified subject/actor token validity after token exchange and explained a
	    bit more about the recommendation to not issue refresh tokens
	    (via http://www.ietf.org/mail-archive/web/oauth/current/msg15318.html).
	  </t>
	  <t>
      Updated the examples appendix to use an issuer value that doesn't imply
      that the client issued and signed the tokens and used "Bearer" and
      "urn:ietf:params:oauth:token-type:access_token" in one of the responses
      (via http://www.ietf.org/mail-archive/web/oauth/current/msg15335.html).
	  </t>
	  <t>
	    Defined and registered urn:ietf:params:oauth:token-type:id_token,
	    since some use cases perform token exchanges for ID Tokens
	    and no URI to indicate that a token is an ID Token had previously been defined.
	  </t>
	</list>
      </t>

      <t>
        -03
        <list style='symbols'>
          <t>Updated the document editors (adding Campbell, Bradley, and Mortimore).</t>
          <t>Added to the title.</t>
          <t>Added to the abstract and introduction.</t>
          <t>
            Updated the format of the request to use application/x-www-form-urlencoded
	    request parameters and the response to use the existing token endpoint
	    JSON parameters defined in OAuth 2.0.
          </t>
          <t>Changed the grant type identifier to urn:ietf:params:oauth:grant-type:token-exchange.</t>
          <t>
	    Added RFC 6755 registration requests for
	    urn:ietf:params:oauth:token-type:refresh_token,
            urn:ietf:params:oauth:token-type:access_token, and
	    urn:ietf:params:oauth:grant-type:token-exchange.
          </t>
          <t>
            Added RFC 6749 registration requests for request/response parameters.
          </t>
	  <t>
	    Removed the Implementation Considerations and the requirement to support JWTs.
	  </t>
          <t>Clarified many aspects of the text.</t>
          <t>
            Changed <spanx style="verb">on_behalf_of</spanx> to
	    <spanx style="verb">subject_token</spanx>,
	    <spanx style="verb">on_behalf_of_token_type</spanx> to
	    <spanx style="verb">subject_token_type</spanx>,
            <spanx style="verb">act_as</spanx> to
	    <spanx style="verb">actor_token</spanx>, and
	    <spanx style="verb">act_as_token_type</spanx> to
	    <spanx style="verb">actor_token_type</spanx>.
          </t>
          <t>
            Added an <spanx style="verb">audience</spanx> request parameter used to
	    indicate the logical names of the target services at which the client
	    intends to use the requested security token.
          </t>
          <t>
      Added a <spanx style="verb">want_composite</spanx> request parameter used to
      indicate the desire for a composite token rather than trying to infer it from the
      presence/absence of token(s) in the request.
          </t>
          <t>
            Added a <spanx style="verb">resource</spanx> request parameter used to
	    indicate the URLs of resources at which the client
	    intends to use the requested security token.
          </t>
	  <t>
	    Specified that multiple <spanx style="verb">audience</spanx> and
	    <spanx style="verb">resource</spanx> request parameter values may be used.
	  </t>
    <t>
      Defined the JWT claim <spanx style="verb">act</spanx> (actor) to express
	    the current actor or delegation principal.
	  </t>
    <t>
      Defined the JWT claim <spanx style="verb">may_act</spanx> to express
      that one party is authorized to act on behalf of another party.
    </t>
	  <t>
	    Defined the JWT claim <spanx style="verb">scp</spanx> (scopes) to express
	    OAuth 2.0 scope-token values.
          </t>
	  <t>
	    Added the <spanx style="verb">N_A</spanx> (not applicable)
	    OAuth Access Token Type definition for use in contexts in which
	    the token exchange syntax requires a <spanx style="verb">token_type</spanx>
	    value, but in which the token being issued is not an access token.
	  </t>
          <t>Added examples.</t>
        </list>
      </t>
      <t>
        -02
        <list style='symbols'>
	  <t>
	    Enabled use of Security Token types other than JWTs for
	    <spanx style="verb">act_as</spanx> and
	    <spanx style="verb">on_behalf_of</spanx> request values.
	  </t>
          <t>
            Referenced the JWT and OAuth Assertions RFCs.
	  </t>
        </list>
      </t>

      <t>
        -01
        <list style='symbols'>
          <t>
            Updated references.
	  </t>
        </list>
      </t>

      <t>
        -00
        <list style='symbols'>
          <t>
            Created initial working group draft from draft-jones-oauth-token-exchange-01.
	  </t>
        </list>
      </t>
      <?rfc subcompact="no"?>
    </section>

  </back>
</rfc>
  <!--   code used to create the JWTs in examples

public class TokenExExamplesTest
{
    @Test
    public void go() throws Exception
    {
        main(null);
    }

    public static void main(String[] args) throws Exception
    {
        AlgorithmFactoryFactory.getInstance(); // init to get the logging out of the way
        System.out.println("\nmain-example");
        System.out.println(" main :::::");

        PublicJsonWebKey mainExKey = PublicJsonWebKey.Factory.newPublicJwk("{\"kty\":\"EC\",\"kid\":\"9er\",\"use\":\"sig\",\"alg\":\"ES256\",\"x\":\"5yoR9FjZHn7kJDALhDzhZ8i8F06mc12YswUMTBv4BoA\",\"y\":\"4uxuIItWj5Duzspth5mUbpLXWrPFzFPQkOCeAGGI6KM\",\"crv\":\"P-256\",\"d\":\"LncS7zrx6c8X5qZRxoSN18ZEYDeI2wfKfUvX_DgwRH8\"}");
        System.out.println(mainExKey.toJson(JsonWebKey.OutputControlLevel.INCLUDE_PRIVATE));

        NumericDate iat = NumericDate.fromSeconds(1441917533);
        System.out.println(iat);
        NumericDate exp = NumericDate.fromSeconds(iat.getValue());
        exp.addSeconds(60);

        JwtClaims claims = new JwtClaims();
        claims.setAudience("https://backend.example.com");
        final String asDotComUri = "https://as.example.com";
        claims.setIssuer(asDotComUri);
        claims.setExpirationTime(exp);
        claims.setIssuedAt(iat);
        claims.setSubject("bdc@example.com");
        claims.setClaim("scope", "api");

        JsonWebSignature jws = new JsonWebSignature();
        jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_AND_SHA256);
        jws.setKeyIdHeaderValue(mainExKey.getKeyId());
        jws.setKey(mainExKey.getPrivateKey());
        jws.setPayload(claims.toJson());
        System.out.println(jws.getCompactSerialization());

        System.out.println("\n\n\n\nimpersonation-example");
        System.out.println("\n subject :::::");
        PublicJsonWebKey dotNetKey = PublicJsonWebKey.Factory.newPublicJwk("{\"kty\":\"EC\",\"kid\":\"16\",\"use\":\"sig\",\"alg\":\"ES256\",\"x\":\"N_MqlYd_Iq0rfzTqXAX7TUC0r7fQSp3YQKh42tn7uSc\",\"y\":\"9tGuwMFkHYWPqkLa51f8GazZNQqdgMOVvJEd6fJ18PI\",\"crv\":\"P-256\",\"d\":\"cZ_4DqRSAWMMErQbKv6dCYqI9G1pi6lxvlvHU152Uts\"}");
        System.out.println(dotNetKey.toJson(JsonWebKey.OutputControlLevel.INCLUDE_PRIVATE));

        iat = NumericDate.fromSeconds(1441910000);
        System.out.println(iat);
        exp = NumericDate.fromSeconds(iat.getValue());
        exp.addSeconds(600);
        NumericDate nbf = NumericDate.fromSeconds(iat.getValue());
        nbf.addSeconds(-1000);

        claims = new JwtClaims();
        claims.setAudience(asDotComUri);
        String originalIssuerDotNetUri = "https://original-issuer.example.net";
        claims.setIssuer(originalIssuerDotNetUri);
        claims.setExpirationTime(exp);
        claims.setNotBefore(nbf);
        claims.setSubject("bdc@example.net");
        claims.setStringClaim("scope", "orders profile history");

        jws = new JsonWebSignature();
        jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_AND_SHA256);
        jws.setKeyIdHeaderValue(dotNetKey.getKeyId());
        jws.setKey(dotNetKey.getPrivateKey());
        String payload = claims.toJson();
        jws.setPayload(payload);
        System.out.println("sub token: " + jws.getCompactSerialization());
        System.out.println("sub token claims: " + payload);

        System.out.println("\n issued :::::");
        PublicJsonWebKey dotComKey = PublicJsonWebKey.Factory.newPublicJwk("{\"kty\":\"EC\",\"kid\":\"72\",\"use\":\"sig\",\"alg\":\"ES256\",\"x\":\"472aI8TvDdm2qfBRpXYw0uZ7feumuQOM-RPRkkTukSo\",\"y\":\"VNNStdPhuxY6q7XfVIeYSW7xh_a4z5W2MCtNmQDcILc\",\"crv\":\"P-256\",\"d\":\"dtJiut8QBJxACG6fcX8NYnzIsAN1muCJvaMiLSrOjIc\"}");
        System.out.println(dotComKey.toJson(JsonWebKey.OutputControlLevel.INCLUDE_PRIVATE));

        iat = NumericDate.fromSeconds(1441910010);
        System.out.println(iat);
        exp = NumericDate.fromSeconds(iat.getValue());
        exp.addSeconds(3600);

        claims = new JwtClaims();
        claims.setAudience("urn:example:cooperation-context");
        claims.setIssuer(asDotComUri);
        claims.setExpirationTime(exp);
        claims.setSubject("bdc@example.net");
        claims.setStringClaim("scope", "orders profile history");

        jws = new JsonWebSignature();
        jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_AND_SHA256);
        jws.setKeyIdHeaderValue(dotComKey.getKeyId());
        jws.setKey(dotComKey.getPrivateKey());
        payload = claims.toJson();
        jws.setPayload(payload);
        System.out.println("issued token: " + jws.getCompactSerialization());
        System.out.println("issued token claims: " + payload);

        System.out.println("\n\n\ndelegation-example");
        System.out.println("\n :::::");

        iat = NumericDate.fromSeconds(1441910000);
        System.out.println(iat);
        exp = NumericDate.fromSeconds(iat.getValue());
        exp.addSeconds(60);

        String admin = "admin@example.net";

        claims = new JwtClaims();
        claims.setAudience(asDotComUri);
        claims.setIssuer(originalIssuerDotNetUri);
        claims.setExpirationTime(exp);
        claims.setStringClaim("scope", "status feed");
        String sub = "user@example.net";
        claims.setSubject(sub);
        JwtClaims mayAct = new JwtClaims();
        mayAct.setSubject(admin);
        claims.setClaim("may_act", mayAct.getClaimsMap());

        jws = new JsonWebSignature();
        jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_AND_SHA256);
        jws.setKeyIdHeaderValue(dotNetKey.getKeyId());
        jws.setKey(dotNetKey.getPrivateKey());
        payload = claims.toJson();
        jws.setPayload(payload);
        System.out.println("sub token: " + jws.getCompactSerialization());
        System.out.println("sub token claims: " + payload);

        claims = new JwtClaims();
        claims.setAudience(asDotComUri);
        claims.setIssuer(originalIssuerDotNetUri);
        claims.setExpirationTime(exp);
        claims.setSubject(admin);

        jws = new JsonWebSignature();
        jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_AND_SHA256);
        jws.setKeyIdHeaderValue(dotNetKey.getKeyId());
        jws.setKey(dotNetKey.getPrivateKey());
        payload = claims.toJson();
        jws.setPayload(payload);
        System.out.println("actor token: " + jws.getCompactSerialization());
        System.out.println("actor token claims: " + payload);

        iat = NumericDate.fromSeconds(1441910010);
        System.out.println(iat);
        exp = NumericDate.fromSeconds(iat.getValue());
        exp.addSeconds(3600);

        claims = new JwtClaims();
        claims.setAudience("urn:example:cooperation-context");
        claims.setIssuer(asDotComUri);
        claims.setExpirationTime(exp);
        claims.setStringClaim("scope", "status feed");
        claims.setSubject(sub);
        JwtClaims actor = new JwtClaims();
        actor.setSubject(admin);
        claims.setClaim("act", actor.getClaimsMap());

        jws = new JsonWebSignature();
        jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_AND_SHA256);
        jws.setKeyIdHeaderValue(dotComKey.getKeyId());
        jws.setKey(dotComKey.getPrivateKey());
        payload = claims.toJson();
        jws.setPayload(payload);
        System.out.println("issued token: " + jws.getCompactSerialization());
        System.out.println("issued token claims: " + payload);
    }
}
-->