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 >>> >>> >>>
- [GNAP] "Access Token" when calling AS is really a… Dick Hardt
- Re: [GNAP] "Access Token" when calling AS is real… Fabien Imbault
- Re: [GNAP] "Access Token" when calling AS is real… Fabien Imbault
- Re: [GNAP] "Access Token" when calling AS is real… Dick Hardt
- Re: [GNAP] "Access Token" when calling AS is real… Fabien Imbault
- Re: [GNAP] "Access Token" when calling AS is real… Dick Hardt
- Re: [GNAP] "Access Token" when calling AS is real… Fabien Imbault
- Re: [GNAP] "Access Token" when calling AS is real… Dick Hardt
- Re: [GNAP] "Access Token" when calling AS is real… Justin Richer
- Re: [GNAP] "Access Token" when calling AS is real… Dick Hardt
- Re: [GNAP] "Access Token" when calling AS is real… Fabien Imbault
- Re: [GNAP] "Access Token" when calling AS is real… Dick Hardt
- Re: [GNAP] "Access Token" when calling AS is real… Fabien Imbault
- Re: [GNAP] "Access Token" when calling AS is real… Fabien Imbault
- Re: [GNAP] "Access Token" when calling AS is real… Dick Hardt