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

From: Dick Hardt <[email-masked]>
Date: Sun, 22 Nov 2020 17:05:55 -0800

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
ᐧ

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 23 Nov 2020 08:40:31 +0100

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 <[email-masked]> a écrit :

> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 23 Nov 2020 13:53:15 +0100

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 <[email-masked]>
wrote:

> In effect the client only has the ability to ask the server to generate
> the next transition.
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 23 Nov 2020 08:08:32 -0800

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

ᐧ

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 23 Nov 2020 17:29:59 +0100

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 <[email-masked]> wrote:

> If all the access token is doing is expressing "please continue" ... why
> do we need an access token?
>
>>> When I look at how GNAP is using access tokens for continuation
>>> requests, and the pull request #129
>>> 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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 23 Nov 2020 09:37:56 -0800

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 <[email-masked]>
wrote:

> If the client was directly managing/storing its state, then it would
> indeed effectively work as a cookie.
> Having a unique URL is a different design (XAuth was more aligned with
> that idea).
>
> Fabien
>
>
>>> As in any state machine, there are states and transitions. Here we're
>>> not passing state, merely expressing "please continue". The client can be
>>> 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
>>>
>>>
>>>> Those "access tokens" look a lot more like cookies (managing state)
>>>> than how access tokens are usually used (representing authorization). See
>>>> table below.
>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 23 Nov 2020 18:44:47 +0100

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 <[email-masked]> wrote:

>>> On Sun, Nov 22, 2020 at 11:40 PM Fabien Imbault <
>>> [email-masked]> wrote:
>>>
>>>> Hi Dick,
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 23 Nov 2020 09:51:18 -0800

If it is an access token, it may be a reference, but is more likely state,
and in the WG people talked about how the server could be stateless as all
state would be in the access token. In this thread, it looked like people
were thinking it would store state:

https://mailarchive.ietf.org/arch/msg/txauth/xPVdY74mytf83xLeyCGyoaV-gK8/

If it is just a reference, then it is an identifier, and then why not just
use a URL? The motivation for it to be an access token seemed to be to
store state.

/Dick
ᐧ

On Mon, Nov 23, 2020 at 9:45 AM Fabien Imbault <[email-masked]>
wrote:

>>>> If all the access token is doing is expressing "please continue" ...
>>>> why do we need an access token?
>>>>
>>>> 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
>>>>> 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.
>>>>>
>>>>> In effect the client only has the ability to ask the server to
>>>>> generate the next transition.
>>>>>

---

From: Justin Richer <[email-masked]>
Date: Mon, 23 Nov 2020 12:55:04 -0500

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> 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 <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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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
> access tokens
> - issued by an independent service (AS)
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Wed, 25 Nov 2020 12:26:48 -0800

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 <[email-masked]> 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?
>
> 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
>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 25 Nov 2020 21:33:37 +0100

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 <[email-masked]> a écrit :

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

---

From: Dick Hardt <[email-masked]>
Date: Wed, 25 Nov 2020 12:36:56 -0800

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 <[email-masked]>
wrote:

>> 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.
>>
>> 1) It follows the common REST like API model where each resource has a
>> URI which is well understood.
>>
>> 3) There is a standard, persistent unique identifier for the client and
>> AS to refer to a grant request.
>>
>>
>>> 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?
>>>
>>>> On Mon, Nov 23, 2020 at 8:30 AM Fabien Imbault <
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> ᐧ
>>>>>>
>>>>>>> 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.

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 25 Nov 2020 21:43:25 +0100

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 <[email-masked]> a écrit :

>> There is more context on the rationale, from the comments the editors
>> made to the issues yesterday.
>>
>>> 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.
>>>
>>>>> A client may use local storage for saving state, but that is
>>>>> completely different from an HTTP cookie which is issued by the server.
>>>>> ᐧ
>>>>>
>>>>>>>>> Those "access tokens" look a lot more like cookies (managing
>>>>>>>>> state) than how access tokens are usually used (representing
>>>>>>>>> authorization). See table below.
>>>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 26 Nov 2020 10:30:17 +0100

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 <[email-masked]>
wrote:

>>>> 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.
>>>>
>>>>> 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
>>>>> 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
>>>>> Yes. "Cookies were designed to be a reliable mechanism for websites
>>>>> to remember stateful <https://en.wikipedia.org/wiki/Program_state> information".
>>>>>>>> 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.
>>>>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Nov 2020 11:19:26 -0800

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 <[email-masked]>
wrote:

> 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).
>
>>> On Wed, Nov 25, 2020 at 12:33 PM Fabien Imbault <
>>>>> 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
>>>>> 3) There is a standard, persistent unique identifier for the client
>>>>> and AS to refer to a grant request.
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>>> 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.
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>