Subject: [GNAP] Consensus Call on Continuation Request

From: Justin Richer <[email-masked]>
Date: Thu, 10 Dec 2020 10:52:01 -0500

The editors and chairs would like to confirm consensus on a current pull request:

https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 <https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129>

This pull request simplifies the continuation response and request by making the access token mandatory, and it clarifies the responsibilities of the AS in enforcing the security of the continuation request. Several WG members expressed specific support for keeping the access token to enable specific use cases, and there was general support for simplifying the process from what it currently is in the draft. The editors believe the pull request represents a solution that meets these goals.

This call is open until Monday December 14. At that point, the PR will be merged unless the chairs determine there is not rough consensus for its inclusion.

Thank you,

 - Justin, Aaron, and Fabien

---

From: Dick Hardt <[email-masked]>
Date: Thu, 10 Dec 2020 12:05:06 -0800

-1 per all the reasons I laid out in
https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/
ᐧ

On Thu, Dec 10, 2020 at 7:52 AM Justin Richer <[email-masked]> wrote:

> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129
>
> This pull request simplifies the continuation response and request by
> making the access token mandatory, and it clarifies the responsibilities of
> the AS in enforcing the security of the continuation request. Several WG
> members expressed specific support for keeping the access token to enable
> specific use cases, and there was general support for simplifying the
> process from what it currently is in the draft. The editors believe the
> pull request represents a solution that meets these goals.
>
> This call is open until Monday December 14. At that point, the PR will be
> merged unless the chairs determine there is not rough consensus for its
> inclusion.
>
> Thank you,
>
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Warren Parad <[email-masked]>
Date: Fri, 11 Dec 2020 11:24:07 +0100

For the part I agree with Dick, but I also dislike the separation of the
"access token" into its own field. If I understand *continue* correctly,
the *access_token *would only ever be used with the *continue *uri, in
which case, having the token in the url is much better than having a
separate parameter which has to be merged with the continue request to auth
it. In my opinion there is no reason to break HATEOAS here, this is one of
the few places where the capability URL makes sense, and given its limited
use and accessibility the concerns are alleviated. Additionally moving the
token back into the uri, avoids the whole problem of naming and how to
treat this token.

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 11 Dec 2020 15:17:53 +0100

Hi,

I commented previously on Dick's input (in short, I disagree - at least
with the cookie comparison).

I'm not sure I follow your point here. "access_token" already has its
field, the proposal is just reusing it throughout the protocol (see for
instance section 3.2.1) as a fairly consistent api. The only difference is
the meaning of the "key" boolean parameter (which I would be in favor of
renaming to clarify).

The proposed alternative comes with issues with seem very hard to get
around, at least in a systematic way. Like potential logs of capability
URLs that include the token, which opens the doors to vulnerable
implementations.

Fabien

On Fri, Dec 11, 2020 at 11:24 AM Warren Parad <[email-masked]> wrote:

>>> This call is open until Monday December 14. At that point, the PR will
>>> be merged unless the chairs determine there is not rough consensus for its
>>> inclusion.
>>>
>>> Thank you,
>>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 11 Dec 2020 12:07:56 -0500

Consistency and clarity for client developers is the goal with the proposed PR. Since the “continue” set of functions was refactored to be an API, the thought was to treat this API exactly like we’d treat an external API hosted at an RS. This pattern would allow the AS to reap the benefits of a token-based protocol (distributed deployments, better security, and so on) as well as making the client developer’s life easier by not making them do something special just to talk to the AS.

As Fabien points out, the “access_token” field is exactly the same field as what comes back in a response for a separate API. The semantics of everything in that field are exactly the same in both places, including the “key” field. The only difference, right now, is that the “key” field is only allowed to have one value, to indicate it’s bound to the requesting client’s instance key that was used in the initial request. There’s been some confusion on that, and so it’s something we might want to change — but that’s a separate issue, and if we use access tokens for continuation then we can solve that problem in a consistent way.

When the client is continuing, you can think of the key presentation as it “authenticating”, but I’d argue that you don’t need to “authenticate” the client at this stage: you just need the context of the ongoing request, and you need to make sure that the caller of that request is the right caller. That is, they can present the right set of security material. A key-bound access token is the perfect map to this function, and it’s something we already want as a core artifact. It also has the benefit of allowing different parts of the AS to communicate via the access token itself without things getting leaked in the URL. Could we put all that state in the URL itself? Sure, but then we need to include discussion about how to protect all of that. Instead, we have an opportunity to avoid problems that we already know exist, instead of repeating them and requiring fixes out of the gate. GNAP is our opportunity to do things better than before.

It’s been argued that a client that isn’t dealing with access tokens at all would need to know something “new” to deal with this continuation API. While technically true, the difference between signing a request that includes an access token and signing a request that doesn’t include an access token is minimal. Further, I personally think that the use case for clients who aren’t going to have any access tokens is going to be exceedingly small, and so optimizing the protocol for that use case is a big lose for the wider community.

 — Justin

> On Dec 11, 2020, at 9:17 AM, Fabien Imbault <[email-masked]> wrote:
> 
> Hi, 
> 
> I commented previously on Dick's input (in short, I disagree - at least with the cookie comparison).
> 
> I'm not sure I follow your point here. "access_token" already has its field, the proposal is just reusing it throughout the protocol (see for instance section 3.2.1) as a fairly consistent api. The only difference is the meaning of the "key" boolean parameter (which I would be in favor of renaming to clarify).
> 
> The proposed alternative comes with issues with seem very hard to get around, at least in a systematic way. Like potential logs of capability URLs that include the token, which opens the doors to vulnerable implementations. 
> 
> Fabien
> 
> On Fri, Dec 11, 2020 at 11:24 AM Warren Parad <[email-masked] <mailto:[email-masked]>> wrote:
> For the part I agree with Dick, but I also dislike the separation of the "access token" into its own field. If I understand continue correctly, the access_token would only ever be used with the continue uri, in which case, having the token in the url is much better than having a separate parameter which has to be merged with the continue request to auth it. In my opinion there is no reason to break HATEOAS here, this is one of the few places where the capability URL makes sense, and given its limited use and accessibility the concerns are alleviated. Additionally moving the token back into the uri, avoids the whole problem of naming and how to treat this token.
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>.
> 
> 
> On Thu, Dec 10, 2020 at 9:06 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> -1 per all the reasons I laid out in https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/ <https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/>
> ᐧ
> 
> On Thu, Dec 10, 2020 at 7:52 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 11 Dec 2020 09:53:56 -0800

Justin / Fabien: are your responses as editors, or as individuals? Are you
gathering consensus, or arguing your views?

Fabien: I don't think you understand how cookies work -- they are not set
by the client.

I agree with the consistency and clarity goals for client developers --
this proposal violates both.

How the client makes the initial request is different from the continue
calls. To be consistent, the client would authenticate the same way on all
calls.

In contrast to calls to the AS, the RS is not handing back an
"access_token" to use on subsequent calls.

A key-bound access token is an important option when calling an RS -- but
bearer tokens have proven to be adequate for many APIs -- so many clients
will likely not have to use key-bound access tokens when calling an RS.

Not all clients are needed to access an RS -- the client may only be
acquiring claims.

While a token-based protocol is interesting -- it is not a common pattern
-- and a token-based protocol is not the same as one using an access token
-- and it is not a common pattern that I have seen -- for the small number
of AS that want to be completely distributed and stateless -- they can put
it in the URL -- or a new standard mechanism for a token-based protocol can
be developed -- or they could use cookies just as web browsers do for
maintaining state.

I have zero requirement to encapsulate the grant request in a token --
having a URI uniquely identify the request works fine, just as it does with
many, many other deployed APIs -- requiring an AS to create a token it does
not need so that it conforms with the protocol adds complexity with zero
benefit.

ᐧ

On Fri, Dec 11, 2020 at 9:07 AM Justin Richer <[email-masked]> wrote:

> Consistency and clarity for client developers is the goal with the
> proposed PR. Since the “continue” set of functions was refactored to be an
> API, the thought was to treat this API exactly like we’d treat an external
> API hosted at an RS. This pattern would allow the AS to reap the benefits
> of a token-based protocol (distributed deployments, better security, and so
> on) as well as making the client developer’s life easier by not making them
> do something special just to talk to the AS.
>
> As Fabien points out, the “access_token” field is exactly the same field
> as what comes back in a response for a separate API. The semantics of
> everything in that field are exactly the same in both places, including the
> “key” field. The only difference, right now, is that the “key” field is
> only allowed to have one value, to indicate it’s bound to the requesting
> client’s instance key that was used in the initial request. There’s been
> some confusion on that, and so it’s something we might want to change — but
> that’s a separate issue, and if we use access tokens for continuation then
> we can solve that problem in a consistent way.
>
> When the client is continuing, you can think of the key presentation as it
> “authenticating”, but I’d argue that you don’t need to “authenticate” the
> client at this stage: you just need the context of the ongoing request, and
> you need to make sure that the caller of that request is the right caller.
> That is, they can present the right set of security material. A key-bound
> access token is the perfect map to this function, and it’s something we
> already want as a core artifact. It also has the benefit of allowing
> different parts of the AS to communicate via the access token itself
> without things getting leaked in the URL. Could we put all that state in
> the URL itself? Sure, but then we need to include discussion about how to
> protect all of that. Instead, we have an opportunity to avoid problems that
> we already know exist, instead of repeating them and requiring fixes out of
> the gate. GNAP is our opportunity to do things better than before.
>
> It’s been argued that a client that isn’t dealing with access tokens at
> all would need to know something “new” to deal with this continuation API.
> While technically true, the difference between signing a request that
> includes an access token and signing a request that doesn’t include an
> access token is minimal. Further, I personally think that the use case for
> clients who aren’t going to have any access tokens is going to be
> exceedingly small, and so optimizing the protocol for that use case is a
> big lose for the wider community.
>
>  — Justin
>

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 11 Dec 2020 18:58:04 +0100

That was as an individual.

Fabien

ps: I'm pretty sure I understand how cookies work, but that's beyond the
point.

On Fri, Dec 11, 2020 at 6:54 PM Dick Hardt <[email-masked]> wrote:

>> When the client is continuing, you can think of the key presentation as
>> it “authenticating”, but I’d argue that you don’t need to “authenticate”
>> the client at this stage: you just need the context of the ongoing request,
>> and you need to make sure that the caller of that request is the right
>> caller. That is, they can present the right set of security material. A
>> key-bound access token is the perfect map to this function, and it’s
>> something we already want as a core artifact. It also has the benefit of
>> allowing different parts of the AS to communicate via the access token
>> itself without things getting leaked in the URL. Could we put all that
>> state in the URL itself? Sure, but then we need to include discussion about
>> how to protect all of that. Instead, we have an opportunity to avoid
>> problems that we already know exist, instead of repeating them and
>> requiring fixes out of the gate. GNAP is our opportunity to do things
>> better than before.
>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 11 Dec 2020 12:58:36 -0500

Others had already responded to this previous thread, but I wanted to add a couple points to clarify some things.

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

I’m not sure what you mean by these being different — the whole point of the design is that the client would be doing the same thing with the access token at the AS that it does with the RS by re-using the access token structure. Can you please describe what the differences are, apart from the rotation? Presentation of the token and signing of the message are identical.

Rotation of the access token and artifacts for ongoing continuation responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87

And for what it’s worth, GNAP is absolutely the right place to have new designs — not that this is one.

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

Correct, but the delta between the calls a client would make with and without an access token is vanishingly small. The client has to sign the initial request in some fashion, and it will sign the continuation request in the same exact fashion, but now include an access token in that request. 

Clients making a request to an AS and not getting an access token is a new design pattern. I think it has value and should be included, but OAuth today shows us the immense value of getting access tokens for calling APIs, and so we shouldn’t optimize away from that pattern.

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

More properly, if the AS does not provide a “continue” field then the client can’t delete the request — and yes, that’s intentional. The AS is telling this client instance that it can’t do anything else with this ongoing request. If the AS wants to allow the client to manage it, it will include the mechanisms to do so in the “continue” field.

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

Debugging and auditing this kind of thing are functions of the AS. How is interoperability harmed by different ASs having different methods to identify their internal data elements? The client doesn’t need any knowledge of the AS’s identifiers, it just needs to know the next steps for continuing the negotiation.

I do agree that there’s a potential use for a consistent identifier, for things like “extending a grant request”, and we need to look at that separately as it doesn’t need to be exposed to the core protocol for most use cases.

 — Justin

> On Dec 10, 2020, at 3:05 PM, Dick Hardt <[email-masked]> wrote:
>

---

From: Denis <[email-masked]>
Date: Fri, 11 Dec 2020 19:12:50 +0100

Hi,

My two cents.

I fear we might have a vocabulary problem. At the moment an access token 
is issued by an Authorization Server (AS) and consumed by a Resource 
Server (RS).
Changing this would create confusion.

  * If a similar data structure as the one currently used in an access
    token would be exchanged between the RC and the AS,
    let us call it differently: xxxxxx token.

  * If a similar data structure as the one currently used in an access
    token is not exchanged between the RC and the AS, then
    there is no terminology problem.

Denis

> Others had already responded to this previous thread, but I wanted to 
> add a couple points to clarify some things.
>
>> 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.
>>
>
> I’m not sure what you mean by these being different — the whole point 
> of the design is that the client would be doing the same thing with 
> the access token at the AS that it does with the RS by re-using the 
> access token structure. Can you please describe what the differences 
> are, apart from the rotation? Presentation of the token and signing of 
> the message are identical.
>
> Rotation of the access token and artifacts for ongoing continuation 
> responses is a separate issue to be discussed: 
> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 
> <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87>
>
>> 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.
>
> Correct, but the delta between the calls a client would make with and 
> without an access token is vanishingly small. The client has to sign 
> the initial request in some fashion, and it will sign the continuation 
> request in the same exact fashion, but now include an access token in 
> that request.
>
> Clients making a request to an AS and not getting an access token is a 
> new design pattern. I think it has value and should be included, but 
> OAuth today shows us the immense value of getting access tokens for 
> calling APIs, and so we shouldn’t optimize away from that pattern.
>
>>
>> 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".
>
> More properly, if the AS does not provide a “continue” field then the 
> client can’t delete the request — and yes, that’s intentional. The AS 
> is telling this client instance that it can’t do anything else with 
> this ongoing request. If the AS wants to allow the client to manage 
> it, it will include the mechanisms to do so in the “continue” field.
>
>>
>> 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.
>
> Debugging and auditing this kind of thing are functions of the AS. How 
> is interoperability harmed by different ASs having different methods 
> to identify their internal data elements? The client doesn’t need any 
> knowledge of the AS’s identifiers, it just needs to know the next 
> steps for continuing the negotiation.
>
> I do agree that there’s a potential use for a consistent identifier, 
> for things like “extending a grant request”, and we need to look at 
> that separately as it doesn’t need to be exposed to the core protocol 
> for most use cases.
>
>  — Justin
>
>
>> On Dec 10, 2020, at 3:05 PM, Dick Hardt <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> <https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/>
>> ᐧ
>>
>>     <https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129>
>>
>>     This pull request simplifies the continuation response and
>>     request by making the access token mandatory, and it clarifies
>>     the responsibilities of the AS in enforcing the security of the
>>     continuation request. Several WG members expressed specific
>>     support for keeping the access token to enable specific use
>>     cases, and there was general support for simplifying the process
>>     from what it currently is in the draft. The editors believe the
>>     This call is open until Monday December 14. At that point, the PR
>>     will be merged unless the chairs determine there is not rough
>>     consensus for its inclusion.
>>
>>     Thank you,
>>
>>     <https://www.ietf.org/mailman/listinfo/txauth>
>>
>
>

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 11 Dec 2020 19:24:39 +0100

Hi Denis,

Well we're not doing exactly the same as OAuth.
I don't think this would create confusion in the context of GNAP, we would
adapt the vocabulary to what the protocol specifies.

Fabien

On Fri, Dec 11, 2020 at 7:13 PM Denis <[email-masked]> wrote:

> is issued by an Authorization Server (AS) and consumed by a Resource Server
> (RS).
>    - If a similar data structure as the one currently used in an access
>    - If a similar data structure as the one currently used in an access
> 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.
>
>
> I’m not sure what you mean by these being different — the whole point of
> the design is that the client would be doing the same thing with the access
> token at the AS that it does with the RS by re-using the access token
> structure. Can you please describe what the differences are, apart from the
> rotation? Presentation of the token and signing of the message are
> identical.
>
> 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.
>
>
> without an access token is vanishingly small. The client has to sign the
> initial request in some fashion, and it will sign the continuation request
> in the same exact fashion, but now include an access token in that request.
>
> Clients making a request to an AS and not getting an access token is a new
> design pattern. I think it has value and should be included, but OAuth
> today shows us the immense value of getting access tokens for calling APIs,
> and so we shouldn’t optimize away from that pattern.
>
>
> 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".
>
>
> client can’t delete the request — and yes, that’s intentional. The AS is
> telling this client instance that it can’t do anything else with this
> ongoing request. If the AS wants to allow the client to manage it, it will
> include the mechanisms to do so in the “continue” field.
>
>
> 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.
>
>
> Debugging and auditing this kind of thing are functions of the AS. How is
> interoperability harmed by different ASs having different methods to
> identify their internal data elements? The client doesn’t need any
> knowledge of the AS’s identifiers, it just needs to know the next steps for
> continuing the negotiation.
>
> I do agree that there’s a potential use for a consistent identifier, for
> things like “extending a grant request”, and we need to look at that
> separately as it doesn’t need to be exposed to the core protocol for most
> use cases.
>
>  — Justin
>
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 11 Dec 2020 12:02:41 -0800

inline ...

> rotation? Presentation of the token and signing of the message are

The client is getting the "access token" from its API. It is not using an
"access_token" in other API calls to the AS.

> designs — not that this is one.

You are proposing a new way for an API to provide context for subsequent
API calls. Looks out of scope to me.

> in the same exact fashion, but now include an access token in that request.

Per my other point, there is no value to me in my implementations of
passing context back and forth between the client and AS -- so it is extra
work providing no value.

Also, any client authentication mechanism that wants to use the HTTP
Authentication header is precluded from using it.

> include the mechanisms to do so in the “continue” field.

There is nuance in that intention. A related concern is that deleting a
request does not seem like it is a "continue" operation.

> continuing the negotiation.

Debugging between the client and the AS was what I was referring to. How
does a client developer identify the request when communicating to the AS
developer. Seems complicated.

ᐧ

---

From: Stephen Moore <[email-masked]>
Date: Fri, 11 Dec 2020 17:01:40 -0500

Even though I've only been lightly following things, I feel the need to
voice my preference as a developer since I will probably someday have to
either write a RC or RS...

The way I see it is the RC makes the initial request to the AS as part of
this request, it provides it's key in the body... (So no use of the
Authorization header)
At this point that request, represented by the continue URL + "Access
Token", from my lazy developer standpoint, is a Resource Endpoint and
Access Token, and the AS is acting as a specialized RS in this case.
So my client posts to whatever URL with the 'access token' in the
authorization header, just like acting on any other resource I have a token
for. YES, I get a new token value to use every call, and there is a
decision point of "Do I have another continue, or do I have a real token
for the resource..." But the mechanism is the same to me in the client.
Personally I like that, because if I have an access_token, I already think
"Put it in the auth header."

So my vote would be +1 for the pull request at this time.
-steve

On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <[email-masked]> wrote:

>> new design pattern. I think it has value and should be included, but OAuth
>> 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".
>>
>>
>> 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.
>>
>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 11 Dec 2020 14:32:34 -0800

Hi Stephen

The client is signing the first request. The key *might* be in the body.
The client is signing all the subsequent requests as well. The "access
token" is not needed by the client to prove it is authorized as the client
is proving it is the same client again.

In other words, I don't see the need for an access token, so it does not
need to be put in a URL or an auth header.

If a developer really, really wants to hand context back to the client for
subsequent calls, they can put it in the URL or some other method. Putting
it in the HTTP Authorization header is confusing because it is NOT an
access token -- it is the context of the request.

ᐧ

On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <[email-masked]> wrote:

>>> 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.
>>>
>>>
>>> is interoperability harmed by different ASs having different methods to

---

From: Stephen Moore <[email-masked]>
Date: Fri, 11 Dec 2020 17:53:01 -0500

But from the spec:
"
When sending a non-continuation request to the AS, the RC MUST identify
itself by including the client field of the request...
...
key (object / string) : The public key of the RC to be used in this request
as described in {{request-key}}. This field is REQUIRED.
...
"

So on the initial request, the key will be there.
If you don't have the access token, then how do you differentiate between
two requests from the same web application by two different users? Is the
web application supposed to have different credentials for every request?
So in this case, the easy way out is to pass the access token to the
client, who then, as i stated before, treats the continue request as a RS
call (albeit a specialized version of the RS where the RS is the AS) OR to
use the unique URL,
but that seems open to a brute force attack by a malicious RC. (What would
be the point of that attack, I don't know, I guess if someone had the
client credentials but not any subjects/resources they could try to
intercept the grant via continue... I just don't feel right locking things
down to unique URLs that way.)
-steve

On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <[email-masked]> wrote:

>> Personally I like that, because if I have an access_token, I already
>> think "Put it in the auth header."
>>
>>>> of the design is that the client would be doing the same thing with the
>>>> access token at the AS that it does with the RS by re-using the access
>>>> token structure. Can you please describe what the differences are, apart
>>>> from the rotation? Presentation of the token and signing of the message are
>>>> identical.
>>>>
>>>
>>> The client is getting the "access token" from its API. It is not using
>>> an "access_token" in other API calls to the AS.
>>>
>>>
>>>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 11 Dec 2020 15:34:11 -0800

On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <[email-masked]> wrote:

> key (object / string) : The public key of the RC to be used in this
> request as described in {{request-key}}. This field is REQUIRED.
> ...
> "
>

The client field can be an object or a string. If the client is
pre-registered, then a string could be provided instead of an object.

> web application supposed to have different credentials for every request?

The AS returns a URI for manipulating the request. I would change the spec
so that each request would have a unique URI. This is the usually
RESTful pattern that the resource (the grant request) has an URI.

> down to unique URLs that way.)

If someone has the client credentials, they can impersonate the client, and
all bets are off.

LOTS of RS servers return a resource specific URL -- my proposal is no
different.

>> If a developer really, really wants to hand context back to the client
>> for subsequent calls, they can put it in the URL or some other method.
>> Putting it in the HTTP Authorization header is confusing because it is NOT
>> an access token -- it is the context of the request.
>>
>> ᐧ
>>
>>> The way I see it is the RC makes the initial request to the AS as part
>>> of this request, it provides it's key in the body... (So no use of the
>>> Authorization header)
>>>>> as access tokens for an RS. The client gets a new "access token" for each
>>>> You are proposing a new way for an API to provide context for
>>>> subsequent API calls. Looks out of scope to me.
>>>>
>>>>
>>>>>
>>>> Debugging between the client and the AS was what I was referring to.
>>>> How does a client developer identify the request when communicating to the
>>>> AS developer. Seems complicated.
>>>>
>>>> ᐧ
>>>> --
>>>> TXAuth mailing list
>>>> [email-masked]

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 12 Dec 2020 02:51:33 +0100

Again speaking in my own name here.

Dick, we know you'd prefer to have a different design, but this PR
shouldn't be about that.

Back on your 3 items :

1) yes we could make pre-register mandatory, but we already decided that
wouldn't be how that would work. We have a client instance that allows a
more generic and flexible pattern (which BTW also allows what you want)

2) instead of blame arguments of who's less restful/HATEOAS/whatever that
have the tenancy to flame conversations, I suggest we speak in less
abstract terms and ask ourselves what that means in practice for devs.
Stephen and several others (myself included) have expressed that it
wouldn't be harder to implement, it would even simplify things quite a lot.
If you disagree please send us a code sample to really show that point by
example, because that's really not obvious.

3) "If someone has the client credentials, they can impersonate the client,
and all bets are off." Are you seriously making this argument? Because if
you have a better proposal than using cryptographic keys, I'm all hears.
You make it look like there's a problem, while in reality we're only
relying on the basic assumption of all modern digital communications.

And more importantly you never responded to the issues of how to avoid the
security pitfalls of what you proposed.

Fabien

Le sam. 12 déc. 2020 à 00:35, Dick Hardt <[email-masked]> a écrit :

>> but that seems open to a brute force attack by a malicious RC. (What
>> would be the point of that attack, I don't know, I guess if someone had the
> If someone has the client credentials, they can impersonate the client,
> and all bets are off.
>
>>>>>> will be required to support an API calling mechanism they would not have to
>>>>>> support otherwise.
>>>>>>
>>>>>>
>>>>>> Clients making a request to an AS and not getting an access token is
>>>>>> a new design pattern. I think it has value and should be included, but
>>>>>> OAuth today shows us the immense value of getting access tokens for calling
>>>>>> APIs, and so we shouldn’t optimize away from that pattern.
>>>>>>
>>>>>>
>>>>>> mechanism for a client to delete the request, as the client is not allowed
>>>>>> to make a call without an "access token".
>>>>>>
>>>>>>
>>>>> There is nuance in that intention. A related concern is that deleting
>>>>> a request does not seem like it is a "continue" operation.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Debugging and auditing this kind of thing are functions of the AS.
>>>>>> How is interoperability harmed by different ASs having different methods to

---

From: Stephen Moore <[email-masked]>
Date: Fri, 11 Dec 2020 21:15:12 -0500

Hi Fabien,

For #3) Even after I typed out the hypothetical attack, that was sort of in
the back of my mind, it isn't a huge risk there. So I actually agree with
Dick there. Something doesn't sit right with me for the unique URL
solution, so I don't like it and came up with a hypothetical that seems
like it could be a down side.

I still think the access token model with the signed request is the way I'd
like to go, because again, it's a mechanism I'd be implementing anyway to
talk to any 'normal' resource. The fact is there is _something_
representing context that has to pass back and forth here, whether that is
an access token (which I feel like is more flexible for extensions etc), a
unique url, or even a cookie sent in the cookie header. So just to
re-iterate, I'm a +1 on this pull request, speaking as a lazy developer ;)
-steve

On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <[email-masked]>
wrote:

> 3) "If someone has the client credentials, they can impersonate the
> client, and all bets are off." Are you seriously making this argument?
> Because if you have a better proposal than using cryptographic keys, I'm
> all hears. You make it look like there's a problem, while in reality we're
> only relying on the basic assumption of all modern digital communications.
>
>>> If you don't have the access token, then how do you differentiate
>>> between two requests from the same web application by two different users?
>>> Is the web application supposed to have different credentials for every
>>> request?
>>>
>>
>> The AS returns a URI for manipulating the request. I would change the
>> spec so that each request would have a unique URI. This is the usually
>>>> The client is signing the first request. The key *might* be in the
>>>> body. The client is signing all the subsequent requests as well. The
>>>> "access token" is not needed by the client to prove it is authorized as the
>>>> client is proving it is the same client again.
>>>>
>>>> In other words, I don't see the need for an access token, so it does
>>>> not need to be put in a URL or an auth header.
>>>>
>>>>> Even though I've only been lightly following things, I feel the need
>>>>> to voice my preference as a developer since I will probably someday have to
>>>>>>> Others had already responded to this previous thread, but I wanted
>>>>>>> to add a couple points to clarify some things.
>>>>>>>
>>>>>>> I’m not sure what you mean by these being different — the whole
>>>>>>> point of the design is that the client would be doing the same thing with
>>>>>>> the access token at the AS that it does with the RS by re-using the access
>>>>>> The client is getting the "access token" from its API. It is not
>>>>>> using an "access_token" in other API calls to the AS.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Correct, but the delta between the calls a client would make with
>>>>>>> and without an access token is vanishingly small. The client has to sign
>>>>>>> request in the same exact fashion, but now include an access token in that
>>>>>>> request.
>>>>>>>
>>>>>>
>>>>>>> More properly, if the AS does not provide a “continue” field then
>>>>>>> the client can’t delete the request — and yes, that’s intentional. The AS
>>>>>>> is telling this client instance that it can’t do anything else with this

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 12 Dec 2020 03:34:58 +0100

You're completely right. Allowing the dev to be lazy is a very good thing
in general, because it's what we know will work :-)

Le sam. 12 déc. 2020 à 03:15, Stephen Moore <[email-masked]> a écrit :

> Hi Fabien,
>
> For #3) Even after I typed out the hypothetical attack, that was sort of
> in the back of my mind, it isn't a huge risk there. So I actually agree
> with Dick there. Something doesn't sit right with me for the unique URL
> I still think the access token model with the signed request is the way
> I'd like to go, because again, it's a mechanism I'd be implementing anyway
> to talk to any 'normal' resource. The fact is there is _something_
>> And more importantly you never responded to the issues of how to avoid
>> the security pitfalls of what you proposed.
>>
>> Fabien
>>
>>
>>>>>> The way I see it is the RC makes the initial request to the AS as
>>>>>> part of this request, it provides it's key in the body... (So no use of the
>>>>>> Authorization header)
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> Clients making a request to an AS and not getting an access token
>>>>>>>> is a new design pattern. I think it has value and should be included, but
>>>>>>> There is nuance in that intention. A related concern is that
>>>>>>> deleting a request does not seem like it is a "continue" operation.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 12 Dec 2020 11:33:22 +0100

Hi all,

I didn’t follow GNAP closely so bear with me if me question seems naive.

After having skimmed through the current draft and the PR, I‘m not sure whether the continuation requests accepts any access token issued to the RC or the particular access token returned in the „continue“ element in section 3.1..

Can you please shed some light on this?

kind regards,
Torsten.

> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <[email-masked]>:
> 
> 
> You're completely right. Allowing the dev to be lazy is a very good thing in general, because it's what we know will work :-) 
> 
>> For #3) Even after I typed out the hypothetical attack, that was sort of in the back of my mind, it isn't a huge risk there. So I actually agree with Dick there. Something doesn't sit right with me for the unique URL solution, so I don't like it and came up with a hypothetical that seems like it could be a down side.
>> 
>> I still think the access token model with the signed request is the way I'd like to go, because again, it's a mechanism I'd be implementing anyway to talk to any 'normal' resource. The fact is there is _something_ representing context that has to pass back and forth here, whether that is an access token (which I feel like is more flexible for extensions etc), a unique url, or even a cookie sent in the cookie header. So just to re-iterate, I'm a +1 on this pull request, speaking as a lazy developer ;)
>> -steve
>> 
>>> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <[email-masked]> wrote:
>>> Dick, we know you'd prefer to have a different design, but this PR shouldn't be about that. 
>>> 
>>> Back on your 3 items :
>>> 
>>> 1) yes we could make pre-register mandatory, but we already decided that wouldn't be how that would work. We have a client instance that allows a more generic and flexible pattern (which BTW also allows what you want) 
>>> 
>>> 2) instead of blame arguments of who's less restful/HATEOAS/whatever that have the tenancy to flame conversations, I suggest we speak in less abstract terms and ask ourselves what that means in practice for devs. Stephen and several others (myself included) have expressed that it wouldn't be harder to implement, it would even simplify things quite a lot. If you disagree please send us a code sample to really show that point by example, because that's really not obvious. 
>>> 
>>> 3) "If someone has the client credentials, they can impersonate the client, and all bets are off." Are you seriously making this argument? Because if you have a better proposal than using cryptographic keys, I'm all hears. You make it look like there's a problem, while in reality we're only relying on the basic assumption of all modern digital communications. 
>>>  
>>> And more importantly you never responded to the issues of how to avoid the security pitfalls of what you proposed. 
>>> 
>>> Fabien 
>>> 
>>> 
>>>>> When sending a non-continuation request to the AS, the RC MUST identify itself by including the client field of the request...
>>>>> ...
>>>>> key (object / string) : The public key of the RC to be used in this request as described in {{request-key}}. This field is REQUIRED. 
>>>>> ...
>>>>> "
>>>> The client field can be an object or a string. If the client is pre-registered, then a string could be provided instead of an object.
>>>>  
>>>>> 
>>>>> If you don't have the access token, then how do you differentiate between two requests from the same web application by two different users? Is the web application supposed to have different credentials for every request?
>>>> 
>>>> The AS returns a URI for manipulating the request. I would change the spec so that each request would have a unique URI. This is the usually RESTful pattern that the resource (the grant request) has an URI.
>>>> 
>>>>  
>>>>> So in this case, the easy way out is to pass the access token to the client, who then, as i stated before, treats the continue request as a RS call (albeit a specialized version of the RS where the RS is the AS) OR to use the unique URL, 
>>>>> but that seems open to a brute force attack by a malicious RC. (What would be the point of that attack, I don't know, I guess if someone had the client credentials but not any subjects/resources they could try to intercept the grant via continue... I just don't feel right locking things down to unique URLs that way.)
>>>> 
>>>> If someone has the client credentials, they can impersonate the client, and all bets are off.
>>>> 
>>>> LOTS of RS servers return a resource specific URL -- my proposal is no different.
>>>> 
>>>> 
>>>>  
>>>>> -steve
>>>>> 
>>>>>> The client is signing the first request. The key *might* be in the body. The client is signing all the subsequent requests as well. The "access token" is not needed by the client to prove it is authorized as the client is proving it is the same client again.
>>>>>> 
>>>>>> In other words, I don't see the need for an access token, so it does not need to be put in a URL or an auth header.
>>>>>> 
>>>>>> If a developer really, really wants to hand context back to the client for subsequent calls, they can put it in the URL or some other method. Putting it in the HTTP Authorization header is confusing because it is NOT an access token -- it is the context of the request.
>>>>>> 
>>>>>> ᐧ
>>>>>> 
>>>>>>> Even though I've only been lightly following things, I feel the need to voice my preference as a developer since I will probably someday have to either write a RC or RS... 
>>>>>>> 
>>>>>>> The way I see it is the RC makes the initial request to the AS as part of this request, it provides it's key in the body... (So no use of the Authorization header)
>>>>>>> At this point that request, represented by the continue URL + "Access Token", from my lazy developer standpoint, is a Resource Endpoint and Access Token, and the AS is acting as a specialized RS in this case.
>>>>>>> So my client posts to whatever URL with the 'access token' in the authorization header, just like acting on any other resource I have a token for. YES, I get a new token value to use every call, and there is a decision point of "Do I have another continue, or do I have a real token for the resource..." But the mechanism is the same to me in the client.
>>>>>>> Personally I like that, because if I have an access_token, I already think "Put it in the auth header." 
>>>>>>> 
>>>>>>>> The client is getting the "access token" from its API. It is not using an "access_token" in other API calls to the AS.
>>>>>>>>  
>>>>>>>>> 
>>>>>>>> You are proposing a new way for an API to provide context for subsequent API calls. Looks out of scope to me.
>>>>>>>>  
>>>>>>>>> 
>>>>>>>> Per my other point, there is no value to me in my implementations of passing context back and forth between the client and AS -- so it is extra work providing no value.
>>>>>>>> 
>>>>>>>> Also, any client authentication mechanism that wants to use the HTTP Authentication header is precluded from using it.
>>>>>>>> 
>>>>>>>>  
>>>>>>>>> 
>>>>>>>> There is nuance in that intention. A related concern is that deleting a request does not seem like it is a "continue" operation.
>>>>>>>>  
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> Debugging between the client and the AS was what I was referring to. How does a client developer identify the request when communicating to the AS developer. Seems complicated.
>>>>>>>>  
>>>>>>>> ᐧ
>>>>>>>> -- 
>>>>>>>> TXAuth mailing list
>>>>>>>> [email-masked]
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 12 Dec 2020 12:06:15 +0100

Hi,

On the contrary your feedback is most welcome.

It doesn't accept any token, it needs the particular token as described in
3.1 and which is not a bearer token (that's what the "key" : true parameter
is supposed to convey).

Let us know if you need more clarifications.

Best
Fabien

Le sam. 12 déc. 2020 à 11:33, Torsten Lodderstedt <[email-masked]>
a écrit :

> After having skimmed through the current draft and the PR, I‘m not sure
> whether the continuation requests accepts any access token issued to the RC
> or the particular access token returned in the „continue“ element in
> section 3.1..
>
>>> 2) instead of blame arguments of who's less restful/HATEOAS/whatever
>>> that have the tenancy to flame conversations, I suggest we speak in less
>>>>> When sending a non-continuation request to the AS, the RC MUST
>>>>> identify itself by including the client field of the request...
>>>>> ...
>>>>>> If a developer really, really wants to hand context back to the
>>>>>> client for subsequent calls, they can put it in the URL or some other
>>>>>> method. Putting it in the HTTP Authorization header is confusing because it
>>>>>> is NOT an access token -- it is the context of the request.
>>>>>>
>>>>>> ᐧ
>>>>>>
>>>>>>> At this point that request, represented by the continue URL +
>>>>>>> "Access Token", from my lazy developer standpoint, is a Resource Endpoint
>>>>>>> and Access Token, and the AS is acting as a specialized RS in this case.
>>>>>>>>> Rotation of the access token and artifacts for ongoing
>>>>>>>>> continuation responses is a separate issue to be discussed:
>>>>>>>>> <https://www.google.com/url?q=https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87&source=gmail-imap&ust=1608345320000000&usg=AOvVaw33VPGP0MsjajzYTXZf5Sla>
>>>>>>>>>
>>>>>>>> Per my other point, there is no value to me in my implementations
>>>>>>>> of passing context back and forth between the client and AS -- so it is
>>>>>>>> extra work providing no value.
>>>>>>>>
>>>>>>>> Also, any client authentication mechanism that wants to use the
>>>>>>>> HTTP Authentication header is precluded from using it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>> Debugging between the client and the AS was what I was referring
>>>>>>>> to. How does a client developer identify the request when communicating to
>>>>>>>> the AS developer. Seems complicated.
>>>>>>>>
>>>>>>>> ᐧ
>>>>>>>> --
>>>>>>>> TXAuth mailing list
>>>>>>>> [email-masked]
>>>>>>>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI>
>>>>>>>>
>>>>>>> ᐧ
>>>> --
>>>> TXAuth mailing list
>>>> [email-masked]
>>>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI>
>>>>
>>> --
> TXAuth mailing list
> [email-masked]
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 12 Dec 2020 06:43:08 -0500

It’s the token returned in the “continue” request. It’s required to be a bound token, and specifically bound to the client’s original presentation method and key (so bearer tokens aren’t allowed here).

This is currently specified to be a token that isn’t usable elsewhere, but there’s a separate issue filed for whether that’s a requirement (and honestly whether it’s enforceable): https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/66 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/66>

 — Justin

> On Dec 12, 2020, at 5:33 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi all,
> 
>> Le sam. 12 déc. 2020 à 03:15, Stephen Moore <[email-masked] <mailto:[email-masked]>> a écrit :
>> Hi Fabien,
>> 
>> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>> Le sam. 12 déc. 2020 à 00:35, Dick Hardt <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> 
>> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <[email-masked] <mailto:[email-masked]>> wrote:
>> But from the spec:
>> "
>> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Stephen
>> 
>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <[email-masked] <mailto:[email-masked]>> wrote:
>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> inline ... 
>> 
>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> Rotation of the access token and artifacts for ongoing continuation responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 <https://www.google.com/url?q=https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87&source=gmail-imap&ust=1608345320000000&usg=AOvVaw33VPGP0MsjajzYTXZf5Sla>
>> 
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI>
>> ᐧ
>> -- 
>> TXAuth mailing list
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI>
>> -- 
>> TXAuth mailing list
>> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Mon, 14 Dec 2020 09:59:55 -0800

Fabien: a discussion would be more productive if you took some time reading
what I wrote.

I am not suggesting pre-registration be mandatory

I am not making blame arguments are trying to start a flamewar -- I am
pointing out that a RESTful like pattern is well understood.

I am not suggesting we not use cryptographic keys.

I am saying having an "access token" in addition to a URI adds complexity
to both the client and the AS with little if any value. A URI is all that
is needed unless there is a desire to make the AS stateless, or pass
context between the AS and another server -- which seems to me of
dubious value. That is all that I used in
https://github.com/dickhardt/XAuth-poc

So far we are discussing the "access token" in abstract terms. Would you
describe what would be contained in the "access token"?

/Dick

ᐧ

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 14 Dec 2020 19:50:13 +0100

Hello Dick,

I'm reading what you write.

RESTful patterns are well understood, up to a limit. I've seen more debate
around what's good and what's not that on any other subject in my entire
career. It rarely helps, if ever. Because everyone thinks he applies the
concepts correctly anyway.

I observe we're going too much around XAuth (to cite you, "That is all that
I used in https://github.com/dickhardt/XAuth-poc") vs XYZ vs GNAP, in some
fashion, while I'm really hoping we can go forward. I also advise against
making personal attacks and would prefer that we'd keep the discussion to
technical arguments only. I'm sure we would all benefit from a win win
situation, where we try to arbitrate the best possible technical solution
that matches the group's goal. Knowing that there are many cases where it's
not black and white.

If you are able to convince me with your arguments, I'll back your proposal
(or any other, for that matter). But we're really not yet there in that
specific case. The cookie comparison is far stretched. I don't understand
what is complex in having to handle a token. Please note I'm also expecting
some feedback on the security model that should be put in place around the
URI model that you propose.

Then on your last point, I agree with you, we can certainly give an example
of access token. I'll get back to you on that.

Fabien
ps : I'm also open to discuss privately with you on a better way to
cooperate in general.

On Mon, Dec 14, 2020 at 7:00 PM Dick Hardt <[email-masked]> wrote:

> Fabien: a discussion would be more productive if you took some time
> reading what I wrote.
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 14 Dec 2020 11:37:54 -0800

I am proposing a URI that is straight forward, and has no security concerns.

For example, the URI could be:

<as uri>/grant/<unique grant id>

eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f

The routing code in the AS then is:

router.post(      '/', grant.create);
router.get(        '/grant/:grant', grant.read);
router.post(      '/grant/:grant', grant.update);
router.delete(   '/grant/:grant', grant.delete);
router.options( '/grant/:grant', grant.options);

Where there is a "grant" module to manage for working with grant requests.

/Dick

ps: your previous email, and this one, are making the discussion personal.
Happy to discuss privately.

ᐧ

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 14 Dec 2020 11:45:55 -0800

Thanks for the clear description. However saying "has no security concerns"
is a bold claim. Can you clarify how you will ensure that there are no
security concerns with this method?

My main worry with this is people will start to get "creative" with the
values of the things in this URL. We've seen this over and over, everything
from using plaintext data in JWT access tokens in OAuth (now the access
token contents are visible to clients), to putting data in the OAuth
"state" parameter (easy to exploit unless it's signed/encrypted), and I'm
sure someone somewhere is putting things in the authorization code that
they shouldn't.

Aaron

---

From: Warren Parad <[email-masked]>
Date: Mon, 14 Dec 2020 21:11:08 +0100

Here's a terrible alternative:

It would seem to me that one compromise could be making the object
extensible by authorization servers (and their corresponding SDK). In a
similar way that JWTs are extensible, we could require explicitly the URI
in the spec, and an optional object to be defined by the AS.

--------

One source of the problem could be that the language for taking the
response object and converting it back into a request one is not well
defined.
Instead if we allowed an optional headers object to be returned:
{
    uri: "https://as/grant/{grantId}",
    headers: {
        'Authorization': 'Bearer ${accessToken}
    }
}

Thereby explicitly telling the client what they need to return back. It
avoids the problem of "what to name these things" and also ensures that the
data is exactly what the server expects. Additionally it sidesteps the
naming issue, where to include tokens, and whether to include them at all.

Otherwise it sucks to be in a situation where the benefits/detriments
aren't clear to everyone, and potentially we can choose a path forward
where both approaches could be used without requiring other clients to jump
over arbritrary hurdles suchs as custom implementations.

Warren Parad

Founder, CTO

On Mon, Dec 14, 2020 at 8:46 PM Aaron Parecki <[email-masked]> wrote:

> Thanks for the clear description. However saying "has no security
> concerns" is a bold claim. Can you clarify how you will ensure that there
> are no security concerns with this method?
>
>> ps: your previous email, and this one, are making the discussion
>> personal. Happy to discuss privately.
>>
>> ᐧ
>> --
>> TXAuth mailing list
>> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Mon, 14 Dec 2020 12:23:54 -0800

I don't understand what security risks are unique with the GNAP URI
relative to other API URIs that have a unique identifier in them.

Developers can get "creative" and put "inappropriate" values in any API URI
they design.

What are the security implications of using a large random value as the
<unique grant id>?

ᐧ

---

From: Justin Richer <[email-masked]>
Date: Mon, 14 Dec 2020 15:29:03 -0500

Warren,

(as editor):

Your proposal below is not dissimilar to what’s in the current spec text: the URI is required, and the access token is optional. If the access token is included, the client has to include it in its request. The feedback from the working group during the IETF109 meeting, and leading up to it, was nearly universally that this optionality was not helpful, especially to client developers. The editors’ PR being discussed here removes that optionality by making both fields required with only one method of presentation, and therefore a single code path for the client.

 — Justin

> On Dec 14, 2020, at 3:11 PM, Warren Parad <[email-masked]> wrote:
> 
> It would seem to me that one compromise could be making the object extensible by authorization servers (and their corresponding SDK). In a similar way that JWTs are extensible, we could require explicitly the URI in the spec, and an optional object to be defined by the AS.
> 
> --------
> 
> One source of the problem could be that the language for taking the response object and converting it back into a request one is not well defined.
>     uri: "https://as/grant/{grantId} <https://as/grant/%7BgrantId%7D>",
>     headers: {
> Thereby explicitly telling the client what they need to return back. It avoids the problem of "what to name these things" and also ensures that the data is exactly what the server expects. Additionally it sidesteps the naming issue, where to include tokens, and whether to include them at all.
> 
> Otherwise it sucks to be in a situation where the benefits/detriments aren't clear to everyone, and potentially we can choose a path forward where both approaches could be used without requiring other clients to jump over arbritrary hurdles suchs as custom implementations.
> 
> 
> Warren Parad
> Founder, CTO
> On Mon, Dec 14, 2020 at 8:46 PM Aaron Parecki <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks for the clear description. However saying "has no security concerns" is a bold claim. Can you clarify how you will ensure that there are no security concerns with this method?
> 
> My main worry with this is people will start to get "creative" with the values of the things in this URL. We've seen this over and over, everything from using plaintext data in JWT access tokens in OAuth (now the access token contents are visible to clients), to putting data in the OAuth "state" parameter (easy to exploit unless it's signed/encrypted), and I'm sure someone somewhere is putting things in the authorization code that they shouldn't.
> 
> Aaron
> 
> 
> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f <https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f>
> 
> router.post <http://router.post/>(      '/', grant.create);
> router.post <http://router.post/>(      '/grant/:grant', grant.update);
> ps: your previous email, and this one, are making the discussion personal. Happy to discuss privately.
> 
> ᐧ
> -- 
> TXAuth mailing list

---

From: Warren Parad <[email-masked]>
Date: Mon, 14 Dec 2020 21:41:38 +0100

So then I would say the question becomes, why force AS to create "access
tokens" (or whatever we want to call them) if they don't see the benefit of
doing so. I.e. right now the Warren AS (and the Dick AS) both think we
would not be generating "access tokens". If the spec requires it, I would
probably just hard code the same value in every request because my AS
doesn't see the value in requiring it when I'm in control of the URI.

If I understand the discussion correctly, we are trying to prevent AS from
exposing the uri containing the "access token", because doing so would
hypothetically create an attack surface for the AS. If that's the case,
then I would say, forcing the token to be in auth header only provides a
negligible amount of surface decrease and thus the extra complexity is not
well offset by the security improvement. So for me rather than arguing if
there is any benefit at all, I'll make a stronger argument:
*If there is a benefit to using the access token, it surely can't be a
meaningful amount in such a way that it's important from the GNAP protocol
standpoint to provide this mechanism for improvement.*

Warren Parad

Founder, CTO

On Mon, Dec 14, 2020 at 9:29 PM Justin Richer <[email-masked]> wrote:

> Warren,
>
> (as editor):
>
> Your proposal below is not dissimilar to what’s in the current spec text:
> the URI is required, and the access token is optional. If the access token
> is included, the client has to include it in its request. The feedback from
> the working group during the IETF109 meeting, and leading up to it, was
> nearly universally that this optionality was not helpful, especially to
> client developers. The editors’ PR being discussed here removes that
> optionality by making both fields required with only one method of
> presentation, and therefore a single code path for the client.
>
>  — Justin
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 14 Dec 2020 16:03:28 -0500

(As an individual):

There are a number of reasons and use cases that drive toward using an access token. A stateless, distributed AS is one of them, and an access token gives us a proven better way to shield the components from each other. While we could tell people to put that information into the URI, we’d then need to tell people how to protect all the information in the URI. This is a case where we can avoid problems in the design instead of having to fix them later. 

Then there’s the question of client authentication:  After the initial request, the AS doesn’t even need the client to “authenticate” as much as it needs to make sure that the same party is making the future call. Authentication only applies to clients that have a pre-registered key at the AS, and in that case only in the initial call. Anything after that can be tied to the context of the ongoing request, in much the same way an any other protected API just needs to know the context of the token. Now, from a client’s perspective, it’s still signing the continue request exactly like it did the initial request, it’s just including the access token as a header and covering it with the signature. And the AS can still look up the client’s instance information based on that request, just like any RS with access to that information would be able to. But at this point, the AS doesn’t :have: to do that because it can associate any rights and features for that request in the first step and carry that forward. After that first stage, it’s just modification of the ongoing request, and as long as that modification is being made by the authorized party (the client with access to the key) then it works. It’s the same argument that OAuth made for moving APIs to access tokens and away from API keys, and now that we are viewing “continue” as an API for the client to call, with multiple actions over time, then it makes sense to treat it like other APIs.

So, what does this mean for an AS to create access tokens for this step? Well, for the vast majority of AS’s out there, creating an access token is something they’re already really good at, and need to be prepared to do anyway. For an AS that isn’t dealing in access tokens at all, it’s an extra field to include, you are right.But even then, it would be trivial for an AS to create, for example, a simple signed JWT for continuation access to hand to the client. Do you want that token to last for 10 years and be good across all continuation requests for a given client? Go for it, that’s your security decision to make. And you can still use unique identifiers in your URLs, which has always been the case. But importantly, this specific use case can be supported without getting in the way of other patterns and at minimal cost. The cost to other patterns in terms of complexity and security risk is far greater if we use only URLs.

 — Justin

> On Dec 14, 2020, at 3:41 PM, Warren Parad <[email-masked]> wrote:
> 
> So then I would say the question becomes, why force AS to create "access tokens" (or whatever we want to call them) if they don't see the benefit of doing so. I.e. right now the Warren AS (and the Dick AS) both think we would not be generating "access tokens". If the spec requires it, I would probably just hard code the same value in every request because my AS doesn't see the value in requiring it when I'm in control of the URI.
> 
> If I understand the discussion correctly, we are trying to prevent AS from exposing the uri containing the "access token", because doing so would hypothetically create an attack surface for the AS. If that's the case, then I would say, forcing the token to be in auth header only provides a negligible amount of surface decrease and thus the extra complexity is not well offset by the security improvement. So for me rather than arguing if there is any benefit at all, I'll make a stronger argument:
> If there is a benefit to using the access token, it surely can't be a meaningful amount in such a way that it's important from the GNAP protocol standpoint to provide this mechanism for improvement.
> 
> 
> Warren Parad
> Founder, CTO
> On Mon, Dec 14, 2020 at 9:29 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Warren,
> 
> (as editor):
> 
>> On Dec 14, 2020, at 3:11 PM, Warren Parad <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 14 Dec 2020 22:19:15 +0100

Hi Warren,

The goal is not to force a behavior for the sake of forcing it, as Justin
explained one of the goals is to avoid to the extra complexity of
optionality when there's no fundamental reason for doing so. Which leaves
open the question of which alternative is best of course, and that's what
we're discussing here (security is not the only argument).

Just wondering. If you're ready to hardcode the same value in every request
in one case, why do you think better to have unique URIs in the other case?

Plus the problem is not that you control the AS URI, it's that you have
only limited trust for what's in front of that. A bound access token
ensures that your call is anthenticated with the same key as before, while
the alternative doesn't.

Fabien

---

From: Dave Tonge <[email-masked]>
Date: Mon, 14 Dec 2020 22:25:36 +0100

On the call I voiced my opinion that opionality should be reduced in the
spec where possible. At the time I was in favour of access tokens being
required. However, after reading the thread and looking again at the spec
I'm no longer convinced.

The only advantage I can see of the access token, is that it provides a way
for the AS to be stateless, but I'm not sure how common or desirable that
use-case is? As soon as the AS has to look some information up about a
grant in order to continue, then there is no benefit in the access token.
The identity of the grant can be in the url, and the authenticity of the
client is provided by the signature.

I know this is beyond the scope of this pull request, but for the majority
of use-cases, my personal opinion is that a consistent identifier for each
grant and a mandated REST like URL structure would be far more useful.

The GNAP spec is being designed in an extensible manner that will allow a
huge amount of use cases. Maybe in the future there will be new endpoints
dreamed up at the AS that require tokens. But the current ones described
in  the spec don't (create grant, continue grant, modify grant, get grant,
cancel grant, rotate token & revoke token).

I also think there is some confusion that "binding" is being used for:
 - client authentication
 - sender constraining access tokens
 - http request signing

If the signing mechanism is ok to authenticate the client in the first
request, why is it not sufficient to authenticate the client on the
continuation request?

I think we need a stronger use-case for access tokens at the AS to
warrant even its optional inclusion in the spec.

On Mon, 14 Dec 2020 at 21:25, Dick Hardt <[email-masked]> wrote:

> Developers can get "creative" and put "inappropriate" values in any API
> URI they design.
>

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at *https://register.fca.org.uk/
<https://register.fca.org.uk/>*. Moneyhub Financial Technology is
registered in England & Wales, company registration number  06909772 .
Moneyhub Financial Technology Limited 2019 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: Warren Parad <[email-masked]>
Date: Mon, 14 Dec 2020 23:21:28 +0100

Based on the information shared, my preference would be to call the "access
token", *session token*, I'll continue to do so in further communication.
It's really how it's being used and now I can understand why conversation
about cookies has come up. The "access token" is a session token, and
session tokens have historically been transmitted via cookies, but in this
case we are looking to transfer session token via the authorization header.

>  And the AS can still look up the client’s instance information based on
> that request, just like any RS with access to that information would be
> able to

If the AS can use the existing information in the request to look up the
client to ensure it is the same party, the question for me is "Why wouldn't
it?".

What's the benefit of changing the auth mechanism between the first call
and subsequent ones to identify the calling party?

Warren Parad

Founder, CTO

On Mon, Dec 14, 2020 at 10:26 PM Dave Tonge <[email-masked]> wrote:

> The only advantage I can see of the access token, is that it provides a
> way for the AS to be stateless, but I'm not sure how common or desirable
> that use-case is? As soon as the AS has to look some information up about a
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772. Moneyhub Financial Technology Limited 2020 ©
> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1
> 6EA.
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 15 Dec 2020 01:36:59 +0100

It's not acting as a session id, as least not in the way you describe it.

A big difference is that you may encode (and encrypt) the content of the
access token, so it may for instance :
- indicate a start time and end time for the request
- specify a client instance and maybe a dynamic client posture
- and contain any other info the server may wish to embed
- plus this is bound to a key which might be rotated if needed

So it's really a token, with a content and format that is fully opaque to
the client. That answers to your question "why wouldn't it?". Because you
have a more powerful and generic mechanism using tokens.

But since you're referring to sessions, it gives you one hint on the
difference between the initial request and the continuations. Of course at
the initialization, there's no server state yet.

Le lun. 14 déc. 2020 à 23:21, Warren Parad <[email-masked]> a écrit :

> Based on the information shared, my preference would be to call the
> "access token", *session token*, I'll continue to do so in further
> communication. It's really how it's being used and now I can understand why
> conversation about cookies has come up. The "access token" is a session
> token, and session tokens have historically been transmitted via cookies,
> but in this case we are looking to transfer session token via the
> authorization header.
>
>
>> I know this is beyond the scope of this pull request, but for the
>> majority of use-cases, my personal opinion is that a consistent identifier
>> for each grant and a mandated REST like URL structure would be far more
>> useful.
>>

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 15 Dec 2020 01:46:39 +0100

Maybe we'd need to clarify the use cases indeed.

A big part of what you're saying is : it can be done differently. Which is
true, just not with the same expressiveness.

Beyond what we're covering here, I see at least one important service that
would directly benefit from tokens, around introspection/management api
(e.g. is the token still valid?). Here there's no information lookup about
a grant, we could just query a bloom filter if we get the authorization to
do so. I agree it's not yet included but it's perfectly feasible.

Statelessness can be good for scalability in general, at least if it
doesn't come at the expense of something important (which I don't think is
the case here).

For end developers, it's often much easier to use a URL and pass a token,
and not to have to decode the parameters (only HTTP specialists are used to
that). That's basically what made JWT successful.

As for key presentation, it's the very same mechanism used in the various
calls (cf section 2.3 and section 8). But of course when you initialize,
you have never reached the server and so there is no state, which I don't
think would be difficult to understand by client devs, especially as the
calls are already distinct.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 15 Dec 2020 09:50:21 +0100

Hi Fabien, 

> Am 12.12.2020 um 12:06 schrieb Fabien Imbault <[email-masked]>:
> 
> Hi,
> 
> It doesn't accept any token, it needs the particular token as described in 3.1 and which is not a bearer token (that's what the "key" : true parameter is supposed to convey). 
> 

Thanks for the clarification. I think only accepting this kind of token at the continuation is a good idea otherwise the AS would need to be able to parse and understand all sorts of access tokens.

Conceptually, I like the idea to treat the continuation as another kind of resource. However, here are some observations I want to share with you: 
- This resource is different as it will issue other access tokens (of this kind) to be used in subsequent continuation requests. This requires different handing on the client side.
- This access token (if I understand correctly) is (or at least feels like) a handle for the underlying grant. So it is kind of the super access token to obtain other access tokens. 

I would consider using a different term to refer to this special access token, grant token or grant handle for example, in order to prevent confusion. 

best regards,
Torsten. 

> 
> Best
> Fabien 
> 
> Le sam. 12 déc. 2020 à 11:33, Torsten Lodderstedt <[email-masked]> a écrit :
> Hi all,
>

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 15 Dec 2020 10:10:56 +0100

Hi Torsten,

You're right on both accounts.
- for the first remark, it fits quite nicely the init request  /
continuation pattern
- for the second remark, it is a sort of handle for the
continuation request, which will eventually lead to the issuance or refresh
of standard access tokens

Having a specific name is a possibility, I actually suggested that too at
some point.

Fabien

On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <[email-masked]>
wrote:

> Hi Fabien,
>
> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <[email-masked]
> >:
> >
> > Hi,
> >
> > It doesn't accept any token, it needs the particular token as described
> in 3.1 and which is not a bearer token (that's what the "key" : true
> parameter is supposed to convey).
> >
> Thanks for the clarification. I think only accepting this kind of token at
> the continuation is a good idea otherwise the AS would need to be able to
> parse and understand all sorts of access tokens.
>
> Conceptually, I like the idea to treat the continuation as another kind of
> resource. However, here are some observations I want to share with you:
> - This resource is different as it will issue other access tokens (of this
> kind) to be used in subsequent continuation requests. This requires
> different handing on the client side.
> - This access token (if I understand correctly) is (or at least feels
> like) a handle for the underlying grant. So it is kind of the super access
> token to obtain other access tokens.
>
> I would consider using a different term to refer to this special access
> token, grant token or grant handle for example, in order to prevent
> confusion.
>
> best regards,
> Torsten.
>
>
> >
> > Best
> > Fabien
> >
> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <[email-masked]
> >:
> >>
> >> 
> >> You're completely right. Allowing the dev to be lazy is a very good
> thing in general, because it's what we know will work :-)
> >>
> >> For #3) Even after I typed out the hypothetical attack, that was sort
> of in the back of my mind, it isn't a huge risk there. So I actually agree
> >> 1) yes we could make pre-register mandatory, but we already decided
> that wouldn't be how that would work. We have a client instance that allows
> a more generic and flexible pattern (which BTW also allows what you want)
> >>

---

From: Dave Tonge <[email-masked]>
Date: Tue, 15 Dec 2020 11:08:33 +0100

So we've established that this is a different access token, that requires
different handling at the client. So keeping it could cause more confusion?

As an RC, I will have to store the continue `uri` as although it could be
static it could also be dynamic. Why do I need to store an access token as
well. It brings me no benefit as an RC, in fact it brings more complexity.
As I will now need to manage multiple types of tokens with different
lifecycles:

*Continuation token*
  - can only be used at the continue endpoint (the name of which is
confusing as I can use this endpoint to revoke a grant or get metadata on
the grant).
 - may be rotated each time it is used, or may not be
 - provided in the `continue` section of the response
 - must be sender-constrained
 - can't be used with the token management APIs?
 - can be used to identify the grant when making subsequent grants

*Access token(s) to use at RS*
  - can only be used at the specified RS
  - may be sender constrained
  - when used at the RS, will not result in rotation

>From my perspective, most use-cases will require the RC to have a
persistent identifier for the grant. Why not bring this into the protocol
and let the AS provide this persistent identifier (through the form of the
continue uri). Using a rotating access token as a persistent identifier
doesn't seem like the right choice.

I see no security benefit to having the continuation access token. It
doesn't matter if the continue uri leaks as it is useless without an
accompanying signature, i.e. any security benefit of having an access token
is already provided by having a signature.

The only benefits that I can see are:
 - If the AS wants to be fully stateless, then you can encode more data in
a token than in a uri
 - If the AS wants to have a static endpoint for CRUD operations on the
grant
 - To allow the AS to identity a previous grant

If we dropped the access token for the continue endpoint and rather
mandated a dynamic uri this would make things conceptually easier to
understand, easier for the RC to implement, easier to debug and less chance
of errors when rotating tokens (i.e. race conditions could be quite likely
if the AS always rotates the token)

*One-off grant with no continuation or ongoing management:*
RC sends signature and metadata, no `continue` response provided, therefore
no grant management possible

*Grant with ongoing management*
RC sends signature and metadata, AS responds with a continue uri that has
these purposes:
 - can be used by the RC to continue/update, read or revoke the grant
 - can be used by the RC when making a new grant to identify the previous
grant

As an RC the only permanent items I need to store are:
 - the continue uri associated with the grant
 - any access tokens I receive for the grant

Dave

On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <[email-masked]>
wrote:

> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <
> [email-masked]> wrote:
>
>> Hi Fabien,
>>
>> Thanks for the clarification. I think only accepting this kind of token
>> at the continuation is a good idea otherwise the AS would need to be able
>> to parse and understand all sorts of access tokens.
>>
>> Conceptually, I like the idea to treat the continuation as another kind
>> of resource. However, here are some observations I want to share with you:
>> - This resource is different as it will issue other access tokens (of
>> this kind) to be used in subsequent continuation requests. This requires
>> >> I still think the access token model with the signed request is the
>> way I'd like to go, because again, it's a mechanism I'd be implementing
>> anyway to talk to any 'normal' resource. The fact is there is _something_

-- 

DISCLAIMER: This email

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 15 Dec 2020 12:10:10 +0100

I think we always said the access token was different, and handled as a
bound token.

But it doesn't mean it's more difficult for the client that already needs
to be able to handle tokens anyway (bearer or not, both cases could occur).
It's mostly consolidating the logic.

You're anticipating a lot of issues which have no specific reason to occur,
such as "can't be used with the token management APIs?". The management API
is part of the same general flow.
Anticipating issues with rotation is useful, but there are also many ways
it can be hard to manage through a stateful approach too. And
fundamentally, having everything in a common model (both for the internals
of the AS and for the API calls) will help improve by a large margin what
is probably the weakest point in today's infrastructure. But it's early to
be definitive as to the downstream impact either way.

As for a persistent identifier instead of a continuation API, and generally
the end of your message, it's a totally unrelated issue to this PR, so I
suggest we don't discuss that here, but in a separate issue if needed.

Fabien

On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge <[email-masked]> wrote:

> RC sends signature and metadata, no `continue` response provided,
> therefore no grant management possible
>
>>> > It doesn't accept any token, it needs the particular token as
>>> described in 3.1 and which is not a bearer token (that's what the "key" :
>>> true parameter is supposed to convey).
>>> >
>>> > After having skimmed through the current draft and the PR, I‘m not
>>> sure whether the continuation requests accepts any access token issued to
>>> the RC or the particular access token returned in the „continue“ element in
>>> section 3.1..
>>> >
>>> >> And more importantly you never responded to the issues of how to
>>> avoid the security pitfalls of what you proposed.
>>> >>
>>> >> Fabien
>>> >>
>>> >>

---

From: Dave Tonge <[email-masked]>
Date: Tue, 15 Dec 2020 13:50:02 +0100

The persistent identifier is not a different issue, the current access
token is used to reference an existing grant
<https://github.com/ietf-wg-gnap/gnap-core-protocol/blob/main/draft-ietf-gnap-core-protocol.md#referencing-an-existing-grant-request-request-existing>

It may not be more difficult for a client to *use* an access token at the
AS / RS. But there is definitely an overhead on the client to *manage* this
separate access token.

On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <[email-masked]>
wrote:

> You're anticipating a lot of issues which have no specific reason to
> occur, such as "can't be used with the token management APIs?". The
> management API is part of the same general flow.
> As for a persistent identifier instead of a continuation API, and
> generally the end of your message, it's a totally unrelated issue to this
> PR, so I suggest we don't discuss that here, but in a separate issue if
> needed.
>
> Fabien
>
>>  - If the AS wants to be fully stateless, then you can encode more data
>> in a token than in a uri
>>> Having a specific name is a possibility, I actually suggested that too
>>> at some point.
>>>
>>> Fabien
>>>
>>>> >> For #3) Even after I typed out the hypothetical attack, that was
>>>> sort of in the back of my mind, it isn't a huge risk there. So I actually
>>>> agree with Dick there. Something doesn't sit right with me for the unique
>>>> URL solution, so I don't like it and came up with a hypothetical that seems
>>>> >> The AS returns a URI for manipulating the request. I would change
>>>> the spec so that each request would have a unique URI. This is the usually

-- 

DISCLAIMER: This email

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 15 Dec 2020 13:52:33 +0100

Ok, could you be more specific as to what you'd expect for the persistent
identifier ?
Thanks
Fabien

On Tue, Dec 15, 2020 at 1:50 PM Dave Tonge <[email-masked]> wrote:

>>> So we've established that this is a different access token, that
>>> requires different handling at the client. So keeping it could cause more
>>> confusion?
>>>
>>> As an RC, I will have to store the continue `uri` as although it could
>>> be static it could also be dynamic. Why do I need to store an access token
>>> as well. It brings me no benefit as an RC, in fact it brings more
>>> complexity. As I will now need to manage multiple types of tokens with
>>> different lifecycles:
>>>
>>> *Continuation token*
>>> RC sends signature and metadata, AS responds with a continue uri that
>>> has these purposes:
>>>  - can be used by the RC when making a new grant to identify the
>>> previous grant
>>>
>>>>> Thanks for the clarification. I think only accepting this kind of
>>>>> token at the continuation is a good idea otherwise the AS would need to be
>>>>> able to parse and understand all sorts of access tokens.
>>>>>
>>>>> Conceptually, I like the idea to treat the continuation as another
>>>>> kind of resource. However, here are some observations I want to share with
>>>>> you:
>>>>> I would consider using a different term to refer to this special
>>>>> access token, grant token or grant handle for example, in order to prevent
>>>>> confusion.
>>>>>
>>>>> best regards,
>>>>> Torsten.
>>>>>
>>>>>
>>>>> >
>>>>> > Best
>>>>> > Fabien
>>>>> >
>>>>> >> 2) instead of blame arguments of who's less
>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversations, I
>>>>> suggest we speak in less abstract terms and ask ourselves what that means
>>>>> in practice for devs. Stephen and several others (myself included) have
>>>>> expressed that it wouldn't be harder to implement, it would even simplify
>>>>> things quite a lot. If you disagree please send us a code sample to really
>>>>> show that point by example, because that's really not obvious.
>>>>> >>
>>>>> >> So in this case, the easy way out is to pass the access token to
>>>>> the client, who then, as i stated before, treats the continue request as a
>>>>> RS call (albeit a specialized version of the RS where the RS is the AS) OR
>>>>> to use the unique URL,
>>>>> >> but that seems open to a brute force attack by a malicious RC.
>>>>> (What would be the point of that attack, I don't know, I guess if someone
>>>>> had the client credentials but not any subjects/resources they could try to
>>>>> >> In other words, I don't see the need for an access token, so it
>>>>> does not need to be put in a URL or an auth header.
>>>>> >>
>>>>> >> Even though I've only been lightly following things, I feel the
>>>>> need to voice my preference as a developer since I will probably someday
>>>>> have to either write a RC or RS...
>>>>> >>
>>>>> >> Personally I like that, because if I have an access_token, I
>>>>> already think "Put it in the auth header."
>>>>> >>

---

From: Warren Parad <[email-masked]>
Date: Tue, 15 Dec 2020 14:58:13 +0100

> do so. I agree it's not yet included but it's perfectly feasible.

I think we are so focused on the "we can do this and this and thin with it"
that we aren't thinking about why we *need *it. Instead of what can be done
we should be thinking about, "what can't be done without it" or even
perhaps "With it we won't have to..."

For instance, it's easy to construct an argument against hypothetical value
it could provide in cases that don't exist yet. Equally vacuous arguments
could be made for coupling to the future apis/services endpoints when
necessary as well as delaying adding the session token to the spec until
after it is necessary.

> ensures that your call is anthenticated with the same key as before, while

Could you say more about the potential problem here, I'm not totally
following.

> resource.

Exactly, and why not. Further just as we can return arbitrary urls in the
body of a request, why not utilize the hardened REST patterns and return
them in for instance a Location header. By encouraging custom responses
having to reassemble future requests we are implicitly saying "We don't
like any of the existing recommended patterns", and while it's totally okay
to digress from them, we should have a really good reason to do so.

Warren Parad

Founder, CTO

On Tue, Dec 15, 2020 at 1:53 PM Fabien Imbault <[email-masked]>
wrote:

>> It may not be more difficult for a client to *use* an access token at
>> the AS / RS. But there is definitely an overhead on the client to
>> *manage* this separate access token.
>>
>>
>>
>>> But it doesn't mean it's more difficult for the client that already
>>> needs to be able to handle tokens anyway (bearer or not, both cases could
>>> occur). It's mostly consolidating the logic.
>>>
>>> Anticipating issues with rotation is useful, but there are also many
>>> ways it can be hard to manage through a stateful approach too. And
>>>>>> >> You're completely right. Allowing the dev to be lazy is a very
>>>>>> good thing in general, because it's what we know will work :-)
>>>>>> >>
>>>>>> >> I still think the access token model with the signed request is
>>>>>> the way I'd like to go, because again, it's a mechanism I'd be implementing
>>>>>> >> 1) yes we could make pre-register mandatory, but we already
>>>>>> decided that wouldn't be how that would work. We have a client instance
>>>>>> that allows a more generic and flexible pattern (which BTW also allows what
>>>>>> you want)
>>>>>> >>
>>>>>> >> 3) "If someone has the client credentials, they can impersonate
>>>>>> the client, and all bets are off." Are you seriously making this argument?
>>>>>> >> key (object / string) : The public key of the RC to be used in
>>>>>> this request as described in {{request-key}}. This field is REQUIRED.
>>>>>> >> ...
>>>>>> >> "
>>>> Financial Services Register (FRN 809360) at
>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is
>>>> registered in England & Wales, company registration number 06909772.
>>>> Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus
>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.
>>>>

---

From: Dave Tonge <[email-masked]>
Date: Tue, 15 Dec 2020 14:58:24 +0100

A string that can be used to identify the grant in order to get its latest
status, continue, update, revoke.

Internally an AS will have an identifier for a grant
Internally an RC will have an identifier for a grant
Why can't we just make this explicit in the protocol.

In the current world of OAuth 2 we have
 - refresh token
 - PAR
 - device_code in OAuth Device Flow
 - grant management
<https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md>
 - auth_req_id in CIBA
 - "consent ids" in proprietary APIs

They all somehow represent the "grant", but the fact that most of them are
tacked on to the existing protocol, causes problems.

I really like the fact that GNAP has the current "continue" endpoint built
into the spec - allowing "grant management" to be a first class feature of
the protocol. But I don't like the fact that an ephemeral rotating token is
the identifier for the grant.

A failed network request can mean that the RC no longer has access to
manage a grant - in fact they may not even be able to reference it when
starting a new grant as they may only have access to an expired access
token that the AS may not accept. This seems unnecessarily brittle.

-- 

DISCLAIMER: This email

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 15 Dec 2020 15:11:20 +0100

Hi there
Comments embedded
Thxs

On Tue, Dec 15, 2020 at 2:58 PM Warren Parad <[email-masked]> wrote:

> I think we are so focused on the "we can do this and this and thin with
> it" that we aren't thinking about why we *need *it. Instead of what can
> be done we should be thinking about, "what can't be done without it" or
> even perhaps "With it we won't have to..."
>

[FI] I guess we're all guilty of "why not" now and then. But in this
specific case, the need is pretty clear and directly related to the
revocation features we've been discussing.

>
> For instance, it's easy to construct an argument against hypothetical
> value it could provide in cases that don't exist yet. Equally vacuous
> arguments could be made for coupling to the future apis/services endpoints
> when necessary as well as delaying adding the session token to the spec
> until after it is necessary.
>

[FI] not a big deal when people use a library, but otherwise end developers
may just end up copying the URI directly, not checking the TLD+1. With a
basic stateless URL, a simple compare is enough.

> to digress from them, we should have a really good reason to do so.

[FI] where did you see that we don't follow any of the existing recommended
patterns?

>>>>>  - If the AS wants to be fully stateless, then you can encode more
>>>>> data in a token than in a uri
>>>>>  - If the AS wants to have a static endpoint for CRUD operations on
>>>>> the grant
>>>>>> Having a specific name is a possibility, I actually suggested that
>>>>>> too at some point.
>>>>>>
>>>>>> Fabien
>>>>>>
>>>>>>> - This resource is different as it will issue other access tokens
>>>>>>> (of this kind) to be used in subsequent continuation requests. This
>>>>>>> requires different handing on the client side.
>>>>>>> - This access token (if I understand correctly) is (or at least
>>>>>>> feels like) a handle for the underlying grant. So it is kind of the super
>>>>>>> access token to obtain other access tokens.
>>>>>>>
>>>>>>> >> The client is signing the first request. The key *might* be in
>>>>>>> the body. The client is signing all the subsequent requests as well. The
>>>>>>> >> Others had already responded to this previous thread, but I
>>>>>>> wanted to add a couple points to clarify some things.
>>>>>>> >>
>>>>>>> >>> 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
>>>>>>> >>> 6) There is no standard identifier for the request. Debugging
>>>>>>> and auditing are hampered by the client and AS having no standard way to
>>>>>>> >> Debugging and auditing this kind of thing are functions of the
>>>>>>> AS. How is interoperability harmed by different ASs having different
>>>>>>> methods to identify their internal data elements? The client doesn’t need
>>>>>>> any knowledge of the AS’s identifiers, it just needs to know the next steps
>>>>>>> for continuing the negotiation.
>>>>>>> >>
>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial
>>>>> Technology Limited which is authorised and regulated by the Financial
>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the
>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial
>>>>> Technology Limited which is authorised and regulated by the Financial
>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Dec 2020 09:33:24 -0500

I agree with Fabien that the persistent identifier is a separate issue. The current spec re-uses the access token for this artifact, but that’s potentially brittle and could be changed out for something else. There’s an issue asking for expanding on the use cases for this functionality (which hasn’t been addressed by this PR):

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87>

A potentially-rotating URI would be just as brittle, and so having a single codified identifier for this artifact would be useful, but it does assume some things about the nature of the AS. Every other use the client has to manage the ongoing request over time doesn’t need an explicit identifier. Just like with OAuth-protected APIs, the server can determine the context not just from the URI but from the rest of the request, including the access token itself. This is both more common and more powerful than a strict reading of REST designs. It also follows the HATEOS principles as the entire HTTP request is taken into account, including the access token and signature portions. 

I’ll also point out that the rotation of these credentials is also filed as a separate issue that’s not being addressed right now, so we can revisit that discussion separately:

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87>

As for the name, we could give it a different label. We have this same pattern of issuing a resource-specific access token alongside a URL in the Dynamic Registration specification, both in OAuth (https://tools.ietf.org/html/rfc7592#section-3 <https://tools.ietf.org/html/rfc7592#section-3>) and OpenID Connect (https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse <https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse>). Here it’s called the “registration access token” — but what’s important there, as it is here, is that it’s not a different kind of artifact that the client now has to figure out how to use, it’s an access token plain and simple. In the OAuth world this is a bearer token, since that’s what OAuth 2 uses. In the GNAP world it’ll be a bound token, as that’s what we’re looking to build on. This is also related to another future discussion about responses tying an access token to a specific API that’s told to the client, as we could potentially re-use those components and concepts here as well:

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69>

And finally, no speculation on the complexity is needed: I implemented this pattern several months ago during the design team discussions when we were considering this pattern, and the code is all online for people to see. 

https://github.com/bspk/oauth.xyz-java/ <https://github.com/bspk/oauth.xyz-java/>

On the AS side, the most interesting code to this discussion is in the TransactionEndpoint class:

https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java <https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java>

Here, you’ll see that on initial request, the server looks up the client to see if it’s been registered, but after that, it makes sure that the token and key are appropriate for the ongoing request. From the client side it’s even simpler. The client’s got a small service function to manage the different signature methods that are implemented, and all of them can take in an optional access token: 

https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java <https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java>

The heavy lift is doing the actual signing, and you need that in order to start the process anyway. Managing the access token as an artifact to use at the API is completely trivial since the client already needs to manage its own state internally to do any of this. And note that all of this is changed from how it was before: Previously, the XYZ Protocol had used a “transaction handle” returned by the AS that the client would use to continue the request. However, this simple model was limiting, and the design team adopted XAuth’s model of continuation being an API. In doing so, we made it like all of the other APIs the client is going to call: in the initial state, it doesn’t have any kind of access rights, it’s just calling. From that initial call forward, the AS just needs to know that the token and key match what it expects. 

In summary, my views are:
 - The access token pattern has a lot of benefits, otherwise we wouldn’t have an entire OAuth ecosystem based on it
 - Magic URIs have a lot of drawbacks which are well understood; while they can be mitigated, they can also be avoided
 - Continuation is an API, and treating it like the other kinds of API the client would call makes sense
 - Calling this by a special name, like “grant access token” or “continuation access token” is fine, but it should function like any other access token
 - The heavy lift for clients is on protecting the message cryptographically, which they need to do anyway

 — Justin

> On Dec 15, 2020, at 7:50 AM, Dave Tonge <[email-masked]> wrote:
> 
> The persistent identifier is not a different issue, the current access token is used to reference an existing grant <https://github.com/ietf-wg-gnap/gnap-core-protocol/blob/main/draft-ietf-gnap-core-protocol.md#referencing-an-existing-grant-request-request-existing> 
> 
> It may not be more difficult for a client to use an access token at the AS / RS. But there is definitely an overhead on the client to manage this separate access token. 
> 
> 
> 
> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> I think we always said the access token was different, and handled as a bound token.
> 
> But it doesn't mean it's more difficult for the client that already needs to be able to handle tokens anyway (bearer or not, both cases could occur). It's mostly consolidating the logic.
> 
> You're anticipating a lot of issues which have no specific reason to occur, such as "can't be used with the token management APIs?". The management API is part of the same general flow.
> Anticipating issues with rotation is useful, but there are also many ways it can be hard to manage through a stateful approach too. And fundamentally, having everything in a common model (both for the internals of the AS and for the API calls) will help improve by a large margin what is probably the weakest point in today's infrastructure. But it's early to be definitive as to the downstream impact either way.   
> 
> As for a persistent identifier instead of a continuation API, and generally the end of your message, it's a totally unrelated issue to this PR, so I suggest we don't discuss that here, but in a separate issue if needed.
> 
> Fabien
> 
> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge <[email-masked] <mailto:[email-masked]>> wrote:
> So we've established that this is a different access token, that requires different handling at the client. So keeping it could cause more confusion?
> 
> As an RC, I will have to store the continue `uri` as although it could be static it could also be dynamic. Why do I need to store an access token as well. It brings me no benefit as an RC, in fact it brings more complexity. As I will now need to manage multiple types of tokens with different lifecycles:
> 
> Continuation token 
>   - can only be used at the continue endpoint (the name of which is confusing as I can use this endpoint to revoke a grant or get metadata on the grant).
> Access token(s) to use at RS
> From my perspective, most use-cases will require the RC to have a persistent identifier for the grant. Why not bring this into the protocol and let the AS provide this persistent identifier (through the form of the continue uri). Using a rotating access token as a persistent identifier doesn't seem like the right choice. 
> 
> I see no security benefit to having the continuation access token. It doesn't matter if the continue uri leaks as it is useless without an accompanying signature, i.e. any security benefit of having an access token is already provided by having a signature.
> 
>  - If the AS wants to be fully stateless, then you can encode more data in a token than in a uri
>  - If the AS wants to have a static endpoint for CRUD operations on the grant
> If we dropped the access token for the continue endpoint and rather mandated a dynamic uri this would make things conceptually easier to understand, easier for the RC to implement, easier to debug and less chance of errors when rotating tokens (i.e. race conditions could be quite likely if the AS always rotates the token)
> 
> One-off grant with no continuation or ongoing management:
> RC sends signature and metadata, no `continue` response provided, therefore no grant management possible
> 
> Grant with ongoing management
> RC sends signature and metadata, AS responds with a continue uri that has these purposes:
>  - can be used by the RC when making a new grant to identify the previous grant
> 
> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Torsten, 
> 
> - for the first remark, it fits quite nicely the init request  / continuation pattern 
> - for the second remark, it is a sort of handle for the continuation request, which will eventually lead to the issuance or refresh of standard access tokens 
> 
> Having a specific name is a possibility, I actually suggested that too at some point. 
> 
> Fabien
> 
> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Fabien, 
> 
> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <[email-masked] <mailto:[email-masked]>>:
> > 
> > Hi,
> > 
> > Le sam. 12 déc. 2020 à 11:33, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> a écrit :
> > Hi all,
> > 
> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <[email-masked] <mailto:[email-masked]>>:
> >> 
> >> 
> >> Rotation of the access token and artifacts for ongoing continuation responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87>
> >> 
> >> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI>
> 
> -- 
> TXAuth mailing list
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> 
> 
> 
> -- 
> Dave Tonge
> CTO
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
>

---

From: Dave Tonge <[email-masked]>
Date: Tue, 15 Dec 2020 16:50:53 +0100

> The access token pattern has a lot of benefits, otherwise we wouldn’t
have an entire OAuth ecosystem based on it

*But what are the benefits in this particular use case?* The continuation
API is not like any other API - it is integral to the AS. There are quite a
few extensions to OAuth that use client authentication rather than access
tokens. From a previous email the advantages I see are:
 - more data can be encoded in a token than in a uri (this seems more of an
edge case)
 - it can be an identifier for the grant (I don't agree with this)

Another question I have: *do we envisage granting access tokens to the RC
that will allow it to manage multiple grants*?

I also think there will be confusion with the signing being used for
different things. Maybe it just needs to be called out in the spec that:

Request 1: signature = client authentication
Request 2+: signature = proof of possession for access token

On Tue, 15 Dec 2020 at 15:33, Justin Richer <[email-masked]> wrote:

> I agree with Fabien that the persistent identifier is a separate issue.
> The current spec re-uses the access token for this artifact, but that’s
> potentially brittle and could be changed out for something else. There’s an
> issue asking for expanding on the use cases for this functionality (which
> hasn’t been addressed by this PR):
>
> A potentially-rotating URI would be just as brittle, and so having a
> single codified identifier for this artifact would be useful, but it does
> assume some things about the nature of the AS. Every other use the client
> has to manage the ongoing request over time doesn’t need an explicit
> identifier. Just like with OAuth-protected APIs, the server can determine
> the context not just from the URI but from the rest of the request,
> including the access token itself. This is both more common and more
> powerful than a strict reading of REST designs. It also follows the HATEOS
> principles as the entire HTTP request is taken into account, including the
> access token and signature portions.
>
> I’ll also point out that the rotation of these credentials is also filed
> as a separate issue that’s not being addressed right now, so we can revisit
> that discussion separately:
>
> As for the name, we could give it a different label. We have this same
> pattern of issuing a resource-specific access token alongside a URL in the
> Dynamic Registration specification, both in OAuth (
> https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect (
> https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse).
> Here it’s called the “registration access token” — but what’s important
> there, as it is here, is that it’s not a different kind of artifact that
> the client now has to figure out how to use, it’s an access token plain and
> simple. In the OAuth world this is a bearer token, since that’s what OAuth
> 2 uses. In the GNAP world it’ll be a bound token, as that’s what we’re
> looking to build on. This is also related to another future discussion
> about responses tying an access token to a specific API that’s told to the
> client, as we could potentially re-use those components and concepts here
> as well:
>
> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69
>
> And finally, no speculation on the complexity is needed: I implemented
> this pattern several months ago during the design team discussions when we
> were considering this pattern, and the code is all online for people to
> see.
>
> https://github.com/bspk/oauth.xyz-java/
>
> https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java
>
> Here, you’ll see that on initial request, the server looks up the client
> to see if it’s been registered, but after that, it makes sure that the
> token and key are appropriate for the ongoing request. From the client side
> it’s even simpler. The client’s got a small service function to manage the
> different signature methods that are implemented, and all of them can take
> in an optional access token:
>
>
> https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java
>
> The heavy lift is doing the actual signing, and you need that in order to
> start the process anyway. Managing the access token as an artifact to use
> at the API is completely trivial since the client already needs to manage
> its own state internally to do any of this. And note that all of this is
> changed from how it was before: Previously, the XYZ Protocol had used a
> “transaction handle” returned by the AS that the client would use to
> continue the request. However, this simple model was limiting, and the
> design team adopted XAuth’s model of continuation being an API. In doing
> so, we made it like all of the other APIs the client is going to call: in
> the initial state, it doesn’t have any kind of access rights, it’s just
> calling. From that initial call forward, the AS just needs to know that the
> token and key match what it expects.
>
>  - The access token pattern has a lot of benefits, otherwise we wouldn’t
> have an entire OAuth ecosystem based on it
>  - Magic URIs have a lot of drawbacks which are well understood; while
> they can be mitigated, they can also be avoided
>  - Calling this by a special name, like “grant access token” or
> “continuation access token” is fine, but it should function like any other
> access token
>  - The heavy lift for clients is on protecting the message
> cryptographically, which they need to do anyway
>
>  — Justin
>
>

-- 

DISCLAIMER: This email

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Dec 2020 11:30:33 -0500

On Dec 15, 2020, at 10:50 AM, Dave Tonge <[email-masked]> wrote:
> 
> > The access token pattern has a lot of benefits, otherwise we wouldn’t have an entire OAuth ecosystem based on it
> 
> But what are the benefits in this particular use case? The continuation API is not like any other API - it is integral to the AS. There are quite a few extensions to OAuth that use client authentication rather than access tokens.

Yes, and the propagation of that has lead to a mess in the OAuth world. You’ve got re-definitions of client authentications at all different endpoints, they’re technically allowed to vary between endpoints (though I don’t know of it happening in practice, that feels like a downgrade attack waiting to happen to someone). Then there’s the fact that all the newest security mechanisms we have — PKCE, DPoP, and MTLS — don’t rely on client authentication at all to achieve security. All of these work without the client having credentials previously known to the AS, and we already know that GNAP is going to need to live in this more dynamic world. We need to think beyond what OAuth 2 has done in the past, and especially from our perceptions and assumptions of the models that drive OAuth 2’s decisions, lest we repeat its mistakes. 

Also, I want to challenge this idea of “integral to the AS” as a point. In OAuth 1, the API was “integral” to the server side, but in OAuth 2 we split that into the RS concept. Even though in practice, a lot of RS’s are still integrated to the AS in some fashion because it’s a single service, OAuth 2 is clear about what’s expected to be known by each component. For the AS as currently defined in GNAP, I’m seeing three distinct functions. As per the Terminology discussion, we don’t have explicit names for these yet:

 - starting a request; this is an endpoint to kick things off; it needs to be able to look up the rights asked for by the client (if it knows the client at all ahead of time) and make initial decisions about needed interaction and follow up
 - continuing a request; this is an API that needs to know the context of the request itself, including which key it’s bound to; this is separate from any identity of the client and possibly the user, but an AS implementation that has access to those elements can use them
 - interacting with the user; this is front-facing and in OAuth today is already deployed as a separate service in some places, we should embrace that at the very least (but doing so formally is a separate issue)

Why separate these in this way? There is immense power in having a single consistent way to start the process. The “continuation API” gives us an HTTP-defined mechanism for managing a request over time, including the simple case of returning information from the front channel, but people have already raised the question of non-HTTP and self-hosted AS’s, which would probably want a different kind of continuation API to communicate to the AS. The same thing with separating out the interaction: there are going to be a lot of different ways to handle interaction out there, and not all of them will be “integral” to the AS in the way that a simple implementation might do. We’re defining a protocol based strongly on HTTP and JSON, but we should structure it in such a way that it can be extended and translated elsewhere in a clear way.

This all raises the question: if we can rely on a unique URL for redirect-based interaction, why not here? The simple reason is that a URL is the :only: mechanism we have in the front channel for passing information, and we need to warn implementors against including sensitive information in it, and we need to protect it with additional items. We have access to more than just URLs when we’re dealing with the continuation API, and we ought to make use of all of our tools in ways that are consistent and make sense.

> From a previous email the advantages I see are:
>  - more data can be encoded in a token than in a uri (this seems more of an edge case)

It allows the parts above to live separately, even if they don’t HAVE to. And it simplifies what we’re asking the client to do by making it consistent with other parts of the ecosystem. The AS offering an API doesn’t :have: to be different, and OpenID Connect showed us, with the UserInfo Endpoint, that that’s very much the case in practice. 

Having my client code do very similar things in slightly different ways is not simpler.

> 
> Another question I have: do we envisage granting access tokens to the RC that will allow it to manage multiple grants?  

I don’t see that happening, personally, and it hasn’t been brought up as a use case to date. 

> 
> I also think there will be confusion with the signing being used for different things. Maybe it just needs to be called out in the spec that:
> 

That’s more or less the intent of what’s in the specification right now, and why all the signature methods, which are used for both client auth and token possession, are all together in section 8 and not separated by use.  (With the caveat: it’s only client authentication in the first request if the AS knows about the client instance ahead of time, which isn’t always going to be true.) That all can likely be made clearer, as is always the case with spec text. But you can use the signature methods with and without access tokens, and it only gets used without in an initial call where you don’t :have: an access token to present.

Separating the different kinds of “client authentication" out in OAuth is the source of some real confusion. Like right now, what happens if you try to combine a client assertion, signed request objects for PAR, and DPoP proofs, all in a single request? All of these are optional and all of them “do client authentication” in some arguable fashion. I’ve worked on several systems and implemented these things, and their interplay is really confusing to manage and can go sideways really fast. And that’s just the work for a single endpoint, this gets repeated for introspection, revocation, CIBA, device, and on.

At the end of the day I’m in favor of giving the client developers a very clear set of directions on what they need to do and how they need to access things, and treating the continuation as a token-bound API is, to me, the clearest pattern we can offer for this piece.

 — Justin

> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, 15 Dec 2020 at 15:33, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 15, 2020, at 7:50 AM, Dave Tonge <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dave Tonge <[email-masked]>
Date: Tue, 15 Dec 2020 22:11:19 +0100

Thanks for the detailed response.

I think you make the points well and I'm now in favour of the PR.
However I do think that to keep the consistency that keeps being discussed,
that the tokens shouldn't be rotated.

I also think it would be good to have a discussion about "grant management"
and identifiers for a grant.

Dave

On Tue, 15 Dec 2020 at 17:30, Justin Richer <[email-masked]> wrote:

> tokens.
> Yes, and the propagation of that has lead to a mess in the OAuth world.
> You’ve got re-definitions of client authentications at all different
> endpoints, they’re technically allowed to vary between endpoints (though I
> don’t know of it happening in practice, that feels like a downgrade attack
> waiting to happen to someone). Then there’s the fact that all the newest
> security mechanisms we have — PKCE, DPoP, and MTLS — don’t rely on client
> authentication at all to achieve security. All of these work without the
> client having credentials previously known to the AS, and we already know
> that GNAP is going to need to live in this more dynamic world. We need to
> think beyond what OAuth 2 has done in the past, and especially from our
> perceptions and assumptions of the models that drive OAuth 2’s decisions,
> lest we repeat its mistakes.
>
> Also, I want to challenge this idea of “integral to the AS” as a point. In
> OAuth 1, the API was “integral” to the server side, but in OAuth 2 we split
> that into the RS concept. Even though in practice, a lot of RS’s are still
> integrated to the AS in some fashion because it’s a single service, OAuth 2
> is clear about what’s expected to be known by each component. For the AS as
> currently defined in GNAP, I’m seeing three distinct functions. As per the
> Terminology discussion, we don’t have explicit names for these yet:
>
>  - starting a request; this is an endpoint to kick things off; it needs to
> be able to look up the rights asked for by the client (if it knows the
> client at all ahead of time) and make initial decisions about needed
> interaction and follow up
>  - continuing a request; this is an API that needs to know the context of
> the request itself, including which key it’s bound to; this is separate
> from any identity of the client and possibly the user, but an AS
> implementation that has access to those elements can use them
>  - interacting with the user; this is front-facing and in OAuth today is
> already deployed as a separate service in some places, we should embrace
> that at the very least (but doing so formally is a separate issue)
>
> Why separate these in this way? There is immense power in having a single
> consistent way to start the process. The “continuation API” gives us an
> HTTP-defined mechanism for managing a request over time, including the
> simple case of returning information from the front channel, but people
> have already raised the question of non-HTTP and self-hosted AS’s, which
> would probably want a different kind of continuation API to communicate to
> the AS. The same thing with separating out the interaction: there are going
> to be a lot of different ways to handle interaction out there, and not all
> of them will be “integral” to the AS in the way that a simple
> implementation might do. We’re defining a protocol based strongly on HTTP
> and JSON, but we should structure it in such a way that it can be extended
> and translated elsewhere in a clear way.
>
> This all raises the question: if we can rely on a unique URL for
> redirect-based interaction, why not here? The simple reason is that a URL
> is the :only: mechanism we have in the front channel for passing
> information, and we need to warn implementors against including sensitive
> information in it, and we need to protect it with additional items. We have
> access to more than just URLs when we’re dealing with the continuation API,
> and we ought to make use of all of our tools in ways that are consistent
> and make sense.
>
> It allows the parts above to live separately, even if they don’t HAVE to.
> And it simplifies what we’re asking the client to do by making it
> consistent with other parts of the ecosystem. The AS offering an API
> doesn’t :have: to be different, and OpenID Connect showed us, with the
> UserInfo Endpoint, that that’s very much the case in practice.
>
> That’s more or less the intent of what’s in the specification right now,
> and why all the signature methods, which are used for both client auth and
> token possession, are all together in section 8 and not separated by use.
>  (With the caveat: it’s only client authentication in the first request if
> the AS knows about the client instance ahead of time, which isn’t always
> going to be true.) That all can likely be made clearer, as is always the
> case with spec text. But you can use the signature methods with and without
> access tokens, and it only gets used without in an initial call where you
> don’t :have: an access token to present.
>
> Separating the different kinds of “client authentication" out in OAuth is
> the source of some real confusion. Like right now, what happens if you try
> to combine a client assertion, signed request objects for PAR, and DPoP
> proofs, all in a single request? All of these are optional and all of them
> “do client authentication” in some arguable fashion. I’ve worked on several
> systems and implemented these things, and their interplay is really
> confusing to manage and can go sideways really fast. And that’s just the
> work for a single endpoint, this gets repeated for introspection,
> revocation, CIBA, device, and on.
>
> At the end of the day I’m in favor of giving the client developers a very
> clear set of directions on what they need to do and how they need to access
> things, and treating the continuation as a token-bound API is, to me, the
> clearest pattern we can offer for this piece.
>
>  — Justin
>
>
>
>
>
>
>
>
>

-- 

DISCLAIMER: This email

---

From: Dick Hardt <[email-masked]>
Date: Tue, 15 Dec 2020 15:01:50 -0800

Dave: which points changed your mind?

On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <[email-masked]> wrote:

> However I do think that to keep the consistency that keeps being
> discussed, that the tokens shouldn't be rotated.
>
> I also think it would be good to have a discussion about "grant
> management" and identifiers for a grant.
>
> Dave
>
>> *But what are the benefits in this particular use case?* The
>> continuation API is not like any other API - it is integral to the AS.
>> There are quite a few extensions to OAuth that use client authentication
>> rather than access tokens.
>>
>>
>> Also, I want to challenge this idea of “integral to the AS” as a point.
>> In OAuth 1, the API was “integral” to the server side, but in OAuth 2 we
>> split that into the RS concept. Even though in practice, a lot of RS’s are
>> still integrated to the AS in some fashion because it’s a single service,
>> OAuth 2 is clear about what’s expected to be known by each component. For
>> the AS as currently defined in GNAP, I’m seeing three distinct functions.
>> As per the Terminology discussion, we don’t have explicit names for these
>> yet:
>>
>>  - starting a request; this is an endpoint to kick things off; it needs
>> to be able to look up the rights asked for by the client (if it knows the
>> Another question I have: *do we envisage granting access tokens to the
>> RC that will allow it to manage multiple grants*?
>>
>>
>>> The heavy lift is doing the actual signing, and you need that in order
>>> to start the process anyway. Managing the access token as an artifact to
>>> use at the API is completely trivial since the client already needs to
>>> manage its own state internally to do any of this. And note that all of
>>> this is changed from how it was before: Previously, the XYZ Protocol had
>>> used a “transaction handle” returned by the AS that the client would use to
>>>>> <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
>>>>> t: +44 (0)117 280 5120
>>>>>
>>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA
>>>>> <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>
>>>>> .
>>>>>
>>> <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
>>> t: +44 (0)117 280 5120
>>>
>>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol,
>>> BS1 6EA
>>> <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>
>>> .
>>>
>> <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
>> t: +44 (0)117 280 5120
>>
>> 6EA
>> <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>
>> .
>>
> <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
> t: +44 (0)117 280 5120
>
> 6EA
> <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>
> .
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Dec 2020 01:14:43 +0000

I'm in agreement with the need for both of those discussions, we've a ways to go for this protocol, yet. Thanks for the discussion and insights. 

- Justin
________________________________________
From: Dave Tonge [[email-masked]]
Sent: Tuesday, December 15, 2020 4:11 PM
To: Justin Richer
Cc: Fabien Imbault; Torsten Lodderstedt; txauth gnap; Steve Moore; Dick Hardt
Subject: Re: [GNAP] Consensus Call on Continuation Request

I think you make the points well and I'm now in favour of the PR.
However I do think that to keep the consistency that keeps being discussed, that the tokens shouldn't be rotated.

I also think it would be good to have a discussion about "grant management" and identifiers for a grant.

Dave

On Tue, 15 Dec 2020 at 17:30, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 — Justin

On Tue, 15 Dec 2020 at 15:33, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Fabien that the persistent identifier is a separate issue. The current spec re-uses the access token for this artifact, but that’s potentially brittle and could be changed out for something else. There’s an issue asking for expanding on the use cases for this functionality (which hasn’t been addressed by this PR):

As for the name, we could give it a different label. We have this same pattern of issuing a resource-specific access token alongside a URL in the Dynamic Registration specification, both in OAuth (https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect (https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse). Here it’s called the “registration access token” — but what’s important there, as it is here, is that it’s not a different kind of artifact that the client now has to figure out how to use, it’s an access token plain and simple. In the OAuth world this is a bearer token, since that’s what OAuth 2 uses. In the GNAP world it’ll be a bound token, as that’s what we’re looking to build on. This is also related to another future discussion about responses tying an access token to a specific API that’s told to the client, as we could potentially re-use those components and concepts here as well:

 — Justin

On Dec 15, 2020, at 7:50 AM, Dave Tonge <[email-masked]<mailto:[email-masked]>> wrote:

The persistent identifier is not a different issue, the current access token is used to reference an existing grant<https://github.com/ietf-wg-gnap/gnap-core-protocol/blob/main/draft-ietf-gnap-core-protocol.md#referencing-an-existing-grant-request-request-existing>

On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <[email-masked]<mailto:[email-masked]>> wrote:
I think we always said the access token was different, and handled as a bound token.

Fabien

On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge <[email-masked]<mailto:[email-masked]>> wrote:
So we've established that this is a different access token, that requires different handling at the client. So keeping it could cause more confusion?

Continuation token

Dave

On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <[email-masked]<mailto:[email-masked]>> wrote:
Hi Torsten,

Fabien

On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Fabien,

> Am 12.12.2020 um 12:06 schrieb Fabien Imbault <[email-masked]<mailto:[email-masked]>>:
>
> Hi,
>

best regards,
Torsten.

>
> Best
> Fabien
>
> Le sam. 12 déc. 2020 à 11:33, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> a écrit :
> Hi all,
>
>> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <[email-masked]<mailto:[email-masked]>>:
>>
>> 
>> Le sam. 12 déc. 2020 à 03:15, Stephen Moore <[email-masked]<mailto:[email-masked]>> a écrit :
>> Hi Fabien,
>>
>> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <[email-masked]<mailto:[email-masked]>> wrote:
>> Le sam. 12 déc. 2020 à 00:35, Dick Hardt <[email-masked]<mailto:[email-masked]>> a écrit :
>>
>>
>> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <[email-masked]<mailto:[email-masked]>> wrote:
>> But from the spec:
>> "
>> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
>> Hi Stephen
>>
>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <[email-masked]<mailto:[email-masked]>> wrote:
>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
>> inline ...
>>
>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

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

--
Dave Tonge
CTO
[Moneyhub Enterprise]<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
Moneyhub Financial Technology Limited 2019 ©

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.

--
Dave Tonge
CTO
[Moneyhub Enterprise]<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
Moneyhub Financial Technology Limited 2019 ©

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.

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

--
Dave Tonge
CTO
[Moneyhub Enterprise]<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
Moneyhub Financial Technology Limited 2019 ©

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.

--
Dave Tonge
CTO
[Moneyhub Enterprise]<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
Moneyhub Financial Technology Limited 2019 ©

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.

---

From: Dave Tonge <[email-masked]>
Date: Wed, 16 Dec 2020 10:09:17 +0100

> Dave: which points changed your mind?

1. The issue with re-using client authentication across endpoints in the
OAuth 2 world
(token_endpoint_auth_methods_supported,
revocation_endpoint_auth_methods_supported,
introspection_endpoint_auth_methods_supported...)

2. The clear articulation of the 3 different functions of the AS (including
the idea of a self-hosted AS)

3. The aim to support a more dynamic environment where client
authentication only happens in the first interaction between the RC and the
AS

4. The agreement that there should be further discussion on whether this
access token should be rotated, and whether it should be an identifier of
the grant.

On Wed, 16 Dec 2020 at 00:02, Dick Hardt <[email-masked]> wrote:

>>>  - continuing a request; this is an API that needs to know the context
>>> of the request itself, including which key it’s bound to; this is separate
>>> Why separate these in this way? There is immense power in having a
>>> single consistent way to start the process. The “continuation API” gives us
>>> an HTTP-defined mechanism for managing a request over time, including the
>>> It allows the parts above to live separately, even if they don’t HAVE
>>> to. And it simplifies what we’re asking the client to do by making it
>>> Separating the different kinds of “client authentication" out in OAuth
>>> is the source of some real confusion. Like right now, what happens if you
>>> try to combine a client assertion, signed request objects for PAR, and DPoP
>>> At the end of the day I’m in favor of giving the client developers a
>>> very clear set of directions on what they need to do and how they need to
>>> access things, and treating the continuation as a token-bound API is, to
>>> me, the clearest pattern we can offer for this piece.
>>>
>>>  — Justin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> I’ll also point out that the rotation of these credentials is also
>>>> filed as a separate issue that’s not being addressed right now, so we can
>>>> revisit that discussion separately:
>>>>
>>>> Here, you’ll see that on initial request, the server looks up the
>>>> client to see if it’s been registered, but after that, it makes sure that
>>>> the token and key are appropriate for the ongoing request. From the client
>>>> side it’s even simpler. The client’s got a small service function to manage
>>>> the different signature methods that are implemented, and all of them can
>>>> take in an optional access token:
>>>>
>>>>
>>>>  - The access token pattern has a lot of benefits, otherwise we
>>>> wouldn’t have an entire OAuth ecosystem based on it
>>>>>> As an RC, I will have to store the continue `uri` as although it
>>>>>> could be static it could also be dynamic. Why do I need to store an access
>>>>>> token as well. It brings me no benefit as an RC, in fact it brings more
>>>>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>>> Hi Torsten,
>>>>>>>
>>>>>>>> > After having skimmed through the current draft and the PR, I‘m
>>>>>>>> not sure whether the continuation requests accepts any access token issued
>>>>>>>> to the RC or the particular access token returned in the „continue“ element
>>>>>>>> in section 3.1..
>>>>>>>> >
>>>>>>>> >> If you don't have the access token, then how do you
>>>>>>>> differentiate between two requests from the same web application by two
>>>>>>>> different users? Is the web application supposed to have different
>>>>>>>> credentials for every request?
>>>>>>>> >>
>>>>>>>> >> The AS returns a URI for manipulating the request. I would
>>>>>>>> change the spec so that each request would have a unique URI. This is the
>>>>>>>> usually RESTful pattern that the resource (the grant request) has an URI.
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> The way I see it is the RC makes the initial request to the AS
>>>>>>>> as part of this request, it provides it's key in the body... (So no use of
>>>>>>>> the Authorization header)
>>>>>>>> >> So my client posts to whatever URL with the 'access token' in
>>>>>>>> the authorization header, just like acting on any other resource I have a
>>>>>>>> token for. YES, I get a new token value to use every call, and there is a
>>>>>>>> >> Correct, but the delta between the calls a client would make
>>>>>>>> with and without an access token is vanishingly small. The client has to
>>>>>>>> sign the initial request in some fashion, and it will sign the continuation
>>>>>>>> >> Per my other point, there is no value to me in my
>>>>>>>> implementations of passing context back and forth between the client and AS
>>>>>>>> -- so it is extra work providing no value.
>>>>>>>> >>
>>>>>>>> >> Clients making a request to an AS and not getting an access
>>>>>>>> token is a new design pattern. I think it has value and should be included,
>>>>>>>> but OAuth today shows us the immense value of getting access tokens for
>>>>>>>> >> More properly, if the AS does not provide a “continue” field
>>>>>>>> then the client can’t delete the request — and yes, that’s intentional. The
>>>>>>>> AS is telling this client instance that it can’t do anything else with this

-- 

DISCLAIMER: This email

---

From: Warren Parad <[email-masked]>
Date: Wed, 16 Dec 2020 11:15:26 +0100

#4 is a prereq for this discussion though. If the token is the identifier
of the grant then it must be in the url to avoid the problem of arbitrary
url construction. Of course the uri would be
*https://as/grants/{grantIdentifier}
<https://as/grants/{grantIdentifier}>*. And this is actually independent of
whether or not the token gets rotated.

#3 The idea of a dynamic environment is important here, however the
argument doesn't justify having this being the same endpoint. Nothing stops
us from having two endpoints, one that requests an access token separate
from the ones that manage the grant resource.

Warren Parad

Founder, CTO

On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge <[email-masked]> wrote:

> (token_endpoint_auth_methods_supported, revocation_endpoint_auth_methods_supported, introspection_endpoint_auth_methods_supported...)
>
> 2. The clear articulation of the 3 different functions of the AS
> (including the idea of a self-hosted AS)
>
>>>> > The access token pattern has a lot of benefits, otherwise we
>>>>  - interacting with the user; this is front-facing and in OAuth today
>>>> is already deployed as a separate service in some places, we should embrace
>>>> That’s more or less the intent of what’s in the specification right
>>>> now, and why all the signature methods, which are used for both client auth
>>>> and token possession, are all together in section 8 and not separated by
>>>> use.  (With the caveat: it’s only client authentication in the first
>>>> request if the AS knows about the client instance ahead of time, which
>>>> isn’t always going to be true.) That all can likely be made clearer, as is
>>>> always the case with spec text. But you can use the signature methods with
>>>> and without access tokens, and it only gets used without in an initial call
>>>> where you don’t :have: an access token to present.
>>>>
>>>>> I agree with Fabien that the persistent identifier is a separate
>>>>> issue. The current spec re-uses the access token for this artifact, but
>>>>> that’s potentially brittle and could be changed out for something else.
>>>>> There’s an issue asking for expanding on the use cases for this
>>>>> functionality (which hasn’t been addressed by this PR):
>>>>>
>>>>>>> I see no security benefit to having the continuation access token.
>>>>>>> It doesn't matter if the continue uri leaks as it is useless without an
>>>>>>>>> >> For #3) Even after I typed out the hypothetical attack, that
>>>>>>>>> was sort of in the back of my mind, it isn't a huge risk there. So I
>>>>>>>>> actually agree with Dick there. Something doesn't sit right with me for the
>>>>>>>>> unique URL solution, so I don't like it and came up with a hypothetical
>>>>>>>>> that seems like it could be a down side.
>>>>>>>>> >>
>>>>>>>>> >> And more importantly you never responded to the issues of how
>>>>>>>>> to avoid the security pitfalls of what you proposed.
>>>>>>>>> >>
>>>>>>>>> >> Fabien
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> So in this case, the easy way out is to pass the access token
>>>>>>>>> to the client, who then, as i stated before, treats the continue request as
>>>>>>>>> a RS call (albeit a specialized version of the RS where the RS is the AS)
>>>>>>>>> OR to use the unique URL,
>>>>>>>>> >>> 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
>>>>>>>>> >> The client is getting the "access token" from its API. It is
>>>>>>>>> not using an "access_token" in other API calls to the AS.
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> Debugging between the client and the AS was what I was
>>>>>>>>> referring to. How does a client developer identify the request when
>>>>>>>>> communicating to the AS developer. Seems complicated.
>>>>>>>>> >>
>>>>>>>>> >> ᐧ
>>>>>>>>> >> --
>>>>>>>>> >> TXAuth mailing list
>>>>>>>>> >> [email-masked]

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 16 Dec 2020 12:07:01 +0100

Hi,

I've created 2 separate issues :
* Grant identifier
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146
* Rotation https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/147

Cheers
Fabien

On Wed, Dec 16, 2020 at 11:15 AM Warren Parad <[email-masked]> wrote:

> url construction. Of course the uri would be *https://as/grants/{grantIdentifier}
> <https://as/grants/%7BgrantIdentifier%7D>*. And this is actually
> independent of whether or not the token gets rotated.
>
>>>>> Yes, and the propagation of that has lead to a mess in the OAuth
>>>>> world. You’ve got re-definitions of client authentications at all different
>>>>> Also, I want to challenge this idea of “integral to the AS” as a
>>>>> point. In OAuth 1, the API was “integral” to the server side, but in OAuth
>>>>> 2 we split that into the RS concept. Even though in practice, a lot of RS’s
>>>>> are still integrated to the AS in some fashion because it’s a single
>>>>> service, OAuth 2 is clear about what’s expected to be known by each
>>>>> component. For the AS as currently defined in GNAP, I’m seeing three
>>>>> distinct functions. As per the Terminology discussion, we don’t have
>>>>> explicit names for these yet:
>>>>>
>>>>>  - starting a request; this is an endpoint to kick things off; it
>>>>> needs to be able to look up the rights asked for by the client (if it knows
>>>>> the client at all ahead of time) and make initial decisions about needed
>>>>> Another question I have: *do we envisage granting access tokens to
>>>>> the RC that will allow it to manage multiple grants*?
>>>>>
>>>>>
>>>>>> As for the name, we could give it a different label. We have this
>>>>>> same pattern of issuing a resource-specific access token alongside a URL in
>>>>>> the Dynamic Registration specification, both in OAuth (
>>>>>> And finally, no speculation on the complexity is needed: I
>>>>>> implemented this pattern several months ago during the design team
>>>>>> discussions when we were considering this pattern, and the code is all
>>>>>> online for people to see.
>>>>>>
>>>>>> The heavy lift is doing the actual signing, and you need that in
>>>>>> order to start the process anyway. Managing the access token as an artifact
>>>>>> to use at the API is completely trivial since the client already needs to
>>>>>>  - Magic URIs have a lot of drawbacks which are well understood;
>>>>>> while they can be mitigated, they can also be avoided
>>>>>> The persistent identifier is not a different issue, the current
>>>>>> access token is used to reference an existing grant
>>>>>> It may not be more difficult for a client to *use* an access token
>>>>>> at the AS / RS. But there is definitely an overhead on the client to
>>>>>> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <
>>>>>>>>>> Conceptually, I like the idea to treat the continuation as
>>>>>>>>>> another kind of resource. However, here are some observations I want to
>>>>>>>>>> share with you:
>>>>>>>>>> >> I still think the access token model with the signed request
>>>>>>>>>> is the way I'd like to go, because again, it's a mechanism I'd be
>>>>>>>>>> implementing anyway to talk to any 'normal' resource. The fact is there is
>>>>>>>>>> _something_ representing context that has to pass back and forth here,
>>>>>>>>>> whether that is an access token (which I feel like is more flexible for
>>>>>>>>>> extensions etc), a unique url, or even a cookie sent in the cookie header.
>>>>>>>>>> So just to re-iterate, I'm a +1 on this pull request, speaking as a lazy
>>>>>>>>>> developer ;)
>>>>>>>>>> >> -steve
>>>>>>>>>> >>
>>>>>>>>>> >> 3) "If someone has the client credentials, they can
>>>>>>>>>> impersonate the client, and all bets are off." Are you seriously making
>>>>>>>>>> this argument? Because if you have a better proposal than using
>>>>>>>>>> cryptographic keys, I'm all hears. You make it look like there's a problem,
>>>>>>>>>> while in reality we're only relying on the basic assumption of all modern
>>>>>>>>>> digital communications.
>>>>>>>>>> >>
>>>>>>>>>> >> The client field can be an object or a string. If the client
>>>>>>>>>> is pre-registered, then a string could be provided instead of an object.
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> In other words, I don't see the need for an access token, so
>>>>>>>>>> it does not need to be put in a URL or an auth header.
>>>>>>>>>> >>
>>>>>>>>>> >> If a developer really, really wants to hand context back to
>>>>>>>>>> the client for subsequent calls, they can put it in the URL or some other
>>>>>>>>>> >> Even though I've only been lightly following things, I feel
>>>>>>>>>> the need to voice my preference as a developer since I will probably
>>>>>>>>>> someday have to either write a RC or RS...
>>>>>>>>>> >>
>>>>>>>>>> >> I’m not sure what you mean by these being different — the
>>>>>>>>>> whole point of the design is that the client would be doing the same thing
>>>>>>>>>> with the access token at the AS that it does with the RS by re-using the
>>>>>>>>>> access token structure. Can you please describe what the differences are,
>>>>>>>>>> apart from the rotation? Presentation of the token and signing of the
>>>>>>>>>> message are identical.
>>>>>>>>>> >>
>>>>>>>>>> >> Also, any client authentication mechanism that wants to use
>>>>>>>>>> the HTTP Authentication header is precluded from using it.
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Dec 2020 06:37:34 -0500

On Dec 16, 2020, at 5:15 AM, Warren Parad <[email-masked]> wrote:
> 
> #4 is a prereq for this discussion though. If the token is the identifier of the grant then it must be in the url to avoid the problem of arbitrary url construction. Of course the uri would be https://as/grants/{grantIdentifier} <https://as/grants/%7BgrantIdentifier%7D>. And this is actually independent of whether or not the token gets rotated.

That’s not true: the identifier exposed to the client for some purpose like grant extension doesn’t have to be the same identifier that the AS uses for management. The latter is internal, and exposing internal state to the protocol shouldn’t be a requirement to the pattern. 

> 
> #3 The idea of a dynamic environment is important here, however the argument doesn't justify having this being the same endpoint. Nothing stops us from having two endpoints, one that requests an access token separate from the ones that manage the grant resource.

Nobody said this has to be the same endpoint. In fact, this structure is being put in place to allow them to be separate endpoints. My original design in XYZ used a single endpoint and exposed an internal identifier of the ongoing grant request to the client within the protocol (the transaction handle). Changing this to a properly abstracted and protected API pattern allows much greater flexibility. The AS now has the choice of how it wants to manage its own dispatching, without the client needing to be aware of any of it since the client always does the same thing.

 — Justin

> On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge <[email-masked] <mailto:[email-masked]>> wrote:
> 1. The issue with re-using client authentication across endpoints in the OAuth 2 world (token_endpoint_auth_methods_supported, revocation_endpoint_auth_methods_supported, introspection_endpoint_auth_methods_supported...)
> 
> 2. The clear articulation of the 3 different functions of the AS (including the idea of a self-hosted AS)
> 
> 3. The aim to support a more dynamic environment where client authentication only happens in the first interaction between the RC and the AS
> 
> 4. The agreement that there should be further discussion on whether this access token should be rotated, and whether it should be an identifier of the grant.
> 
> 
> On Wed, 16 Dec 2020 at 00:02, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, 15 Dec 2020 at 17:30, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> On Dec 15, 2020, at 10:50 AM, Dave Tonge <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>t: +44 (0)117 280 5120
>>> 
>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>. 
>>> 
>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>t: +44 (0)117 280 5120
>>> 
>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>. 
>>> 
>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>t: +44 (0)117 280 5120
>> 
>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>. 
>> 
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>t: +44 (0)117 280 5120
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>. 
>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 16 Dec 2020 09:52:50 -0800

This has been a great discussion, and we've opened three new issues to
track things that came up in this thread that follow on from the changes in
the PR:

* persistent grant identifier
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146
* rotation of tokens related to continuation request
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/147
* special label for access token used for continuation
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/149

The editors believe the specifics in this PR have rough consensus, so we're
going ahead with merging it.

Aaron

On Wed, Dec 16, 2020 at 3:37 AM Justin Richer <[email-masked]> wrote:

> That’s not true: the identifier exposed to the client for some purpose
> like grant extension doesn’t have to be the same identifier that the AS
> uses for management. The latter is internal, and exposing internal state to
> the protocol shouldn’t be a requirement to the pattern.
>
>
> Nobody said this has to be the same endpoint. In fact, this structure is
> being put in place to allow them to be separate endpoints. My original
> design in XYZ used a single endpoint and exposed an internal identifier of
> the ongoing grant request to the client within the protocol (the
> transaction handle). Changing this to a properly abstracted and protected
> API pattern allows much greater flexibility. The AS now has the choice of
> how it wants to manage its own dispatching, without the client needing to
> be aware of any of it since the client always does the same thing.
>
>  — Justin
>
>
> Warren Parad
> Founder, CTO

---

From: Mike Varley <[email-masked]>
Date: Fri, 18 Dec 2020 14:38:29 +0000

Apologies for being late to the conversation – and I see the discussion has sparked off other topics, but I just wanted to add my support (+1) for the access token requirement for the AS continuation API endpoint.

I’ll admit I struggled with why this needed to be a hard MUST and could not remain optional; although there are a broader range of deployment use cases that are supported with the concept of an access token (distributed AS systems, for example) why make it a _requirement_? But I am supportive of the requirement for the following reasons:

  1.  Optional spec requirements lead to interop challenges, as implementations usually cover the MUSTS and leave the ‘rest for later’ – so when a system is designed using the options, finding supporting libraries and products is a challenge to interop and deployment. And I agree with the github remark on the issue of either it is important enough to be a requirement and we can justify it, or it should be removed.
  2.  In recent systems SK has worked with where there is a GNAP-like protocol, being able to provide a Client with a context specific access_token for the ‘continuation’ api calls – linking those tokens to a session at the AS beyond a cookie or ‘txn_id’ – would make the API more consistent for the Client for when access_tokens are required for other parts of the protocol. Even in situations where our AS was just performing an authentication (and not returning claims beyond the authN activity) the access token makes sense; we would have access_tokens for ‘live session API calls’  and rely on client-credentials for broader scope, non-session bound API calls.
  3.  Having the capability for the AS to leverage access_tokens (instead of just client credentials) enables – but does not require – a more diverse range of distributed system/decoupled scenarios. For example, one could design a system where there is a loose consortium of AS providers controlling access to an individual’s personal data provider of choice, and the access_tokens allow these AS to transfer session control between them. This is great but _even in the case where this nonsense is not required_ having a single implementation pattern for a Client is crucial for interopetability, and I believe this access_token requirement does not introduce over complexity to support.

Thanks,

MV

From: TXAuth <[email-masked]>
Date: Wednesday, December 16, 2020 at 12:53 PM
To: Justin Richer <[email-masked]>
Cc: Dave Tonge <[email-masked]>, txauth gnap <[email-masked]>, Steve Moore <[email-masked]>, Fabien Imbault <[email-masked]>, Torsten Lodderstedt <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [GNAP] Consensus Call on Continuation Request
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

This has been a great discussion, and we've opened three new issues to track things that came up in this thread that follow on from the changes in the PR:

* persistent grant identifier https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146
* rotation of tokens related to continuation request https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/147
* special label for access token used for continuation https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/149

The editors believe the specifics in this PR have rough consensus, so we're going ahead with merging it.

Aaron

On Wed, Dec 16, 2020 at 3:37 AM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
On Dec 16, 2020, at 5:15 AM, Warren Parad <[email-masked]<mailto:[email-masked]>> wrote:

#4 is a prereq for this discussion though. If the token is the identifier of the grant then it must be in the url to avoid the problem of arbitrary url construction. Of course the uri would be https://as/grants/{grantIdentifier}<https://as/grants/%7BgrantIdentifier%7D>. And this is actually independent of whether or not the token gets rotated.

 — Justin

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement Authress<https://bit.ly/37SSO1p>.

On Wed, 16 Dec 2020 at 00:02, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Dave: which points changed your mind?

On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the detailed response.

Dave

 — Justin

 — Justin

Fabien

Continuation token

Dave

Fabien

best regards,
Torsten.

>> ?
>> ?
>> ?
>> ?

--
Dave Tonge
CTO
Error! Filename not specified.<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL<https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA<https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>.

--
Dave Tonge
CTO
Error! Filename not specified.<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL<https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA<https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>.

--
Dave Tonge
CTO
Error! Filename not specified.<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL<https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA<https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>.

--
Dave Tonge
CTO
Error! Filename not specified.<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL<https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA<https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>.

--
Dave Tonge
CTO
Error! Filename not specified.<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.