[Openid-specs-ab] Issue #1374: Credential Issuance: OAuth 2.0 Token Exchange compatibility (openid/connect)

[Thomas Bellebaum]

New issue 1374: Credential Issuance: OAuth 2.0 Token Exchange compatibility
https://bitbucket.org/openid/connect/issues/1374/credential-issuance-oauth-20-token

Thomas Bellebaum:

Moved to here from Github.  
  
The draft specifies a method for effectively exchanging an access token \(and optionally some verifiable presentations\) for a verifiable credential at a new credential endpoint \(Resulting in Step 7 in the diagram\).

This functionality is somewhat related to [OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/rfc8693/), where security tokens \(of any type\) are exchanged for new security tokens \(of any type\).

Some important differences:

* **Different request parameters**: The request parameters for the Credential- and Token-exchange mechanisms are quite different, though there is a natural mapping for the most part.
* **No distinction between** `format` and `type`: We would either need to define additional parameters, or define a general URI scheme, like appending the format to the type \(see example below\)

Is it possible to build the Issuance procedure on top of Token Exchange?  
If it was, it would probably be much simpler to generalize the mechanism from OpenID to general OAuth.

Here is what I think such a request could look like \(encoding omitted and additional line breaks included for readability\):

```http request
POST /token HTTP/1.1
Host: server.example.org
Content-Type: application/x-www-form-urlencoded
Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:<something>:<something>:health_card:ldp_vc
&subject_token_type=urn:<something>:<something>:proof-of-posession
&subject_token={...}
```

The subject security token would be something along the lines of the proof parameter in the current draft, including the `verificationMethod` \(representing `did` or `sub_jwk`\):

```json
{
  "type": "RsaSignature2018",
  "created": "2018-09-14T21:19:10Z",
  "proofPurpose": "authentication",
  "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21/keys/1",
  "challenge": "2H4dB9xl-FZQL-pixV-WJk0eOt4CXQ-1NXKW",
  "domain": "<https://issuer.example.com",>
  "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..l9d0YHjcFAH2H4dB9xlWFZQLUpixVCWJk0eOt4CXQe1NXKWZwmhmn9OQp6YxX0a2LffegtYESTCJEoGVXLqWAA",
}
```

In the response, the `credential` resp. `acceptance token` is conveyed in the `access_token` parameter. As Token Exchange explains, this is for backwards compatibility. The type is indicated by the `issued_token_type` parameter. The `c_nonce` and `c_nonce_expires_in` parameters would have to be added to this endpoint, but the current draft does this anyways at the token endpoint.