co-existence of multiple query languages

[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

[bc-pi]

Secondhand from an implementer, "we support a very narrow set of features from PE 1.0 [for that DIF JWT VC presentation profile]. We don't have support for PE 2.0", which I chose to interpret as support for option 2. I concur that Inclusion of PE in VP is harming interoperability and complicating things.

[awoie]

WG discussion: option 1: keep both PE and DCQL in VP. HAIP already mandates DCQL only. currently preferred option 2: remove PE entirely from VP - need to reach out to the implementers. removing it in 1.1 might be ok

As an implementer I would love to see DCQL to be the only option sooner than later.

[Sakurann]

WG discussion

• agreement to remove PE from 1.0 to improve interoperability and avoid confusion

[davux]

The issue argues that having multiple languages is a bad thing for interop, which is a common argument for diversity. Debatable and shouldn't be played as an absolute wildcard, but OK.

So I wonder a few things, not addressed in the issue:

• If multiple languages is a bad thing, why was DCQL introduced in the first place as an alternative to PE?
• Why remove PE and not DCQL?

It sounds a bit like "hey can I squeeze in between you guys, it will be so cozy", and 10 minutes later "gosh it's feeling very uncomfortable here, can someone not be selfish and please let us breathe?"

There's probably a good argument for both questions, but neither is really addressed in the issue, so from the outside it sounds like there's more to it (a.k.a. unofficial motives). Transparency is important, especially when it comes to Internet standards definition.

I know I'm late for the party but still wanted to state that, for the record.

[danielfett]

@davux

If multiple languages is a bad thing, why was DCQL introduced in the first place as an alternative to PE?

For many years, OpenID4VP had only PE as the query language, but the feedback from implementers was that it is too complex, too hard to implement fully, and (because of that) often non-interoperable. Attempts were made to define a profile of PE to fix those problems, but that didn't work out in the end. That's why, ultimately, DCQL was developed.

Why remove PE and not DCQL?

DCQL was initially provided as an alternative to PE in order to evaluate its qualities and matureness. The feedback received was overwhelmingly positive. After a while, there were many voices calling for a "DCQL only" approach, i.e., remove PE in order to reduce the overall implementation complexity. There were also unsolved questions around interoperability when a verifier uses PE and the wallet doesn't support it, or vice-versa. After several discussions in the DCP working group, the decision was made to remove PE for good.

With that in mind, the question "Remove PE or DCQL" never came up. It was just whether PE should remain or not, the answer to which you can find above.

All of this development happened in the open and over a time span of 1½ years or so. Mike Jones provides a good write-up of the development in his blog. You can also read the meeting minutes of various DCP calls in which this topic was discussed on the DCP mailing list.

[selfissued]

Also, see A Significant Event Without Fanfare, marking the ultimate removal of PE.

[davux]

@danielfett, @selfissued, thanks for taking the time of providing all that context. As an implementer, I came to this issue from the PR, because I wondered where the decision of dropping PE came from. Thanks to your summary and pointers, we can now better understand the decision.