OAuth 2.0 Token Exchange: An STS for the REST of UsMicrosoftmbj@microsoft.comhttp://self-issued.info/Microsofttonynad@microsoft.comPing Identitybrian.d.campbell@gmail.comPing Identityve7jtb@ve7jtb.comSalesforcecmortimore@salesforce.com
Security
OAuth Working GroupRFCRequest for CommentsI-DInternet-DraftJSON Web TokenJWTDelegationImpersonationSTSExchangeTokenOAuth
This specification defines a protocol for a lightweight HTTP- and 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.
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) and
SAML Assertions .
Security tokens are typically signed to achieve integrity
and sometimes also encrypted to achieve confidentiality.
Security tokens are also sometimes described as Assertions, such as in
.
A Security Token Service (STS) is a service capable of validating and issuing
security tokens, which enables clients to obtain appropriate
access credentials for resources in heterogeneous environments or across security
domains.
Web Service clients have used WS-Trust
as the protocol to interact with an STS for token exchange,
however WS-Trust is a fairly heavyweight protocol, which uses XML, SOAP, etc.
Whereas, the trend in modern Web development
has been towards lightweight services utilizing RESTful patterns and JSON.
The OAuth 2.0 Authorization Framework
and OAuth 2.0 Bearer Tokens
have emerged as popular standards for authorizing and securing access to HTTP and
RESTful resources but do not provide everything necessary to facilitate
token exchange interactions.
This specification defines a lightweight 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.
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.
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,
which 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.
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 and security characteristics of the tokens themselves
(both those presented to the AS and those obtained by the client)
are explicitly out of 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 required; 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.
The security tokens obtained could be used in a number of contexts,
the specifics of which are also beyond the scope of this specification.
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 in
so far 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.
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 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.
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.
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. A client can indicate the desire for a
composite token by including a want_composite parameter in the request with the value
true. Typically, in the request, the subject_token
represents the identity of the party on
behalf of whom the token is being requested while the actor_token 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.
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 request parameter, however, does provide a means
for providing information about the desired actor though the representation
of a chain of delegation using the JWT act claim.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in
RFC 2119.
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,
and the terms "Claim" and "JWT Claims Set" defined by
JSON Web Token (JWT).
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 OAuth 2.0.
Client authentication to the authorization server is done using the normal
mechanisms provided by OAuth 2.0.
Section 2.3.1 of The OAuth 2.0 Authorization Framework
defines password-based authentication of the client,
however, client authentication is extensible and other mechanisms are possible.
For example, defines client authentication using
JSON Web Tokens (JWTs) .
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.
The client makes a token exchange request to the token endpoint with an extension
grant type by including the
following parameters using the application/x-www-form-urlencoded
format with a character encoding of UTF-8 in the HTTP request entity-body:
REQUIRED. The value
urn:ietf:params:oauth:grant-type:token-exchange
indicates that a token exchange is being performed.
OPTIONAL.
Indicates the physical location of 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 the location of the service where it intends to use the token.
The resource 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 resource parameter MUST be an
absolute URI, as specified by Section 4.3 of ,
which MAY include a query component and MUST NOT include a fragment component.
Multiple resource parameters may be used to indicate
that the issued token is intended to be used at the multiple resources listed.
OPTIONAL.
The logical name of the target service where the client intends to use
the requested security token. This serves a purpose similar to the
resource parameter, but with the client providing a logical name
rather than a physical location. 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 ,
an OpenID Connect Issuer Identifier ,
or a URI are examples of things that
might be used as audience parameter values.
Multiple audience parameters may be used to indicate
that the issued token is intended to be used at the multiple audiences listed.
OPTIONAL.
A list of space-delimited, case-sensitive strings 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.
OPTIONAL.
An identifier, as described in , for the type of the requested security token.
For example, a JWT can be requested with the identifier
urn:ietf:params:oauth:token-type:jwt.
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 resource or
audience parameter.
REQUIRED.
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 this request.
REQUIRED.
An identifier, as described in , that indicates the type of the security token in
the subject_token parameter. For example,
a value of urn:ietf:params:oauth:token-type:jwt,
would indicate that the token is a JWT and a value of
urn:ietf:params:oauth:token-type:access_token
would indicate that the token is an OAuth access token.
OPTIONAL.
A security token that represents
the identity of the party that is authorized to use the requested security token and act on behalf of the subject.
An identifier, as described in , that indicates the type of the security token in the
actor_token parameter.
This is REQUIRED when the actor_token parameter
is present in the request but MUST NOT be included otherwise.
OPTIONAL.
When the value of this parameter is true, it indicates the client's desire
for a composite security token to be issued, which contains claims about both the main subject of the
token as well as about the party who is authorized to act on behalf of that subject. Note that this
parameter only provides a means for the client to indicate its preference. The authorization server
is not required to honor the stated preference and the nature of the tokens it issues are ultimately at
its discretion.
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 . Additional details and
explanation are provided in the following subsections.
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 , 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.
REQUIRED. The security token issued by the authorization server in response
to the token exchange request.
The access_token parameter from
Section 5.1 of 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 access_token is used for historical
reasons and the issued token need not be an OAuth access token.
REQUIRED. An identifier, as described in ,
for the representation of the issued security token.
For example, a value of urn:ietf:params:oauth:token-type:access_token
indicates that the issued token is an access token and a value of
urn:ietf:params:oauth:token-type:jwt indicates that it is a JWT.
REQUIRED.
A case-insensitive value specifying the method of using of the access token issued,
as specified in Section 7.1 of .
It provides the client
with information about how to utilize the access token to access protected resources.
For example, a value of Bearer,
as specified in , indicates that
the 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 issued_token_type parameter,
which declares the representation of the issued security token;
the term "token type" is typically used with this meaning, as it is in
all *_token_type parameters in this specification.
If the issued token is not an access token or usable as an access token,
then the token_type value N_A is used
to indicate that an OAuth 2.0
token_type identifier is not applicable in that context.
RECOMMENDED. The validity lifetime, in seconds, of the token issued by the
authorization server. Oftentimes the client will not have the inclination or capability
to inspect the content of the 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.
OPTIONAL, if the scope of the issued security token is identical to the scope requested by the client;
otherwise, REQUIRED.
NOT RECOMMENDED.
Refresh tokens will typically not be issued in response to
urn:ietf:params:oauth:grant-type:token-exchange
grant type requests. Profiles or deployments of this specification that do
issue refresh tokens SHOULD clearly document the conditions and reasons for doing so.
If either the subject_token or actor_token
are invalid for any reason, or are unacceptable based on policy, the authorization server
MUST construct an error response, as specified in Section 5.2 of .
The value of the error
parameter MUST be the invalid_request error code. The authorization
server MAY include additional information regarding the reasons for the error
using the error_description and/or error_uri parameters.
Other error codes may also be used, as appropriate.
The following example demonstrates a hypothetical token exchange in which
an OAuth resource server
assumes the role of the client during token exchange in order to
trade an access token that it received in a request for a
token that it will use to call to a backend service
(extra line breaks and indentation in the examples are for display purposes only).
The resource server receives the following request containing
an OAuth access token in the Authorization request header, as specified in
Section 2.1 of .
The resource server assumes the role of the client for the token exchange
and the access token from the request above is sent
to the authorization
server using a request as specified in .
The value of the subject_token parameter carries the
access token and the value of
the subject_token_type parameter indicates that it is
an OAuth 2.0 access token.
The resource server, acting as the client, uses its identifier and secret to authenticate to
the authorization server using the HTTP Basic authentication scheme.
The resource parameter indicates the location
of the backend service, https://backend.example.com/api,
where the issued token will be used.
The authorization server validates the client credentials and the
subject_token presented in the token
exchange request. From the resource
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.
The access_token parameter of the
response 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 so the issued_token_type
indicates only that it is an access token.
The resource server can then use the newly acquired access token in making
a request to the backend server.
Additional examples can be found in .
Several parameters in this specification utilize an identifier as the value to
describe the type of token in question. Specifically, they are the
requested_token_type,
subject_token_type, actor_token_type
parameters of the request and the issued_token_type member of the response.
Token type identifiers are URIs.
This specification defines the token type identifiers
urn:ietf:params:oauth:token-type:access_token and
urn:ietf:params:oauth:token-type:refresh_token to indicate
that the token is an OAuth 2.0 access token or refresh token, respectively.
The value urn:ietf:params:oauth:token-type:jwt defined in
Section 9 of indicates that the token is a JWT.
Other URIs to indicate other token types MAY be used.
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.
Similar definitions for other types of tokens are possible but
beyond the scope of this specification.
The act (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 act claim value is a JSON object and
members in the JSON object are claims that identify the actor.
The claims that make up the act
claim identify and possibly provide additional information about the actor.
For example, the combination of the two claims iss
and sub might be necessary to uniquely identify an actor.
However, claims within the act 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, claims such as exp, nbf, and
aud are not meaningful when used within an act
claim, and therefore should not be used.
A chain of delegation can be expressed by nesting one act claim within
another. The outermost act claim represents the current actor while nested
act claims represent prior actors. The least recent actor is the most deeply
nested.
The scp claim is an array of strings, each of which
represents an OAuth scope granted for the issued security token.
Each array entry of the claim value is a scope-token, as defined in
Section 3.3 of OAuth 2.0.
The may_act claim makes a statement that one party is authorized to
become the actor and act on behalf of another party.
The claim value is a JSON 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 may_act
claim identify and possibly provide additional information about the authorized actor.
For example, the combination of the two claims iss
and sub are sometimes necessary to uniquely identify an authorized actor,
while the email claim might be used to provide additional useful information about
that party.
However, claims within the may_act 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 exp, nbf, and
aud are not meaningful when used within a may_act
claim, and therefore should not be used.
This specification registers the following values in the
IANA "OAuth URI" registry
established by .
URN: urn:ietf:params:oauth:grant-type:token-exchangeCommon Name: Token exchange grant type for OAuth 2.0Change controller: IESGSpecification Document: of [[ this specification ]]URN: urn:ietf:params:oauth:token-type:access_tokenCommon Name: Token type URI for an OAuth 2.0 access tokenChange controller: IESGSpecification Document: of [[this specification]]URN: urn:ietf:params:oauth:token-type:refresh_tokenCommon Name: Token Type URI for an OAuth 2.0 refresh tokenChange controller: IESGSpecification Document: of [[this specification]]
This specification registers the following values
in the IANA "OAuth Parameters" registry
established by .
Parameter name: resourceParameter usage location: token requestChange controller: IESGSpecification document(s): of [[ this specification ]]Parameter name: audienceParameter usage location: token requestChange controller: IESGSpecification document(s): of [[ this specification ]]Parameter name: requested_token_typeParameter usage location: token requestChange controller: IESGSpecification document(s): of [[ this specification ]]Parameter name: subject_tokenParameter usage location: token requestChange controller: IESGSpecification document(s): of [[ this specification ]]Parameter name: subject_token_typeParameter usage location: token requestChange controller: IESGSpecification document(s): of [[ this specification ]]Parameter name: actor_tokenParameter usage location: token requestChange controller: IESGSpecification document(s): of [[ this specification ]]Parameter name: actor_token_typeParameter usage location: token requestChange controller: IESGSpecification document(s): of [[ this specification ]]Parameter name: want_compositeParameter usage location: token requestChange controller: IESGSpecification document(s): of [[ this specification ]]Parameter name: issued_token_typeParameter usage location: token responseChange controller: IESGSpecification document(s): of [[ this specification ]]
This specification registers the following access token type
in the IANA "OAuth Access Token Types" registry
established by .
Type name: N_AAdditional Token Endpoint Response Parameters: (none)HTTP Authentication Scheme(s): (none)Change controller: IESGSpecification document(s): of [[ this specification ]]
This specification registers the following Claims
in the IANA "JSON Web Token Claims" registry
established by .
Claim Name: actClaim Description: ActorChange Controller: IESGSpecification Document(s): of [[ this specification ]]Claim Name: scpClaim Description: Scope ValuesChange Controller: IESGSpecification Document(s): of [[ this specification ]]Claim Name: may_actClaim Description: May Act ForChange Controller: IESGSpecification Document(s): of [[ this specification ]]
All of the normal security issues that are discussed in ,
especially in relationship to comparing URIs and dealing with unrecognized values,
also apply here.
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 scp claim is suggested to mitigate
potential for such abuse, as it restricts the contexts in which
the delegated rights can be exercised.
JSON Web Token (JWT)MicrosoftPing IdentityNomura Research Institute, Ltd.JSON Web Token ClaimsIANAOAuth ParametersIANAWS-Trust 1.4OpenID Connect Core 1.0Nomura Research Institute, Ltd.Ping IdentityMicrosoftGoogleSalesforce
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).
In the following token exchange request, an anonymous client is requesting a token
with impersonation semantics.
The client tells the authorization server that it needs a token for use at
the target service with the logical name
urn:example:cooperation-context.
The subject_token in the prior request is a 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 (bc@example.net) is
the party on behalf of whom the new token is being requested.
The access_token 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.
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 urn:example:cooperation-context
any time before its expiration.
The subject (sub) 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
urn:example:cooperation-context by using the token.
In the following token exchange request, an anonymous client is requesting a token
with delegation semantics, which is indicated by the inclusion of the
want_composite parameter.
The client tells the authorization server that it needs a token for use at
the target service with the logical name
urn:example:cooperation-context.
The subject_token in the prior request is a 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
(user@example.net) is
the party on behalf of whom the new token is being requested.
The actor_token in the prior request is a 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
(admin@example.net) is
the actor that will wield the security token being requested.
The access_token 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.
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
urn:example:cooperation-context
any time before its expiration.
The subject (sub)
of the JWT
is the same as the subject of
the subject_token used to make the request.
The actor (act) of the JWT is the same as the subject
of the actor_token used to make the request.
This indicates delegation and identifies
admin@example.net as the current actor to whom authority
has been delegated to act on behalf of user@example.net.
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 and Derek Atkins
with Kathleen Moriarty and Stephen Farrell serving as
Security Area Directors.
The following individuals contributed ideas, feedback, and wording
to this specification:
Caleb Baker,
William Denniss,
Phil Hunt,
Jason Keglovitz,
Matt Miller,
Matthew Perry,
Justin Richer,
Scott Tomilson,
and
Hannes Tschofenig.
The following decisions need to be made and updates to this spec performed:
Should there be a way to use short names for some common token type identifiers?
URIs are necessary in the general case for extensibility and vendor/deployment specific types.
But short names like access_token and jwt
are aesthetically appealing and slightly more efficient in terms of bytes on the wire and url-encoding.
There seemed to be rough consensus in Prague ('No objection to use the proposed mechanism for a default prefix'
from https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for supporting a shorthand for
commonly used types - i.e. when the value does not contain a ":" character, the value would
be treated as though urn:ietf:params:oauth:token-type:
were prepended to it. So, for example, the value jwt
for requested_token_type would be semantically equivalent
to urn:ietf:params:oauth:token-type:jwt and the value
access_token would be equivalent to
urn:ietf:params:oauth:token-type:access_token.
However, it was a fairly brief discussion in Prague and it has since been
suggested that making participants handle both syntaxes will unnecessarily complicate
the supporting code.
Provide a way to include supplementary claims or information in the request that would/could potentially be included in the
issued token. There are real use cases for this but we would need to work through what it would look like.
Understand and define exactly how the presentation of PoP/non-bearer tokens works.
Of course, the specifications defining these kinds of tokens need to do so
first before there is much we can do in this specification in this regard.
It seems there may be cases in which it would be desirable for
the authenticated client to be somehow represented in the issued token,
sometimes in addition to the actor, which can already be represented
using the act claim.
Perhaps with a client_id claim?
[[ to be removed by the RFC Editor before publication as an RFC ]]
-03
Updated the document editors (adding Campbell, Bradley, and Mortimore).Added to the title.Added to the abstract and introduction.
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.
Changed the grant type identifier to urn:ietf:params:oauth:grant-type:token-exchange.
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.
Added RFC 6749 registration requests for request/response parameters.
Removed the Implementation Considerations and the requirement to support JWTs.
Clarified many aspects of the text.
Changed on_behalf_of to
subject_token,
on_behalf_of_token_type to
subject_token_type,
act_as to
actor_token, and
act_as_token_type to
actor_token_type.
Added an audience request parameter used to
indicate the logical names of the target services at which the client
intends to use the requested security token.
Added a want_composite 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.
Added a resource request parameter used to
indicate the URLs of resources at which the client
intends to use the requested security token.
Specified that multiple audience and
resource request parameter values may be used.
Defined the JWT claim act (actor) to express
the current actor or delegation principal.
Defined the JWT claim may_act to express
that one party is authorized to act on behalf of another party.
Defined the JWT claim scp (scopes) to express
OAuth 2.0 scope-token values.
Added the N_A (not applicable)
OAuth Access Token Type definition for use in contexts in which
the token exchange syntax requires a token_type
value, but in which the token being issued is not an access token.
Added examples.
-02
Enabled use of Security Token types other than JWTs for
act_as and
on_behalf_of request values.
Referenced the JWT and OAuth Assertions RFCs.
-01
Updated references.
-00
Created initial working group draft from draft-jones-oauth-token-exchange-01.