Re: [GNAP] Consensus Call on Continuation Request

[Fabien Imbault <[e-mail]>]

Hi Torsten,

You're right on both accounts.
- for the first remark, it fits quite nicely the init request  /
continuation pattern
- for the second remark, it is a sort of handle for the
continuation request, which will eventually lead to the issuance or refresh
of standard access tokens

Having a specific name is a possibility, I actually suggested that too at
some point.

Fabien

On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <[e-mail]>
wrote:

> Hi Fabien,
>
> > Am 12.12.2020 um 12:06 schrieb 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.
>
> Thanks for the clarification. I think only accepting this kind of token at
> the continuation is a good idea otherwise the AS would need to be able to
> parse and understand all sorts of access tokens.
>
> Conceptually, I like the idea to treat the continuation as another kind of
> resource. However, here are some observations I want to share with you:
> - This resource is different as it will issue other access tokens (of this
> kind) to be used in subsequent continuation requests. This requires
> different handing on the client side.
> - This access token (if I understand correctly) is (or at least feels
> like) a handle for the underlying grant. So it is kind of the super access
> token to obtain other access tokens.
>
> I would consider using a different term to refer to this special access
> token, grant token or grant handle for example, in order to prevent
> confusion.
>
> best regards,
> Torsten.
>
>
> >
> > 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
> >>
> >> 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
> >> --
> >> 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
>
>