[Openid-specs-digital-credentials-protocols] Moving OpenID4VCI & VP specs to final / EU wallet implementing acts

[Joseph Heenan]

Hi all

TL;DR The chairs/editors are suggesting a strategy where we accelerate our timelines for getting OID4VC to final towards the end of this year so that they can be listed as required specifications in EU law.

Full version:

We had discussions about the status of the OpenID for Verifiable Credential Issuance & Verifiable Presentation at the working group meetings last week, particularly with reference to the EU wallet implementing acts - the aim of this email is to make sure anyone that couldn’t attend last week’s meetings knows what’s going on and has a chance to ask questions & share their feedback.

For those that don’t know the first revision of the implementing acts for EU wallets is open for feedback:

https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives_en?text=European Digital Identity Wallets <https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives_en?text=European%20Digital%20Identity%20Wallets>
Of particular note is that the "European Digital Identity Wallets – protocols and interfaces to be supported” document only mentions ISO/IEC 18013-5:2021 (i.e. in person presentment of mobile driving licenses).

The chairs investigated why the OpenID4VC specifications aren’t listed there and it turns out that specifications can only be included in the law if they are final issued standards.

It is hopefully uncontroversial to say that it would be good for the OID4VC specifications to be listed in the EU laws as soon as possible, particularly as they form key parts of the EU wallet architecture reference framework.

Timeline wise, it seems we already missed the window to be included in the first drafts, however the acts are expected to be reopened in the first half of 2025, and the advice we were given is that to get into that revision the specs would need to go to final by the end of this year (as there’s a few months of process that needs to be completed before they could go into the draft laws).

Working backwards from having the specs published as final at the end of the year, there is a 7 day voting period, a 60 day public review period, a working group last call of at least 7 days, and a policy of PRs being open for a week before they are merged.

This doesn’t give us much time to actually do much normative work on the specifications, a matter of a few weeks. (Non-normative, i.e. editorial, changes can happen later, for example during the public review period, or even after that in errata).

Hence we need to very carefully prioritize the work we need to progress over the next 2 weeks.  The suggested strategy is to ensure that any known required breaking changes are made and extensibility points added, such that the 1.0 specification can be followed by a (non-breaking) 1.1 update that adds some of the things we know are required. [In this context, non-breaking means existing implementations won’t find themselves out of compliance, e.g. generally adding new, optional, features.] And that would likely be followed up later by a 2.0 that takes learnings from people implementing 1.x and does make some breaking changes.

(There is precedence for these kinds of moves to final within OIDF, for example the FAPI working group did something similar with FAPI 1.0 due to various governments wanting to name FAPI in laws.)

With that in mind, a suggested prioritization was developed, and refined at the working group meetings last week.

The diagram is here:

https://excalidraw.com/#json=k63kh1p2gfImq7DKgxyVt,wtfYkmr6jgiXypb0CzFmRg

(And also a static image below)

There are a number of items in red that are the items we do believe need to progress before final as they’re breaking changes and/or enable further changes to be made in 1.1 without them being breaking.

There are some items in green that are seen as strategic risks and need a bit more thought/investigation:

 There are some requirements from the ISO mDL WG around the browser API profile that might be breaking changes (https://github.com/openid/OpenID4VP/issues/248 is the biggest one and we plan to discuss on tomorrow’s WG Call).
Issues around the deferred endpoint - we need to either fix the things that require breaking changes, or the backup plan would be to temporarily remove deferred for 1.0 and add it back in 1.1 (adding it in 1.1 would be a non-breaking changing, but we couldn’t publish as is and fix it in 1.1 as that would be a breaking change).
There are some concerns around including versioning in the protocols, but we currently believe if these need to be addressed (it’s not an approach typically used in OAuth/OpenID protocols) they could be addressed post 1.0.
Breaking changes around parsing improvements to display in the issuer metadata


Everything else (yellow boxes) we really want to include but there is simply not time to progress them and get implementation feedback & refine them in the next few weeks, hence we’ve focussed on trying to make sure we’re in a position to add them as non-breaking changes in a 1.1 revision, on the basis that it should be easy to get 1.1 referenced (instead of 1.0) in a future revision of the EU implementing acts.

We understand some people will be disappointed that some things aren’t in 1.0 (particularly the new query language) but we’ve not been able to come up with a realistic plan that would ensure a version of OID4VCI/VP that has the new query language finalized and has a good chance of being included in the next revision of the implementing acts, so this plan seems like the best option. We would encourage anyone keen to see the query language or other changes moving quickly to ensure they’ve given feedback on the relevant issues/PR, especially if they have or are willing to try implementing & taking part in interop testing of the proposals.

Any questions, please get in touch with myself or one of the other chairs/editors, or join one of the working group meetings this week, or reply on the mailing list. We’d plan to try and get consensus on moving forward with this plan during the working group calls this week.

Many thanks

Joseph





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240909/17c63a14/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcp-wg-oid4vc-priorities-for-final.png
Type: image/png
Size: 448054 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240909/17c63a14/attachment-0001.png>