Clarify Request URI response can be unsigned for prefixes requiring unsigned requests

[jogu]

The Request URI Response section said the body must be a signed request object, which conflicts with the redirect_uri Client Identifier Prefix rule that requests cannot be signed. Clarify that the request object is signed unless the Client Identifier Prefix in use requires an unsigned request, in which case the JWT uses alg none.

Fixes #756

[paulbastian]

I'm not sure RFC9101 allows that. There is text saying It MUST also reject the request if the Request Object uses an "alg" value of "none".

[jogu]

@paulbastian

I'm not sure RFC9101 allows that. There is text saying It MUST also reject the request if the Request Object uses an "alg" value of "none".

That's in the section where 'require_signed_request_object' is in the client metadata as 'true':

so I don't think applies here. none is generally permitted in RFC9101.

[paulbastian]

But the next paragraph says:

   When the value of it as server metadata is "true", then the server
   MUST reject the authorization request from any client that does not
   conform to this specification.  It MUST also reject the request if
   the Request Object uses an "alg" value of "none".  If omitted, the
   default value is "false".

The text isn't a 100% clear if that sentence is conditional to the first sentence.

[fkj]

RFC 9101 also says (in section 10.1, which is Security Considerations):

When sending the Authorization Request Object through the request parameter, it MUST be either signed using JWS [RFC7515] or signed and then encrypted using JWS [RFC7515] and JWE [RFC7516], respectively, with algorithms considered appropriate at the time.

[jogu]

This is where we would all like if it RFCs had a nicer errata process :-)

The text isn't a 100% clear if that sentence is conditional to the first sentence.

My reading is:

require_signed_request_object: true => reject alg none
require_signed_request_object: false => accept alg none

If we instead assume alg: none is disallowed in both cases, what would the meanings of require_signed_request_object true/false be?

[c2bo]

This is where we would all like if it RFCs had a nicer errata process :-)

The text isn't a 100% clear if that sentence is conditional to the first sentence.

My reading is:

require_signed_request_object: true => reject alg none require_signed_request_object: false => accept alg none

If we instead assume alg: none is disallowed in both cases, what would the meanings of require_signed_request_object true/false be?

That is my interpretation as well and if I recall correctly that is also what we ended up with initially when discussing this?

[paulbastian]

require_signed_request_object means whether it is required to send authorization request as RFC9101 or whether RFC6749 style is still allowed.

[paulbastian]

After re-reading I'm fine