< draft-richer-transactional-authz-00.txt   draft-richer-transactional-authz-01.txt >
Network Working Group J. Richer, Ed. Network Working Group J. Richer, Ed.
Internet-Draft Bespoke Engineering Internet-Draft Bespoke Engineering
Intended status: Standards Track May 15, 2019 Intended status: Standards Track July 3, 2019
Expires: November 16, 2019 Expires: January 4, 2020
Transactional Authorization Transactional Authorization
draft-richer-transactional-authz-00 draft-richer-transactional-authz-01
Abstract Abstract
This document defines a mechanism for delegating authorization to a This document defines a mechanism for delegating authorization to a
piece of software, and conveying that delegation to the software. piece of software, and conveying that delegation to the software.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 16, 2019. This Internet-Draft will expire on January 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Sequence . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transaction request . . . . . . . . . . . . . . . . . . . . . 3 2. Transaction request . . . . . . . . . . . . . . . . . . . . . 3
2.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Resource . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. User . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. User . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Interact . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Interact . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Redirect . . . . . . . . . . . . . . . . . . . . . . 5
2.4.2. Device . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.1. Detatched JWS method . . . . . . . . . . . . . . . . 7 3. Interaction response . . . . . . . . . . . . . . . . . . . . 7
2.5.2. MTLS method . . . . . . . . . . . . . . . . . . . . . 7
2.5.3. DID method . . . . . . . . . . . . . . . . . . . . . 7
3. Interaction response . . . . . . . . . . . . . . . . . . . . 8
3.1. Redirect interaction . . . . . . . . . . . . . . . . . . 8 3.1. Redirect interaction . . . . . . . . . . . . . . . . . . 8
3.2. Secondary device interaction . . . . . . . . . . . . . . 9 3.2. Callback response . . . . . . . . . . . . . . . . . . . . 9
3.3. Secondary device interaction . . . . . . . . . . . . . . 9
4. Wait response . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Wait response . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Interaction at the AS . . . . . . . . . . . . . . . . . . . . 11 5. Interaction at the AS . . . . . . . . . . . . . . . . . . . . 11
6. Error response . . . . . . . . . . . . . . . . . . . . . . . 11 6. Error response . . . . . . . . . . . . . . . . . . . . . . . 11
7. Transaction continue request . . . . . . . . . . . . . . . . 11 7. Transaction continue request . . . . . . . . . . . . . . . . 12
8. Token response . . . . . . . . . . . . . . . . . . . . . . . 12 8. Token response . . . . . . . . . . . . . . . . . . . . . . . 13
9. Handle references . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Presenting Tokens to the RS . . . . . . . . . . . . . . . 13
9.1. Validating handles . . . . . . . . . . . . . . . . . . . 12 9. Handle references . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Transaction handles . . . . . . . . . . . . . . . . . . . 13 9.1. Presenting handles . . . . . . . . . . . . . . . . . . . 14
9.3. Client handles . . . . . . . . . . . . . . . . . . . . . 13 9.2. Validating handles . . . . . . . . . . . . . . . . . . . 14
9.4. Resource handles . . . . . . . . . . . . . . . . . . . . 14 9.3. Transaction handles . . . . . . . . . . . . . . . . . . . 14
9.5. User handles . . . . . . . . . . . . . . . . . . . . . . 14 9.4. Client handles . . . . . . . . . . . . . . . . . . . . . 15
9.6. Key handles . . . . . . . . . . . . . . . . . . . . . . . 15 9.5. Resource handles . . . . . . . . . . . . . . . . . . . . 15
10. Binding Keys . . . . . . . . . . . . . . . . . . . . . . . . 16 9.5.1. Resource-first . . . . . . . . . . . . . . . . . . . 16
10.1. Binding a key to a transaction . . . . . . . . . . . . . 16 9.6. User handles . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Validating detached JWS . . . . . . . . . . . . . . . . 16 9.7. Key handles . . . . . . . . . . . . . . . . . . . . . . . 17
10.3. Validating attached JWS . . . . . . . . . . . . . . . . 17 10. Binding Keys . . . . . . . . . . . . . . . . . . . . . . . . 18
10.4. Validating MTLS . . . . . . . . . . . . . . . . . . . . 17 10.1. Binding a key to a transaction . . . . . . . . . . . . . 18
10.5. Validating DID . . . . . . . . . . . . . . . . . . . . . 17 10.2. Detached JWS . . . . . . . . . . . . . . . . . . . . . . 19
11. Using a Token . . . . . . . . . . . . . . . . . . . . . . . . 17 10.3. Validating MTLS . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10.4. Validating DID . . . . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16. Normative References . . . . . . . . . . . . . . . . . . . . 18 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
Appendix A. Document History . . . . . . . . . . . . . . . . . . 19 15. Normative References . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Document History . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Parties 1. Protocol
This protocol allows a piece of software to request delegated
authorization to an API, protected by an authorization server usually
on behalf of a resource owner.
1.1. Parties
The Authorization Server (AS) manages the transactions. It is The Authorization Server (AS) manages the transactions. It is
defined by its transaction endpoint, a single URL that accepts a POST defined by its transaction endpoint, a single URL that accepts a POST
request with a JSON payload. The AS can also have other endpoints, request with a JSON payload. The AS MAY also have other endpoints,
including interaction endpoints. including interaction endpoints, but these are
The Authorization Requester (AR) is a party calling the AS. It can
be acting as either RC or RS. (TODO: there needs to be a better term
for this.)
The Resource Client (RC) requests tokens from the AS and uses tokens The Resource Client (RC) requests tokens from the AS and uses tokens
at the RS. at the RS.
The Resource Server (RS) accepts tokens from the RC and validates The Resource Server (RS) accepts tokens from the RC and validates
them (potentially at the AS). them (potentially at the AS).
The Resource Owner (RO) authorizes the request from the RC to the RS The Resource Owner (RO) authorizes the request from the RC to the RS,
often interactively at the AS.
1.2. Sequence
1. The RC creates a transaction request and sends it to the AS
2. The AS processes the transaction request and determines if the RO
needs to interact
3. If interaction is required, the AS interacts with the RO,
possibly by directing the RC to send the RO there
4. The RC continues the transaction at the AS
5. The AS processess the transaction again, determining that a token
can be issued
6. The AS issues a token to the RC
7. The RC uses the token with the RS
2. Transaction request 2. Transaction request
To start a transaction, the RC makes a transaction request to the To start a transaction, the RC makes a transaction request to the
transaction endpoint of the AS. The RC creates a JSON document with transaction endpoint of the AS. The RC creates a JSON [RFC8259]
up to five sections. document with five primary sections, included as members of a root
JSON object.
client Information about the RC making the request, including client Information about the RC making the request, including
display name, home page, logo, and other user-facing information. display name, home page, logo, and other user-facing information.
This section is RECOMMENDED. This section is RECOMMENDED.
resources Information about the RS's the resulting token will be resources Information about the RS's the resulting token will be
applied to, including locations, extents of access, types of data applied to, including locations, extents of access, types of data
being accessed, and other API information. This section is being accessed, and other API information. This section is
REQUIRED. REQUIRED.
user Information about the RO as known to or provided to the RC, in user Information about the RO as known to or provided to the RC, in
the form of assertions or references to external data. This the form of assertions or references to external data. This
section is OPTIONAL. section is OPTIONAL.
interact Information about how the RC is able to interact with the interact Information about how the RC is able to interact with the
RO, including callback URI's and state. This section is REQUIRED RO, including callback URI's and state. This section is REQUIRED
if the client is capable of driving interaction with the user. if the RC is capable of driving interaction with the user.
keys Information about the keys known to the RC and able to be keys Information about the keys known to the RC and able to be
presented in future parts of the transaction. This section is presented in future parts of the transaction. This section is
REQUIRED. (Note: I can't think of a good reason for this to be REQUIRED. (Note: I can't think of a good reason for this to be
optional.) optional.)
An AS MAY Each section consists of either a JSON object or an array of JSON
objects, as described in the subsections below. Many sections MAY be
represented by an appropriate handle instead as described in
Section 9. In such cases, the section is replaced entirely by the
handle presentation, which is a single string instead of a JSON
object. The RC MAY present additional sections as defined by
extensions of this specification. The AS MUST ignore any sections
that it does not understand.
2.1. Client 2.1. Client
This section provides descriptive details of the client software This section provides descriptive details of the RC software making
making the call. the call. This section is a JSON object, and all fields are
OPTIONAL. The RC MAY send additional fields, and the AS MUST ignore
name Display name of the client software all fields that it does not understand.
uri User-facing web page of the client software name Display name of the RC software
logo_uri Display image to represent the client software uri User-facing web page of the RC software
logo_uri Display image to represent the RC software
client: { client: {
name: "Display Name", name: "Display Name",
uri: "https://example.com/client" uri: "https://example.com/client"
} }
This can also be presented as a client handle reference. The AS SHOULD use this information in presenting any authorization
screens to the RO during interaction.
The client information MAY instead be presented as a client handle
reference Section 9.4.
2.2. Resource 2.2. Resource
This section identifies the RS and describes what the RC wants to do This section identifies what the RC wants to do with the API hosted
with the API hosted at the RS. This section is an array of objects, at the RS. This section is a JSON array of objects, each object
each object representing a single resource set. That AS MUST representing a single resource or resource set. That AS MUST
interpret the request as being for all of the resources listed. interpret the request as being for all of the resources listed.
actions The types of actions the RC will take at the RS actions The types of actions the RC will take at the RS
locations URIs the RC will call at the RS locations URIs the RC will call at the RS
data types of data available to the RC at the RS's API data types of data available to the RC at the RS's API
resources: [ resources: [
{ {
actions: ["read", "write"], actions: ["read", "write"],
locations: ["https://exapmle.com/resource"] locations: ["https://exapmle.com/resource"]
data: ["foo", "bar"] data: ["foo", "bar"]
} }
] ]
This can also be presented as a set of resource handle references. This can also be presented as a set of resource handle references
Section 9.5, or a combination of handles and resource structures.
2.3. User 2.3. User
This section provides a verifiable assertion about the RO interacting This section provides a verifiable assertion about the RO interacting
with the client on behalf of the request. with the RC on behalf of the request.
assertion The value of the assertion as a string. assertion The value of the assertion as a string.
type The type of the assertion. Possible values include type The type of the assertion. Possible values include
"oidc_id_token"... "oidc_id_token"...
user: { user: {
assertion: "eyj0....", assertion: "eyj0....",
type: "oidc_id_token" type: "oidc_id_token"
} }
This can also be presented as a user handle reference. This can also be presented as a user handle reference Section 9.6.
2.4. Interact 2.4. Interact
This section provides details of how the RC can interact with the RO. This section provides details of how the RC can interact with the RO.
All interact requests MUST have the "type" field. All interact requests MUST have the "type" field.
type REQUIRED. Type of interaction. Can be "redirect" or "device". type REQUIRED. Type of interaction. Can be "redirect" or "device".
The "redirect" type indicates that the RO is capable of sending
the user to an arbitrary URL to be returned from the AS. The
"device" type indicates that the RC is capable of communicating a
short, human-readable code to the RO, which the RO can enter
interactively to the AS.
Each interaction type has its own parameters and behaviors, detailed callback OPTIONAL. IF the RC is capable of receiving inbound
below. messages from the RO's browser, this indicates the URI to send the
RO to after interaction. This URI SHOULD (MUST?) be unique per
This can also be presented as interaction handle reference. transaction and MUST be hosted or accessible by the RC. This URI
MUST NOT contain any fragment component. This URI MUST be
2.4.1. Redirect protected by HTTPS, be hosted on a server local to the user's
browser ("localhost"), or use an application-specific URI scheme.
A redirect type interaction has the RC send the RO to a URL at the AS The allowable URIs MAY be limited by the AS based on the RC's
and interact with the AS directly, using any number of interactions. presented key information.
Following the interaction, the RO is sent back to the RC using the
"callback" URI.
type MUST be "redirect"
callback REQUIRED. URI to send the user to after interaction,
SHOULD (MUST?) be unique per transaction and hosted or accessible
by the RC. This URL MUST NOT contain any fragment component.
This URL MUST be protected by HTTPS, hosted on a server local to
the user's browser ("localhost"), or use an application-specific
URL scheme. MAY be limited by the AS based on the client's
information.
state REQUIRED. Unique value to be returned to the application as a
query parameter on the callback URL, must be sufficiently random
to be unguessable by an attacker. MUST be generated by the client
for this transaction.
interact: {
type: redirect
callback: https://client.foo/
state: foo
}
2.4.2. Device
The device type interaction has the RC instruct the user to go to a state REQUIRED if the "callback" parameter is used. Unique value to
URL at the AS using a secondary device. The user then interacts with be returned to the application as a query parameter on the
the AS directly by entering a short code provided by the AS to the callback URL, must be sufficiently random to be unguessable by an
RC. Following the interaction, the RO is prompted by the AS to check attacker. MUST be generated by the RC for this transaction.
their RC device, which can poll the AS until the authorization is
complete.
type MUST be "device" Each interaction type has its own parameters and behaviors, detailed
below.
interact: { This section MUST NOT be represented by a handle reference. (Note:
type: device this
}
2.5. Keys 2.5. Keys
This section lists the keys that the client can present proof of This section lists the keys that the RC can present proof of
ownership. Each key type has its own proofing mechanism and ownership. The RC MUST send at least one key. The RC MAY send more
additional required parameters, listed in individual sections below. than one key, but only one key of each type.
type Validation method for the key, must be one of "jwsd", "mtls/
x509", or "did/zkp".
All presented keys MUST be validated by the AS as per the Key
Validation section.
This can also be presented as a key handle reference. The key
referenced by a handle MUST be validated by the AS.
key: {
handle: "3eru876tyhgr5678ikjhgt"
}
2.5.1. Detatched JWS method
type MUST be "jwsd"
jwks Value of the public key as a JWK Set JSON object [Note: should jwks Value of the public key as a JWK Set JSON object [Note: should
this be a single JWK instead? And do we want to bother with url- this be a single JWK instead? And do we want to bother with url-
based references?]. MUST contain an "alg" field which is used to based references?]. MUST contain an "alg" field which is used to
validate the signature. MUST contain the "kid" field to identify validate the signature. MUST contain the "kid" field to identify
the key in the signed object. the key in the signed object. This key type MUST be proved using
either the detached JWS or HTTP-Signing mechanisms.
key: {
type: jwsd,
jwks: { keys: [ alg: RS256, kty: ... ] }
}
2.5.2. MTLS method
type MUST be "mtls"
cert REQUIRED. String serialized value of the certificate
thumbprint as per OAuth-MTLS.
key: {
type: mtls, cert String serialized value of the certificate thumbprint as per
cert: "MII...." OAuth-MTLS. This key type MUST be proved using Mutual TLS.
} did The DID URL identifying the key (or keys) used to sign this
request. This key type MUST be proved using [[ note -- how? ]]
2.5.3. DID method The RC MUST provide proof of possession of all presented
keysSection 10. All presented keys MUST be validated by the AS as
per the Key Validation section.
type MUST be "did" This section MAY also be presented as a key handle reference
Section 9.7. The keys referenced by a handle MUST be validated by
the AS.
did The DID URL identifying the key (or keys) used to sign this The following non-normative example shows all three key methods:
request.
key: { key: {
type: did, jwks: { keys: [ alg: RS256, kty: ... ] },
cert: "MII....",
did: "did:v:foo...." did: "did:v:foo...."
} }
3. Interaction response 3. Interaction response
When evaluating a transaction request, the AS can determine that it When evaluating a transaction request, the AS MAY determine that it
needs to have the RO present to interact with the AS before issuing a needs to have the RO present to interact with the AS before issuing a
token. This interaction can include the RO logging in to the AS, token. This interaction can include the RO logging in to the AS,
authorizing the transaction, providing proof claims, determining if authorizing the transaction, providing proof claims, determining if
the transaction decision should be remembered for the future, and the transaction decision should be remembered for the future, and
other items. other items.
The AS responds to the RC based on the type of interaction supported The AS responds to the RC based on the type of interaction supported
by the RC in the transaction request. by the RC in the transaction request.
This response can indicate a set of keys are bound to the transaction This response can indicate a set of keys are bound to the transaction
skipping to change at page 8, line 31 skipping to change at page 8, line 15
3.1. Redirect interaction 3.1. Redirect interaction
If the RC supports a "redirect" style interaction, the AS creates a If the RC supports a "redirect" style interaction, the AS creates a
unique interaction URL and returns it to the RC. This URL MUST be unique interaction URL and returns it to the RC. This URL MUST be
associated with a single pending transaction. associated with a single pending transaction.
interaction_url The interaction URL that the RC will direct the RO interaction_url The interaction URL that the RC will direct the RO
to. This URL MUST be unique to this transaction request. The URL to. This URL MUST be unique to this transaction request. The URL
SHOULD contain a random portion of sufficient entropy so as not to SHOULD contain a random portion of sufficient entropy so as not to
be guessable by the user. The URL MUST NOT contain the be guessable by the user. The URL MUST NOT contain the
transaction handle or any client identifying information. This transaction handle or any RC identifying information. This URL
URL MUST be protected by HTTPS. This URL MUST NOT contain any MUST be protected by HTTPS. This URL MUST NOT contain any
fragment component. fragment component.
handle The transaction handle to use in the continue request once handle The transaction handle to use in the continue request once
the RO has been returned to the RC via the callback URL. See the the RO has been returned to the RC via the callback URL. See the
section on transaction handles. section on transaction handlesSection 9.3.
{ {
interaction_url: "https://server.example.com/interact/123asdfklj", interaction_url: "https://server.example.com/interact/123asdfklj",
handle: { handle: {
value: "tghji76ytghj9876tghjko987yh", value: "tghji76ytghj9876tghjko987yh",
method: "bearer" type: "bearer"
} }
} }
When the RC receives this response, it sends the RO to the When the RC receives this response, it MUST launch the system
interaction URL. When interacting with the RO, the AS MAY perform browser, redirect the RO through an HTTP 302 response, display the
any of the behaviors in the User Interaction section. URL through a scannable barcode, or otherwise send the RO to the
interaction URL. The RC MUST NOT modify the interaction URL or
append anything to it, including any query parameters, fragments, or
special headers.
Once the RO has completed the interaction with the AS, the AS returns The interaction URL MUST be reachable from the RO's browser, though
the user to the RC by redirecting the RO's browser to the RC's note that the RO MAY open the interaction URL on a separate device
callback URL presented at the start of the transaction, with the from the RC itself. The interaction URL MUST be accessible from an
state parameter appended to the callback URL as a query parameter in HTTP GET request, and MUST be protected by HTTPS or equivalent means.
addition to an interaction handle to be returned to the AS in a
transaction continuation request. Upon receiving an incoming request at the interaction URL, the AS
MUST determine the transaction associated with this unique URL. If
the transaction is not found, an error is returned to the end user
through the browser and the AS MUST NOT attempt to redirect to a
callback URL. When interacting with the RO, the AS MAY perform any
of the behaviors in the User Interaction section Section 5.
3.2. Callback response
If the RC has supplied a callback URL in its interact request
Section 2.4, the AS returns the user to the RC by redirecting the
RO's browser to the RC's callback URL presented at the start of the
transaction, with the addition of two query parameters.
state REQUIRED. The (hashed?) value of the state parameter sent by state REQUIRED. The (hashed?) value of the state parameter sent by
the client in the initial interaction request. the RC in the initial interaction request Section 2.4.
interact_handle REQUIRED. A shared secret associated with this interact_handle REQUIRED. A shared secret associated with this
interaction. This value MUST be sufficiently random so as not to interaction. This value MUST be sufficiently random so as not to
be guessable by an attacker. This value MUST be associated by the be guessable by an attacker. This value MUST be associated by the
AS with the underlying transaction that is associated to with this AS with the underlying transaction that is associated to with this
interaction. interaction.
Upon processing this request to the callback URL, the client MUST Upon processing this request to the callback URL, the RC MUST match
match the state value to the value it sent in the original the state value to the value it sent in the original transaction
transaction request. The RC then sends a transaction continuation request. The RC then sends a transaction continuation request with
request with the transaction handle returned in the interaction the transaction handle returned in the interaction response and the
response and the (hash of?) the interaction handle returned as a (hash of?) the interaction handle returned as a query parameter to
query parameter to the callback URL. the callback URL.
The client sends the hash of the interaction handle as the The RC sends (the hash of? example here is hashed) the interaction
"interact_handle" field of the transaction continuation request. handle as the "interact_handle" field of the transaction continuation
requestSection 7, using the transaction handle Section 7 returned in
the most recent transaction response from the AS.
{ {
"handle": "80UPRY5NM33OMUKMKSKU", "handle": "80UPRY5NM33OMUKMKSKU",
"interact_handle": "CuD9MrpSXVKvvI6dN1awtNLx-HhZy46hJFDBicG4KoZaCmBofvqPxtm7CDMTsUFuvcmLwi_zUN70cCvalI6ENw" "interact_handle": "CuD9MrpSXVKvvI6dN1awtNLx-HhZy46hJFDBicG4KoZaCmBofvqPxtm7CDMTsUFuvcmLwi_zUN70cCvalI6ENw"
} }
[Open Question: error conditions. If the user denies access or 3.3. Secondary device interaction
there's some other authorization error, do we return to the callback?
What's the attack surface here? We could always return an error page
to the browser and cancel the underlying transaction, effectively
killing it at the AS.]
If the AS cannot identify the source transaction from the source URL,
it returns an HTTP 404 error page to the browser and optionally an
error message to the user.
3.2. Secondary device interaction
If the RC supports a "device" style interaction, the AS creates a If the RC supports a "device" style interaction, the AS creates a
unique interaction code and returns it to the RC along with a URL to unique interaction code and returns it to the RC. The RC
give the user for interaction. communicates this code to the RO and instructs the RO to enter the
code at a URL hosted by the AS.
user_code A short code that the user can type into an authorization user_code REQUIRED. A short code that the user can type into an
server. This string MUST be case-insensitive, MUST consist of authorization server. This string MUST be case-insensitive, MUST
only easily typeable characters (such as letters or numbers). The consist of only easily typeable characters (such as letters or
time in which this code will be accepted MUST be short lived. numbers). The time in which this code will be accepted SHOULD be
short lived, such as several minutes.
interaction_url The interaction URL that the RC will direct the RO user_code_url RECOMMENDED. The interaction URL that the RC will
to. This URL SHOULD be stable over time. direct the RO to. This URL SHOULD be stable at the AS such that
clients can be statically configured with it.
wait The amount of time to wait before polling again, in integer wait RECOMMENDED. The amount of time to wait before polling again,
seconds. in integer seconds.
handle The transaction handle to use in the continue request. See handle REQUIRED. The transaction handle to use in the continue
the section on transaction handles. request. See the section on transaction handlesSection 9.3.
{ {
user_code: "ABCD1234" user_code: "ABCD1234"
interaction_url: "https://server.example.com/device", user_code_url: "https://server.example.com/device",
wait: 30, wait: 30,
handle: { handle: {
value: "tghji76ytghj9876tghjko987yh", value: "tghji76ytghj9876tghjko987yh",
method: "bearer" type: "bearer"
} }
} }
When the RC receives this response, it MUST communicate the user code When the RC receives this response, it MUST communicate the user code
to the RO. If possible the RC SHOULD communicate the interaction URL to the RO. If possible the RC SHOULD communicate the interaction URL
to the user as well, although this can be a stable URL at the AS. to the user as well.
When the RO enters the unique user code at the user code URL, the AS
MUST determine which active transaction is associated with the user
code. If a transaction is not found, the AS MUST return an error
page to the user and MUST NOT attempt to redirect to a callback URL.
The AS MAY use any mechanism to interact with the RO as listed in
Section 5.
Note that this method is strictly for allowing the user to enter a
code at a static URL. If the AS wishes to communicate a pre-composed
URL to the RO containing both the user code and the URL at which to
enter it, the AS MUST use the "interaction_url" Section 3.1 redirect
mechanism instead as this allows the client to communicate an
arbitrary interaction URL to the RO.
4. Wait response 4. Wait response
If the AS needs to do something that the RC has no part in before it If the AS needs the RC to wait before it can give a definitive
can give a definitive response, the AS replies to the transaction response to a transaction continue requestSection 7, the AS replies
request with a wait response. This tells the RC that it can poll the to the transaction request with a wait response. This tells the RC
transaction after a set amount of time. that it can poll the transaction after a set amount of time.
This response can indicate a set of keys are bound to the transaction This response includes a transaction handle as in Transaction Handle
as in Key Binding. This response includes a transaction handle as in Section 9.3.
Transaction Handle.
wait REQUIRED. The amount of time to wait before polling again, in wait REQUIRED. The amount of time to wait before polling again, in
integer seconds. integer seconds.
handle REQUIRED. The transaction handle to use in the continue handle REQUIRED. The transaction handle to use in the continue
request. This MUST be a newly-created handle and MUST replace any request. This MUST be a newly-created handle and MUST replace any
existing handle for this transaction. See the section on existing handle for this transaction. See the section on
transaction handles. transaction handles.
{ {
wait: 30, wait: 30,
handle: { handle: {
value: "tghji76ytghj9876tghjko987yh", value: "tghji76ytghj9876tghjko987yh",
method: "bearer" type: "bearer"
} }
} }
5. Interaction at the AS 5. Interaction at the AS
When the RO is interacting with the AS at the interaction endpoint, When the RO is interacting with the AS at the interaction endpoint,
the AS MAY perform whatever actions it sees the AS MAY perform whatever actions it sees fit, including but not
limited to:
o authenticate the RO
o gather identity claims about the RO
o gather consent and authorization from the RO
o allow the RO to modify the parameters of the requested transaction
(such as disallowing some requested resources)
When the AS has concluded interacting with the RO, the AS MUST
determine if the RC has registered a callback URL and state parameter
for this transaction. If so, the AS MUST redirect the RO's browser
to the callback URL as described in Section 3. If the AS detects an
error condition, such as an unknown transaction, an untrustworthy
callback URL, an untrustworthy client, or suspicious RO behavior, the
AS MUST return an error to the RO's browser and MUST NOT redirect to
the callback URL.
6. Error response 6. Error response
If the AS determines that the token cannot be issued for any reason, If the AS determines that the token cannot be issued for any reason,
it responds to the client with an error message. This message does it responds to the RC with an error message. This message does not
not include a transaction handle, and the RC can no longer poll for include a transaction handle, and the RC can no longer poll for this
this transaction. The RC MAY create a new transaction and start transaction. The RC MAY create a new transaction and start again.
again.
error The error code. error The error code.
{ {
error: user_denied error: user_denied
} }
TODO: we should have a robust error mechanism. TODO: we should have a more robust error mechanism. Current
candidate list of errors:
user_denied The RO denied the transaction request.
too_fast The RC did not respect the timeout in the wait response.
unknown_transaction The transaction continuation request referenced
an unknown transaction.
unknown_handle The request referenced an unknown handle.
7. Transaction continue request 7. Transaction continue request
Once a transaction has begun, the AS associates that transaction with Once a transaction has begun, the AS associates that transaction with
a transaction handle which is returned to the RC in one of the a transaction handleSection 9.3 which is returned to the RC in one of
transaction responses. This handle MUST be unique, MUST be the transaction responses Section 3.1, Section 3.3, Section 4. This
associated with a single transaction, and MUST be one time use. handle MUST be unique, MUST be associated with a single transaction,
and MUST be one time use.
The RC continues the transaction by making a request with the The RC continues the transaction by making a request with the
transaction handle in the body of the request. The RC MAY add transaction handle in the body of the request. The RC MAY add
additional fields depending on the type of interaction and additional fields to the transaction continuation request, such as
authorization process in play. the interaction handle return in the callback response Section 3.
transaction The (hash of?) transaction handle to use in the continue handle REQUIRED. The (hash of?) transaction handle indicating which
request. transaction to continue.
interaction_handle The (hash of?) interaction handle returned to the interaction_handle OPTIONAL. If the RC has received an interaction
RC's callback URL from the interaction endpoint. handle from the callback response of the interaction URL, the RC
MUST include the (hash of?) that handle in its transaction
continue request.
{ {
transaction: "tghji76ytghj9876tghjko987yh" handle: "tghji76ytghj9876tghjko987yh"
} }
The RC MUST prove all keys initially sent in the transaction
requestSection 2.5 as described in Section 10.
8. Token response 8. Token response
access_token The access token that the RC uses to call the RS. access_token The access token that the RC uses to call the RS. The
access token follows the handle structure described in Section 9.
access_token_keys List of keys that the access token is bound to
using the methods in key validation. If not specified, the access
token is a bearer token.
handle The transaction handle to use in the continue request to get handle The transaction handle to use in the continue
a new access token once the one issued is no longer usable. See requestSection 7 to get a new access token once the one issued is
the section on transaction handles. no longer usable. See the section on transaction
handlesSection 9.3.
key: { key: {
access_token: "08ur4kahfga09u23rnkjasdf", access_token: {
value: "08ur4kahfga09u23rnkjasdf",
type: "bearer"
},
handle: { handle: {
value: "tghji76ytghj9876tghjko987yh", value: "tghji76ytghj9876tghjko987yh",
method: "bearer" type: "bearer"
} }
} }
8.1. Presenting Tokens to the RS
A bearer style access token MUST be presented using the Header method
of OAuth 2 Bearer Tokens [RFC6750]. A sha3 style access token is
hashed as described in Section 9 and presented using the Header
method of OAuth 2 Bearer Tokens [RFC6750].
An access token MAY be bound to any keys presented by the client
during the transaction request. A bound access token MUST be
presented with proof of the key as described in Section 10.
9. Handle references 9. Handle references
Many parts of this protocol are referenced through the use of handles A handle in this protocol is a value presented from one party to
as stand-ins for actual values, including transactions themselves as another as proof that they are the appropriate party for part of the
well as portions of transactions. transaction. Handles can be used to reference the transaction as a
whole, or one of its constituent parts. When a handle is used to
represent a part of a transaction request, the handle presentation
replaces the original value. In practical terms, this often means
that the values of a transaction request are either an object (when
the full value is used) or a single string (when the handle is used).
value The value of the handle as a string. value The value of the handle as a string.
method The verification method, MUST be one of "bearer" or "sha3". method The verification method, MUST be one of "bearer" or "sha3".
9.1. Validating handles 9.1. Presenting handles
Bearer handles are presented by giving the exact string value of the
handle in the appropriate place.
SHA3 handles are validated by taking the SHA3 hash of the handle
value and encoding it in Base64URL with no padding, and presenting
the encoded value.
9.2. Validating handles
Bearer handles are validated by doing an exact byte comparison of the Bearer handles are validated by doing an exact byte comparison of the
string representation of the handle value. string representation of the handle value.
SHA3 handles are validated by taking the SHA3 hash of the handle SHA3 handles are validated by taking the SHA3 hash of the handle
value and encoding it in Base64URL with no padding. value and encoding it in Base64URL with no padding, and comparing
that using an exact byte comparison with the presented value.
9.2. Transaction handles 9.3. Transaction handles
Transaction handles are issued by the AS to the RC to allow the RC to Transaction handles are issued by the AS to the RC to allow the RC to
continue a transaction after every step. A transaction handle MUST continue a transaction after every step. A transaction handle MUST
be discarded after it is used. If the AS determines that the RC can be discarded after it is used by both the AS and the RC. A
continue the transaction, a new transaction handle will be issued in transaction MUST have only a single handle associated with it at any
its place. time. If the AS determines that the RC can still continue the
transaction after a handle has been used, a new transaction handle
will be issued in its place. If the AS does not issue a transaction
handle in its response to the RC, the RC MUST NOT continue that
transaction.
9.3. Client handles Transaction handles always represent the current state of the
transaction which they reference.
Client handles stand in for the client section of the initial Transactions can be continued by the RC if the AS needs to interact
transaction request. The AS MAY issue a client handle to a client as with the ROSection 5 and the RC is expecting a callbackSection 3 or
part of a static registration process, analogous to a client ID, if the AS is still waiting on some external conditionSection 4 while
allowing the client to be associated with an AS-side configuration the RC is polling. The transaction MAY also be continued after an
access token is issued Section 8 as a means of refreshing an access
token with the same rights associated with the transaction.
9.4. Client handles
RC handles stand in for the client section of the initial transaction
requestSection 2.1. The AS MAY issue a client handle to a RC as part
of a static registration process, analogous to a client ID in OAuth
2, allowing the RC to be associated with an AS-side configuration
that does not change at runtime. Such static processes SHOULD be that does not change at runtime. Such static processes SHOULD be
bound to a set of keys known only to the client software. bound to a set of keys known only to the RC software.
Client handles MAY be issued by the RS in response to a transaction Client handles MAY be issued by the RS in response to a transaction
request. The AS MAY bind this handle to the interact, resource, and request. The AS MAY associate the client handle to the interact,
key handles issued in the same response. When the RC receives this resource, and key handles issued in the same response, requiring them
handle, it MAY present the handle in future transaction requests to be used together. When the RC receives this handle, it MAY
instead of sending its information again. present the handle in future transaction requests instead of sending
its information again.
{ {
handle: { handle: {
value: "tghji76ytghj9876tghjko987yh", value: "tghji76ytghj9876tghjko987yh",
method: "bearer" method: "bearer"
}, },
client_handle: { client_handle: {
value: "absc2948afgdkjnasdf9082ur3kjasdfasdf89", value: "absc2948afgdkjnasdf9082ur3kjasdfasdf89",
method: "bearer" method: "bearer"
} }
} }
The RC sends its handle in lieu of the client block of the The RC sends its handle in lieu of the client block of the
transaction request: transaction request:
{ {
client: { client: "absc2948afgdkjnasdf9082ur3kjasdfasdf89"
handle: "absc2948afgdkjnasdf9082ur3kjasdfasdf89"
}
} }
9.4. Resource handles 9.5. Resource handles
Resource handles stand in for the detailed resource request in the Resource handles stand in for the detailed resource request in the
transaction request. Resource handles MAY be created by the transaction requestSection 2.2. Resource handles MAY be created by
authorization server as static stand-ins for specific resource the authorization server as static stand-ins for specific resource
requests, analogous to OAuth2 scopes. requests, analogous to OAuth2 scopes.
Resource handles MAY be issued by the RS in response to a transaction Resource handles MAY be issued by the RS in response to a transaction
request. When the RC receives this handle, it MAY present the handle request. When the RC receives this handle, it MAY present the handle
in future transaction requests instead of sending its information in future transaction requests instead of sending its information
again. again.
{ {
handle: { handle: {
value: "tghji76ytghj9876tghjko987yh", value: "tghji76ytghj9876tghjko987yh",
method: "bearer" method: "bearer"
}, },
resource_handle: { resource_handle: {
value: "foo", value: "foo",
method: "bearer" method: "bearer"
} }
} }
The RC sends its handle in lieu of the resource block of the The RC sends its handle in lieu of the resource block of the future
transaction request: transaction request:
{ {
resource: { resources: ["foo"]
handle: "foo"
}
} }
9.5. User handles Handles and object values MAY be combined.
{
resources: [
"foo",
{
actions: ["read", "write"],
locations: ["https://exapmle.com/resource"]
data: ["foo", "bar"]
}
]
}
9.5.1. Resource-first
[[ Strawman idea: ]]
In order to facilitate dynamic API protection, an RS MAY pre-register
a resource handle in response to an unauthorized request from the RC.
In this scenario, the RS creates a transaction request with no client
information but describing the resources being protected [[Note: this
is currently at odds with the required format above, perhaps this
should be a special mode or flag? We could still use the "keys"
section here though.]] The AS returns a resource handle to the RS,
which then communicates both the resource handle and the AS
transaction endpoint to the RC. The RC then begins its transaction
as normal, using the resource handle as one of perhaps several
resources it requests.
9.6. User handles
User handles MAY be issued by the AS in response to validating a User handles MAY be issued by the AS in response to validating a
specific RO during a transaction. This handle can be used in future specific RO during a transaction and stand in for the user section of
transactions to represent the current user, analogous to the a transaction requestSection 2.3. This handle MAY refer to the RO
persistent claims token. that interacted with the AS, the user presented by claims in the
transaction request, or a combination of these. This handle can be
used in future transactions to represent the current user, analogous
to the persistent claims token of UMA 2.
{ {
handle: { handle: {
value: "tghji76ytghj9876tghjko987yh", value: "tghji76ytghj9876tghjko987yh",
method: "bearer" method: "bearer"
}, },
user_handle: { user_handle: {
value: "absc2948afgdkjnasdf9082ur3kjasdfasdf89", value: "absc2948afgdkjnasdf9082ur3kjasdfasdf89",
method: "bearer" method: "bearer"
} }
} }
The RC sends its handle in lieu of the user block of the transaction The RC sends its handle in lieu of the user block of the transaction
request: request:
{ {
user: { user: "absc2948afgdkjnasdf9082ur3kjasdfasdf89"
handle: "absc2948afgdkjnasdf9082ur3kjasdfasdf89"
}
} }
9.6. Key handles 9.7. Key handles
Key handles stand in for the keys section of the initial transaction Key handles stand in for the keys section of the initial transaction
request. The AS MAY issue a key handle to a client as part of a requestSection 2.5. The AS MAY issue a key handle to a RC as part of
static registration process, allowing the client to be associated a static registration process, allowing the RC to be associated with
with an AS-side configuration that does not change at runtime. an AS-side configuration that does not change at runtime.
Key handles MAY be issued by the RS in response to a transaction Key handles MAY be issued by the AS in response to a transaction
request. The AS SHOULD bind this handle to the client, resource, and request. The AS SHOULD bind this handle to the client, resource, and
user handles issued in the same response. When the RC receives this user handles issued in the same response. When the RC receives this
handle, it MAY present the handle in future transaction requests handle, it MAY present the handle in future transaction requests
instead of sending its information again. instead of sending its information again.
{ {
handle: { handle: {
value: "tghji76ytghj9876tghjko987yh", value: "tghji76ytghj9876tghjko987yh",
method: "bearer" method: "bearer"
skipping to change at page 16, line 23 skipping to change at page 18, line 29
method: "bearer" method: "bearer"
} }
} }
The RC sends its handle in lieu of the client block of the The RC sends its handle in lieu of the client block of the
transaction request: transaction request:
{ {
key: { key: "absc2948afgdkjnasdf9082ur3kjasdfasdf89"
handle: "absc2948afgdkjnasdf9082ur3kjasdfasdf89"
}
} }
When the AS receives a key handle, it MUST validate that the keys When the AS receives a key handle, it MUST validate that the keys
referenced by the handle are bound to the current transaction referenced by the handle are bound to the current transaction
request. request.
10. Binding Keys 10. Binding Keys
Any keys presented by the RC to the AS or RS MUST be validated as Any keys presented by the RC to the AS or RS MUST be validated as
part of the transaction in which they are presented. Any keys bound part of the transaction in which they are presented. Any keys bound
to the transaction are indicated by the bound_keys section of the to the transaction are indicated by the bound_keys section of the
transaction response. Any keys referenced in this section MUST be transaction response. Any keys referenced in this section MUST be
used with all future transaction requests. used with all future transaction requests.
10.1. Binding a key to a transaction 10.1. Binding a key to a transaction
Keys are bound to a transaction by including a bound_keys field in All keys presented by the RC in the transaction requestSection 2 MUST
the transaction response alongside the transaction handle. Any be proved in all transaction continuation requestsSection 7 for that
further keys used for binding transaction. The AS MUST validate all keys presented by the RC or
referenced in the transaction.
10.2. Validating detached JWS 10.2. Detached JWS
To sign a request to the transaction endpoint, the RC takes the To sign a request to the transaction endpoint, the RC takes the
serialized body of the request and signs it using detached JWS. The serialized body of the request and signs it using detached JWS
header of the JWS MUST contain the kid field of the key bound to this [RFC7797]. The header of the JWS MUST contain the kid field of the
client during this transaction. The header MUST contain an alg field key bound to this RC during this transaction. The header MUST
appropriate for the key identified by kid and MUST NOT be none. The contain an alg field appropriate for the key identified by kid and
MUST NOT be none.
The RC presents the signature in the JWS-Signature HTTP Header field. The RC presents the signature in the JWS-Signature HTTP Header field.
[Note: this is a custom header field, do we need this?] [Note: this is a custom header field, do we need this?]
JWS-Signature: eyj0.... JWS-Signature: eyj0....
When the AS receives the JWS-Signature header, it MUST parse its When the AS receives the JWS-Signature header, it MUST parse its
contents as a detached JWS object. The HTTP Body is used as the contents as a detached JWS object. The HTTP Body is used as the
payload for purposes of validating the JWS, with no transformations. payload for purposes of validating the JWS, with no transformations.
10.3. Validating attached JWS 10.3. Validating MTLS
[Note: if we do an attached JWS we end up having two different data
types to deal with at the AS, is this ok?]
To sign a request to the transaction endpoint with an attached JWS,
the RC takes the body of the request as the JWS payload and wraps the
request in a JWS object.
10.4. Validating MTLS
The RC presents its client certificate during TLS negotiation with The RC presents its client certificate during TLS negotiation with
the server. The AS or RS takes the thumbprint of the client the server (either AS or RS). The AS or RS takes the thumbprint of
certificate presented during mutual TLS negotiation and compares that the client certificate presented during mutual TLS negotiation and
thumbprint to the thumbprint presented by the RC application. compares that thumbprint to the thumbprint presented by the RC
application.
10.5. Validating DID
The RC signs the request using [some HTTP signing mechanism] and its 10.4. Validating DID
private key, and attaches the signature to the HTTP request using [a
header method?]. [Note: is DID just a key-lookup mechanism here or
should we use a different kind of crypto method as well?]
11. Using a Token [[ Note: validation of DID-based keys could potentially be either
detached JWS or MTLS, depending on the type of key used, or some
other validation mechanism. ]] The RC signs the request using [some
HTTP signing mechanism] and its private key, and attaches the
signature to the HTTP request using [a header method?]. [Note: is
DID just a key-lookup mechanism here or should we use a different
kind of crypto method as well?]
Bearer access tokens issued through this method can be used with the 11. Acknowledgements
authorization header method found in RFC6750. Other access tokens
are validated by the RS in accordance with the methods in the Binding
Keys section.
12. Acknowledgements 12. IANA Considerations
13. IANA Considerations
This specification creates one registry and registers several values This specification creates one registry and registers several values
into existing registries. into existing registries.
14. Security Considerations 13. Security Considerations
15. Privacy Considerations All requests have to be over TLS or equivalent.
16. Normative References 14. Privacy Considerations
[OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Handles are passed between parties and therefore should be stateful
Core 1.0", November 2014. and not contain any internal structure or information, which could
leak private data.
15. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/bcp195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
[RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload
Option", RFC 7797, DOI 10.17487/RFC7797, February 2016,
<https://www.rfc-editor.org/info/rfc7797>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
Appendix A. Document History Appendix A. Document History
- 01
o Made JSON multimodal for handle requests.
o Major updates to normative language and references throughout
document.
o Allowed interaction to split between how the user gets to the AS
and how the user gets back.
- 00 - 00
o Initial submission. o Initial submission.
Author's Address Author's Address
Justin Richer (editor) Justin Richer (editor)
Bespoke Engineering Bespoke Engineering
Email: ietf@justin.richer.org Email: ietf@justin.richer.org
 End of changes. 109 change blocks. 
319 lines changed or deleted 446 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/