Re: [GNAP] Consensus Call on Continuation Request

[Dick Hardt <[e-mail]>]

I don't understand what security risks are unique with the GNAP URI
relative to other API URIs that have a unique identifier in them.

Developers can get "creative" and put "inappropriate" values in any API URI
they design.

What are the security implications of using a large random value as the
<unique grant id>?


ᐧ

On Mon, Dec 14, 2020 at 11:46 AM 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
>>
>