Mandatory to implement features of the query language

[Sakurann]

Please comment if you think any of the below should not be mandatory to implement for the verifiers and the wallets (only listing requirements that have rough consensus as of April 25th 9pm CET, will be updated based on how the discussion in #144 concludes):

1. Verifier is able to request at least one credential with a minimum set of claims without having to implement the rest of the advanced features.
2. Verifier is able to request any credential format. ie CBOR and JSON
3. Verifier is able to request/receive multiple credentials at the same time.
4. Verifier is able to specify what credential it needs based on
   a. Credential format
   b. Credential type
   c. Specific claims (only for optional claims)
   d. verifier's intend to retain the data
   e. who is the issuer
5. Verifier is able to request matching or filtering based on a data element value
6. Verifier is able to provide multiple options and the preference order how to fulfill the same requirement both at the credential and claims level
7. When Verifier wants to express a preference but prefers receiving a credential even if it does not meet some requirements over not receiving a credential at all
8. Verifier is able to request claims in the nested structure if the credential format allows for it
9. Verifier is able to determine which of the credentials returned in the response fulfill which requirements in the request, when multiple credentials are being requested.

[decentralgabe]

I agree with the list as written.

I would only raise one consideration which is to say - how can the verifier express the trust requirements for the credential? i.e. it was issued by a known issuer, who may be a part of a trust framework, or the credential was attested to with a sufficient mechanism like a biometric. I'm not sure leaving this up to each data model is sufficient, but perhaps requirement (4) is robust enough to cover these cases.

[awoie]

5. or

IMO, additional things can be covered by 4) . For example, US mDL readers require US mDLs to have a real_id claim. One can define claims specific to trust frameworks and the query can be created, so a certain claim has to be present and presented, e.g., part_my_trust_framework.

[David-Chadwick]

@decentralgabe Requirement 4c) can resolve this if the issued credential lists the trust frameworks that the issuer is a member of e.g. by using the TermsOfUse property in W3C VCs (as implemented by a number of organisations).

[selfissued]

1. Verifier is able to request at least one credential with a minimum set of claims without having to implement the rest of the advanced features.

Agreed - especially with the "without having to implement the rest of the advanced features" part

2. Verifier is able to request any credential format. ie CBOR and JSON

I agree that we need this, but I wouldn't express it at the CBOR/JSON/XML/X.509, etc. level, as that's not a sufficient level of detail to be useful. I would express it in terms of the credential specification, such as mDoc, SD-JWT, VC-JOSE-COSE secured with JWT, VC-JOSE-COSE secured with COSE-Sign1, etc. This is a more useful characterization.

3. Verifier is able to request/receive multiple credentials at the same time.

Requesting and receiving multiple credentials should not be mandatory to implement. I am OK with there being an optional to implement syntax for doing this.

4. Verifier is able to specify what credential it needs based on
   4a. Credential format

Per my answer to 2, I would express it in terms of the credential specification, such as mDoc, SD-JWT, VC-JOSE-COSE secured with JWT, VC-JOSE-COSE secured with COSE-Sign1, etc. and not just JSON, CBOR, XML, X.509, etc.

4b. Credential type

Yes, we need to be able to request diplomas, driving permits, national IDs, etc.

4c. Specific claims (only for optional claims)

What is meant here is underspecified. My opening take on this is that optional claims should be just that - optional, and should not be part of the selection criteria. Until I understand the intent better, I oppose having syntax for this or making this MTI. (An example could help.)

4d. verifier's intend to retain the data

This is needed for some ecosystems and not others. It should be expressible but not MTI.

4e. who is the issuer

While something like this is sometimes needed, it's often the case that it's not a single issuer but an issuer meeting particular trust criteria that is needed. For instance, you want an issuer that is AAMVA accredited or one meeting EIDAS criteria. While seemingly simple on the surface of it, I think this needs more discussion.

5. Verifier is able to request matching or filtering based on a data element value

If by this, you mean the equivalent of the OpenID Connect "claims" request "value" matching criteria, then I agree with this.

6. Verifier is able to provide multiple options and the preference order how to fulfill the same requirement both at the credential and claims level

This is also underspecified. I support having a flat list of alternatives in the request. I vehemently oppose having an algebra like PE where you can request 2 from column A or 3 from column B and one from column C, etc.

7. When Verifier wants to express a preference but prefers receiving a credential even if it does not meet some requirements over not receiving a credential at all

I would need to be convinced that this needs to be a separate feature, rather than something that can be accomplished by use of 1 and 6. This doesn't seem to meet the criteria to be MTI as its own feature.

8. Verifier is able to request claims in the nested structure if the credential format allows for it

As a requirement, yes. Just like you have to be able to express namespaces for some credential formats. At the implementation level, I do not support this turning into JSON Query or JSON Path, etc.

9. Verifier is able to determine which of the credentials returned in the response fulfill which requirements in the request, when multiple credentials are being requested.

I suggest we do without this. To use a credential, the verifier has to understand it anyway, and so is able to look inside it and see what it received. Arguably, this need not be expressible, and is certainly not MTI.

[Sakurann]

@awoie what are you referring to by 5. or?

[Sakurann]

currently agreed list of the requirements:

1. Verifier is able to request at least one credential with a minimum set of claims without having to implement the rest of the advanced features.
2. Verifier is able to request any credential format. ie credential formats expressed in both CBOR and JSON.
3. Verifier is able to request/receive multiple credentials at the same time (from the same wallet).
4. Verifier is able to specify what credential it needs based on any parameter in the payload(*):
   a. Credential format
   b. Credential type
   c. Specific claims (e.g. birth_date, address, etc.)
   d. verifier's intend to retain the data
   e. the trust requirements (i.e. it was issued by a known issuer, who may be a part of a trust framework, or the credential was attested to with a sufficient mechanism like a biometric)
5. Verifier is able to specify the value that the claim/data element has to match (e.g. "resident_country" has to be "DE" (Germany))
6. Verifier is able to provide multiple options how to fulfill the same requirement and the preference order of those options, both at the credential and claims level
7. When Verifier wants to express that it wants to receive a credential only when a specific requirement is met (e.g. read_id claim is present)
8. Verifier is able to request claims in the nested structure if the credential format allows for it
9. Verifier is able to determine which of the credentials returned in the response fulfill which requirements in the request, when multiple credentials are being requested.

(*) per issue #158, any parameters in the payload means body of SD-JWT, data doctype/element_identifiers/namespaces part of mdoc) has to be queriable. things in the header of sd-jwt are not queriable. which of those parameters are mandatory to be queriable is to be agreed.

change log:

• Per feedback, clarified 2, 4c, 5, 6, 7, while keeping the originally intended meaning the same
• Updated 4e to the trust requirements
• clarified 4 based on query language requirements discussion: based on any/set piece of data? #158
• clarified that 3 is from the same wallet

[Sakurann]

per issue #161. Note that it is not an explicit requirement, but updated query language should not preclude claim based binding.

[tplooker]

Discussed with regard to the browser API, there is a clear requirement that for the browser API's usage of the query syntax that it be profile-able to support only returning one credential in response rather then multiple.

[jogu]

Discussed with regard to the browser API, there is a clear requirement that for the browser API's usage of the query syntax that it be profile-able to support only returning one credential in response rather then multiple.

I'm pretty sure we confirmed with the WICG group that although the UI the browsers/OSes are developing is only targeting the 'single credential selected' position, they would not stop verifiers requesting multiple credentials, nor would they stop wallets returning multiple credentials. Have there been recent discussions that indicate a different position? If so we may need to raise it there again.

[TomCJones]

as is stated elsewhere - defining the query based on the verifier's needs is plain wrong. The important person is the holder who must understand the identity and purpose of the verifier.