[Openid-specs-mobile-profile] Issue #146: client_notification_token seem redundant (openid/mobile)

[Dave Tonge]

New issue 146: client_notification_token seem redundant
https://bitbucket.org/openid/mobile/issues/146/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.