CIBA: Signed Authentication Request

[Dave Tonge]

The new CIBA core profile defines a signed authentication request. Should this be mandated by the FAPI profile?

As it is a backchannel request and we require strong client auth for this endpoint, there probably isn't a strong security reason to require it.

Advantages are:

• non-repudiation? it this a real need?
• guarantees that pairwise identifiers can be used in poll / ping mode (if a jwks_uri is used)

[Luke Popplewell]

At present CIBA FAPI states that the auth server "shall authenticate the confidential client at the backchannel authentication endpoint using a Signed Request Object". However some would-be OpenID providers have indicated they wish to only use MTLS for client auth but at the same time support RP jwks URIs for request object signature validation/non-repudiation.

[Dave Tonge]

I've merged in a PR that brings the FAPI CIBA draft in line with the latest core CIBA spec.

So in the current draft that clause isn't there.

The new core spec supports the use case you describe. RPs now authenticate at the backchannel endpoint using whatever auth methods they've configured for the token endpoint. But they can still send a signed request as well.

What I'm not sure about is whether we should require the use of the signed request for FAPI CIBA profile, or leave it as optional.

[Luke Popplewell]

Do those RPs that use mtls for client auth in FAPI RW and dont have a jwks uri need to provide a jwks by value at registration to the auth server or can the private key that is paired to the public key in the transport client cert be used to sign a request object JWT (which is mandatory under FAPI RW) ? The OpenID provider could convert the public key to a JWK to validate the request object signature but it sounds messy.

[Brian Campbell]

non-repudiation? it this a real need?

I'd always kind of assumed there was a need/want for something like non-repudiation-ishness where the OP/AS could have/keep an easily verifiable record of the request that initiated the OOB authn/authz. The whole CIBA flow opens new avenues for potential abuse and places added trust/burden on the client to play a part in prevent it. So having a nice record of the client requests seemed useful for tracking and dispute resolution kinds of things.

That's some of my reasoning for supporting the signed authentication request it in core CIBA. I don't know if that rises to the level of requiring it here in FAPI.

[Dave Tonge]

@lukepopp I think we need to add some clarification around this area. The assumption is that the RP has to either provide a jwks by value or a jwks_uri. OIDC says:

The private key used to sign the content MUST be associated with a public key used for signature verification published by the sender in its JWK Set document.

So I think thats clear that you can't just derive the keys from a cert. But I'm not sure if we reference that directly in FAPI.

I'll raise another issue to deal with this :-)

[Luke Popplewell]

Thanks Dave. Issues follow me wherever I go :-)

[Dave Tonge]

I propose that we add this requirement in. As Brian mentioned CIBA places an increased trust burden on the Client and I therefore think it would be good to have this requirement.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/91/make-the-fapi-ciba-profile-require-signed/diff

[Dave Tonge]

Closed as PR has been merged

[Joseph Heenan]

Reopening this to reconsider based on the discussion on https://bitbucket.org/openid/fapi/pull-requests/125/ciba-let-as-determine-whether-signed/diff

[Dave Tonge]

Resolving as this PR was merged: https://bitbucket.org/openid/fapi/pull-requests/125/ciba-let-as-determine-whether-signed/diff