<html 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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
code
{mso-style-priority:99;
font-family:"Courier New";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Cheers Brian for this - Can we get these raised as issues / discussion points separately (unless they’re accepted as tabled).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I would really like to support in particular:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Headers:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">+1 on removing the ‘x-‘ it was a mistake the first time around but it had snuck into implementations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Dpop:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">RB<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Openid-specs-fapi <openid-specs-fapi-bounces@lists.openid.net> on behalf of Brian Campbell via Openid-specs-fapi <openid-specs-fapi@lists.openid.net><br>
<b>Reply to: </b>FAPI Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Date: </b>Wednesday, 18 November 2020 at 15:41<br>
<b>To: </b>FAPI Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Cc: </b>Brian Campbell <bcampbell@pingidentity.com><br>
<b>Subject: </b>Re: [Openid-specs-fapi] FAPI 2.0 Attacker Model and Baseline: Implementer's Draft?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Thanks Daniel, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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:<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">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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?
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</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:10.0pt">request_uri</span></code> and <code><span style="font-size:10.0pt">client_id"</span></code><o:p></o:p></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.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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]"<o:p></o:p></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.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">"shall only issue authorization codes and refresh tokens that are sender-constrained "
<o:p></o:p></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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">"shall require the <code><span style="font-size:10.0pt">redirect_uri</span></code> parameter in authorization requests and evaluate only this parameter to ensure authenticity and integrity of the redirect URI"<o:p></o:p></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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">"... x-fapi-auth-date ... " etc<o:p></o:p></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>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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."
<o:p></o:p></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.
<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"><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"><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"><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">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p>Hi all,<o:p></o:p></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.<o:p></o:p></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.<o:p></o:p></p>
<p>These are the two documents:<o:p></o:p></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>
<o:p></o:p></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>
<o:p></o:p></p>
<p>Thanks,<br>
Daniel<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre><a href="https://danielfett.de" target="_blank">https://danielfett.de</a><o:p></o:p></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><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<b><i><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#555555;border:none windowtext 1.0pt;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><o:p></o:p></p>
</div>
</body>
</html>