Open awoie opened 8 months ago
I basically agree with your conclusions. Sending no response is okay. Sending a response but in the url query format wouldn't be entirely unexpected - certainly that kind of thing can happen when using JARM with the authorization code flow & normal redirects.
Sending a response but in the url query format wouldn't be entirely unexpected - certainly that kind of thing can happen when using JARM with the authorization code flow & normal redirects.
Do you mean application/x-form-encoded
since in case of direct_post
/direct_post.jwt
I assumed the error response MUST be always sent to the response URI?
In this case, the wallet does not have a redirect_uri
that can be used to send the error parameters using the URL query format, right? But I guess you referred to authz code flow/normal redirects.
Do you mean application/x-form-encoded since in case of direct_post/direct_post.jwt I assumed the error response MUST be always sent to the response URI?
Yes, exactly. It sort of feels weird but there are legitimate cases where a JWT can't be encrypted/signed for some reason and bringing alg: none into the mix wouldn't be good. We may need to add a sentence about it I guess...
To my understanding, when a verifier uses a response_mode
related to JARM (direct_post.jwt
, query.jwt
, fragment.jwt
) the wallet during the processing of the authorization request needs to make sure that verifier has included in its client metadata appropriate information to assemble the JARM JWT.
Practically this means that wallet (in case of JARM) must check for a valid combination of:
authorization_signed_response_alg
authorization_encrypted_response_alg
authorization_encrypted_response_enc
and reject the request if no valid or not supported/understandable combination of the above attributes is sent.
In this corner case, IMO, wallet cannot send the erroneous response because it cannot "satisfy" the requested response_mode
To my understanding, when a verifier uses a
response_mode
related to JARM (direct_post.jwt
,query.jwt
,fragment.jwt
) the wallet during the processing of the authorization request needs to make sure that verifier has included in its client metadata appropriate information to assemble the JARM JWT.Practically this means that wallet (in case of JARM) must check for a valid combination of:
authorization_signed_response_alg
authorization_encrypted_response_alg
authorization_encrypted_response_enc
and reject the request if no valid or not supported/understandable combination of the above attributes is sent. In this corner case, IMO, wallet cannot send the erroneous response because it cannot "satisfy" the requested
response_mode
I would agree with this. Those parameters have to be present in the client metadata (via whatever channel it was provided to the wallet, e.g., in the request, entity statements, pre-configured etc.) to generate a error response using JARM.
However, @jogu did I understand you correctly that it wouldn't be unexpected for RPs to receive such error responses without JARM, although the authorization_response parameters are present?
@babisRoutis @jogu Would it be reasonable to add some language to the spec that explains this? Something like, wallets MAY send the error response without JARM envelopes if they have good reasons to do so. Or would this hurt interop too much?
@babisRoutis @jogu Would it be reasonable to add some language to the spec that explains this? Something like, wallets MAY send the error response without JARM envelopes if they have good reasons to do so. Or would this hurt interop too much?
Dear @awoie Thanks for asking this.
I believe that not all errors are equal or reportable, if you will.
Those are errors have to do with attributes that are validated taking into account the response_mode
(that is, their correctness depends on the value of the response_mode)
To my understanding in the bellow cases, wallet cannot convey the error to the verifier:
redirect_uri
while using a response_mode
that requires itresponse_uri
using either direct_post
or direct_post.jwt
?Bottom line, I think that spec should just state that there could be cases where the wallet cannot report back to verifier some errors.
@babisRoutis @jogu Would it be reasonable to add some language to the spec that explains this? Something like, wallets MAY send the error response without JARM envelopes if they have good reasons to do so. Or would this hurt interop too much?
I think I'd be okay with that.
@babisRoutis @jogu Would it be reasonable to add some language to the spec that explains this? Something like, wallets MAY send the error response without JARM envelopes if they have good reasons to do so. Or would this hurt interop too much?
I think I'd be okay with that.
@babisRoutis what do you think? Would you be ok with such a language?
@babisRoutis what do you think? Would you be ok with such a language?
@awoie Yes. As long as there is the "MAY send" :smile:
looks like there is an agreement on the text, please do a PR
direct_post.jwt
requires the wallet to send a JWT to theresponse_uri
. This also applies to an error response. In this case, the error parameters are included in a JWT.What happens in the following case:
A specific OID4VP profile requires encrypting the response (using JARM) but the provided client metadata does not contain encryption keys, so the response cannot be encoded as a JWE.
Do you think we should add this to the implementation considerations? IMO, this would be useful.