Closed reinkrul closed 11 months ago
part of #2330
Well, actually this is not OpenID4VP, but rather using a DIF Presentation Exchange as grant type in an OAuth2 flow.
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
/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
?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?
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.
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:
A very efficient /token endpoint would help a lot.
Thread on W3C credentials mailing list regarding standardization: https://lists.w3.org/Archives/Public/public-credentials/2023Aug/0007.html
Implementation iisue: https://github.com/nuts-foundation/nuts-specification/pull/265
Closing this one.
The regular OpenID4VP, for acquiring an access token given a VP from a wallet, doesn't lend itself for server to server communication. Reasons:
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 ofjwt-bearer
.