OID4VP Query language requirements document

[Sakurann]

WG agreed on the process outlined here as a way forward to approach query language discussion in OID4VP.

Following up on step 1 of what was agreed there, below is a document that started compiling requirements for the query language in OID4VP: https://docs.google.com/document/d/1OSnRT9QB_8OiPGgfg3IbZnoCJtat8chYkJbcthXGf_g/edit

please review and comment directly in the google document.

[selfissued]

I made substantial comments in the document, as requested. All are aimed at simplifying implementation requirements.

For instance, they point out that:

• Requesting multiple credentials at once is not a core requirement.
• Having an algebra to specify combinations of alternatives is not a core requirement.
• Several of the proposed features are credential-format specific and not universally applicable.

[awoie]

IMO, in the document it is requirement to list the use case and the purpose for each requirement clearly. Also what community or ecosystem requires that. Especially for more advanced/complex features, we would also need to find out whether those are already in production. I want to avoid that we start with a list of requirements where it is unclear how this initial list was even compiled and what the purpose is of each requirement. I would prefer we start with a list of fully uncontroversial requirements without premature optimization.

[bc-pi]

As much as is possible (and it is understandably difficult to do given the context of all this) this kind of document should be about what is actually needed in a query language rather than describing features that PE (theoretically) provides, which is somewhat how it reads now.

[jogu]

I responded to a few of Mike's comments. But just to repeat one particular answer here:

Requesting multiple credentials at once is not a core requirement.
Having an algebra to specify combinations of alternatives is not a core requirement.

From my understanding it is a requirement (from the EU) that it is possible to request a PID and a matching credential that uses claims based binding (both from the same wallet) in a single transaction. Hence if we were to deprecate PE in OID4VP, it is a requirement for whatever replaces PE. Whether that feature is mandatory to implement seems separate to me.

[Sakurann]

As much as is possible (and it is understandably difficult to do given the context of all this) this kind of document should be about what is actually needed in a query language rather than describing features that PE (theoretically) provides, which is somewhat how it reads now.

@bc-pi I have not included anything that I thought is hypothetical and included only the features that I know at least one use-case/implementation. would appreciate if you could point out specifically which requirement/feature you think is hypothetical and I am happy to provide a use-case/implementation example. concrete feedback really helps make progress...

[bc-pi]

The ability to ask for and receive more than one credential in a single OID4VP exchange remains something I believe brings more complexity than value (I've said as much back to at least OSW last year), and is the source of at least a good amount of the difficult complexity in PE. Of course, there are use-cases for multiple credentials, but they could be handled up at the application layer with more than one OID4VP exchange in the session/transaction. I am aware that you disagree with me here, but that doesn't make it invalid.

[babisRoutis]

The ability to ask for and receive more than one credential in a single OID4VP exchange remains something I believe brings more complexity than value (I've said as much back to at least OSW last year), and is the source of at least a good amount of the difficult complexity in PE. Of course, there are use-cases for multiple credentials, but they could be handled up at the application layer with more than one OID4VP exchange in the session/transaction. I am aware that you disagree with me here, but that doesn't make it invalid.

In general, I consider that to be able to ask for multiple different credentials can be tackled by application level. The ability, though, to reply (to a single requirement) with multiple credentials I think that it is not a corner case.

A wallet may hold multiple credentials of the same format and type but representing different datasets.

For instance, present your diplomas (in sd-jwt-vc)

One may argue that this could be solved also with multiple presentations, yet there are cases where the number of such credentials (instances) is not so small.

So, single query perhaps defining the number of the results (credentials):

• None (implied)
• One
• top X

[tplooker]

A wallet may hold multiple credentials of the same format and type but representing different datasets.

I think we should distinguish between cases where a relying party wants to, in one request say "I want your drivers license and I will accepted it in this format or that format", from the multi-credential request case which is "I want your DL AND diploma". With the former case only a single credential at maximum is ever sent in response, whilst the latter is where multiple credentials can be returned and where I believe others are highlighting the inherent complexity lies.

[tplooker]

This usecase "Verifier is able to express claim based binding" I don't agreed with being a requirement. As I've said in the comments of the doc, it can easily be addressed through multiple requests and ironically is how relying parties would generally request this information from a user when scanned copies of physical documents are being requested. The functionality as implied by the proposed requirement would likely be a bigger disruption for existing relying party websites to implement then simply allowing them to request each credential individually.

[tplooker]

One may argue that this could be solved also with multiple presentations, yet there are cases where the number of such credentials (instances) is not so small.

More generally for the multi-credential usecase in my experience many relying parties don't want to take such a risk of aggregating their requirements together into one multi credential request, because for instance if the user doesn't have all the information ready at the time a relying party makes a request it can be very difficult for the relying party to help guide the user on what to do next. Another variation of this case is what if the relying party needs a DL and diploma, but the user has the DL in a wallet and a scanned copy of a physical document for the diploma? Given how credentials are being adopted I think usecases where some information is sourced from credentials and the rest from other existing sources is going to be frequent.

[mavarley]

More generally for the multi-credential usecase in my experience many relying parties don't want to take such a risk of aggregating their requirements together into one multi credential request, because ...

I'm wondering if there are 2 conflicting points of view here wrt the role of the wallet/user agent in orchestrating the flow (and if we settle that, the answer to complex requests becomes clearer?)

1. One approach may be looking at the user agent to make as many business logic decisions as possible, since it has a view on the contents of the user's wallet and can help them decide 'up front'. Like when I apply for a passport, I have to show up at the office with all my relevant documentation in one shot based on information provided ahead of time, or
2. the other approach may be trying to keep the user-agent as naive as possible (1 credential at a time, limited options), and requiring the RP to take an active roll in guiding the holder through the process (give me presentation A, then presentation B, skip C, but presentation D is now required...)

From our experience at SecureKey / Gen we have seen a strong desire for option 1 mainly because of the UX cost associated with option 2 in having to continually re-engage the wallet (scanning multiple QR codes just to get through a process...), even though it is prone to errors as Tobias pointed out... and maybe if there is a way to alleviate the UX concern then option 2 becomes the preferred choice for all?

For option 2, is there a method (or a plan to build a method) to easily re-engage with the wallet for follow up presentations to help with the UX?

[jogu]

More generally for the multi-credential usecase in my experience many relying parties don't want to take such a risk of aggregating their requirements together into one multi credential request

Writing personally (not as a chair), unless we think we can convince everyone that multi-credential requests is a bad user experience, it's quite difficult to see how we can combine the feedback of people that say this feature isn't necessary with the feedback of people who say this feature is necessary (which we now seem to have a number of) and come to any conclusion other than that this feature is one that OID4VP must support because sufficient people do require it.

If someone sees a path to coming to a different conclusion please do explain it!

[tplooker]

Writing personally (not as a chair), unless we think we can convince everyone that multi-credential requests is a bad user experience, it's quite difficult to see how we can combine the feedback of people that say this feature isn't necessary with the feedback of people who say this feature is necessary (which we now seem to have a number of) and come to any conclusion other than that this feature is one that OID4VP must support because sufficient people do require it.

Just to be clear in certain cases multi-credential requests are a bad user experience, because if an RP makes a request for 2 or more credentials and any of the following situations occur

1. The user has the required credentials held across different wallets
2. The user doesn't have all the credentials requested
3. The user has some of the credentials required in another form, e.g as a scan of a physical copy or in a file format like PDF

There is no way for a relying party to distinguish these above cases from other cases like the user just failed to provide consent to share the information. Which basically leaves the RP confused as to what to do next or how to adequately guide the user. I appreciate the attraction of this feature in the protocol, but what I think others in this thread have tried to signal is that this feature creates some pretty difficult problems that we need to be able to have an answer to.

From our experience at SecureKey / Gen we have seen a strong desire for option 1 mainly because of the UX cost associated with option 2 in having to continually re-engage the wallet (scanning multiple QR codes just to get through a process...), even though it is prone to errors as Tobias pointed out... and maybe if there is a way to alleviate the UX concern then option 2 becomes the preferred choice for all?

I don't necessarily have an answer to this at this stage, perhaps there are additional protocol features here we could consider. I would point out though that the UX inconvenience is notably less in same device flows as there is no QR scanning required, really the difficultly mainfests most is in cross device flows which require multiple credentials.

[David-Chadwick]

Concerning an additional protocol feature I would suggest that if the RP requests multiple credentials then whichever of the user's wallets answers the request, when none of them can answer the query in full for any reason, then we add a response type of "request single credential queries". In this way the RP knows to return a query requesting just one credential, and to repeat this operation until all of the credentials are obtained.

[tplooker]

Concerning an additional protocol feature I would suggest that if the RP requests multiple credentials then whichever of the user's wallets answers the request, when none of them can answer the query in full for any reason, then we add a response type of "request single credential queries". In this way the RP knows to return a query requesting just one credential, and to repeat this operation until all of the credentials are obtained.

I don't see how this works, by design wallets are not able to understand what may or may not be in other wallets on a users device, so a wallet is unable to conclude "when none of them can answer the query in full for any reason" which is where in lies one of the inherent problems with multi-credential requests. A single wallet can only ever respond based on what they have or do not have.