[Openid-specs-fapi] OpenID/FAPI alternative to draft-cavage-http-signatures
taka at authlete.com
Thu May 9 15:09:46 UTC 2019
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
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.
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
2. Connection between a client and a token endpoint of authorization server
3. Connection between a client and a protected resource endpoint of
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.
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
2019年5月9日(木) 14:40 Anders Rundgren via Openid-specs-fapi <
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
> 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.
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi