[Openid-specs-mobile-profile] auth_req_id and client_notification_token seem redundant

[Dave Tonge]

Yep this is a good question.

>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 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



On Mon, 31 Dec 2018 at 16:24, Brian Campbell via
Openid-specs-mobile-profile <openid-specs-mobile-profile at lists.openid.net>
wrote:

> Eric raises a good question here that I don't have an immediate answer
> for. Honestly, I hadn't really thought critically about the purpose of the client_notification_token
> relative to what the auth_req_id provides. Perhaps someone who was
> involved when the client_notification_token concept was introduced can
> shed some light on the motivations behind it and if there's reason for it
> beyond what's mentioned here?
>
> On Mon, Dec 31, 2018 at 6:07 AM Eric Fazendin via
> Openid-specs-mobile-profile <openid-specs-mobile-profile at lists.openid.net>
> wrote:
>
>> 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.
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*_______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>


-- 
Dave Tonge
CTO
[image: Moneyhub Enterprise]
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20190102/8e0abc6e/attachment.html>