"Wallet MAY continue with JAR" is contradicted later in the spec and intended to be a MUST

[jogu]

https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-1_1-wg-draft.html#name-authorization-request says:

The Wallet MAY continue with JAR when it receives request_uri_method parameter with the value post but does not support this feature.

I don't think this is correct; this is actually a MUST I believe - https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-1_1-wg-draft.html#name-new-parameters says:

Wallets not supporting the post method will send a GET request to the Request URI (default behavior as defined in [RFC9101]).

I'd be tempted to put that 'will' as a MUST too, but I think it's probably clear as is. Deleting 'will' would work too.

I suggest changing the 'MAY continue with JAR' to a 'MUST' (or possibly removing the 'MAY' from the sentence, or just removing the sentence entirely.)

The certification tests treat the 'MAY' as a 'MUST'.

[jogu]

On a slightly related note:

The handling of request_uri_method values other than get and post is weirdly defined. I don't see any normative text. But there is an error defined:

https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-invalid_request_uri_method

(but no text I can see requiring the wallet to return an error).

It seems that both these behaviours would be conformant:

1. The wallet just ignores request_uri_method with a value of say 'PATCH' (because it doesn't support POST and hence ignores the parameter entirely) and does a GET, or
2. The wallet returns a invalid)request_uri_method error

Both behaviours being legal essentially means it's not realistic to add new request_uri_method values in the future in a backwards compatible way.

[brentzundel]

From the discussion today: the direction proposed sounds reasonable. @c2bo will raise a PR.