Signalling that a Request Object must always be present in Authorization Request

Following the ab/connect WG mailing list discussion the issue to discuss/figure out how to enable RPs/OPs to get assurances that only Authorization Requests with a Request Object are processed by the OP.

Problem: Signalling that a request object must always be present in Client's authorization requests.
While this can be made a security profile requirement (e.g. FAPI) I think a Client using a regular authorization server should be able to have the assurances that come out of using signed Request Objects as part of the available registered metadata.

The closest solution to this is request_object_signing_alg but if there's no request object at all, request is still valid as per the current language. This allows a malicious user to form his own authorization request with the properties the RP wishes to protect and enforce with signed request (e.g. claims containing PII, required amr or other sensitive information necessary for the authorization request, max_age, acr_values) in the query instead.

My proposal was to enrich the existing OAuth Dynamic Client Registration Metadata with either a new spec or just a OpenID Connect Dynamic Client Registration 1.1 update with

require_request_object
  OPTIONAL. Boolean value specifying whether the OP should accept an
  Authorization Request without a Request Object for processing. If true,
  the OP MUST reject Authorization Requests without Request Object 
  passed by value (using the request parameter) or by reference (using 
  the request_uri parameter) with the error invalid_request. If omitted,
  the default value is false.

Mike's proposal was to

Rather, we could clarify that if request_object_signing_alg is present, it’s also to be interpreted as a request by the server to only send signed requests. That would be simpler than adding an additional parameter.

The current request_object_signing_alg language says

request_object_signing_alg
OPTIONAL. JWS [JWS] alg algorithm [JWA] that MUST be used for signing Request Objects sent to the OP. All Request Objects from this Client MUST be rejected, if not signed with this algorithm. Request Objects are described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. This algorithm MUST be used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support RS256. The value none MAY be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used.

As I'm reading this there's no suggestion that configuring a client with this metadata MUST force the OP to reject requests without a Request Object and an errata should not change the normative requirements.

Comments (12)