-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encrypted responses in Batch and Deferred Endpoints #286
Comments
For batch request, I think that |
For deferred issuance, there is the obvious problem that a wallet can receive a Should a request to deferred endpoint contain also a |
FYI: It may not be specified in the OID4VCI specification, but as a natural technical consequence for me, I thought that the deferred credential endpoint should be able to accept the
|
Dear @TakahikoKawasaki I totally agree about introducing a For instance, one may think that the issuer should "remember" that the initial request (to the credential endpoint) had a To avoid such ambiguities, I think that: In 11.2.3
Should be updated to add In 8.1The
Also, the above text should be updated to exclude the In 8.2The description should be updated to present the In 9.1The In 9.2
Description should document also the encrypted case (using In 9.3It is unclear to me, what the error response should be in case the wallet requests |
I would appreciate if there could be some response from the specification authors The issue, to my understanding, can be summarized to whether
|
We discussed on yesterday's WG call; though people probably need more time to think about it.
There seemed to be agreement on this and it was proposed to raise a PR to make this clear in the specification; @c2bo agreed to raise that PR
We weren't clear on this. It felt unnecessary. The deferred credential endpoint currently only receives It was also further noted that it's not clear that encryption in this way (over an already encrypted transport) is actually adding any value as the keys aren't attested in anyway, though that applies equally to the encryption support already in the spec at the credential endpoint. |
I am trying to understand how the responses of Batch and Deferred Endpoints should work in case encryption is required
Batch Endpoint
Spec defines that a batch credential response is (besides c_nonce info) a list of single credential responses (credential_responses attribute).
What happens though if the individual credential requests (or even worse only some of them) require encrypted responses (credential_response_encryption included in the requests)?
One could assume that since batch credential response is an accumulator of multiple single credential responses it could be as follows
This seems thought rather complicated. Why need separate encryption per individual response instead of having the whole batch credential response encrypted.
In the case that the whole batch credential response should be encrypted, we are missing from batch credetial request a way to define the encryption information. Property
credential_response_encryption
can be used in batch credential requests as in single ones:Deferred Endpoint
In Section 9.2 spec defines that
This does not align with the case where the corresponding credential request defines that encrypted response is needed. In this case response media type should be application/jwt. Section 9.2 needs to be enriched to reflect how case of encrypted responses should be handled.
The text was updated successfully, but these errors were encountered: