<div dir="ltr"><div>Hello everyone,</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><b>1) signaling that a request object must always be present in Client's authorization requests</b></div><div><b><br></b></div><div>why are current parameters not enough?</div><div><br></div><div>The closest comes <i>request_object_signing_alg</i>, but its worded as <i>"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 ...".</i></div><div>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.</div><div><br></div><div>Proposed client registration metadata:</div><div><dt style="color:rgb(0,0,0);font-size:13.3333px;margin-top:0.5em"><font face="monospace, monospace">request_object_required</font></dt><dd style="color:rgb(0,0,0);font-size:13.3333px;margin-right:2em"><font face="monospace, monospace">OPTIONAL. Boolean value specifying whether the OP should accept an Authorization Request without a Request Object for processing. If <samp>true</samp>, the OP MUST reject Authorization Requests without Request Object passed by value (using the <samp>request</samp> parameter) or by reference (using the <samp>request_uri</samp> parameter) with the error <samp>invalid_request</samp>. If omitted, the default value is <samp>false</samp>.</font></dd><br class="gmail-Apple-interchange-newline"></div><div><br></div><div><b>2) enforcing request object encryption</b> - this one I didn't quite figure out a vector for yet</div><div><b><br></b></div><div>why are current parameters not enough?</div><div><br></div><div><i>request_object_encryption_alg</i> states <i>"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."</i> so the request object may still be sent without encryption.</div><div>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.<br></div><div><br></div><div>Proposed client registration metadata:</div><div><dt style="color:rgb(0,0,0);font-size:13.3333px;margin-top:0.5em"><font face="monospace, monospace"><span style="font-size:13.3333px">request_object_encryption_alg_required</span><br></font></dt><dd style="color:rgb(0,0,0);font-size:13.3333px;margin-right:2em"><font face="monospace, monospace">OPTIONAL. Boolean value specifying whether the <samp>alg</samp> algorithm specified by <samp>request_object_encryption_alg</samp> MUST be used for encrypting Request Objects sent to the OP. When <samp>request_object_encryption_alg_required</samp> is <samp>true</samp> all Authorization Requests with Request Objects from this Client MUST be rejected with the error <samp>invalid_request_object</samp>, if not encrypted with this algorithm or not encrypted at all. When <samp>request_object_encryption_alg_required</samp> is <samp>true</samp>, <samp>request_object_encryption_alg </samp>MUST also be provided and this algorithm MUST be used both when the Request Object is passed by value (using the <samp>request</samp> parameter) and when it is passed by reference (using the <samp>request_uri</samp> parameter). If omitted, the default value is <samp>false</samp>.</font></dd><dt style="color:rgb(0,0,0);font-size:13.3333px;margin-top:0.5em"><font face="monospace, monospace">request_object_encryption_enc_required</font></dt><dd style="color:rgb(0,0,0);font-size:13.3333px;margin-right:2em"><font face="monospace, monospace">OPTIONAL. Boolean value specifying whether the <samp>enc</samp> algorithm specified by <samp>request_object_encryption_enc</samp> MUST be used for encrypting Request Objects sent to the OP. When <samp>request_object_encryption_enc_required</samp> is <samp>true</samp> all Authorization Requests with Request Objects from this Client MUST be rejected with the error <samp>invalid_request_object</samp>, if not encrypted with this algorithm or not encrypted at all. When <samp>request_object_encryption_enc_required</samp> is <samp>true</samp>, <samp>request_object_encryption_enc </samp>MUST also be provided and this algorithm MUST be used both when the Request Object is passed by value (using the <samp>request</samp> parameter) and when it is passed by reference (using the <samp>request_uri</samp> parameter). If omitted, the default value is <samp>false</samp>.</font></dd></div><div><br></div><div>Additionally, having these metadata defined allows an OP to send these in Dynamic Registration Response as a policy of sorts.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Since my IPR Agreement for FAPI WG is not yet processed someone please forward there.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature">Kind Regards,<br><b>Filip</b></div></div></div></div>