openid / OpenID4VP

59 stars 21 forks source link

Clarify JWT envelope for direct_post.jwt in error cases #135

Open awoie opened 8 months ago

awoie commented 8 months ago

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.

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

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

awoie commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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:

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 commented 8 months ago

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 commented 8 months ago

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

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 commented 8 months ago

@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 commented 8 months ago

@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 commented 8 months ago

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

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

Sakurann commented 1 week ago

looks like there is an agreement on the text, please do a PR