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

[Dick Hardt <[e-mail]>]

Fabien: the issues 84 and 55 are unrelated.

The issues you bring up are related to a unique callback URL provided by
the client to the AS -- I am referring to the URL representing the grant
request that is provided by the AS to the client.

wrt issue 67 -- I'm proposing we NOT have an "access token" -- we keep it
simple by having only a unique URL

ᐧ

On Thu, Nov 26, 2020 at 1:30 AM Fabien Imbault <[e-mail]>
wrote:

> Hi there,
>
> We have had several discussions that are related to your items, especially
> related to unique URLs:
>
> * Use of hash with unique callback URL
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
>
> * Unique callback URIs
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55
>
> We tried to describe the rationale for the suggested choice as best we could. Please comment on the issues if needed.
>
> As for issue 67 / PR 129, the general idea is to make use of access tokens (here also we explained why, but feel free to comment the PR, ideally I'd like to review it after yours, so that I can take it into account).
>
> * Refactor key presentation
> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/130
>
> Fabien
>
>
> On Wed, Nov 25, 2020 at 9:43 PM Fabien Imbault <[e-mail]>
> wrote:
>
>> 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
>>>>>>
>>>>>>
>>>>>>