Re: [GNAP] Consensus Call on Continuation Request

[Justin Richer <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> 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
> -- 
> TXAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>