client_notification_token seem redundant

[Dave Tonge]

I'm opening this issue based on some emails on the list:

From Eric Fazendin:

auth_req_id and client_notification_token seem redundant. Unless we can clarify why both are necessary, I suggest we remove client_notification_token from the spec.

Based on 7.1, it's described as "It is a bearer token provided by the Client that will be used by the OpenID Provider to authenticate the callback request to the Client."

10.2 and 10.3.1 says, "The Client MUST verify the client_notification_token used to authenticate the request is valid and is associated with the auth_req_id received in the Ping callback."

There is no further elaboration of why it's needed or what additional value it might provide the client. Examples suggest it is in a GUID format. Perhaps it could be a JWT and therefore reduce the state required to manage by the client, but it's not cryptographically bound to the auth_req_id, so the client is going to have to track the state of a given client_notification_token as being associated to a given auth_req_id.

auth_req_id is described in 7.3 as "This is a unique identifier to identify the authentication request made by the Client."

7.4 says, "The Client MUST keep the auth_req_id in order to validate the callbacks received in Ping and Push modes or to use when making a token request in Poll and Ping modes."

I don't understand the value of the client_notification_token when there is also the auth_req_id. The client_notification_token adds unnecessary complexity to client implementations. If the client wants to track authentication requests and associate them to Ping and Push Callbacks, they can do so with only the auth_req_id.

[Dave Tonge]

From memory the idea of the client notification token was to protect the notification endpoint for what we now call "Push" mode. I think the concept was to not overload the auth_req_id to be both an identifier and a "bearer token" and I suppose to give a bit of extra security in case the auth_req_id leaked. Given that the Client generates the client_notification_token I suppose it gives a bit more architectural flexibility - i.e. the Client could protect its notification endpoint in a similar manner to other endpoints that it has, perhaps rejecting requests with a bad client notification token at an API gateway level before the request even reaches the application logic that would look up the auth_req_id.

However I tend to agree that it is now redundant. Poll Ping mode doesn't really need such a token, and in Push mode we've tightened up the spec such that the ID Token is a detached signature that the Client must verify. I'll open an issue in the tracker so we can discuss on the next call.

[Dave Tonge]

Thanks Brian, good catch - I've edited my comment

[Takahiko Kawasaki]

"rejecting requests with a bad client notification token at an API gateway level" sounds convincing to me.

Clients can decide the value of a client notification token so that the value can be most suitable for being processing at an API gateway level. On the other hand, clients cannot know the value of auth_req_id until they get a response from the backchannel authentication endpoint and it is only after receiving auth_req_id that clients can set up filtering with the value at an API gateway level (if they want to do filtering there).

I'm not so sure CIBA client developers really want to do filtering at an API gateway level, but at least such implementation can be written, for example, by using Amazon API Gateway Lambda Authorizer.

[Brian Campbell]

I guess I would ask if the extra parameter and associated processing rules in the spec and the additional implementation complexity placed on clients and ASs as a result is necessarily worth having in support of a hypothetical architecture.

[Dave Tonge]

I'm torn on this one. On the one hand I would prefer the spec to be as simple as possible, but on the other hand if we think as the ping mode as following the "webhook" model, then best practice seems to be to have some kind of signature or other form of authentication as part of the webhook request.

[Brian Campbell]

The general consensus on the Jan 8th 2019 call http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20190107/001408.html was not to make any change and leave client_notification_token in.

[Joseph Heenan]

An interesting note in case this comes up again: the OB UK specs ( https://github.com/OpenBankingUK/read-write-api-docs-pub/blob/v3.1.4-draft2/profiles/read-write-data-api-profile.md#identifying-the-psu-using-an-intent-id ) assumes that it is safe to publish the auth_req_id in a QR code, meaning that removing the client_notification_token would definitely introduce at least some kind of DoS attack.