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

[Fabien Imbault <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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 <
>>> [e-mail]> 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 <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>