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.
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:
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:
dcql_query
and/orpresentation_definition_uri
/presentation_definition
needs to be present.presentation_submission
you'll know the wallet used the presentation definition.