Re: [GNAP] "Access Token" when calling AS is really a cookie

Dick Hardt <dick.hardt@gmail.com> Wed, 25 November 2020 20:37 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAE13A1CB6 for <txauth@ietfa.amsl.com>; Wed, 25 Nov 2020 12:37:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sMwR_i73NGg for <txauth@ietfa.amsl.com>; Wed, 25 Nov 2020 12:37:39 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18BD73A1CAA for <txauth@ietf.org>; Wed, 25 Nov 2020 12:37:35 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id s27so4978629lfp.5 for <txauth@ietf.org>; Wed, 25 Nov 2020 12:37:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3qtCwpBwqHv0zeXiuMBvJimAM3Abeg6/JXDhZOXCtLA=; b=myz0+mcuqX70l5pcAbnyEdRmjJmnNootsTdn++hqHtano0C+qDGn6sZ9Xon0pHpxZW cVdV02vCYJxXOhQyrHDc6gTKpmdOdOFVoAIzwvRijWd8sqhE4FcY16CiVE3YssydE3bz vEoFH4y/c3Ac2bmKjyOyMvpvIJ12QwqoSYW2CXZ7TzIurvheL3N3wrxaB+otbJv7Ahhe 7hpf9qMawYCzzWvrUTTbHKMub3wmEa5BLaCFYLsK5B/g0DpBYJCRAmLtfhvAnSspMsVS lcPKFEomfI51MKzn36jkQGxU+UrWwD41SHEvzf7e5qKRrZhr6Q4VcYtVThZO7GrdfyJx a+Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3qtCwpBwqHv0zeXiuMBvJimAM3Abeg6/JXDhZOXCtLA=; b=jrmb3HkTI98qNRhcKCV7XwDGgn/7c+P4b3x9/xb+EghE3hI/f2Ipy0k/HbnzpYFQDh 5xC1NG02M2zcN6cK2I1iutntkFw1sjSYFjS5y1k4lJwg7EExJl9+gKQJ8XpmqSD+ZSLB vlEGG5Nx/FwhktQGR7ffB2mYfR+xaIpDmZM9F05SQu+OtNfWR+/5LsQOpOfq+WeT4QE0 9UoxSv9nKSOk6UdwoQrmwqHmPGOE/09/nid8jjOPk9h9Q5SvkeSr8td2lkzY0EnPM9Yy 9VtZd1tewJR9K6rb6t/3sbu7RuLXd0AFFUOXlw1NW8Ns8faFDEYekHDgfRm9lyAW2g7p uw+g==
X-Gm-Message-State: AOAM531YjFtzjN8LjcvgNo8QI8szb29TMtUdO++bP18YgPx2HbmOMJZJ DqZKjdqMDZDtfkCTrCXHZDmsMYp3m5jptrPIK40=
X-Google-Smtp-Source: ABdhPJy8ZLobH7WXy6yY7dhCEnCQhhQm5J6F9JzlpEr8JOQZZPxdAtNkhU2icWceuoclfD495GEzUSsq4Vh15Cv2Kx0=
X-Received: by 2002:a05:6512:3047:: with SMTP id b7mr243274lfb.210.1606336653063; Wed, 25 Nov 2020 12:37:33 -0800 (PST)
MIME-Version: 1.0
References: <CAD9ie-vKSpV6eC3CUPzwFog5yOb+zeshLJC7+8RgNeF9CNFiww@mail.gmail.com> <CAM8feuSh0q3mf+KapqV7Sxo+k9GSaibAbGwK7J2vPh-EAAprwQ@mail.gmail.com> <CAD9ie-vpURieTiZpeCfLscPCtU1VY_CrtOP3UAxFogku6gL0iw@mail.gmail.com> <CAM8feuRLNwvN9VP2w9L9WYtSTpyUR1Wbe8nT88RKb6jhaMWY6w@mail.gmail.com> <CAD9ie-vnZH-zexJ8yiRyozzbCLJKe1sVVfoeKtgysUG32UhAGQ@mail.gmail.com> <CAM8feuT3DLCOc7nj2zS4XLy4ktZ5TaBJv=W52YnEY8DzWfyvZA@mail.gmail.com> <9D3D60CC-5019-4CC2-BE2D-4EF789FABE31@mit.edu> <CAD9ie-tN82_Mqb1BvdkZsnKT2Tt5L0i0P_V9hWAFknXn=G1nxQ@mail.gmail.com> <CAM8feuSv5=dr-2YhQx5SwxX9fu0DZ3o2zKyMeG4-iS3OXqVLhQ@mail.gmail.com>
In-Reply-To: <CAM8feuSv5=dr-2YhQx5SwxX9fu0DZ3o2zKyMeG4-iS3OXqVLhQ@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Wed, 25 Nov 2020 12:36:56 -0800
Message-ID: <CAD9ie-u_Vggw2prSXCR20wqn=cSiEj7QuwczqtzPb8_3hL+=EA@mail.gmail.com>
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000098843805b4f4657c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/nlIprcTmL9dwNVFpriObxNRCbEE>
Subject: Re: [GNAP] "Access Token" when calling AS is really a cookie
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2020 20:37:42 -0000

Would you share a link? I see the discussion on the access token pull
request, but no discussion on unique URLs.

Do you agree with my assessment of the "access token"?

ᐧ

On Wed, Nov 25, 2020 at 12:33 PM Fabien Imbault <fabien.imbault@gmail.com>
wrote:

> Hi Dick,
>
> There is more context on the rationale, from the comments the editors made
> to the issues yesterday.
>
> Especially the part on unique URLs.
>
> Best
> Fabien
>
>
> Le mer. 25 nov. 2020 à 21:27, Dick Hardt <dick.hardt@gmail.com> a écrit :
>
>>
>> There are numerous issues with the proposal:
>>
>> 1) It is not an "access token". Just because it is sent in the HTTP
>> Authorization header does not make it an access token. The client has
>> already authenticated before the "access token" is presented. The AS
>> already knows what the client is authorized to do at the AS before the
>> "access token" is issued, so it is not needed to represent authorization as
>> an access token is with an RS. The "access token" is serving the purpose
>> that the transaction handle served in the past -- the context of the
>> transaction. Per my earlier comments, this "access token" is more like a
>> cookie.
>>
>> 2) Calling it an "access token" is changing the well known meaning of an
>> access token as used in OAuth. The client authenticates to the AS APIs in
>> OAuth 2.0, it does not present an access token. Access tokens are presented
>> by a client to an RS to prove authorization.
>>
>> 3) What the client has to do with the "access token" is not the same as
>> access tokens for an RS. The client gets a new "access token" for each
>> grant request, and for each API call to the AS, and the client learns it
>> can not make any more API calls for that specific request when it does not
>> get an "access token" back. This is a completely different design pattern
>> than calling an RS API with an access token, and is a new design pattern
>> for calling APIs. This adds complexity to the client that it would not
>> normally have, and I don't think GNAP is the right place to start a new
>> design pattern.
>>
>> 4) Clients that only want claims from the AS and no access tokens will be
>> required to support an API calling mechanism they would not have to support
>> otherwise.
>>
>> 5) If the AS does not provide an "access token", there is no mechanism
>> for a client to delete the request, as the client is not allowed to make a
>> call without an "access token".
>>
>> 6) There is no standard identifier for the request. Debugging and
>> auditing are hampered by the client and AS having no standard way to
>> identifying a request. While one AS may provide a unique URL for each grant
>> request, another AS may use a persistent "access token" to identify the
>> grant request, and other ASs may issue a new "access token" on each API
>> call, providing no persistent identifier for the request.
>>
>> Representing each grant request with an unique URL has the following
>> advantages:
>>
>> 1) It follows the common REST like API model where each resource has a
>> URI which is well understood.
>>
>> 2) There is only one way for a client and AS to identify a grant request.
>>
>> 3) There is a standard, persistent unique identifier for the client and
>> AS to refer to a grant request.
>>
>>
>> FWIW: the statement that it is more "access token" like than a cookie
>> because it is bound to a key is untrue. Binding cookies to keys was the
>> motivation for RFC 8471 - The Token Binding Protocol Version 1.0. Having
>> the "access token" bound to a key provides no value as the AS already knows
>> which client it is through client authentication. The only time that would
>> not be the case is if the "access token" was self contained and the grant
>> request APIs were at an server independent of the AS where the original
>> request was made.
>>
>>
>>
>>
>> ᐧ
>>
>> On Mon, Nov 23, 2020 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
>>
>>> An important distinction here is that the access tokens in question are
>>> always going to be bound to a key for presentation purposes, so in many
>>> ways they are quite distinct from cookies.
>>>
>>> Since “continuation” in its various forms is now an API, why not treat
>>> it like other APIs the client would call and use access tokens?
>>>
>>> Apart from design choices, what is the negative cost of requiring an
>>> access token?
>>>
>>> We aren’t asking the client to do anything it’s not already doing. Even
>>> if the client is going to use bearer tokens at a downstream RS, the
>>> signature presentation mechanism for the bound access token at the
>>> continuation API is exactly the same as what the client used in the first
>>> place to get the continuation response.
>>>
>>> We aren’t asking the AS to do anything special either since it already
>>> needs to be able to validate the signature inbound, and it needs to be able
>>> to reference an artifact for the ongoing request (stateful or not).
>>>
>>>  — Justin
>>>
>>> On Nov 23, 2020, at 12:44 PM, Fabien Imbault <fabien.imbault@gmail.com>
>>> wrote:
>>>
>>> Yes. "Cookies were designed to be a reliable mechanism for websites to
>>> remember stateful <https://en.wikipedia.org/wiki/Program_state> information".
>>> We're not storing anything, it's just a reference.
>>>
>>> On Mon, Nov 23, 2020 at 6:38 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>>>
>>>> To clarify, I am talking about HTTP cookies, which are effectively
>>>> opaque to the web browser, and used by the web server to store state.
>>>>
>>>> https://en.wikipedia.org/wiki/HTTP_cookie
>>>>
>>>> A client may use local storage for saving state, but that is completely
>>>> different from an HTTP cookie which is issued by the server.
>>>> ᐧ
>>>>
>>>> On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault <
>>>> fabien.imbault@gmail.com> wrote:
>>>>
>>>>> If the client was directly managing/storing its state, then it would
>>>>> indeed effectively work as a cookie.
>>>>> But here the access token merely provides a map to the current state
>>>>> (opaque to the client), as managed/controlled by the AS.
>>>>> It's a very different use case compared to what cookies are used for
>>>>> in webapps.
>>>>>
>>>>> Having a unique URL is a different design (XAuth was more aligned with
>>>>> that idea).
>>>>>
>>>>> Fabien
>>>>>
>>>>>
>>>>> On Mon, Nov 23, 2020 at 5:09 PM Dick Hardt <dick.hardt@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> If all the access token is doing is expressing "please continue" ...
>>>>>> why do we need an access token?
>>>>>>
>>>>>> Why not just have a unique URL for the grant request? The URL is the
>>>>>> identifier for the grant request that allows the client to delete, update,
>>>>>> etc.
>>>>>>
>>>>>> How the access token is being used is just like a cookie. The AS
>>>>>> gives a string to the client and the client must pass the string back to
>>>>>> the AS when it calls it, the AS may then give a new string to the client
>>>>>> for the next call. Works like a cookie. I don't know why you think there
>>>>>> are legal issues around this.
>>>>>>
>>>>>> /Dick
>>>>>>
>>>>>>
>>>>>>
>>>>>> ᐧ
>>>>>>
>>>>>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault <
>>>>>> fabien.imbault@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Dick,
>>>>>>>
>>>>>>> In GNAP, the client isn't managing state (unlike a web app), the
>>>>>>> entire point is that the lifecycle should be managed by the AS.
>>>>>>>
>>>>>>> As in any state machine, there are states and transitions. Here
>>>>>>> we're not passing state, merely expressing "please continue". The client
>>>>>>> can be completely unaware of the underlying state.
>>>>>>> In effect the client only has the ability to ask the server to
>>>>>>> generate the next transition.
>>>>>>>
>>>>>>> So I don't think you can compare that to cookies. It's a different
>>>>>>> behavior. BTW if it was the case it would lead to a whole new class of
>>>>>>> issues, because there's an entire legal framework around cookies...
>>>>>>>
>>>>>>> To avoid confusion with a standard access token, we have the "key"
>>>>>>> field. My proposal would be to make it more explicitly (cf comment in issue
>>>>>>> 67).
>>>>>>>
>>>>>>> Fabien
>>>>>>>
>>>>>>>
>>>>>>> Le lun. 23 nov. 2020 à 02:06, Dick Hardt <dick.hardt@gmail.com> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> When I look at how GNAP is using access tokens for continuation
>>>>>>>> requests, and the pull request #129
>>>>>>>> <https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129>
>>>>>>>>
>>>>>>>> Those "access tokens" look a lot more like cookies (managing state)
>>>>>>>> than how access tokens are usually used (representing authorization). See
>>>>>>>> table below.
>>>>>>>>
>>>>>>>> If there is a real requirement for passing state back and forth
>>>>>>>> between a server (the AS in this case) and the client when making API
>>>>>>>> calls, then I suggest that is out of scope for GNAP as I see it being a
>>>>>>>> general purpose mechanism for any API.
>>>>>>>>
>>>>>>>> /Dick
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *cookies*- issued by server being accessed
>>>>>>>> - are not presented to other servers
>>>>>>>> - issued after first access
>>>>>>>> - may be different for different URLs
>>>>>>>> - may be updated on each access
>>>>>>>> - represents the context of a session (state)
>>>>>>>>
>>>>>>>>
>>>>>>>> *access tokens*- issued by an independent service (AS)
>>>>>>>> - may be used at any URL at the RS
>>>>>>>> - new ones issued by AS as needed
>>>>>>>> - represents authorization granted to a client at an RS
>>>>>>>> ᐧ
>>>>>>>> --
>>>>>>>> TXAuth mailing list
>>>>>>>> TXAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>
>>>>>>> --
>>> TXAuth mailing list
>>> TXAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>