Should dcql_query and presentation_definition be a string when using JAR?
#378
Comments
|
JAR really should have been more clear about this but I believe the internet has always been that parameters with JSON values remain just JSON when in other JSON. |
|
I agree the spec currently defines both https://github.com/openid/OpenID4VP/blob/main/openid-4-verifiable-presentations-1_0.md?plain=1#L277 The conformance tests send The only example that uses DCQL vaguely suggests it's a JSON object: https://openid.net/specs/openid-4-verifiable-presentations-1_0-ID3.html#appendix-A.2 The As was as JAR, this affects the Digital Credentials API too. ISO 18013 part 7 defines I think we should fix things to make clear that both are intended to be JSON objects, encoded into strings where necessary - we perhaps need similar text to what RAR has for
(from https://datatracker.ietf.org/doc/html/rfc9396#section-3 ) |
When putting JSON into JSON for inclusion in request objects, you should definitely not encode it as a string first. Also switch one of the examples from PE to DCQL as currently the only example showing dcql_query parameter is in DC API appendix. closes #378
When putting JSON into JSON for inclusion in request objects, you should definitely not encode it as a string first. Also switch one of the examples from PE to DCQL as currently the only example showing dcql_query parameter is in DC API appendix. closes #378
When using JAR, the authorization request is encoded as JSON in a JWT. What I've seen most implementations do with
presentation_definitionfield is to keep it as JSON when using JAR, and not encode the JSON object as a string even though the spec mentions "A string containing a Presentation Definition JSON object". We addressed this in our implementation by allowing both string and json.For DCQL we ran into the same issue again. We encode it as string now, but when doing interop testing with @markuskreusch for DCQL it was encoded as JSON object. We hadn't applied the same fix yet to also allow JSON (we currently always expect string for DCQL).
Encoding the JSON as string is required when using query parameters, but not when using JAR, and it seems to lead to ambiquity. In my opinion it makes sense to allow JSON for JAR (as it's more natural to keep JSON as JSON when putting it in a JSON object). I think most important is to maybe add something in the spec about what to do when using JAR:
The text was updated successfully, but these errors were encountered: