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

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