Re: [GNAP] Consensus Call on Continuation Request

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 <wparad@rhosys.ch> 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 <dick.hardt@gmail.com> 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 <jricher@mit.edu> 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
>>> TXAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>> --
>> TXAuth mailing list
>> TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>