Re: [GNAP] Consensus Call on Continuation Request

[Dick Hardt <[e-mail]>]

inline ...

On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <[e-mail]> wrote:

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

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


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

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


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

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.



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

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


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

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.

ᐧ