FAPI-CIBA: Client Authentication at Backchannel Authentication Endpoint

[Takahiko Kawasaki]

It would be kind to state explicitly that client authentication at the backchannel authentication endpoint should follow the guidance written in the FAPI spec. Especially, about the natural conclusion that the following are affected by FAPI requirements.

1. Client authentication method (client_secret_basic and client_secret_post are not allowed. client_secret_jwt is not allowed for Read-and-Write. private_key_jwt, tls_client_auth, self_signed_tls_client_auth are allowed for both Read-Only and Read-and-Write)
2. Size of signing key of client assertion (RSA: 2048 or larger, EC: 160 or larger)

[Joseph Heenan]

This was intended to be pulled in via “The Authorization Server shall support the provisions specified in clause 5.2.2 of Financial-grade API - Part 1 and clause 5.2.2 of Financial-grade API - Part 2.”

‌

but FAPI part 2 says:

shall authenticate the confidential client at the token endpoint using one of the following methods (this overrides FAPI part 1 clause 5.2.2.4):

‌

so technically the spec allows you to use other methods at back channel endpoint, but you’d still be restricted at the token endpoint.

‌

The key size restrictions already apply to FAPI-CIBA, I’m not sure a change is needed there.

[Takahiko Kawasaki]

My interpretation of CIBA Core is that the client authentication method at the backchannel authentication endpoint and that at the token endpoint should or must be the same.

The first clause of 5.2.2 of the FAPI-CIBA profile says "shall only support Confidential Clients for Client Initiated Backchannel Authentication flows", and this is a complete duplicate of a requirement in CIBA Core. Likewise, the FAPI spec also includes duplicate requirements which are found in OIDC Core and RFC 6749. The convention seems to be like "it's okay to duplicately mention inherited requirements that are likely to be overlooked and/or should be emphasized." This is the reason I said "would be kind to mention" (not "must mention") client authentication at the backchannel authentication endpoint.

My personal experience is that soon after I thought I had finished implementing the FAPI-CIBA profile, I noticed that I hadn't checked client authentication method / signature algorithm of client assertion / size of signing key of client assertion at the backchannel authentication endpoint. If the FAPI-CIBA profile kindly reminded me that client authentication at the backchannel authentication endpoint would be affected by the requirements written in the FAPI spec, I wouldn't have forgotten to implement the additional validation.

If people agree that CIBA Core allows a client to use other client authentication method at the backchannel authentication endpoint which is different from the client authentication method at the token endpoint, additional validation for client authentication at the backchannel authentication endpoint is not needed (= not imposed by FAPI). In the case, the FAPI-CIBA profile doesn't have to mention client authentication method. However, other implementers might have the same concerns as I have.

[Dave Tonge]

To discuss on the next call.

We will also open a new issue about broadening the client authentication requirements in part 2 so they apply to all endpoints not just the token endpoint.

[Joseph Heenan]

https://bitbucket.org/openid/fapi/issues/261/part-1-2-client-authentication opened as per Dave’s comment.

[Joseph Heenan]

@Takahiko Kawasaki We discussed this on the WG call yesterday and the consensus seemed to be that now FAPI-R/FAPI-RW state that the client authentication restrictions apply to all endpoints (and those clauses are referred to in FAPI-CIBA) that this can be closed - let us know if you feel something requires further clarification.