Re: [GNAP] Consensus Call on Continuation Request

[Warren Parad <[e-mail]>]

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
>