Re: [GNAP] Consensus Call on Continuation Request

[Fabien Imbault <[e-mail]>]

Hello Dick,

I'm reading what you write.

RESTful patterns are well understood, up to a limit. I've seen more debate
around what's good and what's not that on any other subject in my entire
career. It rarely helps, if ever. Because everyone thinks he applies the
concepts correctly anyway.

I observe we're going too much around XAuth (to cite you, "That is all that
I used in https://github.com/dickhardt/XAuth-poc") vs XYZ vs GNAP, in some
fashion, while I'm really hoping we can go forward. I also advise against
making personal attacks and would prefer that we'd keep the discussion to
technical arguments only. I'm sure we would all benefit from a win win
situation, where we try to arbitrate the best possible technical solution
that matches the group's goal. Knowing that there are many cases where it's
not black and white.

If you are able to convince me with your arguments, I'll back your proposal
(or any other, for that matter). But we're really not yet there in that
specific case. The cookie comparison is far stretched. I don't understand
what is complex in having to handle a token. Please note I'm also expecting
some feedback on the security model that should be put in place around the
URI model that you propose.

Then on your last point, I agree with you, we can certainly give an example
of access token. I'll get back to you on that.

Fabien
ps : I'm also open to discuss privately with you on a better way to
cooperate in general.

On Mon, Dec 14, 2020 at 7:00 PM Dick Hardt <[e-mail]> wrote:

> Fabien: a discussion would be more productive if you took some time
> reading what I wrote.
>
> I am not suggesting pre-registration be mandatory
>
> I am not making blame arguments are trying to start a flamewar -- I am
> pointing out that a RESTful like pattern is well understood.
>
> I am not suggesting we not use cryptographic keys.
>
> I am saying having an "access token" in addition to a URI adds complexity
> to both the client and the AS with little if any value. A URI is all that
> is needed unless there is a desire to make the AS stateless, or pass
> context between the AS and another server -- which seems to me of
> dubious value. That is all that I used in
> https://github.com/dickhardt/XAuth-poc
>
> So far we are discussing the "access token" in abstract terms. Would you
> describe what would be contained in the "access token"?
>
> /Dick
>
>
>
>
>
>
> ᐧ
>
> On Fri, Dec 11, 2020 at 5: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
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>> ᐧ
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>