Re: [GNAP] Consensus Call on Continuation Request

[Fabien Imbault <[e-mail]>]

Hi Warren,

The goal is not to force a behavior for the sake of forcing it, as Justin
explained one of the goals is to avoid to the extra complexity of
optionality when there's no fundamental reason for doing so. Which leaves
open the question of which alternative is best of course, and that's what
we're discussing here (security is not the only argument).

Just wondering. If you're ready to hardcode the same value in every request
in one case, why do you think better to have unique URIs in the other case?

Plus the problem is not that you control the AS URI, it's that you have
only limited trust for what's in front of that. A bound access token
ensures that your call is anthenticated with the same key as before, while
the alternative doesn't.

Fabien


Le lun. 14 déc. 2020 à 21:41, Warren Parad <[e-mail]> a écrit :

> So then I would say the question becomes, why force AS to create "access
> tokens" (or whatever we want to call them) if they don't see the benefit of
> doing so. I.e. right now the Warren AS (and the Dick AS) both think we
> would not be generating "access tokens". If the spec requires it, I would
> probably just hard code the same value in every request because my AS
> doesn't see the value in requiring it when I'm in control of the URI.
>
> If I understand the discussion correctly, we are trying to prevent AS from
> exposing the uri containing the "access token", because doing so would
> hypothetically create an attack surface for the AS. If that's the case,
> then I would say, forcing the token to be in auth header only provides a
> negligible amount of surface decrease and thus the extra complexity is not
> well offset by the security improvement. So for me rather than arguing if
> there is any benefit at all, I'll make a stronger argument:
> *If there is a benefit to using the access token, it surely can't be a
> meaningful amount in such a way that it's important from the GNAP protocol
> standpoint to provide this mechanism for improvement.*
>
> Warren Parad
>
> Founder, CTO
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://bit.ly/37SSO1p>.
>
>
> On Mon, Dec 14, 2020 at 9:29 PM Justin Richer <[e-mail]> wrote:
>
>> Warren,
>>
>> (as editor):
>>
>> Your proposal below is not dissimilar to what’s in the current spec text:
>> the URI is required, and the access token is optional. If the access token
>> is included, the client has to include it in its request. The feedback from
>> the working group during the IETF109 meeting, and leading up to it, was
>> nearly universally that this optionality was not helpful, especially to
>> client developers. The editors’ PR being discussed here removes that
>> optionality by making both fields required with only one method of
>> presentation, and therefore a single code path for the client.
>>
>>  — Justin
>>
>> On Dec 14, 2020, at 3:11 PM, Warren Parad <[e-mail]> wrote:
>>
>> Here's a terrible alternative:
>>
>> It would seem to me that one compromise could be making the object
>> extensible by authorization servers (and their corresponding SDK). In a
>> similar way that JWTs are extensible, we could require explicitly the URI
>> in the spec, and an optional object to be defined by the AS.
>>
>> --------
>>
>> One source of the problem could be that the language for taking the
>> response object and converting it back into a request one is not well
>> defined.
>> Instead if we allowed an optional headers object to be returned:
>> {
>>     uri: "https://as/grant/{grantId}",
>>     headers: {
>>         'Authorization': 'Bearer ${accessToken}
>>     }
>> }
>>
>> Thereby explicitly telling the client what they need to return back. It
>> avoids the problem of "what to name these things" and also ensures that the
>> data is exactly what the server expects. Additionally it sidesteps the
>> naming issue, where to include tokens, and whether to include them at all.
>>
>> Otherwise it sucks to be in a situation where the benefits/detriments
>> aren't clear to everyone, and potentially we can choose a path forward
>> where both approaches could be used without requiring other clients to jump
>> over arbritrary hurdles suchs as custom implementations.
>>
>> Warren Parad
>> Founder, CTO
>> Secure your user data and complete your authorization architecture.
>> Implement Authress <https://bit.ly/37SSO1p>.
>>
>>
>> On Mon, Dec 14, 2020 at 8:46 PM Aaron Parecki <[e-mail]> wrote:
>>
>>> Thanks for the clear description. However saying "has no security
>>> concerns" is a bold claim. Can you clarify how you will ensure that there
>>> are no security concerns with this method?
>>>
>>> My main worry with this is people will start to get "creative" with the
>>> values of the things in this URL. We've seen this over and over, everything
>>> from using plaintext data in JWT access tokens in OAuth (now the access
>>> token contents are visible to clients), to putting data in the OAuth
>>> "state" parameter (easy to exploit unless it's signed/encrypted), and I'm
>>> sure someone somewhere is putting things in the authorization code that
>>> they shouldn't.
>>>
>>> Aaron
>>>
>>>
>>> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> I am proposing a URI that is straight forward, and has no
>>>> security concerns.
>>>>
>>>> For example, the URI could be:
>>>>
>>>> <as uri>/grant/<unique grant id>
>>>>
>>>> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f
>>>>
>>>> The routing code in the AS then is:
>>>>
>>>> router.post(      '/', grant.create);
>>>> router.get(        '/grant/:grant', grant.read);
>>>> router.post(      '/grant/:grant', grant.update);
>>>> router.delete(   '/grant/:grant', grant.delete);
>>>> router.options( '/grant/:grant', grant.options);
>>>>
>>>>
>>>> Where there is a "grant" module to manage for working with grant
>>>> requests.
>>>>
>>>> /Dick
>>>>
>>>> ps: your previous email, and this one, are making the discussion
>>>> personal. Happy to discuss privately.
>>>>
>>>> ᐧ
>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>