Re: [GNAP] Consensus Call on Continuation Request

[Justin Richer <[e-mail]>]

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} <https://as/grant/%7BgrantId%7D>",
>     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] <mailto:[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] <mailto:[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 <https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f>
> 
> The routing code in the AS then is:
> 
> router.post <http://router.post/>(      '/', grant.create);
> router.get(        '/grant/:grant', grant.read);
> router.post <http://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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>