query language requirements discussion: claim based binding?

[Sakurann]

Should verifier be able to express claim based binding? (some comments on google doc, not sure of a direction)

[selfissued]

We need to better define what we mean "Claim based binding" to be able to discuss this question. Is this related to the "Claims-based binding" at https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html#name-claims-based-binding-of-the , for instance?

What kinds of things would need to be expressed in a query language to achieve this and what would the holder need to do? Some examples could help.

[awoie]

IMO, a verifier should know what credentials to ask for and which claims should be included to perform claims-based binding themselves. I don't think we need this feature explicitly.

For example, give me a PID with given_name, family_name and dob, and give me a EEA with firstname, lastname, birthdate.

[jogu]

IMO, a verifier should know what credentials to ask for and which claims should be included to perform claims-based binding themselves. I don't think we need this feature explicitly.

For example, give me a PID with given_name, family_name and dob, and give me a EEA with firstname, lastname, birthdate.

I think there's two main points here:

1. If the user has multiple PIDs and multiple EEAs that belong to different people (ie. mothers with children, power of attorney, etc), expressing that the verifier needs the two returned credentials to match together means that the process of selecting the credentials to return is less error prone and easier for the user, and less likely for the user to end up at a dead end where credentials are returned to the verifier that don't actually satisfy the verifier's need.

2. I'm not sure the verifier can express up front what claims need to match as this will likely vary depending on the jurisdiction that issued the credential, e.g. some countries will likely do claim binding using a national id number, but some won't.

[awoie]

IMO, a verifier should know what credentials to ask for and which claims should be included to perform claims-based binding themselves. I don't think we need this feature explicitly.
For example, give me a PID with given_name, family_name and dob, and give me a EEA with firstname, lastname, birthdate.

I think there's two main points here:

1. If the user has multiple PIDs and multiple EEAs that belong to different people (ie. mothers with children, power of attorney, etc), expressing that the verifier needs the two returned credentials to match together means that the process of selecting the credentials to return is less error prone and easier for the user, and less likely for the user to end up at a dead end where credentials are returned to the verifier that don't actually satisfy the verifier's need.

That is a good point. This can be done by either presenting a purpose on the RP website, or via the query language, or the query language has to have some feature to express that two claims from two credentials have to match.

2. I'm not sure the verifier can express up front what claims need to match as this will likely vary depending on the jurisdiction that issued the credential, e.g. some countries will likely do claim binding using a national id number, but some won't.

I believe the verifier would rather know that than the wallet. Essentially, this is a verifier policy. For example, in some jurisdictions it might be fine to use firstname, lastname, dob for user identification, in other jurisdictions, they will need firstname, lastname, dob and place of birth. If verifier does not know how to link based on claims, the wallet can present anything, even stupid things like "this is my gym membership card number which links to this DL number", and so on. The verifier will have to validate the binding themselves and will also know how to validate. Especially, because the wallet provider might operate outside of the verifier's jurisdiction.

[jogu]

That is a good point. This can be done by either presenting a purpose on the RP website, or via the query language, or the query language has to have some feature to express that two claims from two credentials have to match.

I think the only way to optimise the user experience is via the query language.

I believe the verifier would rather know that than the wallet. Essentially, this is a verifier policy. For example, in some jurisdictions it might be fine to use firstname, lastname, dob for user identification, in other jurisdictions, they will need firstname, lastname, dob and place of birth

I'm not sure if this is universally true. Though I agree we can't expect the wallet itself to know which claims to use to bind credentials together.

I think the issuer of an EEA knows what claims they are (and are not) asserting, and could encode that in the credential (and I think that was Paul's latest suggestion, having a 'cnf' claim in the credential that the non-asserted claims sit inside). For example even in jurisdictions that (say) normally bind a university degree to a national id number, the issuer would have to bind to something else if the graduate was a foreigner that didn't have a national id number, and the verifier can't really be expected to know that when formulating the request.

There would still need to be some kind of agreement that the claims in the 'cnf' can be automatically mapped to the claims in the PID for the wallet to be able to do the matching, which probably gets tricky in the case where the PID is an mDL.

[bc-pi]

This is a somewhat tangential friendly reminder that the cnf claim specified in Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is strictly about representing a proof-of-possession key and is therefore entirely inappropriate as a means of conveying 'claims based binding'.

[Sakurann]

WG discussion: "might not have enough implementation experience. hypothesis that there will be non-cryptographically bound credentials and this feature itself will be useful. the best way forward might be not to have this as an explicit requirement, but as a note/reminder to ensure the updated query language does not preclude claim based binding"