Re: [GNAP] Consensus Call on Continuation Request
Dick Hardt <dick.hardt@gmail.com> Mon, 14 December 2020 18:00 UTC
Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7553A0B22 for <txauth@ietfa.amsl.com>; Mon, 14 Dec 2020 10:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level:
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVLtUWxzRxFO for <txauth@ietfa.amsl.com>; Mon, 14 Dec 2020 10:00:35 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0397B3A0B17 for <txauth@ietf.org>; Mon, 14 Dec 2020 10:00:34 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id a12so32414430lfl.6 for <txauth@ietf.org>; Mon, 14 Dec 2020 10:00:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IU7O9/an3mtsSYBi7ReRMebv0W+fmCJNPYO5wu3gFlU=; b=rlnFD998VeAOnWkDpDC+IWzkAzZ7+FNe1HFjPEQ8H8SiAO2YL3VUMoR20/o6XByHKH 5n0DR+GlewOoTIiuyQXhx/Kogi5+CNaOn3xdr316QrPytKDGXUDmdGBDH7gUkvhgzmcY +GgqWFwNzDbsPN+vOEdollXMJ3L81fm1bCksdZr2hMV4LNHPwNGZNYXNfQzWmc1PSp5I U/nBYBKT9vsGgLiJuSVwjKlE134aFS44FXP+LG74aYgud46rNMYxcDgjnRj4ZdauZXhY +W5bV2WMWHnOSHcFJSVK7WSbbGM9XN+fo0iEhv9cgVaNDQtIwRGjJBp/UYpIRBTDFiJC wmHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IU7O9/an3mtsSYBi7ReRMebv0W+fmCJNPYO5wu3gFlU=; b=qARe39ZNbbe3mzSrOWfNotOrV2iHp2RxQ8LTgtWtcZNfUgxEVRkMtfWVL9IHG5Liow +NZrB2RREy8v/S8Va/6rwsIn3LOAbrOzTtls3tQPQiKIIyyqVeZ1dPGjar7Vpp+eE8Z5 kWaRE36Hh8EsZ4QsYzw341vq5QIyGpsi1eRZZl8wFuhqhw3CeripL1UAvt+m8B4W3D0t Urv3J6D1btRDFw3eOHOg76g0atl5jN6GWAmn4EtSZdy4qW6yXIpUx/UD9zK93UWnhimh Va4HFf4jZpzzxu+DbJRSQ/k7GT0zidcihcwutTjX3pjF6O3DjyiyAHW9H6Gu6xN7CC1W mkAw==
X-Gm-Message-State: AOAM531hmw+Ruo/g5zCGpFdxJvbXPvCtbKx1/uRUEFrAIzn8vfdTlfEa 9W//erxMh9rAHCk7qMVforqIMpdxGTba5aDyZxU=
X-Google-Smtp-Source: ABdhPJybwkA5EckzRNv2Xa49pLndnRS8fveItkIY4wVezWE8mONWXHCzKoZ5QaisSxH9Pt2L0yxZZwneAYFd7X/LcxI=
X-Received: by 2002:a19:3818:: with SMTP id f24mr7584371lfa.89.1607968832698; Mon, 14 Dec 2020 10:00:32 -0800 (PST)
MIME-Version: 1.0
References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <CAD9ie-v-j=PBGjLmiWT+z1Whimfmqo=+Pqw1DVFmXZO-bm7=4w@mail.gmail.com> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> <CAD9ie-spy7fX-9+5cXzyrau62sX=wViqdpMYzmFBfz-Qbi63ZQ@mail.gmail.com> <CAK5Vu_DW=8V8qNH-MnjjrUsnganpdwKxCCE1ZTJmENGYEvFoew@mail.gmail.com> <CAD9ie-vWgOVqcXiTTLfBBLx2AKDw_ry0A06CuL2DpKFmjYQ8YQ@mail.gmail.com> <CAK5Vu_DqO+iZHWaov94PXTfD5tKdN9R4w08o8Dd4RxFD3UGxOA@mail.gmail.com> <CAD9ie-ud4i51dF-PEY4r+QpAu2fYNob==R7Ek69rwU6cjy-zBQ@mail.gmail.com> <CAM8feuRBvjx_2nBNy95dDtc6v8A1ebKGKfNE4SwkcFA0-7SYCw@mail.gmail.com>
In-Reply-To: <CAM8feuRBvjx_2nBNy95dDtc6v8A1ebKGKfNE4SwkcFA0-7SYCw@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 14 Dec 2020 09:59:55 -0800
Message-ID: <CAD9ie-tEpVFfgB8KT3XK=G98wOTcVZxpXXRezCKbVuAP4hZoXQ@mail.gmail.com>
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: Stephen Moore <srmoore@gmail.com>, txauth gnap <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000153ddb05b6706b5a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/LTchvyNXLRtuU9F6Oj11ViP_aeo>
Subject: Re: [GNAP] Consensus Call on Continuation Request
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2020 18:00:39 -0000
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 <fabien.imbault@gmail.com> 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 <dick.hardt@gmail.com> a écrit : > >> >> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> 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 <dick.hardt@gmail.com> 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 <srmoore@gmail.com> >>>> 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 <dick.hardt@gmail.com> >>>>> wrote: >>>>> >>>>>> inline ... >>>>>> >>>>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> >>>>>> 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 >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> ᐧ >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >
- [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Denis
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Stephen Moore
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Stephen Moore
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Stephen Moore
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Torsten Lodderstedt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Aaron Parecki
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Torsten Lodderstedt
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Dick Hardt
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Dave Tonge
- Re: [GNAP] Consensus Call on Continuation Request Warren Parad
- Re: [GNAP] Consensus Call on Continuation Request Fabien Imbault
- Re: [GNAP] Consensus Call on Continuation Request Justin Richer
- Re: [GNAP] Consensus Call on Continuation Request Aaron Parecki
- Re: [GNAP] Consensus Call on Continuation Request Mike Varley