Re: [GNAP] Consensus Call on Continuation Request

[Aaron Parecki <[e-mail]>]

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
>