<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Dear Anders,<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><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><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><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">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">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">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">Openid-specs-fapi@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
</blockquote></div>