Re: [GNAP] Consensus Call on Continuation Request

[Fabien Imbault <[e-mail]>]

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 <[e-mail]> wrote:

> 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
>
> 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/
> ᐧ
>
> On Thu, Dec 10, 2020 at 7:52 AM Justin Richer <[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
>>
>> 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]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>