CIBA Client Notification Endpoint Authentication

[Axel Nennker]

The Client Notification Endpoint is protected by a Bearer Token issued by the Client to the CIBA Authentication Endpoint through the Authentication Request.

Can we do better than Bearer Tokens?

[Axel Nennker]

Dave Tonge (FAPI) suggested that the result should be signed by the OP.

Should the spec recommend signing without specifying more? Or should CIBA recommend a signing method?

[Dave Tonge]

current suggestion (still under discussion) is that the ID Token contains at_hash it will then act as a detached signature.

[Axel Nennker]

Maybe I should rephrase the issue: Do we need to be better than Bearer Tokens?

I think that these tokens are short lived and reasonably secure. If FAPI is OK with the authentication mechanism then I propose to close the issue.

Applications of CIBA can always require at_hash to be part of the id_token. I think that is a separate point. I would not rely on at_hash for authentication alone.

[John Bradley]

The at_hash is about the AT that AS issues not the one that the client is providing for the call back so that is a separate issue.

We could say something hand wavy like if the AS and client have negotiated mutual TLS out of band the client can require the AS to use its certificate for mutual TLS to the call back endpoint to do proof of possession.

Unless the AS were to put the token binding ID that it intends to use on the callback in a new claim in the id_token I don't see any other way to do POP in a way that adds anything. This is possible but should be an extension if anything.

[Dave Tonge]

So, we could just leave the spec to rely on the TLS connection when authentication request is made and when the notification is sent. For the FAPI profile I'm still keen to add auth_req_is and at_hash to the id_token as it binds the id_token, access token and auth_req_id together and gives an extra level of assurance to the RP.

[Dave Tonge]

In the fapi draft we currently have this:

1. when sending a successful token notification shall include the access token hash, at_hash, in the ID Token;
2. when sending a successful token notification, with a refresh token, shall include the refresh token hash, rt_hash, in the ID Token;
3. when sending a successful token notification shall include the auth_req_id, in the ID Token;

The following is a non-normative example of a base64url decoded ID Token sent to the client notification endpoint:

 {
   "iss": "http://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "rXH7QWVTZnXYCou_6Vdpfg",
   "rt_hash": "njCczNMR6mTQQTPa93YPcQ",
   "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1"
  }

[Gonzalo Fernández]

Dave Tonge's proposal has been accepted: at_hash and auth_req_id will be added to the id_token, and in case of sending refresh_tokens to the client, the rt_hash will be addedd too. A reference to the at_hash value calculation will be added.

[Gonzalo Fernández]

The commits d5c8e7a and e1d8ef7 serve to close the issue #54.

[Gonzalo Fernández]

See commits d5c8e7a and e1d8ef7.