]> SignIn.Org

United States dick.hardt@gmail.com

Security Client software often desires resources or identity claims that are independent of the client. This protocol allows a user and/or resource owner to delegate resource authorization and/or release of identity claims to a server. Client software can then request access to resources and/or identity claims by calling the server. The server acquires consent and authorization from the user and/or resource owner if required, and then returns to the client software the authorization and identity claims that were approved. This protocol can be extended to support alternative authorizations, claims, interactions, and client authentication mechanisms.

Introduction This protocol supports the widely deployed use cases supported by OAuth 2.0 & , and OpenID Connect , an extension of OAuth 2.0, as well as other extensions, and other use cases that are not supported, such as acquiring multiple access tokens at the same time, and updating the request during user interaction. This protocol also addresses many of the security issues in OAuth 2.0 by having parameters securely sent directly between parties, rather than via a browser redirection. The technology landscape has changed since OAuth 2.0 was initially drafted. More interactions happen on mobile devices than PCs. Modern browsers now directly support asymetric cryptographic functions. Standards have emerged for signing and encrypting tokens with rich payloads (JOSE) that are widely deployed. Additional use cases are now being served with extensions to OAuth 2.0: OpenID Connect added support for authentication and releasing identity claims; added support for native apps; added support for smart devices; and support for is being worked on. There are numerous efforts on adding proof-of-possession to resource access. This protocol simplifies the overall architectural model, takes advantage of today's technology landscape, provides support for all the widely deployed use cases, and offers numerous extension points. While this protocol is not backwards compatible with OAuth 2.0, it strives to minimize the migration effort. This protocol centers around a Grant, a representation of the collection of user identity claims and/or resource authorizations the Client is requesting, and the resulting identity claims and/or resource authorizations granted by the Grant Server. [Editor: suggestions on how to improve this are welcome!] [Editor: suggestions for other names than XAuth are welcome!]

Parties The parties and their relationships to each other: | Grant | _ _ | Resource | | |<----| Server (GS) | | Server | | | +---------------+ | (RS) | | |-------------------------->| | | |<--------------------------| | +--------+ +------------+ ]]>

• User - the person interacting with the Client who has delegated access to identity claims about themselves to the Grant Server (GS), and can authenticate at the GS.
• Client - requests a Grant from the GS to access one or more Resource Servers (RSs), and/or identity claims about the User. The Client can create, verify, retrieve, update, and delete a Grant. When a Grant is created, the Client receives from the GS the granted access token(s) for the RS(s), and identity claims about the User. The Client uses an access token to access the RS. There are two types of Clients: Registered Clients and Dynamic Clients. All Clients have a key to authenticate with the Grant Server.
• Registered Client - a Client that has registered with the GS and has a Client ID to identify itself, and can prove it possesses a key that is linked to the Client ID. The GS may have different policies for what different Registered Clients can request. A Registered Client MAY be interacting with a User.
• Dynamic Client - a Client that has not been registered with the GS, and each instance will generate it's own key pair so it can prove it is the same instance of the Client on subsequent requests, and to requests of a Resource Server that require proof-of-possession access. A single-page application with no active server component is an example of a Dynamic Client. A Dynamic Client MUST be interacting with a User.
• Grant Server (GS) - manages Grants for access to APIs at RSs and release of identity claims about the User. The GS may require explicit consent from the RO or User to provide these to the Client. A GS may support Registered Clients and/or Dynamic Clients. The GS is a combination of the Authorization Server (AS) in OAuth 2.0, and the OpenID Provider (OP) in OpenID Connect.
• Resource Server (RS) - has API resources that require an access token from the GS. Some, or all of the resources are owned by the Resource Owner.
• Resource Owner (RO) - owns resources at the RS, and has delegated RS access management to the GS. The RO may be the same entity as the User, or may be a different entity that the GS interacts with independently. GS and RO interactions are out of scope of this document.

Reused Terms

• access token - an access token as defined in Section 1.4.
• Claim - a Claim as defined in Section 5. Claims may be issued by the GS, or by other issuers.
• Client ID - a GS unique identifier for a Registered Client as defined in Section 2.2.
• ID Token - an ID Token as defined in Section 2.
• NumericDate - a NumericDate as defined in Section 2.
• authN - short for authentication.
• authZ - short for authorization.

New Terms

• GS URI - the endpoint at the GS the Client calls to create a Grant, and is the unique identifier for the GS.
• Grant - the user identity claims and/or RS authorizations the GS has granted to the Client.
• Grant URI - the URI that represents the Grant. The Grant URI MUST start with the GS URI.
• Authorization - the access granted by the RO to the Client. Contains an access token.
• Authorization URI (AZ URI) - the URI that represents the Authorization the Client was granted by the RO. The AZ URI MUST start with the GS URI. The AZ URI is used to read, update, and delete an access token.
• Interaction - how the Client directs the User to interact with the GS. This document defines the interaction modes redirect, indirect, and user_code in
• Client Handle - a GS unique identifier for a Dynamic Client for the Dynamic Client to refer to itself in subsequent requests.

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in . Certain security-related terms are to be understood in the sense defined in . These terms include, but are not limited to, "attack", "authentication", "authorization", "certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", and "verify". Unless otherwise noted, all the protocol parameter names and values are case sensitive. Some protocol parameters are parts of a JSON document, and are referred to in JavaScript notation. For example, foo.bar refers to the "bar" boolean attribute in the "foo" object in the following example JSON document:

Sequences Before any sequence, the Client needs to be manually or programmatically configured for the GS. See GS Options for details on acquiring GS metadata. [Editor: a plethora of sequences are included to illustrate all the different use cases that are supported. Many sequences are similar, and show a slightly different sequence that can support different use cases. These could potentially be moved to a use case document in the future.]

Create and Verify Grant A Dynamic Client wants a Grant from the User using a Redirect Interaction: | | | | | | | |<--- Interaction Response ---(2)--| | +------+ | | | | | User | | |--(3)--- Interaction Transfer --- | - - - | ------->| | | | | | | | | | | |<--(4)-->| | | | | | authN | | | | | |<--(5)-->| | | | | | authZ | | | |<--- Interaction Transfer ---(6)- | - - - | --------| | | | | | | | | |--(7)--- Verify Grant ----------->| | +------+ | | | | | |<--------- Grant Response ---(8)--| | | | | | +--------+ +-------+ ]]>

1. Create Grant The Client creates a Request JSON document and makes a Create Grant request () by sending the JSON with an HTTP POST to the GS URI.
2. Interaction Response The GS determines that interaction with the User is required and sends an Interaction Response () containing the Grant URI and an interaction object.
3. Interaction Transfer The Client redirects the User to the Redirect URI at the GS.
4. User Authentication The GS authenticates the User.
5. User Authorization If required, the GS interacts with the User to determine which identity claims and/or authorizations in the Grant Request are to be granted.
6. Interaction Transfer The GS redirects the User to the Completion URI at the Client, passing an Interaction Nonce.
7. Read Grant The Client creates a JSON document containing a verification object and does a Verify Grant request by HTTP PATCH with the document to the Grant URI.
8. Grant Response The GS responds with a Grant Response ().

Create and Read Grant - Redirect A Registered Client wants a Grant from the User using a Redirect Interaction: | | | | | | | |<--- Interaction Response ---(2)--| | | | | | | |--(3)--- Read Grant ------------->| | +------+ | | | | | User | | |--(4)--- Interaction Transfer --- | - - - | ------->| | | | | | | | | | | |<--(5)-->| | | | | | authN | | | | | |<--(6)-->| | | | | | authZ | | | |<--------- Grant Response ---(7)--| | | | | | | | | | | |<--- Interaction Transfer ---(8)- | - - - | --------| | | | | | | | +--------+ +-------+ +------+ ]]>

1. Create Grant The Client makes a Create Grant request () to the GS URI.
2. Interaction Response The GS determines that interaction with the User is required and sends an Interaction Response () containing the Grant URI and an interaction object.
3. Read Grant The Client does an HTTP GET of the Grant URI ().
4. Interaction Transfer The Client transfers User interaction to the GS.
5. User Authentication The GS authenticates the User.
6. User Authorization If required, the GS interacts with the User to determine which identity claims and/or authorizations in the Grant Request are to be granted.
7. Grant Response The GS responds with a Grant Response ().
8. Interaction Transfer The GS redirects the User to the Completion URI of the Client. The Client verifies it is the same User that it transferred to the GS.

Create and Read Grant - Indirect A Registered Client wants a Grant from the User using an Indirect Interaction: | | | | | | | |<--- Interaction Response ---(2)--| | | | | | | |--(3)--- Read Grant ------------->| | +------+ | | | | | User | | |--(4)--- Interaction Transfer --- | - - - | ------->| | | | | | | | | | | |<--(5)-->| | | | | | authN | | | | | |<--(6)-->| | | | | | authZ | | | |<--------- Grant Response ---(7)--| | | | +--------+ | | | | | | | | +--------+ | | | | | Info |<--- Interaction Transfer ---(8)- | - - - | --------| | | Server | | | | | +--------+ +-------+ +------+ ]]> The sequence is the same except:

• In step (4) the User either scans a bar code or uses a separate device to navigate to the Code URI and enters the User Code.
• In step (8) the GS redirects the User to the Information URI provided by the Client.

Reciprocal Grant Party A and Party B are both a Client and a GS, and each Client would like a Grant for the other GS. The sequence starts off the same as in , but Party B makes a Create Grant Request before sending a Grant Response: | | | | | | AuthZ | | | | +------+ | GS |--(5)--- Grant Response -------->| Client | | | | | +--------+ +--------+ ]]>

1. Create Grant Party B creates a Grant Request () with user.reciprocal set to the Party B Grant URI that will be in the step (2) Grant Response, and sends it with an HTTP POST to the Party A GS URI. This enables Party A to link the reciprocal Grants.
2. Grant Response Party B responds to Party A's Create Grant Request with a Grant Response that includes the Party B Grant URI.
3. Interaction Transfer Party B redirects the User to the Completion URI at Party A.
4. User Authorization If required, Party A interacts with the User to determine which identity claims and/or authorizations in Party B's Create Grant Request are to be granted.
5. Grant Response Party A responds with a Grant Response ().

GS Initiated Grant The User is at the GS, and wants to interact with a Registered Client. The GS can redirect the User to the Client: | | | | | | | | | |<----- GS Initiation Redirect --- | - - - | --(2)---| | | (3) | | | | | | verify |--(4)--- Read Grant ------------->| | +------+ | | | | | |<--------- Grant Response --(5)---| | | | | | +--------+ +-------+ ]]>

1. User Interaction The GS interacts with the User to determine the Client and what identity claims and authorizations to provide. The GS creates a Grant and corresponding Grant URI.
2. GS Initiated Redirect The GS redirects the User to the Client's interaction_uri, adding a query parameter with the name "Grant URI" and the value being the URL encoded Grant URI.
3. Client Verification The Client verifies the Grant URI is from an GS the Client trusts, and starts with the GS GS URI.
4. Read Grant The Client does an HTTP GET of the Grant URI ().
5. Grant Response The GS responds with a Grant Response ().

See for more details.

Create and Update The Client requests an identity claim to determine who the User is. Once the Client learns who the User is, and the Client updates the Grant for additional identity claims which the GS prompts the User for and returns to the Client. Once those are received, the Client updates the Grant with the remaining identity claims required. | | | | interaction.keep:true | | | | | | | |<--- Interaction Response ---(2)--| | | | | | | |--(3)--- Read Grant ------------->| | +------+ | | | | | User | | |--(4)--- Interaction Transfer --- | - - - | ------->| | | | | | | | | | | |<--(5)-->| | | | | | authN | | | |<--------- Grant Response ---(6)--| | | | | (7) | | | | | | eval |--(8)--- Update Grant ----------->| | | | | | interaction.keep:true | |<--(9)-->| | | | | | authZ | | | |<--------- Grant Response --(10)--| | | | | (11) | | | | | | eval |--(12)-- Update Grant ----------->| | | | | | interaction.keep:false | |<--(13)->| | | | | | authZ | | | | | | | | | |<--- Interaction Transfer --(14)- | - - - | --------| | | | | | | | | |<--------- Grant Response --(15)--| | +------+ | | | | +--------+ +-------+ ]]>

1. Create Grant The Client creates a Grant Request () including an identity claim and interaction.keep:true, and sends it with an HTTP POST to the GS GS URI.
2. Interaction Response The GS sends an Interaction Response () containing the Grant URI, an interaction object, and interaction.keep:true.
3. Read Grant The Client does an HTTP GET of the Grant URI ().
4. Interaction Transfer The Client transfers User interaction to the GS.
5. User Authentication The GS authenticates the User.
6. Grant Response The GS responds with a Grant Response () including the identity claim from User authentication and interaction.keep:true.
7. Grant Evaluation The Client queries its User database and does not find a User record matching the identity claim.
8. Update Grant The Client creates an Update Grant Request () including the initial identity claims required and interaction.keep:true, and sends it with an HTTP PUT to the Grant URI.
9. User AuthN The GS interacts with the User to determine which identity claims in the Update Grant Request are to be granted.
10. Grant Response The GS responds with a Grant Response () including the identity claims released by the User and interaction.keep:true.
11. Grant Evaluation The Client evaluates the identity claims in the Grant Response and determines the remaining User identity claim required.
12. Update Grant The Client creates an Update Grant Request () including the remaining required identity claims and interaction.keep:false, and sends it with an HTTP PUT to the Grant URI.
13. User AuthZ The GS interacts with the User to determine which identity claims in the Update Grant Request are to be granted.
14. Interaction Transfer The GS transfers User interaction to the Client.
15. Grant Response The GS responds with a Grant Response () including the identity claims released by the User.

Create and Delete The Client requests an identity claim to determine who the User is. Once the Client learns who the User is, and the Client knows it already has all the identity claims and authorizations needed for the User, the Client deletes the Grant which prompts the GS to transfer the interaction back to the Client. (If the Client did not already have what was needed, the Client would follow the Create and Update sequence ) | | | | interaction.keep:true | | | | | | | |<--- Interaction Response ---(2)--| | | | | | | |--(3)--- Read Grant ------------->| | +------+ | | | | | User | | |--(4)--- Interaction Transfer --- | - - - | ------->| | | | | | | | | | | |<--(5)-->| | | | | | authN | | | |<--------- Grant Response ---(6)--| | | | | (7) | | | | | | eval |--(8)--- Delete Grant ----------->| | | | | |<------- Delete Response ---------| | | | | | | | | | | |<--- Interaction Transfer ---(9)- | - - - | --------| | | | | | | | +--------+ +-------+ +------+ ]]>

1. Create Grant The Client creates a Grant Request () including an identity claim and interaction.keep:true, and sends it with an HTTP POST to the GS GS URI.
2. Interaction Response The GS sends an Interaction Response () containing the Grant URI, an interaction object, and interaction.keep:true.
3. Read Grant The Client does an HTTP GET of the Grant URI ().
4. Interaction Transfer The Client transfers User interaction to the GS.
5. User Authentication The GS authenticates the User.
6. Grant Response The GS responds with a Grant Response () including the identity claim from User authentication and interaction.keep:true.
7. Grant Evaluation The Client queries its User database and finds the User record matching the identity claim, and that no additional claims or authorizations are required.
8. Delete Grant The Client no longer needs the Grant and decides to Delete Grant () by sending an HTTP DELETE to the Grant URI. If the GS responds with success the Grant no longer exists.

Create, Discover, and Delete The Client wants to discover if the GS has a User with a given identifier. If not, it will abort the request and not transfer interaction to the GS. | | | | user.exists:true | | | | | | | |<--- Interaction Response ---(2)--| | | | user.exists:false | | | | | | | |--(3)--- Delete Grant ----------->| | | |<------- Delete Response ---------| | | | | | +--------+ +-------+ ]]>

1. Create Grant The Client creates a Grant Request () including an identity claim request, a User identifier, and user.exists:true. The Client sends it with an HTTP POST to the GS GS URI.
2. Interaction Response The GS sends an Interaction Response () containing the Grant URI, an interaction object, and user.exists:false.
3. Delete Grant The Client determines the GS cannot fulfil its Grant Request, and decides to Delete Grant () by sending an HTTP DELETE to the Grant URI. If the GS responds with success the Grant no longer exists.

Create and Wait The Client wants access to resources that require the GS to interact with the RO, which may not happen immediately, so the GS instructs the Client to wait and check back later. | | | | | | | |<---------- Wait Response ---(2)--| | +------+ | (3) | | | | RO | | Wait | | |<--(4)-->| | | | | | AuthZ | | | |--(5)--- Read Grant ------------->| | +------+ | | | | | |<--------- Grant Response --(6)---| | | | | | +--------+ +-------+ ]]>

1. Create Grant The Client creates a Grant Request () and sends it with an HTTP POST to the GS GS URI.
2. Wait Response The GS sends an Interaction Response () containing the Grant URI and wait time.
3. Client Waits The Client waits the wait time.
4. RO AuthZ The GS interacts with the RO to determine which identity claims in the Grant Request are to be granted.
5. Read Grant The Client does an HTTP GET of the Grant URI ().
6. Grant Response The GS responds with a Grant Response ().

Read Grant The Client wants to re-acquire the identity claims and authorizations in the Grant. No User or RO interaction is required as no new consent or authorization is required. | | | | | | | |<--------- Grant Response --(2)---| | | | | | +--------+ +-------+ ]]>

1. Read Grant The Client does an HTTP GET of the Grant URI ().
2. Grant Response The GS responds with a Grant Response () containing updated identity claims and authorizations.

Resource Server Access The Client received an AZ URI from the GS. The Client acquires an access token, calls the RS, and later the access token expires. The Client then gets a fresh access token. | | | |<------- AuthZ Response -------------------| | | | | | | | +----------+ | | | | | Resource | | | | |--(2)--- Access Resource --->| Server | | | | |<------- Resource Response --| (RS) | | | | | | | | | | |--(3)--- Access Resource --->| | | | | |<------- Error Response -----| | | | | | | | | | | | +----------+ | | | | | | | |--(4)--- Read AuthZ ---------------------->| | | |<------- AuthZ Response -------------------| | | | | | +--------+ +-------+ ]]>

1. Read AuthZ The Client makes a Read AuthZ () with an HTTP GET to the AZ URI and receives an Response JSON "authorization" object () with a fresh access token.
2. Resource Request The Client accesses the RS with the access token per and receives a response from the RS.
3. Resource Request The Client attempts to access the RS, but receives an error indicating the access token has expired.
4. Read AuthZ The Client makes another Read AuthZ () with an HTTP GET to the AZ URI and receives an Response JSON "authorization" object () with a fresh access token.

GS API Table

request	http verb	uri	response
Create Grant	POST	GS URI	interaction, wait, or grant
Verify Grant	PATCH	Grant URI	grant
Read Grant	GET	Grant URI	wait, or grant
Update Grant	PUT	Grant URI	interaction, wait, or grant
Delete Grant	DELETE	Grant URI	success
Read AuthZ	GET	AZ URI	authorization
Update AuthZ	PUT	AZ URI	authorization
Delete AuthZ	DELETE	AZ URI	success
GS Options	OPTIONS	GS URI	metadata
Grant Options	OPTIONS	Grant URI	metadata
AuthZ Options	OPTIONS	AZ URI	metadata

[ Editor: is there value in an API for listing a Client's Grants? eg:]

Grant and AuthZ Life Cycle [Editor: straw man for life cycles.] Grant life Cycle The Client MAY create, read, update, and delete Grants. A Grant persists until it has expired, is deleted, or another Grant is created for the same GS, Client, and User tuple. At any point in time, there can only be one Grant for the GS, Client, and User tuple. When a Client creates a Grant at the same GS for the same User, the GS MUST invalidate a previous Grant for the Client at that GS for that User. Authorization Life Cycle An Authorization are represented by an AZ URI and are MAY be included in a Grant Response "authorization" Object () or as a member of the Grant Response "authorizations" list. If a Client receives an Authorization, the Client MUST be able to do a Read AuthZ request , and MAY be able to update and delete depending on GS policy. An Authorization will persist independent of the Grant, and persist until invalidated by the GS per GS policy, or deleted by the Client.

GS APIs Client Authentication All APIs except for GS Options require the Client to authenticate. This document defines the JOSE Authentication mechanism in . Other mechanisms include [TBD].

Create Grant The Client creates a Grant by doing an HTTP POST of a JSON document to the GS URI. The JSON document MUST include the following from the Request JSON :

• iat
• nonce
• uri set to the GS URI
• client

and MAY include the following from Request JSON

• user
• interaction
• authorization or authorizations
• claims

The GS MUST respond with one of Grant Response , Interaction Response , Wait Response , or one of the following errors:

• TBD

from Error Responses . Following is a non-normative example where the Client is requesting identity claims about the User and read access to the User's contacts: Following is a non-normative example where the Client is requesting the GS to keep the interaction with the User after returning the ID Token so the Client can update the Grant, and is also asking if the user exists:

Verify Grant The Client verifies a Grant by doing an HTTP PATCH of a JSON document to the corresponding Grant URI. The JSON document MUST contain verification.nonce per . Following is a non-normative example: The GS MUST respond with one of Grant Response or one of the following errors:

• TBD

from Error Responses .

Read Grant The Client reads a Grant by doing an HTTP GET of the corresponding Grant URI. The GS MUST respond with one of Grant Response , Wait Response , or one of the following errors:

• TBD

from Error Responses .

Update Grant The Client updates a Grant by doing an HTTP PUT of a JSON document to the corresponding Grant URI. The JSON document MUST include the following from the Request JSON

• iat
• uri set to the Grant URI

and MAY include the following from Request JSON

• user
• interaction
• authorization or authorizations
• claims

The GS MUST respond with one of Grant Response , Interaction Response , Wait Response , or one of the following errors:

• TBD

from Error Responses . Following is a non-normative example where the Client made an interaction.keep:true request, and now wants to update the request with additional claims:

Delete Grant The Client deletes a Grant by doing an HTTP DELETE of the corresponding Grant URI. The GS MUST respond with OK 200, or one of the following errors:

• TBD

from Error Responses .

Request JSON [Editor: do we want to reuse the JWT claims "iat", "jti", etc.? ]

• iat - the time of the request as a NumericDate.
• nonce - a unique identifier for this request. Note the Grant Response MUST contain a matching nonce attribute value.
• uri - the GS URI if in a Create Grant , or the Grant URI if in an Update Grant .

"client" Object The client object MUST contain one of: the "id" attribute for a Registered Client, the "handle" attribute for a Dynamic Client, or the "display" object for Dynamic Clients.

• id - the Client ID the GS has for a Registered Client.
• handle = the Client Handle the GS previously provided a Dynamic Client
• display - the display object contains the following attributes:
  • name - a string that represents the Dynamic Client
  • uri - a URI representing the Dynamic Client

The name and uri will be displayed by the GS when prompting for authorization. [Editor: a max length for the name and URI so a GS can reserve appropriate space?]

"interaction" Object The interaction object contains one or more interaction mode objects per representing the interactions the Client is willing to provide the User. In addition to the interaction mode objects, the interaction object may contain the "global" object;

• global - and optional object containing parameters that are applicable for all types of interactions. Only one attribute is defined in this document:
  • ui_locales - End-User's preferred languages and scripts for the user interface, represented as a space-separated list of language tag values, ordered by preference. This attribute is OPTIONAL.

[Editor: why is this not a JSON array? Why space-separated?]

"user" Object

• exists - if present, MUST contain the JSON true value. Indicates the Client requests the GS to return a user.exists value in an Interaction Response . This attribute is OPTIONAL, and MAY be ignored by the GS.
• identifiers - REQUIRED if the exists attribute is present. The values MAY be used by the GS to improve the User experience. Contains one or more of the following identifiers for the User:
  • phone_number - contains a phone number per Section 5 of .
  • email - contains an email address per .
  • oidc - is an object containing both the "iss" and "sub" attributes from an OpenID Connect ID Token Section 2.
• claims - an optional object containing one or more assertions the Client has about the User.
  • oidc_id_token - an OpenID Connect ID Token per Section 2.
• reciprocal - indicates this Grant Request or Update is the reciprocal of another Grant. Contains the Grant URI of the reciprocal Grant.

"authorization" Object

• type - one of the following values: "oauth_scope" or "oauth_rich". This attribute is REQUIRED.
• scope - a string containing the OAuth 2.0 scope per section 3.3. MUST be included if type is "oauth_scope" or "oauth_rich".
• authorization_details - an authorization_details object per . MUST be included if type is "oauth_rich".

[Editor: details may change as the document evolves]

"authorizations" Object One or more key / value pairs, where each unique key is created by the client, and the value is an authorization object.

"claims" Object Includes one or more of the following:

• oidc - an object that contains one or both of the following objects:
  • userinfo - Claims that will be returned as a JSON object
  • id_token - Claims that will be included in the returned ID Token. If the null value, an ID Token will be returned containing no additional Claims.

The contents of the userinfo and id_token objects are Claims as defined in Section 5.

• oidc4ia - OpenID Connect for Identity Assurance claims request per .
• vc - [Editor: define how W3C Verifiable Credentials can be requested.]

"verification" Object The verification Object is used with the Verify Grant .

• nonce the Interaction Nonce received from the GS via the Completion URI. This attribute MUST only be used in the Verify Grant .

[Editor: parameters for the Client to request it wants the Grant Response signed and/or encrypted?]

Read Authorization The Client acquires an Authorization by doing an HTTP GET to the corresponding AZ URI. The GS MUST respond with a Authorization JSON document , or one of the following errors:

• TBD

from Error Responses .

Update Authorization The Client updates an Authorization by doing an HTTP PUT to the corresponding AZ URI of the following JSON. All of the following MUST be included.

• iat - the time of the response as a NumericDate.
• uri - the AZ URI.
• authorization - the new authorization requested per the Request JSON "authorization" object .

The GS MUST respond with a Authorization JSON document , or one of the following errors:

• TBD

from Error Responses .

Delete Authorization The Client deletes an Authorization by doing an HTTP DELETE to the corresponding AZ URI. The GS MUST respond with OK 200, or one of the following errors:

• TBD

from Error Responses .

GS Options The Client can get the metadata for the GS by doing an HTTP OPTIONS of the corresponding GS URI. This is the only API where the GS MAY respond to an unauthenticated request. The GS MUST respond with the the following JSON document: [Editor: this section is a work in progress]

• uri - the GS URI.
• client_authentication - an array of the Client Authentication mechanisms supported by the GS
• interactions - an array of the interaction modes supported by the GS.
• authorization - an object containing the authorizations the Client may request from the GS, if any.
  • Details TBD
• claims - an object containing the identity claims the Client may request from the GS, if any, and what public keys the claims will be signed with.
  • Details TBD
• algorithms - a list of the cryptographic algorithms supported by the GS.
• features - an object containing feature support
  • user_exists - boolean indicating if user.exists is supported.
  • authorizations - boolean indicating if a request for more than one authorization in a request is supported.

[Editor: keys used by Client to encrypt requests, or verify signed responses?] [Editor: namespace metadata for extensions?] or one of the following errors:

• TBD

from Error Responses .

Grant Options The Client can get the metadata for the Grant by doing an HTTP OPTIONS of the corresponding Grant URI. The GS MUST respond with the the following JSON document:

• verbs - an array of the HTTP verbs supported at the GS URI.

or one of the following errors:

• TBD

from Error Responses .

AuthZ Options The Client can get the metadata for the AuthZ by doing an HTTP OPTIONS of the corresponding AZ URI. The GS MUST respond with the the following JSON document:

• verbs - an array of the HTTP verbs supported at the GS URI.

or one of the following errors:

• TBD

from Error Responses .

Request Verification On receipt of a request, the GS MUST verify the following:

• TBD

GS Initiated Grant [Editor: In OAuth 2.0, all flows are initiated at the Client. If the AS wanted to initiate a flow, it redirected to the Client, that redirected back to the AS to initiate a flow. Here is a proposal to support GS initiated: authentication; just-in-time (JIT) provisioning; and authorization] initiation_uri A URI at the Client that contains no query or fragment. How the GS learns the Client initiation_uri is out of scope. The GS creates a Grant and Grant URI, and redirects the User to the initiation_uri with the query parameter "grant" and the value of Grant URI. See for the sequence diagram.

GS Responses There are three successful responses to a grant request: Grant Response, Interaction Response, or Wait Response.

Grant Response The Grant Response MUST include the following from the Response JSON

• iat
• nonce
• uri

and MAY include the following from the Response JSON

• client.handle
• authorization or authorizations
• claims
• expires_in

Example non-normative Grant Response JSON document for Example 1 in : Example non-normative Grant Response JSON document for Example 2 in :

Interaction Response The Interaction Response MUST include the following from the Response JSON

• iat
• nonce
• uri
• interaction

and MAY include the following from the Response JSON

• user
• wait

A non-normative example of an Interaction Response follows:

Wait Response The Wait Response MUST include the following from the Response JSON

• iat
• nonce
• uri
• wait

A non-normative example of Wait Response follows:

Response JSON Details of the JSON document:

• iat - the time of the response as a NumericDate.
• nonce - the nonce that was included in the Request JSON .
• uri - the Grant URI.
• wait - a numeric value representing the number of seconds the Client should want before making a Read Grant request to the Grant URI.
• expires_in - a numeric value specifying how many seconds until the Grant expires. This attribute is OPTIONAL.

"client" Object The GS may

"interaction" Object If the GS wants the Client to start the interaction, the GS MUST return an interaction object containing one or more interaction mode responses per to one or more of the interaction mode requests provided by the Client.

"user" Object

• exists - a boolean value indicating if the GS has a user with one or more of the provided identifiers in the Request user.identifiers object

"authorization" Object The authorization object contains Authorization JSON . See Grant Response for non-normative examples.

"authorizations" Object A key / value pair for each key in the client's request authorizations object, and the value is Authorization JSON .

"claims" Object The claims object is a response to the Request "claims" object .

• oidc
  • id_token - an OpenID Connect ID Token containing the Claims the User consented to be released.
  • userinfo - the Claims the User consented to be released.
  Claims are defined in Section 5.
• oidc4ia - OpenID Connect for Identity Assurance claims response per .
• vc The verified claims the user consented to be released. [Editor: details TBD]

Authorization JSON The Authorization JSON is a response to a Read AuthZ request by the Client . A subset of the Authorization JSON is included in the "authorization" object and "authorizations" list members .

• type - the type of claim request: "oauth_scope" or "oauth_rich". See the "type" object in for details. This attribute is REQUIRED.
• scope - the scopes the Client was granted authorization for. This will be all, or a subset, of what was requested. This attribute is OPTIONAL.
• authorization_details - the authorization details granted per . Included if type is "oauth_rich".
• mechanism - one of the access mechanisms: "bearer", "jose", or "jose+body". See for details. This attribute is REQUIRED.
• token - the access token for accessing an RS. This attribute is REQUIRED.
• expires_in - a numeric value specifying how many seconds until the access token expires. This attribute is OPTIONAL.
• certificate - MUST be included if the mechanism is "jose" or "jose+body". Contains the jwk header values for the Client to include in the JWS header when calling the RS using the "jose" or "jose+body" mechanisms. See .
• uri - the AZ URI. Used to refresh an authorization. This attribute is OPTIONAL.

[Editor: would an optional expiry for the Authorization be useful?] The following is a non-normative example of an Authorization JSON document:

Signing and Encryption [Editor: TBD - how response is signed and/or encrypted by the GS. Is there a generalized description, or is it mechanism specific?]

Response Verification On receipt of a response, the Client MUST verify the following:

• TBD

interaction mode Objects This document defines three interaction modes: "redirect", "indirect", and "user_code". Extensions may define additional interaction modes. The "global" attribute is reserved in the interaction object for attributes that apply to all interaction modes.

"redirect" mode A Redirect Interaction is characterized by the Client redirecting the User's browser to the GS, the GS interacting with the User, and then GS redirecting the User's browser back to the Client. The GS correlates the Grant Request with the unique authorization_uri, and the Client correlates the Grant Request with the unique redirect_uri.

request "interaction" object contains: redirect_uri a grant request request unique URI at the Client that the GS will return the User to. This attribute is REQUIRED.

response "interaction" object contains: authorization_uri a grant request request unique URI at the GS that the Client will redirect the User to. This attribute is REQUIRED.

"indirect" mode An Indirect Interaction is characterized by the Client causing the User's browser to load the short_uri at GS, the GS interacting with the User, and then the GS MAY optionally redirecting the User's Browser to a completion_uri. There is no mechanism for the GS to redirect the User's browser back to the Client. Examples of how the Client may initiate the interaction are encoding the short_uri as a code scannable by the User's mobile device, or launching a system browser from a command line interface (CLI) application. The "indirect" mode is susceptible to session fixation attacks. See TBD in the Security Considerations for details.

request "interaction" object contains: completion_uri an OPTIONAL URI that the GS will redirect the User's browser to after GS interaction.

response "interaction" object contains: short_uri the URI the Client will cause to load in the User's browser. The URI SHOULD be short enough to be easily encoded in a scannable code. [Editor: recommend a length?]

"user_code" mode An Indirect Interaction is characterized by the Client displaying a code and a URI for the User to load in a browser and then enter the code.

request "interaction" object contains: completion_uri an OPTIONAL URI that the GS will redirect the User's browser to after GS interaction.

response "interaction" object contains: code the code the Client displays to the User to enter at the display_uri. This attribute is REQUIRED. display_uri the URI the Client displays to the User to load in a browser to enter the code.

RS Access This document specifies three different mechanisms for the Client to access an RS ("bearer", "jose", and "jose+body"). The "bearer" mechanism is defined in {BearerToken}. The "jose" and "jose+body" mechanisms are proof-of-possession mechanisms and are defined in and respectively. Additional proof-of-possession mechanisms may be defined in other documents. The mechanism the Client is to use with an RS is the Response JSON authorization.mechanism attribute .

Bearer Token If the access mechanism is "bearer", then the Client accesses the RS per Section 2.1 of A non-normative example of the HTTP request headers follows:

Error Responses

• TBD

JOSE Authentication How the Client authenticates to the GS and RS are independent of each other. One mechanism can be used to authenticate to the GS, and a different mechanism to authenticate to the RS. Other documents that specify other Client authentication mechanisms will replace this section. In the JOSE Authentication Mechanism, the Client authenticates by using its private key to sign a JSON document with JWS per which results in a token using JOSE compact serialization. [Editor: are there advantages to using JSON serialization in the body?] Different instances of a Registered Client MAY have different private keys, but each instance has a certificate to bind its private key to to a public key the GS has for the Client ID. An instance of a Client will use the same private key for all signing operations. The Client and the GS MUST both use HTTP/2 () or later, and TLS 1.3 () or later, when communicating with each other. [Editor: too aggressive to mandate HTTP/2 and TLS 1.3?] The token may be included in an HTTP header, or as the HTTP message body. The following sections specify how the Client uses JOSE to authenticate to the GS and RS.

GS Access The Client authenticates to the GS by passing either a signed header parameter, or a signed message body. The following table shows the verb, uri and token location for each Client request to the GS:

request	http verb	uri	token in
Create Grant	POST	GS URI	body
Verify Grant	PATCH	Grant URI	body
Read Grant	GET	Grant URI	header
Update Grant	PUT	Grant URI	body
Delete Grant	DELETE	Grant URI	header
Read AuthZ	GET	AZ URI	header
Update AuthZ	PUT	AZ URI	body
Delete AuthZ	DELETE	AZ URI	header
GS Options	OPTIONS	GS URI	header
Grant Options	OPTIONS	Grant URI	header
AuthZ Options	OPTIONS	AZ URI	header

Authorization Header For requests with the token in the header, the JWS payload MUST contain the following attributes: iat - the time the token was created as a NumericDate. jti - a unique identifier for the token per section 4.1.7. uri - the value of the URI being called (GS URI, Grant URI, or AZ URI). verb - the HTTP verb being used in the call ("GET", "DELETE", "OPTIONS") The HTTP authorization header is set to the "jose" parameter followed by one or more white space characters, followed by the resulting token. A non-normative example of a JWS payload and the HTTP request follows: [Editor: make a real example token] GS Verification The GS MUST verify the token by:

• TBD

Signed Body For requests with the token in the body, the Client uses the Request JSON as the payload in a JWS. The resulting token is sent with the content-type set to "application/jose". A non-normative example (line breaks added to the body for readability): [Editor: make a real example token] GS Verification The GS MUST verify the token by:

• TBD

Public Key Resolution

• Registered Clients can use any of the JWS header values to direct the GS to resolve the public key matching the private key used to the Client ID. The GS MAY restrict with JWS headers a Client can use.

[Editor: would examples help here so that implementors understand the full range of options, and how an instance can have its own asymetric key pair] A non-normative example of a JOSE header for a Registered Client with a key identifier of "12":

• Dynamic Clients include their public key in the "jwk" JWS header.

A non-normative example of a JOSE header for a Dynamic Client:

RS Access In the "jose" mechanism , all Client requests to the RS include a proof-of-possession token in the HTTP authorization header. In the "jose+body" mechanism , the Client signs the JSON document in the request if the POST or PUT verbs are used, otherwise it is the same as the "jose" mechanism.

JOSE header The GS provides the Client one or more JWS header parameters and values for a a certificate, or a reference to a certificate or certificate chain, that the RS can use to resolve the public key matching the private key being used by the Client. A non-normative examples JOSE header: [Editor: this enables Dynamic Clients to make proof-of-possession API calls the same as Registered Clients.]

"jose" Mechanism The JWS payload MUST contain the following attributes: iat - the time the token was created as a NumericDate. jti - a unique identifier for the token per section 4.1.7. uri - the value of the RS URI being called. verb - the HTTP verb being used in the call token - the access token provided by the GS to the Client The HTTP authorization header is set to the "jose" parameter followed by one or more white space characters, followed by the resulting token. A non-normative example of a JWS payload and the HTTP request follows: [Editor: make a real example token] RS Verification The RS MUST verify the token by:

• verify access token is bound to the public key - include key fingerprint in access token?
• TBD

"jose+body" Mechanism The "jose+body" mechanism can only be used if the content being sent to the RS is a JSON document. Any requests not sending a message body will use the "jose" mechanism . Requests sending a message body MUST have the following JWS payload: iat - the time the token was created as a NumericDate. jti - a unique identifier for the token per section 4.1.7. uri - the value of the RS URI being called. verb - the HTTP verb being used in the call token - the access token provided by the GS to the Client body - the message body being sent to the RS A non-normative example of a JWS payload and the HTTP request follows: [Editor: make a real example token] RS Verification The RS MUST verify the token by:

• TBD

Public Key Resolution The RS has a public key for the GS that it uses to verify the certificate or certificate chain the Client includes in the JWS header.

Request Encryption [Editor: to be fleshed out] The Client encrypts a request when ??? using the GS public key returned as the ??? attribute in GS Options .

Response Signing [Editor: to be fleshed out] The Client verifies a signed response ??? using the GS public key returned as the ??? attribute in GS Options .

Response Encryption [Editor: to be fleshed out] The Client decrypts a response when ??? using the private key matching the public key included in the request as the ??? attribute in .

Extensibility This standard can be extended in a number of areas:

• Client Authentication Mechanisms
  • An extension could define other mechanisms for the Client to authenticate to the GS and/or RS such as Mutual TLS or HTTP Signing. Constrained environments could use CBOR instead of JSON, and COSE instead of JOSE, and CoAP instead of HTTP/2.
• Grant
  • An extension can define new objects in the Grant Request and Grant Response JSON.
• Top Level
  • Top level objects SHOULD only be defined to represent functionality other the existing top level objects and attributes.
• "client" Object
  • Additional information about the Client that the GS would require related to an extension.
• "user" Object
  • Additional information about the User that the GS would require related to an extension.
• "authorization" Object
  • Additional authorization schemas in addition to OAuth 2.0 scopes and RAR.
• "claims" Object
  • Additional claim schemas in addition to OpenID Connect claims and Verified Credentials.
• interaction modes
  • Additional types of interactions a Client can start with the User.
• Continuous Authentication
  • An extension could define a mechanism for the Client to regularly provide continuous authentication signals and receive responses.

[Editor: do we specify access token / handle introspection in this document, or leave that to an extension?] [Editor: do we specify access token / handle revocation in this document, or leave that to an extension?]

Rational

1. Why is there only one mechanism for the Client to authenticate with the GS? Why not support other mechanisms? Having choices requires implementers to understand which choice is preferable for them. Having one default mechanism in the document for the Client to authenticate simplifies most implementations. Deployments that have unique characteristics can select other mechanisms that are preferable in specific environments.
2. Why is the default Client authentication JOSE rather than MTLS? MTLS cannot be used today by a Dynamic Client. MTLS requires the application to have access below what is typically the application layer, that is often not available on some platforms. JOSE is done at the application layer. Many GS deployments will be an application behind a proxy performing TLS, and there are risks in the proxy passing on the results of MTLS.
3. Why is the default Client authentication JOSE rather than HTTP signing? There is currently no widely deployed open standard for HTTP signing. Additionally, HTTP signing requires passing all the relevant parts of the HTTP request to downstream services within an GS that may need to independently verify the Client identity.
4. What are the advantages of using JOSE for the Client to authenticate to the GS and a resource? Both Registered Clients and Dynamic Clients can have a private key, eliminating the public Client issues in OAuth 2.0, as a Dynamic Client can create an ephemeral key pair. Using asymetric cryptography also allows each instance of a Registered Client to have its own private key if it can obtain a certificate binding its public key to the public key the GS has for the Client. Signed tokens can be passed to downstream components in a GS or RS to enable independent verification of the Client and its request. The GS Initiated Sequence requires a URL safe parameter, and JOSE is URL safe.
5. Why does the GS not return parameters to the Client in the redirect url? Passing parameters via a browser redirection is the source of many of the security risks in OAuth 2.0. It also presents a challenge for smart devices. In this protocol, the redirection from the Client to the GS is to enable the GS to interact with the User, and the redirection back to the Client is to hand back interaction control to the Client if the redirection was a full browser redirect. Unlike OAuth 2.0, the identity of the Client is independent of the URI the GS redirects to.
6. Why is there not a UserInfo endpoint as there is with OpenID Connect? Since the Client can Read Grant at any time, it get the same functionality as the UserInfo endpoint, without the Client having to manage a separate access token and refresh token. If the Client would like additional claims, it can Update Grant, and the GS will let the Client know if an interaction is required to get any of the additional claims, which the Client can then start. [Editor: is there some other reason to have the UserInfo endpoint?]
7. Why is there still a Client ID? The GS needs an identifier to fetch the meta data associated with a Client such as the name and image to display to the User, and the policies on what a Client is allowed to do. The Client ID was used in OAuth 2.0 for the same purpose, which simplifies migration. Dynamic Clients do not have a Client ID.
8. Why have both claims and authorizations? There are use cases for each that are independent: authenticating a user and providing claims vs granting access to a resource. A request for an authorization returns an access token which may have full CRUD capabilities, while a request for a claim returns the claim about the User - with no create, update or delete capabilities. While the UserInfo endpoint in OIDC may be thought of as a resource, separating the concepts and how they are requested keeps each of them simpler in the Editor's opinion. :)
9. Why specify HTTP/2 or later and TLS 1.3 or later for Client and GS communication in ? Knowing the GS supports HTTP/2 enables a Client to set up a connection faster. HTTP/2 will be more efficient when Clients have large numbers of access tokens and are frequently refreshing them at the GS as there will be less network traffic. Mandating TLS 1.3 similarly improves the performance and security of Clients and GS when setting up a TLS connection.
10. Why do some of the JSON objects only have one child, such as the identifiers object in the user object in the Grant Request? It is difficult to forecast future use cases. Having more resolution may mean the difference between a simple extension, and a convoluted extension.
11. Why is the "iss" included in the "oidc" identifier object? Would the "sub" not be enough for the GS to identify the User? This decouples the GS from the OpenID Provider (OP). The GS identifier is the GS URI, which is the endpoint at the GS. The OP issuer identifier will likely not be the same as the GS URI. The GS may also provide claims from multiple OPs.
12. Why complicate things with interaction.keep? The common sequence has a back and forth between the Client and the GS, and the Client can update the Grant and have a new interaction. Keeping the interaction provides a more seamless user experience where the results from the first request determine subsequent requests. For example, a common pattern is to use a GS to authenticate the User at the Client, and to register the User at the Client using additional claims from the GS. The Client does not know a priori if the User is a new User, or a returning User. Asking a returning User to consent releasing claims they have already provided is a poor User experience, as is sending the User back to the GS. The Client requesting identity first enables the Client to get a response from the GS while the GS is still interacting with the User, so that the Client can request additional claims only if needed. Additionally, the claims a Client may want about a User may be dependent on some initial Claims. For example, if a User is in a particular country, additional or different Claims my be required by the Client. There are also benefits for the GS. Today, a GS usually keeps track of which claims a Client has requested for a User. Storing this information for all Clients a User uses may be undesirable for a GS that does not want to have that information about the User. Keeping the interaction allows the Client to track what information it has about the User, and the GS can remain stateless.
13. Why is there a "jose+body" RS access mechanism method for the Client? There are numerous use cases where the RS wants non-repudiation and providence of the contents of an API call. For example, the UGS Service Supplier Framework for Authentication and Authorization .
14. Why use URIs to instead of handles for the Grant and Authorization? A URI is an identifier just like a handle that can contain GS information that is opaque to the Client - so it has all the features of a handle, plus it can be the URL that is resolved to manipulate a Grant or an Authorization. As the Grant URI and AZ URI are defined to start with the GS URI, the Client (and GS) can easily determine which GS a Grant or Authorization belong to. URIs also enable a RESTful interface to the GS functionality.
15. Why use the OPTIONS verb on the GS URI? Why not use a .well-known mechanism? Having the GS URI endpoint respond to the metadata allows the GS to provide Client specific results using the same Client authentication used for other requests to the GS. It also reduces the risk of a mismatch between what the advertised metadata, and the actual metadata. A .well-known discovery mechanism may be defined to resolve from a hostname to the GS URI.
16. Why support UPDATE, DELETE, and OPTIONS verbs on the AZ URI? Maybe there are no use cases for them [that the editor knows of], but the GS can not implement, and they are available if use cases come up.
17. Why have both Client ID and Client Handle? While they both refer to a Client in the protocol, the Client ID refers to a pre-registered client,and the Client Handle is specific to an instance of a Dynamic Client. Using separate terms clearly differentiates which identifier is being presented to the GS.

Acknowledgments This draft derives many of its concepts from Justin Richer's Transactional Authorization draft . Additional thanks to Justin Richer and Annabelle Richard Backman for their strong critique of earlier drafts.

IANA Considerations [ JOSE parameter for Authorization HTTP header ] TBD

Security Considerations TBD

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Informative References The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

Document History

draft-hardt-xauth-protocol-00

• Initial version

draft-hardt-xauth-protocol-01

• text clean up
• added OIDC4IA claims
• added "jws" method for accessing a resource.
• renamed Initiation Request -> Grant Request
• renamed Initiation Response -> Interaction Response
• renamed Completion Request -> Authorization Request
• renamed Completion Response -> Grant Request
• renamed completion handle -> authorization handle
• added Authentication Request, Authentication Response, authentication handle

draft-hardt-xauth-protocol-02

• major rewrite
• handles are now URIs
• the collection of claims and authorizations are a Grant
• an Authorization is its own type
• lots of sequences added

draft-hardt-xauth-protocol-03

• fixed RO definition
• improved language in Rationals
• added user code interaction method, and aligned qrcode interaction method
• added completion_uri for code flows

draft-hardt-xauth-protocol-04

• renamed interaction uris to have purpose specific names

draft-hardt-xauth-protocol-05

• separated claims from identifiers in request user object
• simplified reciprocal grant flow
• reduced interactions to redirect and indirect
• simplified interaction parameters
• added in language for Client to verify interaction completion
• added Verify Grant API and Interaction Nonce
• replaced Refresh AuthZ with Read AuthZ. Read and refresh are same operation.

draft-hardt-xauth-protocol-06

• fixup examples to match specification

draft-hardt-xauth-protocol-07

• refactored interaction request and response syntax, and enabled interaction mode negotiation
• generation of client handle by GS for dynamic clients
• renamed title to Grant Negotiation and Authorization Protocol. Preserved draft-hardt-xauth-protocol filename to ease tracking changes.
• changed Authorizations to be key / value pairs (aka dictionary) instead of a JSON array

Comparison with OAuth 2.0 and OpenID Connect Changed Features The major changes between this protocol and OAuth 2.0 and OpenID Connect are:

• The Client allows uses a private key to authenticate in this protocol instead of the client secret in OAuth 2.0 and OpenID Connect.
• The Client initiates the protocol by making a signed request directly to the GS instead of redirecting the User to the GS.
• The Client does not pass any parameters in redirecting the User to the GS, and optionally only receives an interaction nonce in the redirection back from the GS.
• The refresh_token has been replaced with a AZ URI that both represents the authorization, and is the URI for obtaining a fresh access token.
• The Client can request identity claims to be returned independent of the ID Token. There is no UserInfo endpoint to query claims as there is in OpenID Connect.
• The GS URI is the token endpoint.

Preserved Features

• This protocol reuses the OAuth 2.0 scopes, Client IDs, and access tokens of OAuth 2.0.
• This protocol reuses the Client IDs, Claims and ID Token of OpenID Connect.
• No change is required by the Client or the RS for accessing existing bearer token protected APIs.

New Features

• A Grant represents both the user identity claims and RS access granted to the Client.
• The Client can verify, update, retrieve, and delete a Grant.
• The GS can initiate a flow by creating a Grant and redirecting the User to the Client with the Grant URI.
• The Client can discovery if a GS has a User with an identifier before the GS interacts with the User.
• The Client can request the GS to first authenticate the User and return User identity claims, and then the Client can update Grant request based on the User identity.
• Support for scannable code initiated interactions.
• Each Client instance can have its own private / public key pair.
• Highly extensible per .