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

Fabien Imbault <fabien.imbault@gmail.com> Mon, 23 November 2020 16:30 UTC

Return-Path: <fabien.imbault@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 4EF213A099E for <txauth@ietfa.amsl.com>; Mon, 23 Nov 2020 08:30:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level:
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 1ETXtbbszn2l for <txauth@ietfa.amsl.com>; Mon, 23 Nov 2020 08:30:11 -0800 (PST)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 99FAF3A0997 for <txauth@ietf.org>; Mon, 23 Nov 2020 08:30:11 -0800 (PST)
Received: by mail-il1-x12d.google.com with SMTP id r17so4520227ilo.11 for <txauth@ietf.org>; Mon, 23 Nov 2020 08:30:11 -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=fBclA3/E57SPl+5Ywdny++4ikym9R4bzCethfJWA5xo=; b=SYTgP0IRLVnZ+jBibi9Wvp1enDm8sLG8j+o718Q8Yk73lN57ZS15XFnyyHQm31AFRg KRPCrrncUPPaTntOiZ3BsXoV2cnsw1WtdfuqnWwPuPF+Z+5MukDvBeOmXj4WdliiDUma pK9iDIEu+935qEzm/ZyjAEacZu/SGnKz1CLAxLw4lBPpxmYn//FotRBCHCo4b3IRgH2M VPQ5Tjz6qZqjR9ddAgxwckpBQbiHsRNt1YAsWHZQbrUrHvMEt8tabBfk95oqZjXiHEPH 5rDD1nBbMjSt6hPHShWLH+qMCaWNDbGgz6ci0yqbj5UGPQAe+pDrSkbf7bz62aoTBih+ lxrA==
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=fBclA3/E57SPl+5Ywdny++4ikym9R4bzCethfJWA5xo=; b=gPwgZy/Pouz7amHKoxUV3SbpEzen/a22vJVE1Fcy7OrM/UEU71x1xjRFAj4ytwWTDn FQUVlOSONci2bdIs7mYxhWVHMu02xHwh7Gc7FrB/v9n8pX+2p33FWGjVdgFhSyioFgmZ P3Yx4C4Pg3C7aaEMAORNrVvs1JRJMTS9p0nBKxAfa3n/hv6dGqwtwMvaWeQ4fnLgx0H0 OhN+2ETPv4JDZvmHFLOuSVNOX1t9E0+HMsFfS4/IvbRLBQ/C2jVe6v2cTPWMnyHcul1N QRSllvQP/gsJDJlCqKakUrbtAp+DNyAmE+kRhhX4VdBiXpDTijLLqXpu0lu4Gu/7NkhX jX5g==
X-Gm-Message-State: AOAM532CA2cHr5BQ9XfSrCInvzmX6yFgvBG2C0d9SxwbOsTJqoTL94WH qsjrQn34b4g13+8X80Ki7kgZCb2IMQ7m5Y/FPMk=
X-Google-Smtp-Source: ABdhPJypmnEe4Tx2HjcvB+tpKIkVAKafAqgIjwmlGSEtYfxxd3lUOXn3IC0fCPpc3WzJo8FEE79AvOK9mVvGbQFnLKE=
X-Received: by 2002:a92:6b05:: with SMTP id g5mr478935ilc.289.1606149010922; Mon, 23 Nov 2020 08:30:10 -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>
In-Reply-To: <CAD9ie-vpURieTiZpeCfLscPCtU1VY_CrtOP3UAxFogku6gL0iw@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Mon, 23 Nov 2020 17:29:59 +0100
Message-ID: <CAM8feuRLNwvN9VP2w9L9WYtSTpyUR1Wbe8nT88RKb6jhaMWY6w@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000409fd505b4c8b582"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/0IR0JF0stptqtlS68npudR028G0>
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: Mon, 23 Nov 2020 16:30:13 -0000

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