[Openid-specs-fapi] OpenID/FAPI alternative to draft-cavage-http-signatures

Anders Rundgren anders.rundgren.net at gmail.com
Fri May 10 13:52:41 UTC 2019


On 2019-05-09 17:09, Takahiko Kawasaki wrote:
> Dear Anders,
Hello Kawasaki-san,
I made a few comments in line.

I see that you do interesting things on GitHub.  I may even try "nv-websocket" if I have more time...

>
> I read draft-cavage-http-signatures for the first time just now.
>
> 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.
>
> 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.

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.

<just4fun>
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: https://mobilepki.org/webpay-payeebank/payees/86344
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.
</just4fun>

>
> 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).
>
> 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.
>
> 1. Connection between a client and an authorization endpoint of authorization server
> 2. Connection between a client and a token endpoint of authorization server
> 3. Connection between a client and a protected resource endpoint of resource server
>
> 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).
>
> 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.
>
> For 3, the combination of certificate-bound access tokens (MTLS, Section 3) and mutual TLS is probably enough, but my understanding may be wrong.

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.

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

I see.  Anyway, thanks for the feedback!

Best
Anders Rundgren

>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
>
>
>
>
> 2019年5月9日(木) 14:40 Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>>:
>
>     Dear Chair & List,
>
>     To me it looks close to ridiculous publicly downplaying https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ without providing an alternative.
>
>     If nobody within the OpenID community is even interested in this matter, why the concern?
>
>     Please provide a plan on how to resolve this issue, or simply accept that https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ 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.
>
>     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.
>
>     sincerely,
>     Anders
>     _______________________________________________
>     Openid-specs-fapi mailing list
>     Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20190510/d1fe1007/attachment-0001.html>


More information about the Openid-specs-fapi mailing list