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