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

Fabien Imbault <fabien.imbault@gmail.com> Mon, 23 November 2020 07:40 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 3B05A3A1684 for <txauth@ietfa.amsl.com>; Sun, 22 Nov 2020 23:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.195
X-Spam-Level:
X-Spam-Status: No, score=-0.195 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, RCVD_IN_DNSWL_BLOCKED=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 qnnGWtoM5pBN for <txauth@ietfa.amsl.com>; Sun, 22 Nov 2020 23:40:45 -0800 (PST)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 808A53A167E for <txauth@ietf.org>; Sun, 22 Nov 2020 23:40:45 -0800 (PST)
Received: by mail-ej1-x62c.google.com with SMTP id f23so21911812ejk.2 for <txauth@ietf.org>; Sun, 22 Nov 2020 23:40:45 -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=pIk8OLnNzyq70PSLfgzLdZddBokTuaVyQClXHYE4K90=; b=NynI0oNC+X8VW5V2XPKLMz1WTgcXMqQmjzEiY22pmgIy3kF2dUJOWH5KjSUQMjGX+V a1VMjmxwY3ycU93SgqZplLFA3LQr5/CNyF4FMjiqKlaPWUC/Mjdmq+Of76e9fG6yZdmj rhW7LzEfI9Qxe/uxuKg8JxMRamw10MWAGLwuwksN/m0iLzOtMr6FV9iTBd0UIj+P9cU1 aYW2WRLwWJP5V0ngivAvfbnwmYr7CjlvnHfYK44dszZrlzvJfWCy5lW0Ky3GsLj+ng1w UI7r0j7q6PSjJiSeOeuTDq8bUFf4Lpnw9TEcYb5a2VY72Gd8F/gdSDWaSle5KkndaxYM m9kg==
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=pIk8OLnNzyq70PSLfgzLdZddBokTuaVyQClXHYE4K90=; b=Bntp1ptLG2AlJuseOMU46s4w4EH4J2n/ygQKdoGAxr2V5/5aeiGeHFVdn5suUcN5K/ EXnlRD99fRqpPT6JYJ3w43pLLRowGUebXPN18S+HNHdjRIbs0fbQG6kBrvQLjtpffkIc acIShXkuf4NIrbvBn2YeI1t4kuHAZ9r76S6iY6h+vOnNXqMgjzmMriT9SeKsPwUH765W Y3ncSYPU7NP7jsNG8X+o6VfOVK6qDEgTH2IsELzjAu6Wfgsmg7xU6UgDb9+jipwwuSxx jqkD8lm9LQp2/qtemTrolr7Q10cp4AMlr2RcPerd2evxa0RvdNOf36PpnaTUjeoTIiJl CkUQ==
X-Gm-Message-State: AOAM53369Ra1MsdwXmLdO5lQXJcTypyVgKjj+BEOP+m+Y5ix/xrigvEa FNRjVQPVkwWg7Otsndmo10JOXQT58J3oHPHlETU=
X-Google-Smtp-Source: ABdhPJxMh0sFO9mFwB7vSlKGBzm+3wLZLp6K2k7yBitwmkI8kRZHqKr2DYSGhf4oxFrzIq3f9zGTf1wWDun8QyfCFgA=
X-Received: by 2002:a17:906:3704:: with SMTP id d4mr6950010ejc.338.1606117243799; Sun, 22 Nov 2020 23:40:43 -0800 (PST)
MIME-Version: 1.0
References: <CAD9ie-vKSpV6eC3CUPzwFog5yOb+zeshLJC7+8RgNeF9CNFiww@mail.gmail.com>
In-Reply-To: <CAD9ie-vKSpV6eC3CUPzwFog5yOb+zeshLJC7+8RgNeF9CNFiww@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Mon, 23 Nov 2020 08:40:31 +0100
Message-ID: <CAM8feuSh0q3mf+KapqV7Sxo+k9GSaibAbGwK7J2vPh-EAAprwQ@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c8ce5805b4c14f0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/5Hmau2R5oBvZduDIIMZRvmfmE24>
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 07:40:47 -0000

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
>