co-existence of multiple query languages (to PE, or not to PE)

[Sakurann]

I think we should have an idea how the co-existence of or transition between two query languages in OpenID4Vp will happen: PE v2 and a new one.

Is one or the other mandatory? for whom?
How does the wallet know which query language it is receiving? does this mean we should define a different high level parameter that is not presentation_definition for a new query language?

[Sakurann]

discussed in a WG.

• there seems to be an agreement to use a different top -level parameter for a new query language. @jogu proposed vp_query, but we should bikeshed.
  • there was a proposal to have a top-level parameter under which query language specific parameters sit (would break existing PE implementations and we hopefully/probably won't have more than 2 query languages...) - leaning towards keeping it simple and not defining such an extension.

[bc-pi]

presentation_definition is a... um... silly name at best so no need to keep that

[selfissued]

I agree that the new query language should use its own parameter names.

[David-Chadwick]

I prefer a top level parameter called something like "query-language" and then beneath this there will be the query languages that we support - currently only two, but who knows what else in future? Remember that until a few months ago we only mandated one query language, now we support two. This proposed structure is future proof so that if we want to add a third in future the structure of the current two will not change.

[decentralgabe]

allowing both means that everyone needs to implement both. this increasing the change for interop gaps across implementations.

requiring one but not another also harms interoperability. just require one.

[TimoGlastra]

During the transition period it might be beneficial to allow for both the presentation definition and dcql query to be present in an authorization request. There's no easy way for the verifier to know if the wallet already supports DCQL, and our initial design was that we include both for now, but this doesn't seem allowed:

Exactly one of the following parameters MUST be present in the Authorization Request: dcql_query, presentation_definition, presentation_definition_uri, or a scope value representing a Presentation Definition.

Then the wallet can choose, and we can avoid this problem of knowing which format to use before having interacted with a wallet. Is there a reason for the spec to be this strict? Does it hinder wallet implementations if both can be present?

The logic could be:

• Either dcql_query and/or presentation_definition_uri / presentation_definition needs to be present.
• Wallet chooses which format to use
• If response contains a presentation_submission you'll know the wallet used the presentation definition.

[Sakurann]

WG discussion:
option 1: keep both PE and DCQL in VP 1.0 HAIP already mandates DCQL only.
option 2: remove PE entirely from VP 1.0 currently preferred

[TimoGlastra]

As implementer that currently supports both query languages, I'd generally favour option 2, since the current approach hinders interoperability and complicates things. However I see why now is maybe not the right time yet.

If both languages are kept for v1, it'd be great if we can define in the wallet metadata (like presentation_definition_uri_supported) parameters to indicate which query languages are supported, so the request can be dynamically created based on what the wallet supports