Re: [GNAP] Consensus Call on Continuation Request

[Denis <[e-mail]>]

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>
>
> 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] 
>> <mailto:[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>
>>
>
>