Re: [GNAP] Consensus Call on Continuation Request

[Warren Parad <[e-mail]>]

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
>
>
>