Re: [GNAP] Consensus Call on Continuation Request

[Fabien Imbault <[e-mail]>]

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

> 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 <[e-mail]> 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
>>
>> On Dec 11, 2020, at 9:17 AM, Fabien Imbault <[e-mail]>
>> 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 <[e-mail]> 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 <[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
>>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>