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

Hi there,

Following Justin's feedback, I made an alternative proposal: make the key
verification the default everywhere, and allow bearer tokens for resources
access only when set explicitly.
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67#issuecomment-732119398

I believe this removes the confusion.

Fabien

On Mon, Nov 23, 2020 at 8:40 AM 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
>>
>