<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I'm fine with adding private_key_jwt
      back into Baseline. It seems that there are good reasons to do so.
      Security-wise, the difference to MTLS is negligible. <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">I will do so in the next commit. <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">-Daniel<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Am 27.02.20 um 15:22 schrieb Ralph
      Bragg:<br>
    </div>
    <blockquote type="cite"
      cite="mid:8366A1AB-B071-408E-849F-E8EDACE0B25F@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.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>
      <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"><a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc7523#section-2.1">https://tools.ietf.org/html/rfc7523#section-2.1</a><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"
              moz-do-not-send="true">
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
              <a class="moz-txt-link-rfc2396E" href="mailto:ralph.bragg@raidiam.com"><ralph.bragg@raidiam.com></a><br>
              <b>Date: </b>Thursday, 27 February 2020 at 13:50<br>
              <b>To: </b>Torsten Lodderstedt
              <a class="moz-txt-link-rfc2396E" href="mailto:torsten@lodderstedt.net"><torsten@lodderstedt.net></a>, 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>Cc: </b>Daniel Fett <a class="moz-txt-link-rfc2396E" href="mailto:fett@danielfett.de"><fett@danielfett.de></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"><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
              <a class="moz-txt-link-rfc2396E" href="mailto:ralph.bragg@raidiam.com"><ralph.bragg@raidiam.com></a><br>
              <b>Date: </b>Thursday, 27 February 2020 at 13:36<br>
              <b>To: </b>Torsten Lodderstedt
              <a class="moz-txt-link-rfc2396E" href="mailto:torsten@lodderstedt.net"><torsten@lodderstedt.net></a>, 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>Cc: </b>Daniel Fett <a class="moz-txt-link-rfc2396E" href="mailto:fett@danielfett.de"><fett@danielfett.de></a><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
              <a class="moz-txt-link-rfc2396E" href="mailto:torsten@lodderstedt.net"><torsten@lodderstedt.net></a><br>
              <b>Date: </b>Thursday, 27 February 2020 at 13:30<br>
              <b>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>Cc: </b>Daniel Fett <a class="moz-txt-link-rfc2396E" href="mailto:fett@danielfett.de"><fett@danielfett.de></a>, Ralph
              Bragg <a class="moz-txt-link-rfc2396E" href="mailto:ralph.bragg@raidiam.com"><ralph.bragg@raidiam.com></a><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
              <a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-fapi@lists.openid.net"><openid-specs-fapi@lists.openid.net></a>:<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
                  <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</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"
                        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>
                  <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>
              <a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.openid.net</a><br>
              <a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><o:p></o:p></p>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>