Re: [GNAP] Consensus Call on Continuation Request

[Fabien Imbault <[e-mail]>]

Hi,

On the contrary your feedback is most welcome.

It doesn't accept any token, it needs the particular token as described in
3.1 and which is not a bearer token (that's what the "key" : true parameter
is supposed to convey).

Let us know if you need more clarifications.

Best
Fabien

Le sam. 12 déc. 2020 à 11:33, Torsten Lodderstedt <[e-mail]>
a écrit :

> Hi all,
>
> I didn’t follow GNAP closely so bear with me if me question seems naive.
>
> After having skimmed through the current draft and the PR, I‘m not sure
> whether the continuation requests accepts any access token issued to the RC
> or the particular access token returned in the „continue“ element in
> section 3.1..
>
> Can you please shed some light on this?
>
> kind regards,
> Torsten.
>
> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <[e-mail]>:
>
> 
> You're completely right. Allowing the dev to be lazy is a very good thing
> in general, because it's what we know will work :-)
>
> Le sam. 12 déc. 2020 à 03:15, Stephen Moore <[e-mail]> a écrit :
>
>> Hi Fabien,
>>
>> For #3) Even after I typed out the hypothetical attack, that was sort of
>> in the back of my mind, it isn't a huge risk there. So I actually agree
>> with Dick there. Something doesn't sit right with me for the unique URL
>> solution, so I don't like it and came up with a hypothetical that seems
>> like it could be a down side.
>>
>> I still think the access token model with the signed request is the way
>> I'd like to go, because again, it's a mechanism I'd be implementing anyway
>> to talk to any 'normal' resource. The fact is there is _something_
>> representing context that has to pass back and forth here, whether that is
>> an access token (which I feel like is more flexible for extensions etc), a
>> unique url, or even a cookie sent in the cookie header. So just to
>> re-iterate, I'm a +1 on this pull request, speaking as a lazy developer ;)
>> -steve
>>
>> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <[e-mail]>
>> wrote:
>>
>>> Again speaking in my own name here.
>>>
>>> Dick, we know you'd prefer to have a different design, but this PR
>>> shouldn't be about that.
>>>
>>> Back on your 3 items :
>>>
>>> 1) yes we could make pre-register mandatory, but we already decided that
>>> wouldn't be how that would work. We have a client instance that allows a
>>> more generic and flexible pattern (which BTW also allows what you want)
>>>
>>> 2) instead of blame arguments of who's less restful/HATEOAS/whatever
>>> that have the tenancy to flame conversations, I suggest we speak in less
>>> abstract terms and ask ourselves what that means in practice for devs.
>>> Stephen and several others (myself included) have expressed that it
>>> wouldn't be harder to implement, it would even simplify things quite a lot.
>>> If you disagree please send us a code sample to really show that point by
>>> example, because that's really not obvious.
>>>
>>> 3) "If someone has the client credentials, they can impersonate the
>>> client, and all bets are off." Are you seriously making this argument?
>>> Because if you have a better proposal than using cryptographic keys, I'm
>>> all hears. You make it look like there's a problem, while in reality we're
>>> only relying on the basic assumption of all modern digital communications.
>>>
>>> And more importantly you never responded to the issues of how to avoid
>>> the security pitfalls of what you proposed.
>>>
>>> Fabien
>>>
>>>
>>> Le sam. 12 déc. 2020 à 00:35, Dick Hardt <[e-mail]> a
>>> écrit :
>>>
>>>>
>>>>
>>>> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <[e-mail]>
>>>> wrote:
>>>>
>>>>> But from the spec:
>>>>> "
>>>>> When sending a non-continuation request to the AS, the RC MUST
>>>>> identify itself by including the client field of the request...
>>>>> ...
>>>>> key (object / string) : The public key of the RC to be used in this
>>>>> request as described in {{request-key}}. This field is REQUIRED.
>>>>> ...
>>>>> "
>>>>>
>>>> So on the initial request, the key will be there.
>>>>>
>>>>
>>>> The client field can be an object or a string. If the client is
>>>> pre-registered, then a string could be provided instead of an object.
>>>>
>>>>>
>>>>
>>>>>
>>>>> If you don't have the access token, then how do you differentiate
>>>>> between two requests from the same web application by two different users?
>>>>> Is the web application supposed to have different credentials for every
>>>>> request?
>>>>>
>>>>
>>>> The AS returns a URI for manipulating the request. I would change the
>>>> spec so that each request would have a unique URI. This is the usually
>>>> RESTful pattern that the resource (the grant request) has an URI.
>>>>
>>>>
>>>>
>>>>> So in this case, the easy way out is to pass the access token to the
>>>>> client, who then, as i stated before, treats the continue request as a RS
>>>>> call (albeit a specialized version of the RS where the RS is the AS) OR to
>>>>> use the unique URL,
>>>>> but that seems open to a brute force attack by a malicious RC. (What
>>>>> would be the point of that attack, I don't know, I guess if someone had the
>>>>> client credentials but not any subjects/resources they could try to
>>>>> intercept the grant via continue... I just don't feel right locking things
>>>>> down to unique URLs that way.)
>>>>>
>>>>
>>>> If someone has the client credentials, they can impersonate the client,
>>>> and all bets are off.
>>>>
>>>> LOTS of RS servers return a resource specific URL -- my proposal is no
>>>> different.
>>>>
>>>>
>>>>
>>>>
>>>>> -steve
>>>>>
>>>>> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hi Stephen
>>>>>>
>>>>>> The client is signing the first request. The key *might* be in the
>>>>>> body. The client is signing all the subsequent requests as well. The
>>>>>> "access token" is not needed by the client to prove it is authorized as the
>>>>>> client is proving it is the same client again.
>>>>>>
>>>>>> In other words, I don't see the need for an access token, so it does
>>>>>> not need to be put in a URL or an auth header.
>>>>>>
>>>>>> If a developer really, really wants to hand context back to the
>>>>>> client for subsequent calls, they can put it in the URL or some other
>>>>>> method. Putting it in the HTTP Authorization header is confusing because it
>>>>>> is NOT an access token -- it is the context of the request.
>>>>>>
>>>>>> ᐧ
>>>>>>
>>>>>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Even though I've only been lightly following things, I feel the need
>>>>>>> to voice my preference as a developer since I will probably someday have to
>>>>>>> either write a RC or RS...
>>>>>>>
>>>>>>> The way I see it is the RC makes the initial request to the AS as
>>>>>>> part of this request, it provides it's key in the body... (So no use of the
>>>>>>> Authorization header)
>>>>>>> At this point that request, represented by the continue URL +
>>>>>>> "Access Token", from my lazy developer standpoint, is a Resource Endpoint
>>>>>>> and Access Token, and the AS is acting as a specialized RS in this case.
>>>>>>> So my client posts to whatever URL with the 'access token' in the
>>>>>>> authorization header, just like acting on any other resource I have a token
>>>>>>> for. YES, I get a new token value to use every call, and there is a
>>>>>>> decision point of "Do I have another continue, or do I have a real token
>>>>>>> for the resource..." But the mechanism is the same to me in the client.
>>>>>>> Personally I like that, because if I have an access_token, I already
>>>>>>> think "Put it in the auth header."
>>>>>>>
>>>>>>> So my vote would be +1 for the pull request at this time.
>>>>>>> -steve
>>>>>>>
>>>>>>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> inline ...
>>>>>>>>
>>>>>>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Others had already responded to this previous thread, but I wanted
>>>>>>>>> to add a couple points to clarify some things.
>>>>>>>>>
>>>>>>>>> 3) What the client has to do with the "access token" is not the
>>>>>>>>> same as access tokens for an RS. The client gets a new "access token" for
>>>>>>>>> each grant request, and for each API call to the AS, and the client learns
>>>>>>>>> it can not make any more API calls for that specific request when it does
>>>>>>>>> not get an "access token" back. This is a completely different design
>>>>>>>>> pattern than calling an RS API with an access token, and is a new design
>>>>>>>>> pattern for calling APIs. This adds complexity to the client that it would
>>>>>>>>> not normally have, and I don't think GNAP is the right place to start a new
>>>>>>>>> design pattern.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I’m not sure what you mean by these being different — the whole
>>>>>>>>> point of the design is that the client would be doing the same thing with
>>>>>>>>> the access token at the AS that it does with the RS by re-using the access
>>>>>>>>> token structure. Can you please describe what the differences are, apart
>>>>>>>>> from the rotation? Presentation of the token and signing of the message are
>>>>>>>>> identical.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The client is getting the "access token" from its API. It is not
>>>>>>>> using an "access_token" in other API calls to the AS.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rotation of the access token and artifacts for ongoing
>>>>>>>>> continuation responses is a separate issue to be discussed:
>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87
>>>>>>>>> <https://www.google.com/url?q=https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87&source=gmail-imap&ust=1608345320000000&usg=AOvVaw33VPGP0MsjajzYTXZf5Sla>
>>>>>>>>>
>>>>>>>>> And for what it’s worth, GNAP is absolutely the right place to
>>>>>>>>> have new designs — not that this is one.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You are proposing a new way for an API to provide context for
>>>>>>>> subsequent API calls. Looks out of scope to me.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 4) Clients that only want claims from the AS and no access tokens
>>>>>>>>> will be required to support an API calling mechanism they would not have to
>>>>>>>>> support otherwise.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Correct, but the delta between the calls a client would make with
>>>>>>>>> and without an access token is vanishingly small. The client has to sign
>>>>>>>>> the initial request in some fashion, and it will sign the continuation
>>>>>>>>> request in the same exact fashion, but now include an access token in that
>>>>>>>>> request.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Per my other point, there is no value to me in my implementations
>>>>>>>> of passing context back and forth between the client and AS -- so it is
>>>>>>>> extra work providing no value.
>>>>>>>>
>>>>>>>> Also, any client authentication mechanism that wants to use the
>>>>>>>> HTTP Authentication header is precluded from using it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Clients making a request to an AS and not getting an access token
>>>>>>>>> is a new design pattern. I think it has value and should be included, but
>>>>>>>>> OAuth today shows us the immense value of getting access tokens for calling
>>>>>>>>> APIs, and so we shouldn’t optimize away from that pattern.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 5) If the AS does not provide an "access token", there is no
>>>>>>>>> mechanism for a client to delete the request, as the client is not allowed
>>>>>>>>> to make a call without an "access token".
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> More properly, if the AS does not provide a “continue” field then
>>>>>>>>> the client can’t delete the request — and yes, that’s intentional. The AS
>>>>>>>>> is telling this client instance that it can’t do anything else with this
>>>>>>>>> ongoing request. If the AS wants to allow the client to manage it, it will
>>>>>>>>> include the mechanisms to do so in the “continue” field.
>>>>>>>>>
>>>>>>>>
>>>>>>>> There is nuance in that intention. A related concern is that
>>>>>>>> deleting a request does not seem like it is a "continue" operation.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 6) There is no standard identifier for the request. Debugging and
>>>>>>>>> auditing are hampered by the client and AS having no standard way to
>>>>>>>>> identifying a request. While one AS may provide a unique URL for each grant
>>>>>>>>> request, another AS may use a persistent "access token" to identify the
>>>>>>>>> grant request, and other ASs may issue a new "access token" on each API
>>>>>>>>> call, providing no persistent identifier for the request.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Debugging and auditing this kind of thing are functions of the AS.
>>>>>>>>> How is interoperability harmed by different ASs having different methods to
>>>>>>>>> identify their internal data elements? The client doesn’t need any
>>>>>>>>> knowledge of the AS’s identifiers, it just needs to know the next steps for
>>>>>>>>> continuing the negotiation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Debugging between the client and the AS was what I was referring
>>>>>>>> to. How does a client developer identify the request when communicating to
>>>>>>>> the AS developer. Seems complicated.
>>>>>>>>
>>>>>>>> ᐧ
>>>>>>>> --
>>>>>>>> TXAuth mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI>
>>>>>>>>
>>>>>>> ᐧ
>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI>
>>>>
>>> --
> TXAuth mailing list
> [e-mail]
>
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI
>
>