[Openid-specs-ab] Proposal for "Required Request Object Use" Dynamic Registration extension

[Filip Skokan]

Hello everyone,

I'd like to propose an additional (or Dynamic Registration 1.1) entry into
the openid spec family / IANA "OAuth Dynamic Client Registration Metadata"
that allows for OPs and RPs to get assurances about the used JWT Request
Objects in Authorization Requests.


*1) signaling that a request object must always be present in Client's
authorization requests*

why are current parameters not enough?

The closest comes *request_object_signing_alg*, but its worded as *"All
Request Objects from this Client MUST be rejected, if not signed with this
algorithm. ... This algorithm MUST be used both when the Request Object is
passed by value or ...".*
Meaning if there's no request object at all, request is still valid. This
allows a malicious user to form his own authorization request with the
properties the RP wishes to protect (e.g. claims containing PII, required
amr or other sensitive information necessary for the authorization request,
max_age, acr_values) in the query instead.

Proposed client registration metadata:
request_object_requiredOPTIONAL. 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.

*2) enforcing request object encryption* - this one I didn't quite figure
out a vector for yet

why are current parameters not enough?

*request_object_encryption_alg* states *"JWE algorithm the RP is declaring
that it may use for encrypting Request Objects sent to the OP. ... The RP
MAY still use other supported encryption algorithms or send unencrypted
Request Objects, even when this parameter is present."* so the request
object may still be sent without encryption.
This smells of a very easy downgrade-attack (when symmetrical encryption is
used) vulnerability with no normative protection against it. I mention I
can't figure out a vector for this but just plain possibility of abandoning
high-quality mode of operation directly in the specification is what I wish
to get rid of.

Proposed client registration metadata:
request_object_encryption_alg_required
OPTIONAL. Boolean value specifying whether the alg algorithm specified by
request_object_encryption_alg MUST be used for encrypting Request Objects
sent to the OP. When request_object_encryption_alg_required is true all
Authorization Requests with Request Objects from this Client MUST be
rejected with the error invalid_request_object, if not encrypted with this
algorithm or not encrypted at all. When
request_object_encryption_alg_required is true,
request_object_encryption_alg MUST also be provided and 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). If
omitted, the default value is
false.request_object_encryption_enc_requiredOPTIONAL.
Boolean value specifying whether the enc algorithm specified by
request_object_encryption_enc MUST be used for encrypting Request Objects
sent to the OP. When request_object_encryption_enc_required is true all
Authorization Requests with Request Objects from this Client MUST be
rejected with the error invalid_request_object, if not encrypted with this
algorithm or not encrypted at all. When
request_object_encryption_enc_required is true,
request_object_encryption_enc MUST also be provided and 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). If
omitted, the default value is false.

Additionally, having these metadata defined allows an OP to send these in
Dynamic Registration Response as a policy of sorts.

I'd like to get your feedback on this proposal and I am also able to form a
specification around this if it's welcome.

I'm sending this to both AB/Connect and FAPI working groups, considering
that FAPI requires the use of signed and/or encrypted request objects Mike
Jones figured it'd be something you might be interested in. While some form
of normative requirement is already present in the FAPI specifications
introducing these metadata MAY allow a single OP to operate both in secure
and insecure modes at the same time depending on the provisioned or
dynamically registered client.

Since my IPR Agreement for FAPI WG is not yet processed someone please
forward there.

Kind Regards,
*Filip*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180811/29cd2bb8/attachment.html>