clarify batch issuance requirements #229
Conversation
Sakurann
requested review from
GarethCOliver,
awoie,
bc-pi,
c2bo,
danielfett,
hlozi,
leecam,
martijnharing,
tlodderstedt and
tplooker
|
|
||
| Both Wallet initiated and Issuer initiated issuance are supported. | ||
|
|
||
| The Wallet MUST support batch issuance. For each Credential Configuration, the Issuer MUST indicate whether batch issuance is supported by including or omitting the `batch_credential_issuance` metadata parameter. The Issuer’s decision may be influenced by various factors, including, but not limited to, trust framework requirements, regulatory constraints, applicable laws or internal policies. |
There was a problem hiding this comment.
that effectively means the wallet MUST use batch issuance if the issuer has batch_credential_issuance set to true, right?
There was a problem hiding this comment.
I don't think so, or at least this language isn't strong enough that I feel we'd have justification to implement a conformance test that required that - batch_credential_issuance is at the issuer level, but in the general case it's possible an issuer might have some credentials that have linkability issues and need batch issuance, and some that don't...
There was a problem hiding this comment.
Isn't it meaningless to say a wallet MUST support batch issuance?
batch_size is the maximum size of the array of proofs. So a wallet that only ever sends a single proof still 'supports' batch issuance.
It's also worth noting that single-use credentials can be achieved without batch issuance being supported, as making N credential requests and making 1 credential request for N credentials achieves the same thing (the question is more about how key attestations are generated etc).
There was a problem hiding this comment.
option 1: remove "wallet must support batch issuance". probably annoying to the issuers if wallet will send 10 individual requests to get 10 copies of the same credential within the same session...
option 2: paraphrase to something like the wallet must request issuance of at least 2 credentials when the issuer has indicated batch issuance support, since if the issuer indicates batch issuance support, it probably means issuer wants the wallet to use it..
There was a problem hiding this comment.
I think option 2 would need to be conditional on the credential having cryptographic key binding support listed too (assuming https://github.com/openid/oid4vc-haip/pull/210/files gets merged).
There was a problem hiding this comment.
Imo:
- Wallet MUST support batch issuance to lower impact/load for Credential Issuers that want to use it (instead of sending single requests)
- Credential Issuer knows his use case best
- if a single credential makes sense -> do not offer batch issuance and signal Wallet to keep the single one
- if batch issuance makes sense -> offer batch issuance, Wallet MUST utilize it to avoid linkability and Wallet SHOULD fetch up to
sizeand refill by it's own policy
There was a problem hiding this comment.
if batch issuance makes sense -> offer batch issuance, Wallet MUST utilize it to avoid linkability and Wallet SHOULD fetch up to size and refill by it's own policy
Utilitizing batch issuance isn't necessary to avoid unlinkability though. Batch issuance is purely an optimisation.
Would the opposite statement be easier for people to get behind:
Wallets MUST NOT make multiple single requests for the same credential in a short space of time if the Issuer supports batch issuance.
This seems to get to the heart of the original concern of avoiding unnecessary load on the issuer when the wallet wants 20 instances of the same credential.
There was a problem hiding this comment.
Who decides whether credentials should be used in a one time usage policy, the wallet or the issuer? I think it's the issuer..
There was a problem hiding this comment.
Who decides whether credentials should be used in a one time usage policy, the wallet or the issuer? I think it's the issuer..
As the specs are defined today I think it's the wallet that ultimately decides, but the wallet's choice is made based on out-of-band information from the issuer/ecosystem on the credential properties?
There was a problem hiding this comment.
Functionally, the Wallet is the only one that has enough information to do it today. It would be nice for Issuers to send a signal, if for example the issuer knows every presentation must be fully identifying then encoding that.
IMO mandating something that is performance related, not inter-op related is difficult just because there tends to be so many edge cases in the real world. It does feel like issuers do already have tools in place to deal with overloading wallets (they can load-shed the extra requests, or defer and batch the operations using a rotating job).
I think it'd be reasonable to mandate that issuers support a batch size equal to the amount the ecosystem expects the wallet to maintain on the device, and when that is available strongly recommend that a Wallet use that rather than parallel requests. (The one case I could see wanting otherwise would be wanting a single credential quickly and a batch slowly when none are currently available on the device. This could (potentially substantially) improve user experience given we don't allow partial returns, especially for JIT issuance flows).
|
|
||
| Both Wallet initiated and Issuer initiated issuance are supported. | ||
|
|
||
| The Wallet MUST support batch issuance. For each Credential Configuration, the Issuer MUST indicate whether batch issuance is supported by including or omitting the `batch_credential_issuance` metadata parameter. The Issuer’s decision may be influenced by various factors, including, but not limited to, trust framework requirements, regulatory constraints, applicable laws or internal policies. |
There was a problem hiding this comment.
batch_credential_issuance metadata is not credential configuration specific, it is a general parameter. It is not possible to have batch_credential_issuance per configuration, only per issuer. I suggest rewriting this statement, so it is clear that is for whole credential configuration.
Co-authored-by: Paul Bastian <paul.bastian@posteo.de>
Co-authored-by: Joseph Heenan <joseph@authlete.com>
|
|
||
| Both Wallet initiated and Issuer initiated issuance are supported. | ||
|
|
||
| If the Issuer supports batch issuance, the Wallet SHOULD NOT make multiple requests for a single copy of the same credential in a short space of time. The Issuer MUST indicate whether batch issuance is supported by including or omitting the `batch_credential_issuance` metadata parameter. The Issuer’s decision may be influenced by various factors, including, but not limited to, trust framework requirements, regulatory constraints, applicable laws or internal policies. |
There was a problem hiding this comment.
| If the Issuer supports batch issuance, the Wallet SHOULD NOT make multiple requests for a single copy of the same credential in a short space of time. The Issuer MUST indicate whether batch issuance is supported by including or omitting the `batch_credential_issuance` metadata parameter. The Issuer’s decision may be influenced by various factors, including, but not limited to, trust framework requirements, regulatory constraints, applicable laws or internal policies. | |
| If the Issuer supports batch issuance, the Wallet SHOULD NOT make multiple requests for a single Credential of the same Credential Dataset in a short space of time. The Issuer MUST indicate whether batch issuance is supported by including or omitting the `batch_credential_issuance` metadata parameter. The Issuer’s decision may be influenced by various factors, including, but not limited to, trust framework requirements, regulatory constraints, applicable laws or internal policies. |
Co-authored-by: Oliver Terbu <oliver.terbu@mattr.global>
|
So does this mean that single use policy is out of scope for HAIP 1.0 or do we still want to tackle it? |
|
|
||
| If batch issuance is supported, the Wallet SHOULD use it rather than making consecutive requests for a single Credential of the same Credential Dataset. The Issuer MUST indicate whether batch issuance is supported by including or omitting the `batch_credential_issuance` metadata parameter. The Issuer’s decision may be influenced by various factors, including, but not limited to, trust framework requirements, regulatory constraints, applicable laws or internal policies. | ||
|
|
||
|
|
There was a problem hiding this comment.
| For the Credentials with Cryptographic Holder Binding, | |
| the Wallet MUST use the same Credential only once, | |
| even when the claims being disclosed are the same. | |
There was a problem hiding this comment.
This definitely shouldn't be true. (e.g. ZKP, already identifying responses etc).
|
WG discussion:
|
GarethCOliver
left a comment
GarethCOliver
left a comment
There was a problem hiding this comment.
Approved in the current state (without the change to mandate single use).
|
|
||
| If batch issuance is supported, the Wallet SHOULD use it rather than making consecutive requests for a single Credential of the same Credential Dataset. The Issuer MUST indicate whether batch issuance is supported by including or omitting the `batch_credential_issuance` metadata parameter. The Issuer’s decision may be influenced by various factors, including, but not limited to, trust framework requirements, regulatory constraints, applicable laws or internal policies. | ||
|
|
||
|
|
There was a problem hiding this comment.
This definitely shouldn't be true. (e.g. ZKP, already identifying responses etc).
resolves #202
resolves #150