<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:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">As a follow up there are some implementations which are making use of the jwt authorization grant that currently use client_id within the grant to perform client authentication. I’ve seen this used
 as and it is being proposed as a means of getting around the 90 day re-auth where a TPP can attest in a way that can be validated that it has obtained ongoing re-authorization from its customer without the customer being present.<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">https://tools.ietf.org/html/rfc7523#section-2.1<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The tokens are still sender constrained to tls but the authentication mechanism is performed by signing it also protects the “scope” parameter as this can be included inside the JWT. To reiterate,
 I’m fully onboard with sender constrains but I have concerns about push back and subsequent adoption if we force everyone to support tls_client_auth… especially as tls_client_auth is explicitly excluded by the Australian CDR.
<a href="https://consumerdatastandardsaustralia.github.io/standards/#end-points">
https://consumerdatastandardsaustralia.github.io/standards/#end-points</a><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">Ralph Bragg <ralph.bragg@raidiam.com><br>
<b>Date: </b>Thursday, 27 February 2020 at 13:50<br>
<b>To: </b>Torsten Lodderstedt <torsten@lodderstedt.net>, Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Cc: </b>Daniel Fett <fett@danielfett.de><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"><span style="mso-fareast-language:EN-US">Hi,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:Symbol">·</span>  MUST <span style="background:yellow;mso-highlight:yellow">
support client authentication</span> and sender-constraining of access tokens using Mutual TLS as described in [@!RFC8705]<o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">From a security point of view, MTLS is an edge device capability, private_key_jwt is preferred by many security folks, myself included that are worried about request alteration from within network
 segments that are behind the edge MATLS gateway. I also have concerns about this – immediately Australian CDR would be not FAPI compliant in anyway.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Sender constrained using MTLS but that can be done without mandating client authentication as well.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Be interested in others thoughts.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Kind Regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Ralph</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></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">Ralph Bragg <ralph.bragg@raidiam.com><br>
<b>Date: </b>Thursday, 27 February 2020 at 13:36<br>
<b>To: </b>Torsten Lodderstedt <torsten@lodderstedt.net>, Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Cc: </b>Daniel Fett <fett@danielfett.de><br>
<b>Subject: </b>Re: [Openid-specs-fapi] FAPI 2.0</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Nope – just the fact that if an RS must do something then then an AS must provide a means of doing it and potentially describing how. Introspection? Shared keys for AT decryption? Either works.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">We were pretty good in the OB security profile to make sure both sides, where mutuality of obligation is required was detailed in the requirements.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></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">Torsten Lodderstedt <torsten@lodderstedt.net><br>
<b>Date: </b>Thursday, 27 February 2020 at 13:30<br>
<b>To: </b>Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Cc: </b>Daniel Fett <fett@danielfett.de>, Ralph Bragg <ralph.bragg@raidiam.com><br>
<b>Subject: </b>Re: [Openid-specs-fapi] FAPI 2.0</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Are you referring to validity beyond „exp“, i.e. checking for revocation?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">Am 27.02.2020 um 14:09 schrieb Ralph Bragg via Openid-specs-fapi <openid-specs-fapi@lists.openid.net>:<o:p></o:p></p>
</blockquote>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Small one from me Daniel</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>Requirements for Authorization Servers</b><o:p></o:p></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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></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 Joseph Heenan 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>Thursday, 27 February 2020 at 10:37<br>
<b>To: </b>Daniel Fett <fett@danielfett.de><br>
<b>Cc: </b>Joseph Heenan <joseph@authlete.com>, Openid-specs-fapi <openid-specs-fapi@lists.openid.net><br>
<b>Subject: </b>Re: [Openid-specs-fapi] FAPI 2.0</span><o:p></o:p></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>
<br>
<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">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>
<br>
<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>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-fapi mailing list<br>
Openid-specs-fapi@lists.openid.net<br>
http://lists.openid.net/mailman/listinfo/openid-specs-fapi<o:p></o:p></p>
</div>
</blockquote>
</div>
</body>
</html>