OID4VP - determining which VCs are required

[David W Chadwick]

The first version of the OpenID4VPs spec referred to DIF PEv1 as the only allowed way for the RP to request a set of VCs from the wallet. This was subsequently changed to mandate DIF PEv2. Now DIF are working on PEv3. Furthermore W3C has its own draft Presentation Request specification (see https://w3c-ccg.github.io/vp-request-spec/), but this specification cannot be used with the current OpenID4VPs spec.

It is not tenable for the OpenID4VPs spec to mandate one particular way of requesting a set of VCs, especially when that one way is neither long lived nor stable, and when competing methods are being standardised.

The proposal is that we replace the presentation_definition parameter with a type and a value, where the type is a URI that indicates the presentation request syntax and the value is the presentation request in that syntax. We give example URIs for PEv1, PEv2, PEv3 and W3C PR and provide a couple of request examples in different syntaxes.

[Kristina Yasuda]

I am absolutely against this. This would significantly prevent interoperability of a basic request response protocol.

Few of us warned Presentation Exchange not to cut v2.0 because it did not have enough implementation experience, had several important issues open and was not ready to be published as a stable version. It happened nevertheless.

If PE goes to v3, i would be in favor of dropping using presentation exchange as defined in DIF at all and define a stable query language in OpenID4VP spec. It no doubt will be inspired by PE, but very likely will not use JSON.Path, for example. My only worry is introducing a large breaking change into a spec that many people are actively implementing in larger scale.

So despite PEv3 work, I think we should keep PEv2 in the spec - it is not perfect, but does the job and I doubt PEv3 will be simpler than v2 or will drop JSON path.

[Torsten Lodderstedt]

I strongly object this proposal.

The query language is at the heart of the OID4VP protocol. The purpose of OID4VP is to allow request and presentation of VCs in an interoperable manner across credential formats. Making the query language replaceable defeats this purpose and prevents any interoperability on the protocol layer.

So yes, it is absolutely tenable to use a certain query language. I would go as far as to say, it is required. At least if interoperability is what we are looking for.

wrt PE v3: The OID4VP spec normatively references “Presentation Exchange 2.0.0”. So PE 2.0.0 will be the query language (independent of what happens at DIF) up until we decide to change it.

[David W Chadwick]

Our existing protocols are full of options that inhibit interop. The use of DIDs, of which there are hundreds, is just one example. Allowing alternatives to OID4VP in OID4VCI is another example. So you argue for flexibility and the big tent approach previously when it suits you, but against it now when it does not. Please let us be consistent. A standard can be all encompassing and support different standards, and then profiles will be selected by different groups of users to narrow down all the possible options to one preferred set. By arguing against this approach for the presentation_definition parameter you are actively discouraging some groups from adopting OID4VPs i.e. those that prefer an alternative to DIF PEv2.

[Torsten Lodderstedt]

Standards always need to find a balance between flexibility and interoperability.

The best solution from interoperability perspective would be to define a single protocol supporting exactly one credential format, one signature algorithm, one key management approach (e.g. a certain DID method) and one trust management approach. However given the current situation in the decentralized identity market, that would minimize our chance of adoption. Hyperledger Indy tried it with AnonCreds, CL signatures, link secrets, did:sov and saw some adoption but no breakthrough.

We decided to focus on solving interoperability for a single aspect first: the request and presentation of VCs and leave credential format, signature algorithms, key management and trust management approaches extension points. This combination of request/response interoperability combined with flexibility in the other areas resulted in an amazing adoption of the spec. So I don’t see a compelling reason to drop this last piece of interoperability.

I assume there will be profiles of OID4VP going forward that limit the options in certain domains. We, for example, work on such a profile for the IDunion community in Germany. I hope we will see a reduction of options in the future, which would make interoperability much easier, but that is still a long way to go.

wrt OID4VP in OID4VCI: OID4VCI aims at defining an interoperable interface between Wallet and Issuer. I don’t see how the approach the Issuer chooses to obtain further identity claims about the user in the course of the authorization process affects this interoperability. A request by the Issuer towards the Wallet with OID4VP depends on whether the Wallet supports OID4VP and whether the Issuer requires VCs for a certain process. If it needs to lookup a central registry, it will use a different protocol. But thanks to the design of OID4VCI on top of OAuth, the issuer is free to do whatever is needed as it controls the user interface.

[David W Chadwick]

wrt OID4VP in OID4VCI: OID4VCI

This is a separate issue that still has not been properly resolved (even though the PR has been merged) so let's keep that discussion there (PR#291).

[David W Chadwick]

I am concerned that we are building an immutable standard on shifting sand i.e. OID4VP on DIF PEv2. What happens if our standard is published and we subsequently decide that PEv2 is not the best solution and want to migrate to something else? How do we do that? How do wallets and RPs interact when one supports PEv2 and other the new better method? We can build future proofing in now by having a type and value, by recommending that implementations SHOULD use the type PEv2, but then we have an easy way of migrating in the future to another type. Then for free, we also allow W3C folk who wish to use Presentation Request now to do so if they wish, thereby increasing the size of the OID4VP tent.

[Kristina Yasuda]

also, talked to several people in DIF, no one had the understanding that the work on Presentation Exchange v3.0 is starting. i think there will be maintenance work around PEv2, but there seems to be a long way before PE goes to v3.

[Kristina Yasuda]

OpenID4VP needed a solution for the query language. We tried using claims parameter, native to OIDC, but that was not sufficient. There was no better solution, so PEv2 was adopted. I understand the flaws of the PE and not it’s biggest fan at all, but there is still no better alternative... I do not want to reinvent the wheel.

I am concerned that we are building an immutable standard on shifting sand i.e. OID4VP on DIF PEv2

I understand the concern, but I think we need further implementation experience to come in before we know if it is a shifting sand or not. Presentation Exchange v2 should be a requirement until than.

‌

[Kristina Yasuda]

Can we come back to the topic when PE v3 actually starts or we hear about a fundamental flaw in PE v2 from the implementers and close this issue for now?

[Kristina Yasuda]

closing as there is no action we can take right away. might have to re-open this later.

[David W Chadwick]

This issue is greater than which version of PE to use. As stated in the intro there is also the W3C Presentation Request specification to consider. This is why I think the OID4VP protocol should allow the request query format to be specified and allow implementors to choose the one they want to use in their profile of OID4VP. Ultimately the market will decide which request query format becomes the predominant one.