<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
samp
        {mso-style-priority:99;
        font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#002060;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#002060">Thanks for sending this, Filip.  I’ve added some initial thoughts inline below, prefixed by “Mike>”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><b>From:</b> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net>
<b>On Behalf Of </b>Filip Skokan via Openid-specs-ab<br>
<b>Sent:</b> Saturday, August 11, 2018 6:50 AM<br>
<b>To:</b> openid-specs-ab@lists.openid.net Ab <openid-specs-ab@lists.openid.net>; openid-specs-fapi@lists.openid.net<br>
<b>Cc:</b> Filip Skokan <panva.ip@gmail.com><br>
<b>Subject:</b> [Openid-specs-ab] Proposal for "Required Request Object Use" Dynamic Registration extension<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hello everyone,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>1) signaling that a request object must always be present in Client's authorization requests</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">why are current parameters not enough?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Proposed client registration metadata:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-top:6.0pt"><span style="font-size:10.0pt;font-family:"Courier New";color:black">request_object_required</span><span style="font-size:10.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:24.0pt;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt">
<span style="font-size:10.0pt;font-family:"Courier New";color:black">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>.</span><span style="font-size:10.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">Mike> It’s not clear to me that this is needed.  Rather, we could clarify that if “</span><i>request_object_signing_alg</i><span style="color:#002060">” 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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>2) enforcing request object encryption</b> - this one I didn't quite figure out a vector for yet<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">why are current parameters not enough?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">Mike> This parameter (and the “enc” variant) are about telling the OP about the encryption capabilities of the RP.  This is one half of the algorithm negotiation.  I believe that it’s the OP’s decision whether
 to require encryption of request objects – not the RP’s.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal">Proposed client registration metadata:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-top:6.0pt"><span style="font-size:10.0pt;font-family:"Courier New";color:black">request_object_encryption_alg_required</span><span style="font-size:10.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:24.0pt;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt">
<span style="font-size:10.0pt;font-family:"Courier New";color:black">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>.</span><span style="font-size:10.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-top:6.0pt"><span style="font-size:10.0pt;font-family:"Courier New";color:black">request_object_encryption_enc_required</span><span style="font-size:10.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:24.0pt;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt">
<span style="font-size:10.0pt;font-family:"Courier New";color:black">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>.</span><span style="font-size:10.0pt;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Additionally, having these metadata defined allows an OP to send these in Dynamic Registration Response as a policy of sorts.<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">Mike> First, these two parameters really should just be one – if adopted, because what you’re really saying is that encryption is required.  (It just happens that you need two algorithms values to say *<b>how</b>*
 the encryption is done.)  And again, I believe that the OP can already require the use of encryption by publishing “request_object_encryption_alg_values_supported” and  “request_object_encryption_enc_values_supported” metadata values.  I believe that adding
 this RP metadata value would likely be redundant.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Since my IPR Agreement for FAPI WG is not yet processed someone please forward there.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal">Kind Regards,<br>
<b>Filip<o:p></o:p></b></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">Mike> Let’s talk about this on one of the upcoming working group calls.</span><br clear="all">
<span style="color:#002060"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">                                                       Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">                                                       -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>