+-------------+
| Device      |       
| +--------+  |                                         +-----------+
| |        |-------- Login & Authorization (1)--------->|           |
| |        |  |                                         |           |
| |  App   |<------ ACDC for app- (2)-------------------|           |
| |        |  |                                         |    AS 1   |
| |        |  |                                         |           |
| |        |  |                                         |           |
| |        |  |                                         |           |
| |        |  |                                         +-----------+
| |        |  |                                            
| |        |  |                                             
| |        |  |                                         +-----------+
| |        |---- Request Secondary tokens for app (3)-->|           |
| |        |  |                                         |   AS 2    | 
| |        |<-------Secondary Tokens for apps (4)-------|           |
| |        |  |                                         +-----------+
| |        |  |                                           /\    /\
| |        |  |                                            |     |
| |        |  |                                       Validate tokens (6)
| |        |  |                                            |     | 
| |        |  |                                          +---------+
| |        | -|--------- API Call with token (5)-------> |  RS2    |
| +--------+  |                                          +---------+
+-------------+                                         
                                          
            

Figure 1

1. The client requests a ACDC grant using the acdc responce_type. The client also sends a PKCE challenge. The client may also include the Audience paramater (aud), to indicate the token_endpoint it intends to exchange the acdc at.
2. The ACDC token is returned to the client in the acdc paramater.
3. The client exchanges the acdc and PKCE verifier at the token endpoint identified by the aud paramater from (1).
4. The client receives access token and optional refresh token from AS2.
5. The client accesses the resource server.

Note: the token validation of Step 6 may require a call to the issuing AS (as shown) or may be achieved locally via a digital signarture verification.

3. Deployment Models

ACDC tokens can be obtained in two ways:

1. From the authorization endpoint using the acdc response type.
2. From the token endpoint by using the refresh token grant type and including the PKCE paramater code_challange and 'aud' to indicate the intended audience.

4. Audience

When an authorization server creates a ACDC token, it needs to indicate what token_endpoint it will be used at.

This section defines a new paramater that is used by the client to indicate what protected resource at which resource server it wants to access if requesting a access token, or which token_endpoint if requesting a ACDC grant. This information may subsequently also communicated by the authorization server securely to the resource server, for example within the audience field of the access token or ACDC token.

4.1. Audience Parameter: Token Endpoint

The client constructs the ACDC token request to the token endpoint by adding the 'aud' parameter using the "application/x-www-form-urlencoded" format with a character encoding of UTF-8 in the HTTP request entity-body.

The URI included in the aud parameter MUST be an absolute URI as defined by Section 4.3 of [RFC3986]. It MAY include an "application/x-www-form-urlencoded" formatted query component (Section 3.4 of [RFC3986] ). The URI MUST NOT include a fragment component.

The ABNF syntax for the 'aud' element is defined in Appendix C.

If requesting a code or acdc token the value of the 'aud' paramater MUST be the absolute URI of the token_endpoint that the resulting token is to be presented to. Failing to provide the propper URI may cause the token to be rejected by the token_endpoint.

4.2. Audience Parameter: Authorization Endpoint

The client constructs the ACDC token request to the authorization endpoint by adding the 'aud' parameter to the query string of the authorization request.

The URI included in the aud parameter MUST be an absolute URI as defined by Section 4.3 of [RFC3986]. It MAY include an "application/x-www-form-urlencoded" formatted query component (Section 3.4 of [RFC3986] ). The URI MUST NOT include a fragment component.

The ABNF syntax for the 'aud' element is defined in Appendix C.

If requesting a acdc token the value of the 'aud' paramater MUST be the absolute URI of the token_endpoint that the resulting token is to be presented to. Failing to provide the propper URI may cause the token to be rejected by the token_endpoint.

5. ACDC Token Response Type

This section registers a new Response Type, the acdc , in accordance with the stipulations in the OAuth 2.0 specification, Section 8.4. The intended purpose of the acdc is that it MUST provide an assertion of the scopes authorized by the Resource Owner as understood by the Authorization Server. The assertion MUST specify a targeted audience, e.g. the target AS and SHOULD contain the identity of the Resource Owner as understood by the Authorization Server.

6. ACDC Grant type

This section registers a new Grant Type, the urn:ietf:params:oauth:grant-type:jwt-acdc

This isa profile of the JWT Authorization grant defined in Sec 4 of [RFC7523]

6.1. ACDC Grant type processing

JWT authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with a JWT authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server. However, if client credentials are present in the request, the authorization server MUST validate them.

The cnf element MUST be present in the JWT. The default confirmation method is PKCE. Other Proof of possession methods may be defined as extensions, but are out of scope for this document.

The pkce element is present in the JWT, the AS must require the code_verifyer to be present in the request and validate it according to the PKCE [I-D.ietf-oauth-spop] specification.

If the JWT is not valid, or the current time is not within the token's valid time window for use, the authorization server constructs an error response as defined in OAuth 2.0 [RFC6749]. The value of the "error" parameter MUST be the "invalid_grant" error code. The authorization server MAY include additional information regarding the reasons the JWT was considered invalid using the "error_description" or "error_uri" parameters.

For example:

   
HTTP/1.1 400 Bad Request
     Content-Type: application/json
     Cache-Control: no-store

     {
      "error":"invalid_grant",
      "error_description":"Audience validation failed"
     }
                
            

  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "azp": "client-ID",
   "aud": "https://server.partner.com",
   "exp": 1311281970,
   "iat": 1311280970,
   "sid": "Work iPhone",
   "cnf":{ "code_challange" : "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM",
          "code_challange_method" : "S256" },
   "scopes" : [ "scope1" , "scope2" ]
  }