Proposal for OpenID 4 VP profile for the W3C Digital Credentials API

[tlodderstedt]

Here is a first proposal of how an profile of OpenID 4 VP for the W3C Digital Credentials API (aka Browser API) could look like.

https://docs.google.com/document/d/1A10PZ_DviMJeyy2mDFt2QLcXUbT4O2dc_BizNXAD2PQ/edit

Please review and comment on the document.

Please comment on this issue whether you think the DCP WG should be a new DCP WG item (i.e. a new specification).

[tlodderstedt]

Hi all,

I extended the proposal to have two modes now:

• “platform trust management mode”: In order to also have an easy to use option for those applications not obliged to follow a regulation, a mode utilizing the web platform trust model is also envisioned.
• “external trust management mode”: This mode allows application obliqued to follow requirements for RP Authentication that cannot be met based on the platform mechanism to use signed requests and provide additional data with the request (e.g. in the form of x.509 Certificates or Trust Chains).

I also cited relevant requirements from the eIDAS regulation (as an example).

[tlodderstedt]

I just added an alternative approach to the document. It uses existing OpenID 4 VP messages. This allows to use signed requests in a secure fashion without the need to extend the W3C Digital Credentials API.

[tlodderstedt]

I reworked the proposal to use existing OID4VP messages. That makes the proposal easier to implement for existing implementers and more powerful (it leverages existing OID4VP security mechanisms on top of Browser API).

[jogu]

We discussed the latest proposal in the google doc in today's working group call.

For the people present on today's call, there was unanimous consensus to raise a PR, but not to merge the PR before implementer's draft 3 (to make sure we don't publish it when it may not be ready / to avoid holding up ID3 for it).

We'll raise again on Tuesday's call to let people not present today to offer their opinions too.

[selfissued]

Is the goal for this to be a new specification or to be added to OpenID4VP? I'm asking, in part, because if it's going to be a new specification, we'll need to contribute the specification to the working group and then run a call for adoption.

[c2bo]

Is the goal for this to be a new specification or to be added to OpenID4VP? I'm asking, in part, because if it's going to be a new specification, we'll need to contribute the specification to the working group and then run a call for adoption.

The proposal on yesterday's call was to add this to OpenID4VP as an appendix if I remember correctly.

[jogu]

Yes, what Christian says is correct - the proposal in the circulated agenda & discussed on yesterday's call was adding the browser API as an appendix in the VP spec rather than a brand new specification, hence the suggested next step of a PR which would add it to the VP sec.

The rational was essentially that the latest proposal is pretty small so would fit well in an appendix, and there is a very tight link (mainly in the examples) to the main spec so keeping them together helps at least for now. (I don't think this commits us to a permanent position, if this approach turns out to be a flaw we can separate it out into a separate spec in the future.)

[tlodderstedt]

I re-added response_type and response_mode in order to be as close as possible to the OID4VP as is. Only redirect_uri does not make sense for the profile and should be omitted by the RP and, if present, be ignored by the Wallet.

[jogu]

We discussed this again on today's working group call. There was some discussion about the final details but a consensus on moving forward with creating a PR to add Torsten's current draft as an appendix to the OID4VP spec. So we know have a consensus from both the APAC & EU friendly calls to go ahead with a PR so I've marked this 'ready for pr'.

[Sakurann]

in person mtg: "review/merge PR" cc @leecam