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

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