DPoP and acceptance tokens

[Oliver Terbu]

Some people might want to use DPoP with OpenID for Credential Issuance. In case a client used a DPoP key with the token endpoint to get an access token for the credential endpoint that results in an acceptance token, is the client expected to use the same DPoP key with the deferred credential endpoint (and the acceptance token) since the acceptance token is also sent as a bearer token in the authorization header?

[Oliver Terbu]

IMO, the client must use the same DPoP key. For that reason, it might be worth rephrasing the current spec text that defines the `acceptance_token`.

The current spec says:

acceptance_token: OPTIONAL. A JSON string containing a token subsequently used to obtain a Credential. MUST be present when credential is not returned.

I’d suggest to change the text, so that the `acceptance_token` becomes an Access Token for the deferred credential endpoint, so that it is compatible with the DPoP text. Are there any concerns with that?

‌

[Oliver Terbu]

Alternatively, we could say that the acceptance_token becomes A new Access Token for all subsequent requests (including refresh) but then we would need to change more parts of the specification.

[Oliver Terbu]

Alternatively, the client would still send the orginal access token and would send the acceptance token in the payload as a request parameter.

[Nikos Fotiou]

I agree that the client must use the same DPoP key, otherwise we may end up in a downgrade attack. In addition to what Oliver says, IMHO it should be mentioned something like “if an access token is bound to a public key, e.g, using a mechanisms described in Section 6 of https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop , then the acceptance_token MUST also be bound to the same key”.

[Kristina Yasuda]

Binding Acceptance token to the same DPoP key as Access Token (approach A) is I think the simplest approach and I agree with the text proposed by Nikos.

Using `acceptance_token`as an Access Token for the deferred credential endpoint (approach B) does not really make sense to me it might add significant complexity..

@Daniel Fett Are there any possible security concerns with either of the approacheds?

‌

[Torsten Lodderstedt]

I suggest to change the endpoint to use access tokens and turn the acceptance token into a ' transaction_id`. That way DPoP could be used to protect the deferred issuance as well. Here is an example:

POST /credential_deferred HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW

transaction_id=8xLOxBtZp8

‌

[Oliver Terbu]

I agree with @tlodderstedt . That is also my preferred solution.

[Kristina Yasuda]

Assuming definition of acceptance_token and a transaction_id is the same, is the rationale of renaming to clarify its function?

[Kristina Yasuda]

to change the endpoint to use access tokens

actually, if we do this, I would like to merge deferred endpoint functionality into the credential endpoint. Credential endpoint already supports access tokens.

[Kristina Yasuda]

Security Analysis seem to recommend using Access Token at the deferred endpoint: openid / connect / Pull Request #468: First draft of OpenID 4 VC Security Analysis — Bitbucket

[Kristina Yasuda]

Having read the security analysis PR, I am in strong favor of merging the deferred endpoint functionality into Credential/Batch Endpoints to decrease attack surface (mix-up attacks).

[Torsten Lodderstedt]

Can you please describe why merging the deferred endpoint reduces the attack surface?

[Kristina Yasuda]

this part in the security analysis.

**ATTACK**: An attacker can configure Mix-Up 1a. The attacker receives

an acceptance token from the Wallet's request to the deferred credential

endpoint and uses it to obtain a credential from the deferred

credential endpoint of the honest server. *Potential solution:* The

credential endpoint and batch credential endpoint can only be accessed

by using an access token. Can DPoP or MTLS be enforced for an acceptance

token? Better to use access token instead.

Mix-up 1a being :

• `credential_issuer`: Attacker's Credential Issuer Identifier

• `authorization_server`: Honest Issuer's Authorization Server

• `credential_endpoint` Honest Issuer's Authorization Server

• `batch_credential_endpoint`: Honest Issuer's Authorization Server

• `deferred_credential_endpoint`: attacker-controlled.

‌

[Torsten Lodderstedt]

The recommendation is to require an access token, right? I did PR #472 to do so.

[Oliver Terbu]

If we merge PR #472, this would solve this issue.

[Kristina Yasuda]

PR exists - have discussed during multiple SIOP calls

[Kristina Yasuda]

PR #472 merged