Clarify JWT envelope for direct_post.jwt in error cases

[awoie]

direct_post.jwt requires the wallet to send a JWT to the response_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.

• Should the wallet not send a response at all? Probably safest.
• Should the wallet send the response with alg=none? Potentially dangerous.
• Should the wallet sign the response, and if so what key should be used? Probably makes no sense.

Do you think we should add this to the implementation considerations? IMO, this would be useful.

[jogu]

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.

[awoie]

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.

[jogu]

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...

[babisRoutis]

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

[awoie]

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]

@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:

• The case described in this issue. Caller requires JARM but it doens't provide the required metadata to form the JARM
• When wallet cannot fetch JAR (by reference)
• When wallet cannot fetch client/verifier metadata (by reference)
• An authorization request that misses or has an invalid redirect_uri while using a response_mode that requires it
• Similarly, what if an authorization request misses response_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.

[jogu]

@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.

[awoie]

@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]

@babisRoutis what do you think? Would you be ok with such a language?

@awoie Yes. As long as there is the "MAY send" 😄