CIBA: client authentication at the backchannel authentication endpoint

[Takahiko Kawasaki]

"7.1.1. Signed Authentication Request" says that JWTs used as the value of the request request parameter "MUST be secured with an asymmetric signature". This description makes me feel like confirming consensus on client authentication at the backchannel authentication endpoint.

Regarding client authentication at the backchannel authentication endpoint, "7.1. Authentication Request" says as follows.

The Client MUST authenticate to the Backchannel Authentication Endpoint using the authentication method registered for its client_id, such as the authentication methods from Section 9 of [OpenID.Core] or authentication methods defined by extension in other specifications.

The client authentication methods listed in Section 9 of "OpenID Connect Core 1.0" are as follows (excluding none).

• client_secret_basic
• client_secret_post
• client_secret_jwt
• private_key_jwt

In addition, client authentication methods defined in "OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens" are as follows.

• tls_client_auth
• self_signed_tls_client_auth

If signature algorithms for the request object are intentionally limited to asymmetric ones, is there any hidden consensus which prohibits client authentication methods using a client secret (which is a shared symmetric key)? Or hasn't it been discussed yet?

BTW, if a TLS-based client authentication method is used, client_id is needed as a request parameter, or some other means to identify the client ID is needed anyway.

[Dave Tonge]

Hi @authlete-taka so regarding client authentication we intentionally wanted CIBA to be in line with how the client already authenticates at the token endpoint.

So the consensus (from my memory) is that while we would obviously prefer asymmetric client auth methods we don't think that CIBA itself should concern itself with that. The FAPI profile of CIBA will limit client auth methods in the same manner that FAPI part 2 does.

You do raise a point about the fact that client_id may need to be sent as a request param, I'll open a PR to make that clearer.

[Brian Campbell]

I elected to use asymmetric and only asymmetric for Signed Authentication Requests because non-repudiation like features was a primary motivation (as I understood things anyway) for having the functionality and so limiting to asymmetric made sense while also not introducing another potential reason for the AP/OP to have to store the client secret in reversible form (as is needed for HMAC). What was done for Signed Authentication Requests, however, has no direct bearing on client authentication and CIBA doesn't prohibit the symmetric styles of client authentication.

Some of the different client authentication methods do use request parameters so yeah the backchannel authentication endpoint needs to be able to handle whatever client authn modes are supported by the AS. They will be application/x-www-form-urlencoded request parameters in both the 'normal' backchannel authentication request and signed backchannel authentication request cases.

[Dave Tonge]

Hi @b_d_c I'm struggling with wording for this. Do you think we need a PR?

I was thinking we could perhaps change this:

An authentication request is composed of the following parameters and MAY contain additional parameters defined by extension or profile:

to

An authentication request is composed of the following parameters and MAY contain additional parameters required by the client authentication method used or defined by extension or profile:

This phrase "could" I suppose be misinterpreted:

The signed authentication request JWT is passed as an application/x-www-form-urlencoded HTTP request parameter with the name request, which is the only HTTP request parameter that has meaning in the case of a signed CIBA authentication request.

But I'm struggling to come up with alternative wording...

[Brian Campbell]

Despite my confident talk on the call earlier, I've struggled with the wording quite a bit too :)

I did put some words together in pull request #51 that aren't terribly elegant but I think are accurate and hopefully clarify things somewhat.

[Dave Tonge]

I think the PR looks good, thanks Brian

[Brian Campbell]

Thanks for the review @dgtonge. I've merged pull request #51 and am marking this one as resolved.