<div dir="ltr"><div>individual issues now filed and linked inline below<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 18, 2020 at 9:41 AM Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I wasn't sure if raising individual issues was appropriate or needed. But I'm happy to do so, if it helps facilitate the process of discussion and resolution. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 18, 2020 at 8:51 AM Ralph Bragg <<a href="mailto:ralph.bragg@raidiam.com" target="_blank">ralph.bragg@raidiam.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div>
<p class="MsoNormal"><span>Cheers Brian for this - Can we get these raised as issues / discussion points separately (unless they’re accepted as tabled).<u></u><u></u></span></p>
<p class="MsoNormal"><span>I would really like to support in particular:<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Headers:<u></u><u></u></span></p>
<p class="MsoNormal"><span>+1 on removing the ‘x-‘ it was a mistake the first time around but it had snuck into implementations.<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Dpop:<u></u><u></u></span></p>
<p class="MsoNormal"><span>Dpop support would be great as it would potentially give an avenue for fapi compliant mobile based confidential clients that can’t rely on mtls.<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>RB<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-color:rgb(181,196,223) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:12pt;color:black">From: </span></b><span style="font-size:12pt;color:black">Openid-specs-fapi <<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@lists.openid.net</a>> on behalf of Brian Campbell via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Reply to: </b>FAPI Working Group List <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Date: </b>Wednesday, 18 November 2020 at 15:41<br>
<b>To: </b>FAPI Working Group List <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Cc: </b>Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>><br>
<b>Subject: </b>Re: [Openid-specs-fapi] FAPI 2.0 Attacker Model and Baseline: Implementer's Draft?<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">Thanks Daniel, <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">These two documents are shaping up nicely and I love the relative simplicity vs. the v1.0 stuff. That said, I do have the following feedback, questions, comments, etc., which I believe should be addressed/discussed before progressing the
documents:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think some introductory content in the Introduction section of Baseline is needed. This will likely be the entry point (I think anyway?) for many readers so some intro or context setting or something here is important.</p></div></div></div></div></blockquote></div></blockquote><div><br></div><div><a href="https://bitbucket.org/openid/fapi/issues/337/intro-text-in-basline">https://bitbucket.org/openid/fapi/issues/337/intro-text-in-basline</a></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><div><div><p class="MsoNormal"><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">With "shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [OIDD] and [RFC8414]"in baseline, is the "A5 - Read Token Requests and Responses" really relevant?
<u></u><u></u></p>
</div>
</div></div></div></blockquote></div></blockquote><div><br></div><div><a href="https://bitbucket.org/openid/fapi/issues/338/a5-attacker-model">https://bitbucket.org/openid/fapi/issues/338/a5-attacker-model</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><div><div><p class="MsoNormal"><u></u></p>
</div>
<div>
<p class="MsoNormal">A7 & A8 in the attacker model read like they are grouped in with "Attackers at the Token Endpoint". Maybe a new heading for 'attackers at resources' or something would organize them better?</p></div></div></div></div></blockquote></div></blockquote><div><br></div><div><a href="https://bitbucket.org/openid/fapi/issues/339/resources-token-endpoint">https://bitbucket.org/openid/fapi/issues/339/resources-token-endpoint</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><div><div><p class="MsoNormal"><u></u><u></u></p>
</div>
<div>
</div>
<div>
<p class="MsoNormal">"shall reject authorization requests sent without [@I-D.lodderstedt-oauth-par] or authorization request parameters sent outside of the PAR request, except for
<code><span style="font-size:10pt">request_uri</span></code> and <code><span style="font-size:10pt">client_id"</span></code><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Request parameters outside shouldn't require rejection, rather they just must not be relied upon so should be ignored. The end of
<a href="https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30#section-5" target="_blank">
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30#section-5</a> even talks about why a client might send parameters duplicated outside. Also the I-D.lodderstedt-oauth-par reference should be I-D.ietf-oauth-par.
</p></div></div></div></div></blockquote></div></blockquote><div><br></div><div><a href="https://bitbucket.org/openid/fapi/issues/340/treatment-of-authorization-request">https://bitbucket.org/openid/fapi/issues/340/treatment-of-authorization-request</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><div><div><p class="MsoNormal"><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">"shall only issue sender-constrained access tokens using Mutual TLS as described in [@!RFC8705]" and "shall support sender-constrained access tokens using Mutual TLS as described in [@!RFC8705]"<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Why not allow for DPoP too? MTLS just isn't accessible in a lot of cases and mandating it is severely limiting the applicability of FAPI2.
</p></div></div></div></div></blockquote></div></blockquote><div><br></div><div><a href="https://bitbucket.org/openid/fapi/issues/341/free-dpop">https://bitbucket.org/openid/fapi/issues/341/free-dpop</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><div><div><p class="MsoNormal"><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">"shall only issue authorization codes and refresh tokens that are sender-constrained "
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">What's the intent of having this? The two previous items requiring client auth and PKCE mean a priori that the RT is sender-constrained and the auth code is constrained twice. But this text maybe suggests something else. Or is redundant.
I'm not sure.</p></div></div></div></div></blockquote></div></blockquote><div><br></div><div><a href="https://bitbucket.org/openid/fapi/issues/342/sender-constrained-auth-codes-refresh">https://bitbucket.org/openid/fapi/issues/342/sender-constrained-auth-codes-refresh</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><div><div><p class="MsoNormal"><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">"shall require the <code><span style="font-size:10pt">redirect_uri</span></code> parameter in authorization requests and evaluate only this parameter to ensure authenticity and integrity of the redirect URI"<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">What does "evaluate only this parameter to ensure authenticity and integrity" mean? I don't know and don't know how I'd do it. I'm guessing this text is somehow related to wanting to allow non-static redirect URIs to be sent in authenticated
PAR. But I can't tell what it actually means or how one would conform to this (other than requiring the redirect_uri parameter).</p></div></div></div></div></blockquote></div></blockquote><div><br></div><div><a href="https://bitbucket.org/openid/fapi/issues/343/what-is-authenticity-and-integrity-of-the">https://bitbucket.org/openid/fapi/issues/343/what-is-authenticity-and-integrity-of-the</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><div><div><p class="MsoNormal"><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">"... x-fapi-auth-date ... " etc<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I'll note that x- naming is not what the cool kids are doing these days
<a href="https://tools.ietf.org/html/rfc6648" target="_blank">https://tools.ietf.org/html/rfc6648</a></p></div></div></div></div></blockquote></div></blockquote><div><br></div><div><a href="https://bitbucket.org/openid/fapi/issues/344/x-isnt-cool-anymore">https://bitbucket.org/openid/fapi/issues/344/x-isnt-cool-anymore</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><div><div><p class="MsoNormal">
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">"Access tokens shall be non-guessable with a minimum of 128 bits of entropy where the probability of an attacker guessing the generated token is less than or equal to 2^(-160) as per [@!RFC6749] section 10.10."
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Should ATs be the only artifact for which we give such requirements? There are also RTs, auth codes, request_uri values from PAR, and maybe other stuff I'm forgetting.
</p></div></div></div></div></blockquote></div></blockquote><div><br></div><div><a href="https://bitbucket.org/openid/fapi/issues/345/its-okay-if-a-refresh-token-can-be-guessed">https://bitbucket.org/openid/fapi/issues/345/its-okay-if-a-refresh-token-can-be-guessed</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><div><div><p class="MsoNormal"><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Nov 17, 2020 at 5:25 AM Daniel Fett via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p>Hi all,<u></u><u></u></p>
<p>as discussed in last week's call, I revised the FAPI 2.0 Baseline and Attacker Model documents again and I think that they are in a good shape.<u></u><u></u></p>
<p>I'd like to hear your feedback if we can proceed with the next steps for this document becoming an implementer's draft.<u></u><u></u></p>
<p>These are the two documents:<u></u><u></u></p>
<p><a href="https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Attacker_Model.md" target="_blank">https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Attacker_Model.md</a>
<u></u><u></u></p>
<p><a href="https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md" target="_blank">https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md</a>
<u></u><u></u></p>
<p>Thanks,<br>
Daniel<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre><a href="https://danielfett.de" target="_blank">https://danielfett.de</a><u></u><u></u></pre>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<b><i><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(85,85,85);border:1pt none windowtext;padding:0cm">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s).
Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</span></i></b><u></u><u></u></p>
</div>
</div>
</blockquote></div>
</blockquote></div></div>
<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</font></span></i>