OAuth2 Presentation Exchange 4 Server-to-Server

[reinkrul]

The regular OpenID4VP, for acquiring an access token given a VP from a wallet, doesn't lend itself for server to server communication. Reasons:

• It starts with the verifier (resource owner) instructing the user agent to perform a GET request to its wallet. The wallet then wants a person (the owner of the wallet) to confirm/reject the authorization request. In server-to-server exchanges, there is no person involved to make the decision. Solutions that involve linking the outer authorization code flow (access token) to the inner (OpenID4VP) are impossible, since there's no specified method of doing so.
• Authz code flow uses redirects to send the user agent back and forth, which could be parsed by a HTTP client, but it's weird and indicates the flow is not meant for programmatic user agents (HTTP clients). Furthermore, redirects could be done using HTML pragma tags or Javascript, meaning parsing becomes very involved or next to impossible.
• The extra step of acquiring a code and using it to get an access token it there to make sure the backend-application does not get hold of the access token, and only the browser gets it to perform API calls (presumably using Javascript) directly to the resource owner. In server-to-server exchanges the backend-application and user-agent are one, thus removing the need to separate these concerns.
• If we still manage to build an implementation, it's very unlikely third-party implementations of server-to-server exchanges using OpenID4VP follow the same principles, ultimately eliminating the advantage of using a standard in first place ("almost" compliant means not compliant).

A solution is to use the EBSI service-to-service flow (https://api-conformance.ebsi.eu/docs/ct/verifiable-presentation-exchange-guidelines-v3#service-to-service-token-flow), which is actually very, very much like our current OAuth2 JWT Bearer Token Grant flow to acquire an access token. Main difference is the preliminary GET request to retrieve the presentation definition and the grant type being vp_token instead of jwt-bearer.

[gerardsn]

part of #2330

[reinkrul]

Well, actually this is not OpenID4VP, but rather using a DIF Presentation Exchange as grant type in an OAuth2 flow.

[gerardsn]

Until there is an actual standard for the service-to-service flow this seems like the best solution.

---

Where should we send the vp_token?
We currently have

1. an OAuth token endpoint at /n2n/identity/{did}/token (requires mTLS(, do we verify that requests match the certificate?)) for the OpenID4VCI pre-authorized_code flow that can be found in the standardized /.well-known/oauth-authorization-server. The well-known can only define 1 token endpoint, is it fine on /n2n?
2. a custom token endpoint at n2n/auth/v1/accesstoken for the semi-custom jwt-bearer flow that is found as service on the DID document.

The grant_type=vp_token is a custom flow.
Do we care about mixing the custom flow with "official" oauth token endpoint for a DID (option 1)? If not, should/can the endpoint move away from /n2n/?
Or, do we use reuse (option 2)/add a new (option x) custom access token endpoint? If so, how will it be found?

[gerardsn]

Well, actually this is not OpenID4VP, but rather using a DIF Presentation Exchange as grant type in an OAuth2 flow.

I suppose that is true. Defining a new flow/grant_type inspired by the OpenID4VP spec.

[woutslakhorst]

The grant_type=vp_token is a custom flow.
Do we care about mixing the custom flow with "official" oauth token endpoint for a DID (option 1)? If not, should/can the endpoint move away from /n2n/?
Or, do we use reuse (option 2)/add a new (option x) custom access token endpoint? If so, how will it be found?

Let's try to put it on the generic public /token endpoint.

This would generate some security considerations:

• DOS (lvl4 rate limit per IP)
• replay prevention (proper nonce storage)

A very efficient /token endpoint would help a lot.

[reinkrul]

Thread on W3C credentials mailing list regarding standardization: https://lists.w3.org/Archives/Public/public-credentials/2023Aug/0007.html

[reinkrul]

Implementation iisue: nuts-foundation/nuts-specification#265

Closing this one.