Re: [GNAP] Consensus Call on Continuation Request

[Justin Richer <[e-mail]>]

(As an individual):

There are a number of reasons and use cases that drive toward using an access token. A stateless, distributed AS is one of them, and an access token gives us a proven better way to shield the components from each other. While we could tell people to put that information into the URI, we’d then need to tell people how to protect all the information in the URI. This is a case where we can avoid problems in the design instead of having to fix them later. 

Then there’s the question of client authentication:  After the initial request, the AS doesn’t even need the client to “authenticate” as much as it needs to make sure that the same party is making the future call. Authentication only applies to clients that have a pre-registered key at the AS, and in that case only in the initial call. Anything after that can be tied to the context of the ongoing request, in much the same way an any other protected API just needs to know the context of the token. Now, from a client’s perspective, it’s still signing the continue request exactly like it did the initial request, it’s just including the access token as a header and covering it with the signature. And the AS can still look up the client’s instance information based on that request, just like any RS with access to that information would be able to. But at this point, the AS doesn’t :have: to do that because it can associate any rights and features for that request in the first step and carry that forward. After that first stage, it’s just modification of the ongoing request, and as long as that modification is being made by the authorized party (the client with access to the key) then it works. It’s the same argument that OAuth made for moving APIs to access tokens and away from API keys, and now that we are viewing “continue” as an API for the client to call, with multiple actions over time, then it makes sense to treat it like other APIs.

So, what does this mean for an AS to create access tokens for this step? Well, for the vast majority of AS’s out there, creating an access token is something they’re already really good at, and need to be prepared to do anyway. For an AS that isn’t dealing in access tokens at all, it’s an extra field to include, you are right.But even then, it would be trivial for an AS to create, for example, a simple signed JWT for continuation access to hand to the client. Do you want that token to last for 10 years and be good across all continuation requests for a given client? Go for it, that’s your security decision to make. And you can still use unique identifiers in your URLs, which has always been the case. But importantly, this specific use case can be supported without getting in the way of other patterns and at minimal cost. The cost to other patterns in terms of complexity and security risk is far greater if we use only URLs.

 — Justin

> On Dec 14, 2020, at 3:41 PM, Warren Parad <[e-mail]> wrote:
> 
> 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] <mailto:[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] <mailto:[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>