<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>