Moving to a Credential Format specific query language in OID4VP

[Kristina Yasuda]

Based on the discussion in the IIW regarding credential presentation request syntax (query language), there seems to be consensus to move towards a format specific request syntax from a general one, which means dropping the usage of PE. Originally, PE was chosen because it was the best option out there, and this choice not only allowed editors to focus on other aspects of the protocol, but also to onboard DIF community members. However, as OID4VP matures, the voices that “we can do better“ in terms of a query language has been growing.

Some rationale behind moving to a credential specific request syntax

1. PE is powerful, but is too verbose. Can be a barrier to adoption.
2. usage of JSON.Path in PE has security implications. some implementers of OID4VP use PE without JSON.Path, with simple string matching already.
3. Credential format specific approach in OID4VCI has been working well - simple and extensible enough.
4. potentially a better alignment with browser API built by Google(/Apple)

First sketches of a credential format specific request syntax discussed by the editors are:

• Authorization req asks only for one VC by default
• Authz res returns a request for the next VC if more than 1 VCs are needed to be presented

• A use-case where more than one VC is requested in the authz req is when the verifier is requesting presentation of one credential with a certain attribute out all several options (e.g. give me age claim either from driving licence or passport or …) 

  1. Need to find out if this is the only use-case for the multiple credentials

The point of this issue is to

a) get consensus if the WG thinks it is a good idea to move to a format specific syntax. It will be a significant breaking change in OID4VP ID3.

b) agree on the requirements for a credential format specific request syntax.

‌

[Kristina Yasuda]

one requirement that our implementation has around biometrics-based holder binding is “present to me VC1 only if a biometrics-based matching using VC2 is successful (no need to return VC2 itself)“. which I think is another case when requesting multiple credentials in one request is important

[Sam Goto]

I wouldn’t reach the conclusion that format-specific query languages necessarily leads to “better alignment with browser API built by Google(/Apple)”: we are not particularly proud of the format-specific query language that we came up with, and would be happy to change to something better if you could point us to something that works better. So far, the mental model has been that “Presentation Exchange is probably too complex and unnecessarily expressive“ but also that “Format-specific query languages doesn’t sound ideal either“. Maybe there is a sweet spot somewhere between these extremes.

FWIW, here are some examples of what having format-specific query languages would lead to [1], and while I think it could buy us some time (and autonomy for each format type to innovate independently), I think we’d find some convergence long term (e.g. specifically wrt to things like optionality, inclusion, predicates, etc).

[1]
https://github.com/agl/identity-credential#examples

‌

[Kristina Yasuda]

yeap that’s why I said “potentially“ :P when you say “we’d find some convergence long term“, do you mean in terms of converging to one credential format?

[David W Chadwick]

I have been arguing for ages (in several previous issues) that tying the OID4VP protocol to PEv2 was fundamentally wrong. Moving to a credential specific format is an improvement on this, but is not the best option. Rather we should allow the verifier to identify the particular query language that it wants to use, and then use that language. In this way, a default specific format can be used, or PEv2 or W3C CCG Verifiable Presentation Request or something better that is invented in the future. In this way OID4VP is made independent of the query language. The verifier (and holder) choose from the best of breed that is available at any point in time. The latter can evolve as implementation experience improves without needing to update OID4VP each time we change our mind (as we have already done by moving from PEv1 to PEv2 and now to something else)

[Sam Goto]

when you say “we’d find some convergence long term“, do you mean in terms of converging to one credential format?

I mean in terms of “converging on the query language”, not “converging on the format”. My intuition is that formats (MDocs and VCs, specifically) are always going to co-exist long term.

[Kim Duffy]

I agree with the concerns that PE is complex, but (for better or for worse) over the last year I’ve attempted to chip away at it and simplify. We’ve made good headway, culminating in PEv2, which separated out the less precise/less testable aspects as “features”. This resulted in a noticeably more approachable and layered spec. I believe many of the requests, which we factored in (and adopted) originated from the OID4VP group, in fact.

There are remaining issues to sort out, and I agree that the blanket JSONPath dependency is higher priority among these. Within the PE working group, we’ve already been discussing this, but want to gather more information first. While we’re open to removing/replacing it, we’ve also discussed supporting a subset of its capabilities (at least in a layered manner, as is our current model).

If the OID4VP participants are interested in continuing to promote alignment of these standards, we’d be more than happy to take detailed input to improve the spec. So, we’d love to hear more from those voices!

For example, security implications were mentioned as a reason for removal of JSONPath. In the PE working group, we’ve discussed some potential risks as well, including denial of service, unintended disclosure, injection. We’ve also discussed mitigations including the more obvious implementation best practices (input sanitization), as well as proposing a reduced subject of JSONPath functionality, e.g., disallowing certain operators, expressions, or functions.

It would be helpful to hear more context behind the concerns mentioned above – are there others you are thinking about? At minimum it can help us improve the PE spec. But ideally, it will help continue to drive alignment in this already fractured decentralized identity standards space.

‌

Edit: I just noticed David’s proposal of making this flexible, and that’s also worth considering, as well as its potential downsides (additional complexity/optionality – but we could also consider achieving that in the layering/feature style).

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VP