<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Good point!</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">What about this?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">AS...</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">" * MUST provide a means for resource
servers to verify the validity, integrity, expiration and
revocation status of access tokens, either by providing an
introspection endpoint [@!RFC7662], by exposing signature
verification keys, or by deployment-specific means."</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regarding Joseph's point of
short-lived, unrevocable ATs, I propose to add a note:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">"Note: In deployments using exclusively
short-lived access tokens that cannot be revoked, RS and AS do not
need to use or provide means for checking the revocation status."</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">What do you think?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">-Daniel</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Am 27.02.20 um 14:09 schrieb Ralph
Bragg:<br>
</div>
<blockquote type="cite"
cite="mid:8FD1F078-CB5A-44D9-A38F-5013253665C7@raidiam.com">
<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:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{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>
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Small
one from me Daniel<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>Requirements
for Authorization Servers<o:p></o:p></b></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Doesn’t
include explicitly the requirement to support a means of
validating that an access token is still valid. I had to add
this to the Open Banking security profile to force banks to
either share the keys with their RS’s or expose an
introspection endpoint. I know it’s stupid but can we please
make sure that if there is an explicit requirement to
validate an access token on the RS then there is an explicit
obligation to provide a means to do so on the AS.<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"><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
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-fapi-bounces@lists.openid.net"><openid-specs-fapi-bounces@lists.openid.net></a> on
behalf of Joseph Heenan via Openid-specs-fapi
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-fapi@lists.openid.net"><openid-specs-fapi@lists.openid.net></a><br>
<b>Reply to: </b>Financial API Working Group List
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-fapi@lists.openid.net"><openid-specs-fapi@lists.openid.net></a><br>
<b>Date: </b>Thursday, 27 February 2020 at 10:37<br>
<b>To: </b>Daniel Fett <a class="moz-txt-link-rfc2396E" href="mailto:fett@danielfett.de"><fett@danielfett.de></a><br>
<b>Cc: </b>Joseph Heenan <a class="moz-txt-link-rfc2396E" href="mailto:joseph@authlete.com"><joseph@authlete.com></a>,
Openid-specs-fapi
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-fapi@lists.openid.net"><openid-specs-fapi@lists.openid.net></a><br>
<b>Subject: </b>Re: [Openid-specs-fapi] FAPI 2.0<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Thanks Daniel - a few responses inline: <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">(Any points I removed I agree with your
response - thanks!)<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 27 Feb 2020, at 08:12, Daniel
Fett <<a href="mailto:fett@danielfett.de"
moz-do-not-send="true">fett@danielfett.de</a>>
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">Thanks for the feedback,
Joseph! Answers inline.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Am 26.02.20 um 17:23 schrieb
Joseph Heenan:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Thanks Daniel! <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A few quick initial thoughts:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">"2.4. Differences to FAPI
1.0” the first column doesn’t seem quite right -
as this is the base line profile should it be
comparing against FAPI-R rather than FAPI-RW?<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">It
is based off FAPI-RW. To reach the security goals,
it is easier to start from RW. If we find that we
can give some leeway, we can reintroduce features
from R. (Baseline and Advanced are not just new
names for R and RW.)<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">Good answer :-) I think it’s also a
reasonable position given I believe we’re not aware of
deployments of FAPI-R.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I have some concerns about
FAPI 2.0 baseline only allowing MTLS for client
authentication.As it stands today this still
adds quite a burden on RPs, compared to FAPI-R
which did allow simple RP credentials.<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Currently,
RPs need MTLS anyway for sender-constraining of the
AT. Therefore I'm not sure if RP credentials would
actually make things easier.<o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal">Good point.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think it would be interesting to
discuss whether dPoP would meet the goals and is something
we could include as an alternative. DPoP feels to me to be
easier for clients than MTLS (and potentially servers too
- the certification team has seen a LOT of people struggle
to get MTLS working on production systems due to issues
with WAFs and similar that are required for PCI
compliance).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">RS Checking access tokens are
not revoked ("MUST verify that the access token
is neither expired nor revoked;”) is also very
strong language in a baseline profile, and
appears to rule out the implementation choice of
having short lived JWT access tokens that cannot
be revoked.<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">That
is actually taken from the current R spec. How I
read it, it still allows for unrevokable short-lived
JWTs, since if they are never revoked, the check
always passes.<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal">Interesting, I never noticed that before.
We may want to make the language a little clearer in both
places I guess.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Joseph<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>