openid
Define batch issuance for credentials without key binding
From the spec:
batch_credential_issuance: OPTIONAL. Object containing information about the Credential Issuer's support for issuance of multiple Credentials in a batch in the Credential Endpoint. The presence of this parameter means that the issuer supports more than one key proof in the proofs parameter in the Credential Request so can issue more than one Verifiable Credential for the same Credential Dataset in a single request/response.
batch_size: REQUIRED. Integer value specifying the maximum array size for the proofs parameter in a Credential Request. It MUST be 2 or greater.
This suggests that the requested batch size (from the wallet) corresponds to the number of elements in the proofs array in the request. However, if the wallet wants to obtain multiple copies of a credential without key binding, or if the issuer does not support credentials using key binding, this mechanism is not applicable.
Such a use case could still be useful, as even in the absence of key binding, there may be a risk of collusion if the same copy is used with different RPs.
I think we might have assumed in a few places that batching is only necessary for credentials that are key bound, and that non-key-bound credentials are likely claims-bound instead so necessarily reveal the user's identity. I think that's the direction we've gone in HAIP at least.
What's an example of a non-key-bound credential where batching would be useful?
I believe that if we don't support batch issuance for credentials without key binding, we may run into issues when issuing credentials with key binding.
Unless the credential endpoint can be called multiple times for credentials without key binding, effectively achieving batch issuance, this could be problematic.
Credentials without key binding are often presented alongside key-bound credentials. So if one such non-key-bound credential is reused across multiple presentations (e.g., together with freshly issued PID instances), it could introduce correlation risks.
In that scenario, the credential without key binding becomes the correlation factor across presentations.
Realistically, I'm not aware of any practical, real-world use cases where a credential without key binding contains no PII and does not pose a correlation risk on its own.
Unless the credential endpoint can be called multiple times for credentials without key binding, effectively achieving batch issuance, this could be problematic.
I think you can call the credential endpoint multiple times to achieve it (so long as the issuer isn't revoking the previous credential is that case, see #606 ).
Credentials without key binding are often presented alongside key-bound credentials. So if one such non-key-bound credential is reused across multiple presentations (e.g., together with freshly issued PID instances), it could introduce correlation risks.
In that scenario, the credential without key binding becomes the correlation factor across presentations.
Realistically, I'm not aware of any practical, real-world use cases where a credential without key binding contains no PII and does not pose a correlation risk on its own.
(just to record what we talked about offline)
I agree there's a potential risk of correlation - I am struggling to think of a scenario where it matters.
If the non-key-bound credential was a claims-bound credential instead, the cases we've commonly thought about (e.g. University degree in a particular name presented together with a PID in the same name) have all revealed the user's identity so correlation is (presumably) not an issue.
I can think of cases like presenting a PID for over_18 to buy alcohol, and presenting it together with a (non-key-bound) loyalty/discount card, but in that case I would presume that presenting the loyalty card would be a correlating factor (because it contains some kind of unique identifier for the user, as the main reason for loyalty schemes is usually to model the user's behaviour) even if the signature was non-corralateble.
I think it's probably good if we have an example use case before we add extra complexity to the spec.