Transactional AuthorizationBespoke Engineeringietf@justin.richer.orgThis document defines a mechanism for delegating authorization to a
piece of software, and conveying that delegation to the software.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
RFC 2119RFC
8174 when, and only when, they appear in all capitals, as shown
here.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.The Authorization Server (AS) manages the transactions. It is
defined by its transaction endpoint, a single URL that accepts a POST
request with a JSON payload. The AS MAY also have other endpoints,
including interaction endpoints and user code endpoints, and these are
introduced to the RC as needed during the transaction process.The Resource Client (RC) requests tokens from the AS and uses
tokens at the RS.The Resource Server (RS) accepts tokens from the RC and validates
them (potentially at the AS).The Resource Owner (RO) authorizes the request from the RC to the
RS, often interactively at the AS.The RC creates a transaction request and sends it to the ASThe AS processes the transaction request and determines if the
RO needs to interactIf interaction is required, the AS interacts with the RO,
possibly by directing the RC to send the RO thereThe RC continues the transaction at the ASThe AS processes the transaction again, determining that a
token can be issuedThe AS issues a token to the RCThe RC uses the token with the RSTo start a transaction, the RC makes a transaction request to the
transaction endpoint of the AS. The RC creates a JSON document with different sections, included as members
of a root JSON object. Contents of this section are defined by a
registry [TBD].Information about the RS's the resulting
token will be applied to, including locations, extents of access,
types of data being accessed, and other API information. This
section is REQUIRED.Information about the keys known to the RC and
able to be presented in future parts of the transaction. This
section is REQUIRED. (Note: I can't think of a good reason for this
to be optional.)Information about how the RC is able to
interact with the RO, including callback URI's and nonce if
applicable. This section is REQUIRED if the RC is capable of driving
interaction with the user.Information about the RC making the request,
including display name, home page, logo, and other user-facing
information. This section is RECOMMENDED.Information about the RO as known to or provided
to the RC, in the form of assertions or references to external data.
This section is OPTIONAL.Information about the RO as known to or
provided to the AS being requested by the RS. This section is
OPTIONAL.Information about the capabilities of the
RC. This section is OPTIONAL.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 . 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.A non-normative example of a transaction request is below:This section provides descriptive details of the RC software making
the call, useful for displaying information about the client to the
user during the authorization request. This section is a JSON object,
and all fields are OPTIONAL. The RC MAY send additional fields, and
the AS MUST ignore all fields that it does not understand. The fields
of this section will be determined by a registry [TBD].Display name of the RC softwareUser-facing web page of the RC softwareDisplay image to represent the RC
softwareThe AS SHOULD use this information in presenting any authorization
screens to the RO during interaction.The display information MAY instead be presented as a display
handle reference .This section identifies what the RC wants to do with the API hosted
at the RS. When requesting a single resource, this section is a JSON
array of objects, each object representing a single resource or
resource set. That AS MUST interpret the request as being for all of
the resources listed. The fields in this section will be controlled by
a registry [TBD].The types of actions the RC will take at the
RSURIs the RC will call at the RStypes of data available to the RC at the
RS's APIThis can also be presented as a set of resource handle references
, or a combination of handles and
resource structures.When requesting multiple resources, this section is a JSON object
whose keys identifiers chosen by the RC and whose values are resource
description arrays, as described above.When a client requests multiple resources in this manner, a
successful response MUST follow the multiple access token format.This section provides a verifiable assertion about the person
interacting with the RC on behalf of the request. This person MAY be
the RO or MAY be another party. The assertion types will be defined in
a registry [TBD].The value of the assertion as a
string.The type of the assertion. Possible values
include "oidc_id_token"...This can also be presented as a user handle reference .This section provides details of how the RC can interact with the
RO. All fields are OPTIONAL, and the RC MAY include multiple possible
interaction modes. If a field is not present, it is interpreted as the
client's lack support for that feature. The fields in this section are
defined by a registry [TBD].If this object is present, it indicates the
RC is capable of receiving inbound messages from the RO's browser
in response to user interaction. This object contains the
following fields:REQUIRED. Indicates the URI to send the RO
to after interaction. This URI MAY be unique per transaction
and MUST be hosted or accessible by the RC. This URI MUST NOT
contain any fragment component. This URI MUST be protected by
HTTPS, be hosted on a server local to the user's browser
("localhost"), or use an application-specific URI scheme. If
the RC needs any state information to tie to the front channel
interaction response, it MUST encode that into the callback
URI. The allowable URIs and URI patterns MAY be limited by the
AS based on the RC's presented key information. The callback
URI SHOULD be presented to the RO during the interaction phase
before redirect.REQUIRED. Unique value to be used in the
calculation of the "hash" query parameter on the callback URL,
must be sufficiently random to be unguessable by an attacker.
MUST be generated by the RC as a unique value for this
transaction.OPTIONAL. The signature mechanism to
be used for the callback hash in . Can be one of sha3 or sha2. If
absent, the default value is sha3.If this is set to true, the RC is capable
of redirecting the RO to an arbitrary interaction URL as described
in . The RC MAY communicate the
URI to the user through a browser redirection, a QR code, or some
other mechanism.If this is set to true, the RC is capable
of displaying a short user code to the user and directing them to
a fixed URL as described in .If this is set to true, the RC is capable of
relaying a DIDComm message to an agent or wallet.If this is set to true, the RC is
capable of relaying a DIDComm query to an agent or wallet.This section MUST NOT be represented by a handle reference. (Note:
this decision is largely due to the "callback" section being variable
per transaction. We could allow a handle but restrict it to
non-callback methods -- but in that case, it's simpler and shorter to
just send the booleans instead of having a special case.)The following example is from an RC that can redirect to the
interaction endpoint and receive returns on a callback URI:This section lists the keys that the RC can present proof of
ownership. The RC MUST send at least one key format. The RC MAY send
more than one key format, but all keys MUST be equivalent. The types
of keys in this section will be defined by a registry [TBD].The form of proof that the RC will use when
presenting the key to the AS. The valid values of this field and
the processing requirements for each are detailed in . This field is REQUIRED.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-based references?]. MUST contain an "alg" field
which is used to validate the signature. MUST contain the "kid"
field to identify the key in the signed object.PEM serialized value of the certificate used
for TLS transactions, with optional internal whitespace.The certificate thumbprint calculated as
per OAuth-MTLS.The DID URL identifying the key (or keys) used
to sign this request.The RC MUST provide proof of possession of all presented keys. All presented keys MUST be validated by the
AS using the method defined by proof.This section MAY also be presented as a key handle reference . The keys referenced by a handle MUST be
validated by the AS.The following non-normative example shows three key types, with the
detached JWS proofing mechanism:This section lists the extensions and special features supported by
the RC. Values of extensions MUST be listed in [[ a registry ]].This section allows the RC to request identity and authentication
information about the RO. All fields are OPTIONAL and consist of
boolean values. A "true" value indicates that the RC is requesting
that claim be returned in the transaction response. A "false" or
omitted value indicates that the RC is not requesting that claim be
returned. The kinds of claims in this section will be defined by a
registry [TBD].A subject identifier for the current
user.An email address for the current user.A phone number for the current user.An OpenID Connect ID Token for the
current user.The following non-normative example shows how to request the
subject and email address of the current user.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
token. This interaction can include the RO logging in to the AS,
authorizing the transaction, providing proof claims, determining if the
transaction decision should be remembered for the future, and other
items.The AS responds to the RC based on the type of interaction supported
by the RC in the transaction request. The AS MAY respond with multiple
possible interaction methods to be chosen by the RC. The fields in this
response are determined by a registry [TBD]. For example, if the RC
indicates that it can handle redirects and user codes and has a callback
URI, it would send a transaction request like this:The AS would then respond with a transaction response like this:This response MUST include a transaction handle as described in so that the transaction can continue after
the user has interacted.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
associated with the current transaction and no other transaction.REQUIRED. The interaction URL that
the RC will direct the RO to. This URL MUST be unique to this
transaction request. The URL SHOULD contain a random portion of
sufficient entropy so as not to be guessable by the user. The URL
MUST NOT contain the transaction handle or any RC identifying
information. This URL MUST be protected by HTTPS. This URL MUST
NOT contain any fragment component.REQUIRED. The transaction handle to use in
the continue the transaction .When the RC receives this response, it MUST launch the system
browser, redirect the RO through an HTTP 302 response, display the 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.The interaction URL MUST be reachable from the RO's browser, though
note that the RO MAY open the interaction URL on a separate device
from the RC itself. The interaction URL MUST be accessible from an
HTTP GET request, and MUST be protected by HTTPS or equivalent
means.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 .If the RC has supplied a callback URL in its interact request , the AS returns a nonce in its interaction
response.REQUIRED. A unique value from the
server included in the calculation of the "hash" value returned in
the callback response. REQUIRED if the client has sent a
"callback" parameter in its interaction request.This example also includes the interaction URL from .When interaction has concluded, 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.REQUIRED. The interaction hash value as
described in .REQUIRED. A shared secret associated
with this interaction. This value MUST be sufficiently random so
as not to be guessable by an attacker. This value MUST be
associated by the AS with the underlying transaction that is
associated to with this interaction.The AS MUST properly process the callback parameter from the
interaction request as a URL, adding these values as query parameters.
The AS MUST NOT use simple string concatenation. For example, for the
callback URL of "https://example.com/client/123456", the AS would add
query parameters as follows (newlines added for display purposes
only):Upon processing this request to the callback URL, the RC MUST
calculate the expected value of the "hash" parameter as described in
and compare that value to the "hash"
parameter on the incoming request.The RC also sends (the hash of? example here is not hashed) the
interaction reference as the "interact_ref" field of the transaction
continuation request, using the
transaction handle returned in the
most recent transaction response from the AS.The "hash" parameter in the interaction response ties the front
channel response to a transaction by using values known only to the
parties in the transaction. To calculate the "hash" value for the
interaction response, the party doing the calculation first takes the
"nonce" value sent by the RC in the interaction section of the initial
transaction request , the
"server_nonce" value returned in the transaction response , and the "interact_ref" returned in the
callback response . These three
values are concatenated to each other in this order using a single
newline character as a separator between the fields. There is no
padding or whitespace before or after any of the lines, and no
trailing newline character.The party then hashes this string with the appropriate algorithm
based on the "hash_method" parameter of the "callback" section of the
interaction request. If the
"hash_method" value is not present in the RC's request, the AS
defaults to "sha3".The "sha3" hash method consists of hashing the string with the
512-bit SHA3 algorithm. The byte array is then encoded using URL
Safe Base64 with no padding. The resulting string is the hash
value.The "sha2" hash method consists of hashing the string with the
512-bit SHA2 algorithm. The byte array is then encoded using URL
Safe Base64 with no padding. The resulting string is the hash
value.If the RC supports a "user_code" style interaction, the AS creates
a unique user interaction code and returns it to the RC. The RC
communicates this code to the RO and instructs the RO to enter the
code at a URL hosted by the AS.REQUIRED. An object containing the user
code information.REQUIRED. A short code that the user
can type into an authorization server. This string MUST be
case-insensitive, MUST consist of only easily typeable
characters (such as letters or numbers). The time in which
this code will be accepted SHOULD be short lived, such as
several minutes.RECOMMENDED. The interaction URL
that the RC will direct the RO to. This URL SHOULD be stable
at the AS such that clients can be statically configured with
it.RECOMMENDED. The amount of time to wait before
polling again, in integer seconds. If not specified, the default
is 30 seconds. See .REQUIRED. The transaction handle to use in
the continue request. See the section on transaction handles.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 user as well. However, the URL is generally understood to
be stable over time for a given service, and this URL MAY be
communicated through a static means such as the device's documentation
or packaging.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 .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" redirect mechanism instead as this allows
the client to communicate an arbitrary interaction URL to the RO.If the AS needs the RC to wait before it can give a definitive
response to a transaction continue request, the AS replies to the transaction
request with a wait response. This tells the RC that it can poll the
transaction after a set amount of time.This response includes a transaction handle as in Transaction Handle
.REQUIRED. The amount of time to wait before
polling again, in integer seconds.REQUIRED. The transaction handle to use in the
continue request. This MUST be a newly-created handle and MUST
replace any existing handle for this transaction. See the section on
transaction handles.When the RO is interacting with the AS at the interaction uri, the AS
MAY perform whatever actions it sees fit, including but not limited
to:authenticate the ROgather identity claims about the ROgather consent and authorization from the ROallow 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 nonce parameter
for this transaction. If so, the AS MUST redirect the RO's browser to
the callback URL as described in . 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.If the AS determines that the token cannot be issued for any reason,
it responds to the RC with an error message. This message does not
include a transaction handle, and the RC can no longer poll for this
transaction. The RC MAY create a new transaction and start again.The error code.TODO: we should have a more robust error mechanism and controlled by
a registry [TBD]. Current candidate list of errors:The RO denied the transaction request.The RC did not respect the timeout in the
wait response.The transaction continuation
request referenced an unknown transaction.The request referenced an unknown
handle.Once a transaction has begun, the AS associates that transaction with
a transaction handle which is
returned to the RC in one of the transaction responses , , . This 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
transaction handle in the body of the request. The RC MAY add additional
fields to the transaction continuation request, such as the interaction
reference return in the callback response .REQUIRED. The (hash of?) transaction handle
indicating which transaction to continue.OPTIONAL. If the RC has received an
interaction reference from the callback response of the interaction
URL, the RC MUST include the (hash of?) that reference in its
transaction continue request.The RC MUST prove all keys initially sent in the transaction
request as described in .[[ Note: should we allow the client to mutate the transaction at this
point? We already allow the presentation of the interaction handle, and
any messaging protocols like DIDComm would allow additional work to be
done here. But do we want the client to be able to specify additional
resources, or new interaction methods, or anything like that? I'm
inclined not to so that's been left out for now. ]]The transaction response contains a set of fields returned as a JSON
object. The fields of the transaction response will be controlled by a
registry [TBD].The access token that the RC uses to call
the RS. The access token follows the handle structure described in
. This field is mutually exclusive with the
multiple_access_tokens field.The transaction handle to use in the continue
request to get a new access
token once the one issued is no longer usable. See the section on
transaction handles.The set of claims that the AS asserts for the
current user. This field is returned only if the RC has requested
using the "claims" object. This object contains the following
OPTIONAL fields (the list of available fields will be determined by
a registry [TBD]):ISO-formatted timestamp string of when
the user's profile information was last updated. The RC SHOULD
compare this value to previous values when determining whether
to get additional user information from an external
endpoint.The machine-readable unique subject
identifier of the user.The email address of the user.The phone number of the user.An OpenID Connect ID Token
representing the user.If the RC requested multiple
named resources, this structure contains the access tokens. The keys
of this JSON object are the labels determined by the RC in its
request, and the values are the same as a single access_token
response. This field is mutually exclusive with the access_token
field.A value used to represent the
information in the display object that the client can use in a
future request, as described in .A value used to represent the information
in the key object that the client can use in a future request, as
described in .A value used to represent the information
in the user object that the client can use in a future request, as
described in .A value used to represent the
information in the resource object that the client can use in a
future request, as described in .A value used to represent the
information in the claims object that the client can use in a future
request, as described in .The following example shows a single access token, a transaction
handle, and a set of claims about the current user being returned in a
successful response.The following example shows multiple access tokens, a key handle, and
a user handle being returned in a successful response. The RC has chosen
the labels "token1" and "token2" in this response.A bearer style access token MUST be presented using the Header
method of OAuth 2 Bearer Tokens . A sha3 style
access token is hashed as described in and presented using the Header method of
OAuth 2 Bearer Tokens .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 .Additional user information MAY be made available to the RC through
use of an access token at a protected resource representing the user.
This endpoint could be an OpenID Connect UserInfo Endpoint, a SCIM
endpoint, or another similar resource. Specification of this resource
is outside the scope of this specification.A handle in this protocol is a value presented from one party to
another as proof that they are the appropriate party for part of the
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).The value of the handle as a string.The verification method, MUST be one of "bearer"
or "sha3".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.Bearer handles are validated by doing an exact byte comparison of
the string representation of the handle value.SHA3 handles are validated by taking the SHA3 hash of the handle
value and encoding it in Base64URL with no padding, and comparing that
using an exact byte comparison with the presented value.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
be discarded after it is used by both the AS and the RC. A transaction
MUST have only a single handle associated with it at any 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.Transaction handles always represent the current state of the
transaction which they reference.Transactions can be continued by the RC if the AS needs to interact
with the RO and the RC is expecting a
callback or if the AS is still
waiting on some external condition while
the RC is polling. The transaction MAY also be continued after an
access token is issued as a means of
refreshing an access token with the same rights associated with the
transaction.RC handles stand in for the display section of the initial
transaction request. The AS MAY issue a
display 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 bound to a set of keys known only to the RC
software.Display handles MAY be issued by the RS in response to a
transaction request. The AS MAY associate the display handle to the
interact, resource, and key handles issued in the same response,
requiring them to be used together. When the RC receives this handle,
it MAY present the handle in future transaction requests instead of
sending its information again.The RC sends its handle in lieu of the display block of the
transaction request:Resource handles stand in for the detailed resource request in the
transaction request. Resource handles
MAY be created by the authorization server as static stand-ins for
specific resource requests, analogous to OAuth2 scopes.Resource handles MAY be issued by the RS in response to a
transaction request. In such cases, the resource handle returned
represents the total of all resources represented in the request.The RC sends its handle in lieu of the resource block of the future
transaction request:Note that handles and object values MAY be combined in a single
request.If the RC requests multiple named resources to result in multiple
access tokens, the AS MUST NOT return a resource handle.[[ 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.User handles MAY be issued by the AS in response to validating a
specific RO during a transaction and stand in for the user section of
a transaction request. This handle MAY
refer to the RO 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.The RC sends its handle in lieu of the user block of the
transaction request:Key handles stand in for the keys section of the initial
transaction request. The AS MAY issue a
key handle to a RC as part of a static registration process, allowing
the RC to be associated with an AS-side configuration that does not
change at runtime.Key handles MAY be issued by the AS in response to a transaction
request. The AS SHOULD bind this handle to the display, resource, and
user handles issued in the same response. When the RC receives this
handle, it MAY present the handle in future transaction requests
instead of sending its information again.The RC sends its handle in lieu of the keys block of the
transaction request:When the AS receives a key handle, it MUST validate that the keys
referenced by the handle are bound to the current transaction request
using the proof method referenced by the handle.Claims handles stand in for the claims section of the initial
transaction request. Claims handles MAY
be created by the authorization server as static stand-ins for
specific claim set requests, analogous to OIDC scopes.Claims handles MAY be issued by the RS in response to a transaction
request. In such cases, the resource handle returned represents the
total of all claims requested in the transaction request. When the RC
receives this handle, it MAY present the handle in future transaction
requests instead of sending the claims information again.The RC sends its handle in lieu of the claims block of the
transaction request:When the AS receives a key handle, it MUST validate that the keys
referenced by the handle are bound to the current transaction request
using the proof method referenced by the handle.Any keys presented by the RC to the AS or RS MUST be validated as
part of the transaction in which they are presented.The type of binding
used is indicated by the proof parameter of the keys section in the
transaction request. Values defined by this specification are as
follows:A detached JWS signature headerMutual TLS certificate verificationOAuth DPoP key proof headerHTTP Signing signature headerOAuth PoP key proof authentication headerAdditional values can be defined by a registry [TBD].All keys presented by the RC in the transaction request MUST be proved in all transaction
continuation requests for that
transaction. The AS MUST validate all keys presented by the RC or
referenced in the transaction at each call to the transaction endpoint.
The client MUST NOT use a different key during the transaction.This method is indicated by jwsd in the
proof field of a key request. To sign a
request to the transaction endpoint, the RC takes the serialized body
of the request and signs it using detached JWS . The header of the JWS MUST contain the kid field
of the key bound to this RC during this transaction. The JWS header
MUST 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. [Note: this is a custom header field, do we need this?]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
payload for purposes of validating the JWS, with no
transformations.This method is indicated by mtls in the
proof field of a key request. The RC
presents its client certificate during TLS negotiation with the server
(either AS or RS). The AS or RS takes the thumbprint of the client
certificate presented during mutual TLS negotiation and compares that
thumbprint to the thumbprint presented by the RC application as
described in section 3.This method is indicated by dpop in the
proof field of a key request. The RC
creates a DPoP signature header as described in section 2.This method is indicated by httpsig in
the proof field of a key request. The RC
creates an HTTP Signature header as described in section 4. The RC MUST calculate
and present the Digest header as defined in .This method is indicated by oauthpop in
the proof field of a key request. The RC
creates an HTTP Authorization PoP header as described in section 4, with the
following additional requirements:The at (access token) field MUST be omitted [note: this is in
contrast to the requirements in the existing spec]The b (body hash) field MUST be calculated and supplied[We'll want a registry for key proof types, and maybe some other
field names. We'll need to register at least one header and maybe some
others?]All requests have to be over TLS or equivalent. Many handles act as
shared secrets, though they can be combined with a requirement to
provide proof of a key as well.Handles are passed between parties and therefore should be stateful
and not contain any internal structure or information, which could leak
private data.Recommendations for Secure Use of Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer
Security (DTLS) are widely used to protect data exchanged over
application protocols such as HTTP, SMTP, IMAP, POP, SIP, and
XMPP. Over the last few years, several serious attacks on TLS have
emerged, including attacks on its most commonly used cipher suites
and their modes of operation. This document provides
recommendations for improving the security of deployed services
that use TLS and DTLS. The recommendations are applicable to the
majority of use cases.-07Marked sections as being controlled by a future registry TBD.-06Added multiple resource requests and multiple access token
response.-05Added "claims" request and response for identity support.Added "capabilities" request for inline discovery support.- 04Added crypto agility for callback return hash.Changed "interaction_handle" to "interaction_ref".- 03Removed "state" in favor of "nonce".Created signed return parameter for front channel return.Changed "client" section to "display" section, as well as
associated handle.Changed "key" to "keys".Separated key proofing from key presentation.Separated interaction methods into booleans instead of "type"
field.- 02Minor editorial cleanups.- 01Made JSON multimodal for handle requests.Major updates to normative language and references throughout
document.Allowed interaction to split between how the user gets to the AS
and how the user gets back.- 00Initial submission.