Re: [GNAP] Consensus Call on Continuation Request

[Dick Hardt <[e-mail]>]

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
>>>>
>>> ᐧ