<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 2019-05-09 17:09, Takahiko Kawasaki
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHdPCmNCpSspN6U6Z4k1P5fR5FRxc_OJH-TYGJTMEh3j7QJQWQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr">Dear Anders,</div>
          </div>
        </div>
      </div>
    </blockquote>
    Hello Kawasaki-san,<br>
    I made a few comments in line.<br>
    <br>
    I see that you do interesting things on GitHub.  I may even try
    "nv-websocket" if I have more time...<br>
    <br>
    <blockquote type="cite"
cite="mid:CAHdPCmNCpSspN6U6Z4k1P5fR5FRxc_OJH-TYGJTMEh3j7QJQWQ@mail.gmail.com">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr">
              <div><br>
              </div>
              <div>I read draft-cavage-http-signatures for the first
                time just now.</div>
              <div><br>
              </div>
              <div>According to the specification, when a server
                receives a request, the server uses keyId to look up a
                public key whereby to verify the signature attached to
                the request. However, details of keyId are left to each
                implementation. Therefore, it is even possible for a
                server implementation to make all clients share one
                private key although it may sound ridiculous. Of course,
                such server implementation cannot distinguish clients
                from the signature.</div>
              <div><br>
              </div>
              <div>If a server implementation wants to make each client
                use their own private key, the server implementation has
                to be able to look up a corresponding public key of each
                client from keyId. This implies that keyId has to be
                associated with information whereby for the server
                implementation to identify the client making the request
                and look up the client's public key. However, the
                specification does not define anything about how to
                identify a client from keyId and how to manage public
                keys of clients. So, if I were told to implement the
                specification, I would start from inventing my own rule
                for keyId.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    As a PKI-man since 20 years back I also had a problem with this. 
    However, a keyId + public pey is what is powering FIDO which
    intended for very large scale authentication.  Anyway, if PKI
    support is a requirement, it should be a relatively simple thing to
    add.  The true strength of PKI seem to be when there are one-2-many
    connections and an established identity concept.  <br>
    <br>
    <just4fun><br>
    In spite of my background in PKI I'm currently working with more
    flexible schemes where a connecting party provides a URL to its
    "accreditor".   Why is that?  Well, PKI is great but not as an
    information resource.  Here is a live example of such a URL: <a
      class="moz-txt-link-freetext"
      href="https://mobilepki.org/webpay-payeebank/payees/86344">https://mobilepki.org/webpay-payeebank/payees/86344</a><br>
    These schemes depend on that all messages are signed.  By using the
    "accreditor" as sole external reference you limit the number of
    parties (and fuzz) needed to get a trust network running.  Selling
    eIDAS certificate services for PSD2 is likely to be a pretty poor
    business. <br>
    </just4fun><br>
    <br>
    <blockquote type="cite"
cite="mid:CAHdPCmNCpSspN6U6Z4k1P5fR5FRxc_OJH-TYGJTMEh3j7QJQWQ@mail.gmail.com">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr">
              <div><br>
              </div>
              <div>In contrast, OpenID Connect already has
                infrastructure for (1) client identifiers (client_id in
                RFC 6749), (2) server-side key management (jwks and
                jwks_uri in OIDC Discovery), (3) client-side key
                management (jwks and jwks_uri in OIDC Dynamic Client
                Registration) and (4) signing and encryption rules (RFC
                7515 to RFC 7519).</div>
              <div><br>
              </div>
              <div>In the context of OAuth/OIDC/FAPI, I think there are
                three points where message integrity may be desired. The
                following are the three points.</div>
              <div><br>
              </div>
              <div>1. Connection between a client and an authorization
                endpoint of authorization server</div>
              <div>2. Connection between a client and a token endpoint
                of authorization server</div>
              <div>3. Connection between a client and a protected
                resource endpoint of resource server</div>
              <div><br>
              </div>
              <div>For 1, Request Object (OIDC Core, Section 6) exists
                for message integrity of requests and JARM (JWT Secured
                Authorization Response Mode for OAuth 2.0) exists for
                message integrity of responses. If JARM is not
                supported, ID Token can be used as detached signature
                (FAPI Part 2, Section 5.1).</div>
              <div><br>
              </div>
              <div>For 2, the combination of PKCE (RFC 7636) and mutual
                TLS with certificate-based client authentication (MTLS,
                Section 2) is probably enough, but my understanding may
                be wrong.</div>
              <div><br>
              </div>
              <div>For 3, the combination of certificate-bound access
                tokens (MTLS, Section 3) and mutual TLS is probably
                enough, but my understanding may be wrong.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I guess my personal interest mainly is in #3 because that is the
    generic R/W scenario which in most cases involve signed data and
    outside of Open Banking often even without mutual TLS.  The related
    message from Philippe Leothaud to this list is also worth looking
    into.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAHdPCmNCpSspN6U6Z4k1P5fR5FRxc_OJH-TYGJTMEh3j7QJQWQ@mail.gmail.com">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr">
              <div><br>
              </div>
              <div>Therefore, it might be difficult to find imminent and
                strong need to officially adopt yet another
                specification for message integrity in the context of
                OAuth/OIDC/FAPI.</div>
              <div><br>
              </div>
              <div>From an implementer's point of view, lack of the
                concept of client identifiers and key management
                infrastructure might be a kind of hurdle to discuss
                draft-cavage-http-signature deeply here in this FAPI
                Working Group although the specification seems great as
                a generic solution for HTTP message integrity.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I see.  Anyway, thanks for the feedback!<br>
    <br>
    Best<br>
    Anders Rundgren<br>
    <br>
    <blockquote type="cite"
cite="mid:CAHdPCmNCpSspN6U6Z4k1P5fR5FRxc_OJH-TYGJTMEh3j7QJQWQ@mail.gmail.com">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr">
              <div><br>
              </div>
              <div>Best Regards,</div>
              <div>Takahiko Kawasaki</div>
              <div>Authlete, Inc.</div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div><br>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">2019年5月9日(木) 14:40 Anders
          Rundgren via Openid-specs-fapi <<a
            href="mailto:openid-specs-fapi@lists.openid.net"
            moz-do-not-send="true">openid-specs-fapi@lists.openid.net</a>>:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear
          Chair & List,<br>
          <br>
          To me it looks close to ridiculous publicly downplaying <a
            href="https://datatracker.ietf.org/doc/draft-cavage-http-signatures/"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://datatracker.ietf.org/doc/draft-cavage-http-signatures/</a>
          without providing an alternative.<br>
          <br>
          If nobody within the OpenID community is even interested in
          this matter, why the concern?<br>
          <br>
          Please provide a plan on how to resolve this issue, or simply
          accept that <a
            href="https://datatracker.ietf.org/doc/draft-cavage-http-signatures/"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://datatracker.ietf.org/doc/draft-cavage-http-signatures/</a>
          is the de-facto standard for (at least) Open Banking.  The
          industry in general (as proven by this case) does not seems to
          have any major issues with de-facto standards.<br>
          <br>
          If OpenID/FAPI intend to wait another year addressing this
          issue, the de-facto status will be cemented.  Personally I see
          no problems if that would be the case.  The authors also seem
          open to input.<br>
          <br>
          sincerely,<br>
          Anders<br>
          _______________________________________________<br>
          Openid-specs-fapi mailing list<br>
          <a href="mailto:Openid-specs-fapi@lists.openid.net"
            target="_blank" moz-do-not-send="true">Openid-specs-fapi@lists.openid.net</a><br>
          <a
            href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>