OID4VP support

[marsouin]

Hi!
Thanks for the fantastic work here, this is exactly the kind of lower-level implementation that is needed, without dependancies like express ;)
Any plans to implement OID4VP? Is there a way we can contribute?
Also wondering if you plan to support other verifications methods apart from did and jwk, typically JWT VC Issuer Metadata as per the IETF spec?

[TimoGlastra]

Hey! Apologie for the late reply, I didn't have notifications enabled yet on this repository :)

Yes the idea is definitely to add OID4VP, it's on our todo list for the coming weeks/months, and will be part of the effort in support the latest draft 23 of OID4VP.

We currently still depend on https://github.com/Sphereon-Opensource/OID4VC/tree/develop/packages/siop-oid4vp and will use that as a basis for some parts (mainly the JARM pieces).

Some things we need to determine:

• which draft versions do we need to support of OID4VP?

Regarding the verification methods, this seems like a concern of the credential format implementation (which this library purposefully does not handle to avoid complexities in dealing with credential formats). How would you like to see this integrated?

[TimoGlastra]

For contributions, yes these are definitely welcome, but we'll also start working on the OID4VP part and so we should coordinate on design and tasks first (we have quite some idea on what this library should/shouldn't do).

We're in the process of contributing this library to OWF (https://github.com/openwallet-foundation) and having other maintainers / contributors will make the project stronger.

[marsouin]

Hey :) No worries.

I was thinking of aiming for support of draft 23 and go from there. At first we were going to work with the Sphereon packages but it's opinionated (for instance we'd like to be able to define the routes outside of the package).

In terms of verification methods, you are right, it's out of scope of the spec, but the lib should provide a method to validate the vp_token.

Amazing to contribute this to OWF. I'm happy to hop on a call this week if you want to discuss tasks and how you want to do things.

[TimoGlastra]

I was thinking of aiming for support of draft 23 and go from there. At first we were going to work with the Sphereon packages but it's opinionated (for instance we'd like to be able to define the routes outside of the package).

Yes that probably makes sense. For us we probably need to support at least draft 21, 22, 23 as we already have oid4vp deployed in production.

The approach we took for OID4VCI is that all code assumes draft 14 (the latest supported version), and then we use valibot transformers to transform old drafts to new and vice versa. In most cases this works and means we don't have to deal with a lot of different versions within the code.

I think a similar strategy could be used here.

In terms of verification methods, you are right, it's out of scope of the spec, but the lib should provide a method to validate the vp_token.

Yes agreed! We will probably just parse the vp_token value but don't decode any of the credential values. So the callback will get the vp_token entry (string or object) with the presentation submission entry / DCQL entry and should return something like:

• verified (i would like to make this an object so it can include separate checks whether isExpired: false, isRevoked: false, etc..).
• decoded payload.

The decoded payload can then be used for the presentation exchange and DCQL matching. (You can see some examples of the input DCQL needs here: https://github.com/auer-martin/dcql/blob/main/dcql/src/dcql-query/dcql-query-complex.test.ts). For PEX we probably need some additional metadata

One thing I'm not sure about is what we want to do for PEX. We can leverage the Sphereon PEX library but this library does implement all credential formats, so then we do add in a lot of dependencies on w3c vcs / mdoc / sd-jwt vc. We've been thinking of creating a PEX light (which behaves very similar to https://github.com/auer-martin/dcql) but for a first pass we might want to rely on PEX and swap out the PEX implementation later (depending on how soon it will be removed from the OID4VP spec).

[marsouin]

I agree on everything :)
About PEX, I love the objective of staying lightweight. We should also probably only support PEX v2. But I agree this might be time consuming at first so we can simply use the Sphereon lib and code it in a way that makes it easy to switch to another implementation.