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

[Fabien Imbault <[e-mail]>]

Couldn't say I agree here.

Will send more info and explanations when I reopen my laptop tomorrow
morning :-)

Fabien

Le mer. 25 nov. 2020 à 21:37, Dick Hardt <[e-mail]> a écrit :

> Would you share a link? I see the discussion on the access token pull
> request, but no discussion on unique URLs.
>
> Do you agree with my assessment of the "access token"?
>
> ᐧ
>
> On Wed, Nov 25, 2020 at 12:33 PM Fabien Imbault <[e-mail]>
> wrote:
>
>> Hi Dick,
>>
>> There is more context on the rationale, from the comments the editors
>> made to the issues yesterday.
>>
>> Especially the part on unique URLs.
>>
>> Best
>> Fabien
>>
>>
>> Le mer. 25 nov. 2020 à 21:27, Dick Hardt <[e-mail]> a écrit :
>>
>>>
>>> There are numerous issues with the proposal:
>>>
>>> 1) It is not an "access token". Just because it is sent in the HTTP
>>> Authorization header does not make it an access token. The client has
>>> already authenticated before the "access token" is presented. The AS
>>> already knows what the client is authorized to do at the AS before the
>>> "access token" is issued, so it is not needed to represent authorization as
>>> an access token is with an RS. The "access token" is serving the purpose
>>> that the transaction handle served in the past -- the context of the
>>> transaction. Per my earlier comments, this "access token" is more like a
>>> cookie.
>>>
>>> 2) Calling it an "access token" is changing the well known meaning of an
>>> access token as used in OAuth. The client authenticates to the AS APIs in
>>> OAuth 2.0, it does not present an access token. Access tokens are presented
>>> by a client to an RS to prove authorization.
>>>
>>> 3) What the client has to do with the "access token" is not the same as
>>> access tokens for an RS. The client gets a new "access token" for each
>>> grant request, and for each API call to the AS, and the client learns it
>>> can not make any more API calls for that specific request when it does not
>>> get an "access token" back. This is a completely different design pattern
>>> than calling an RS API with an access token, and is a new design pattern
>>> for calling APIs. This adds complexity to the client that it would not
>>> normally have, and I don't think GNAP is the right place to start a new
>>> design pattern.
>>>
>>> 4) Clients that only want claims from the AS and no access tokens will
>>> be required to support an API calling mechanism they would not have to
>>> support otherwise.
>>>
>>> 5) If the AS does not provide an "access token", there is no mechanism
>>> for a client to delete the request, as the client is not allowed to make a
>>> call without an "access token".
>>>
>>> 6) There is no standard identifier for the request. Debugging and
>>> auditing are hampered by the client and AS having no standard way to
>>> identifying a request. While one AS may provide a unique URL for each grant
>>> request, another AS may use a persistent "access token" to identify the
>>> grant request, and other ASs may issue a new "access token" on each API
>>> call, providing no persistent identifier for the request.
>>>
>>> Representing each grant request with an unique URL has the following
>>> advantages:
>>>
>>> 1) It follows the common REST like API model where each resource has a
>>> URI which is well understood.
>>>
>>> 2) There is only one way for a client and AS to identify a grant request.
>>>
>>> 3) There is a standard, persistent unique identifier for the client and
>>> AS to refer to a grant request.
>>>
>>>
>>> FWIW: the statement that it is more "access token" like than a cookie
>>> because it is bound to a key is untrue. Binding cookies to keys was the
>>> motivation for RFC 8471 - The Token Binding Protocol Version 1.0. Having
>>> the "access token" bound to a key provides no value as the AS already knows
>>> which client it is through client authentication. The only time that would
>>> not be the case is if the "access token" was self contained and the grant
>>> request APIs were at an server independent of the AS where the original
>>> request was made.
>>>
>>>
>>>
>>>
>>> ᐧ
>>>
>>> On Mon, Nov 23, 2020 at 9:55 AM Justin Richer <[e-mail]> wrote:
>>>
>>>> An important distinction here is that the access tokens in question are
>>>> always going to be bound to a key for presentation purposes, so in many
>>>> ways they are quite distinct from cookies.
>>>>
>>>> Since “continuation” in its various forms is now an API, why not treat
>>>> it like other APIs the client would call and use access tokens?
>>>>
>>>> Apart from design choices, what is the negative cost of requiring an
>>>> access token?
>>>>
>>>> We aren’t asking the client to do anything it’s not already doing. Even
>>>> if the client is going to use bearer tokens at a downstream RS, the
>>>> signature presentation mechanism for the bound access token at the
>>>> continuation API is exactly the same as what the client used in the first
>>>> place to get the continuation response.
>>>>
>>>> We aren’t asking the AS to do anything special either since it already
>>>> needs to be able to validate the signature inbound, and it needs to be able
>>>> to reference an artifact for the ongoing request (stateful or not).
>>>>
>>>>  — Justin
>>>>
>>>> On Nov 23, 2020, at 12:44 PM, Fabien Imbault <[e-mail]>
>>>> wrote:
>>>>
>>>> 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
>>>>>>>>>
>>>>>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>
>>>>