<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle19
{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="#0563C1" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">HI Michael,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">On 1; Public client support is removed, the security issues are well documented with public clients however <u>this does not mean native app clients are not supported</u>. A native
app, particularly on modern smart phones, can and should be implemented as private clients.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">RB<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;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="color:black">From: </span></b><span style="color:black">Openid-specs-fapi <openid-specs-fapi-bounces@lists.openid.net> on behalf of "Peck, Michael A via Openid-specs-fapi" <openid-specs-fapi@lists.openid.net><br>
<b>Reply to: </b>Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Date: </b>Sunday, 15 March 2020 at 18:04<br>
<b>To: </b>Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Cc: </b>"Peck, Michael A" <mpeck@mitre.org><br>
<b>Subject: </b>[Openid-specs-fapi] Questions / comments on FAPI 2.0 Baseline Profile<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi all,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I have some questions and comments on the current draft of the FAPI 2.0 Baseline Profile (<a href="https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md">https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md</a>).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I’m new here, please let me know if I’m misunderstanding something / if these are more appropriate for the issue tracker instead.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">1.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The profile appears to not allow public clients. Is that intentional? If so, why not – are native app clients not an intended use case?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">(Requirements for Authorization Servers #9 states “MUST authenticate clients” and Requirements for Clients #4 states “MUST support client authentication”, which to me preclude public clients.)</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">2.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The profile requires that resource servers verify the revocation status of access tokens (Requirements for Resource Servers #3). Is this practical?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Requirements for Authorization Servers #15 states “MUST provide a means for resource servers to verify the validity, integrity, sender-constraining, scope…expiration and revocation status of an access token,
either by providing an introspection endpoint…by exposing signature verification keys, or by deployment-specific means.”</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I would think the revocation status requirement would force the resource server to connect back to the authorization server (to its introspection endpoint or other “deployment-specific means”) every time an
access token is presented, which might not always be feasible?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I don’t see how “exposing signature verification keys” would suffice to meet the revocation status verification requirement?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Another option might be to weaken the MUST for verifying revocation status of access tokens, add a requirement that the AS limit the lifetime of access tokens, and ensure that the AS check the revocation status
of refresh tokens when they are presented? That would enable resource servers to more safely accept access tokens without having to reach back to the AS every time to check revocation status?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">3.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Requirements for Resource Servers #6 states “MUST identify the associated entity to the access token”.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">What does “associated entity” mean? Does it mean the subject of the access token?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">4.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Cryptography and Secrets #3 states “authorization servers MUST provide a client secret that adheres to the requirements…if a symmetric key is used.”</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I think this statement should be removed since the profile does not allow a symmetric key / client secret to be used for client authentication?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Mike</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Michael Peck</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The MITRE Corporation</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">+1-410-272-5959</span><o:p></o:p></p>
</div>
</body>
</html>