Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Tim Bray <twbray@google.com> Wed, 05 June 2013 21:00 UTC

Return-Path: <twbray@google.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD39721F8E12 for <oauth@ietfa.amsl.com>; Wed, 5 Jun 2013 14:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaSra4aFJ5PM for <oauth@ietfa.amsl.com>; Wed, 5 Jun 2013 14:00:13 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4C71A21F8E8C for <oauth@ietf.org>; Wed, 5 Jun 2013 14:00:12 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id ar20so2362249iec.7 for <oauth@ietf.org>; Wed, 05 Jun 2013 14:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/zJYCmehR2J4LCNjvqITBv4Rsxu540eELPe6sDTgE+8=; b=SUeGKWzJKMoRXXPn3a5KINE6Gfd5HMqvbTtzIqyF5gY0HDEs17v/SWCV65w53JX8dw QV8pSqJIqphusVFmjfI3LF/CZd/AgchG+m1/YfTnHdUBC9fQ8Zdiv4tNHG0nLuVCu5zR yyK5YxdphIxosFpC8NQlxoAOV+ZcHbiAtchK5Gt1M0GMvjk1g3kKAZz/F19ffFni3BDf D0+FkVXstHaIXlavVhunc4I3PIxanzXbb64gVnPe+dqVOBlYjrBDuosr96p8RDmcviEF D7d5Kp6meGWbmyVMEpcpTthg9paC/JaFPsZCXsm3snXicFWIaduvsxMYahq2skknSOUE PCdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=/zJYCmehR2J4LCNjvqITBv4Rsxu540eELPe6sDTgE+8=; b=oPvpICs/0uNNZnSPdjSyOm8tB2u4XaOdtWIGNhJjRCFfd5l9xvqAlt4bHp6a9nXFuk dK7I1sv9ebdBgcqTjwGFV4YWwvm3xFy6SNMxkyT9/8TMbqLTWTYUKI1Qv3ve8SoqeJ0J zgJN70mXtSoqSUVX177OEBvLeyfNgxYfURInxQfHUETYX3Vw24/qop5y2LkTCDesMiew dXxNnk5sDZDuHGjMM3hVEkxFiPr8XHuHYmYU6jeNGGUA7fSxVWX88bhSqxTCLUkbjZ8U lJuHnjIpY7aUDOiMEKOiF5PpRc7uQFvp5VG8BtDQqGlf8lNnIYNNAJJSdYlk3RuVmBxQ 9v1g==
X-Received: by 10.50.40.34 with SMTP id u2mr4121086igk.16.1370466012448; Wed, 05 Jun 2013 14:00:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.23.103 with HTTP; Wed, 5 Jun 2013 13:59:42 -0700 (PDT)
In-Reply-To: <004401ce5e3a$01854b70$048fe250$@reminetworks.com>
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> <B33BFB58CCC8BE4998958016839DE27E08F97708@IMCMBX01.MITRE.ORG> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <F293690C-1E82-4350-80D4-2E2C0EF86E55@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <F319CA95-B5A8-4BD5-A8BA-F57BCBA6806B@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com>
From: Tim Bray <twbray@google.com>
Date: Wed, 05 Jun 2013 13:59:42 -0700
Message-ID: <CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA@mail.gmail.com>
To: Donald F Coffin <donald.coffin@reminetworks.com>
Content-Type: multipart/alternative; boundary="089e0122f84cd9b72904de6e7bec"
X-Gm-Message-State: ALoCoQlIqrPviDtaE+vn7r1Vgto5EbkceIe3gpD7bg1la97ebWCoX3UCi3Ew3uUgqw9LeC9fYBnVvrmsO4e5T/wMjyALCT+Wa7o1GGjrsGAKtTy6EtjyMzJsQCWVWSQQgEQ7ci9UecZKMNgNikSKDBt7Wr/scThSgHK3bDsOdSDKhk+V+HQ28HTmtCJy4/y9pZvqI4LCrmKr
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 21:00:16 -0000

FWIW, I just read the spec through with fresh eyes, and I found the
explanation of the workflow in 1.4.2 very useful.

- A developer manually registers and then is able to request “Initial
tokens” tokens for a dynamic-app-registration-scope,
- you use that “Initial token” token to register, in exchange you get the
client-id & so on, and also a a per-registration “Registration token” for
updating that particular registration information
- you fetch/update/delete your registration information with that
registration token.

The first part, where the developer registers & gets a token for a scope,
is vanilla OAuth 2. (right?)  The bit about getting an access token
specific to that registration is a new flow (right?), but it seems
convenient.   From an OAuth 2 point of view, there's nothing special about
how you get or use the Initial token, but giving it a special name makes
explaining a plausible workflow easier.

Having said that, I have trouble imagining the scenario where you'd use the
1.4.1 flow, but that may be because of my Google-centric worldview.

And I’m not sure 1.4.3 adds any value at all.  It just seems to be a matter
of different ways you could get and make use of the registration access
token; and I'm sure there are various interesting combinations that haven't
been thought of there.  I'd just lose 1.4.3.

 -T






On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin <
donald.coffin@reminetworks.com> wrote:

> See my comments inline [DFC]****
>
> ** **
>
> Best regards,****
>
> Don****
>
> Donald F. Coffin****
>
> Founder/CTO****
>
> ** **
>
> REMI Networks****
>
> 22751 El Prado Suite 6216****
>
> Rancho Santa Margarita, CA  92688-3836****
>
> ** **
>
> Phone:      (949) 636-8571****
>
> Email:       donald.coffin@reminetworks.com****
>
> ** **
>
> *From:* Justin Richer [mailto:jricher@mitre.org]
> *Sent:* Friday, May 31, 2013 12:40 PM
> *To:* Phil Hunt
> *Cc:* Donald F Coffin; oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] review comments on
> draft-ietf-oauth-dyn-reg-11.txt****
>
> ** **
>
> I feel the need to clarify a couple erroneous things in Phil's statement:
>
>
>   * To be clear, Draft 11 has the same Registration Access Token system
> that has been in place since draft 01, it is not inventing something new at
> the last minute as could be inferred from the statement below.****
>
> [DFC]  I agree with Justin.  There is nothing new in draft 11 regarding
> Registration Access Tokens that wasn’t in the initial draft.  It appears
> because Phil hasn’t been following the proposed drafts until the last call
> he is now raising an issue no one in the WG saw as an issue.  That’s not to
> say his point isn’t valid, but the discussion continues to go all over the
> map between “local” and “federated” tokens, usage of the RFC6749 “Token”
> endpoint, etc.  It would be great if all of Phil’s points could be
> addressed in priority
> without the threads becoming so convoluted no one is able to make sense or
> even comprehend the point being discussed.****
>
>
>   * DynReg is using an absolutely standard OAuth 2 Bearer token as the
> Registration Access Token, it's just not coming from a Token Endpoint.
> However, since an OAuth Protected Resource doesn't care where its tokens
> come from so long as it can validate them, I don't see this as a problem --
> this is a key point where Phil and I disagree.****
>
> [DFC]  I understand the disagreement, but I have not seen a proposal from
> Phil that would describe the differences between the two perspectives other
> than to say that the Dynamic Registration should use the Token endpoint
> defined in RFC6749, which does not    discuss dynamic registration.  Phil’s
> point as I understand it is that there should be no difference between an
> access token used to access resource owner protected data and the
> registration structure, which I do not agree with.  As I said in the
> previous
>             response, my users do NOT want to provide implied access to
> resource owner protected data just because a client is creating a
> registration with an AS.  This would be the situation if the client
> credential flow is used to register an application.  Since our
>             implementation does NOT support the implicit flow, that use
> case is one we have elected NOT to support.****
>
>             [DFC]  I repeat my initial comment, this conversation has been
> a circular exchange now for the past few days without any appearance of an
> alternative option to resolve the issues.****
>
>
>  -- Justin****
>
> On 05/31/2013 03:33 PM, Phil Hunt wrote:****
>
> Don,****
>
> ** **
>
> I am not proposing any change in meaning. If registration acces token
> issues by normal token server with scope registration everything is clear
> as it is for any other protected API. Draft 11 invents a whole new system.
> I strongly disagree with this.
>
> Phil****
>
>
> On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@reminetworks.com>
> wrote:****
>
> For something that was agreed to be parked a few hours ago, there sure
> seems to still be a lot of circular discussion.  Should we ask a mediator
> to intervene?****
>
>  ****
>
> FWIW I believe that is a significantly strong reason to differentiate an
> access token that can access the registration information without having
> the ability to access protected data.  Especially given the implied
> strength of the “client credential” obtained access token.  I have found it
> extremely confusing to users when explaining the difference between an
> access token obtained thorough an authorization code flow and a client
> credential flow, simply because they are both called an “access token”.
> Changing the meaning of an access token obtained through the client
> credential flow to mean it has the ability to update a registration, when a
> user may not want it to have access to protected data will only increase
> both the complexity of the access tokens as well as make their usage harder
> to explain to non-technical individuals who have to understand the
> differences between the access tokens obtained through the various flows.*
> ***
>
>  ****
>
> Just my two cents.****
>
>  ****
>
> Best regards,****
>
> Don****
>
> Donald F. Coffin****
>
> Founder/CTO****
>
>  ****
>
> REMI Networks****
>
> 22751 El Prado Suite 6216****
>
> Rancho Santa Margarita, CA  92688-3836****
>
>  ****
>
> Phone:      (949) 636-8571****
>
> Email:       donald.coffin@reminetworks.com****
>
>  ****
>
> *From:* Phil Hunt [mailto:phil.hunt@oracle.com <phil.hunt@oracle.com>]
> *Sent:* Friday, May 31, 2013 11:11 AM
> *To:* Justin Richer
> *Cc:* oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] review comments on
> draft-ietf-oauth-dyn-reg-11.txt****
>
>  ****
>
> To be clear. ****
>
>  ****
>
> It is two separate issues. ****
>
>  ****
>
> 1. Anonymous clients can easily be handled through policy config. ****
>
>  ****
>
> 2. Support for implicit clients needs to be discussed. The current
> proposal creates large negative value for the service provider and most
> would never allow in current form. Yes it gives each execution instance a
> new id, but that isnt what sp's want. It is a huge attack and management
> headache. Eliminate or propose a different solution.
>
> Phil****
>
>
> On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:****
>
> I'm not willing to write out an entire class of clients from this spec,
> especially when we have stated use cases for them doing dynamic
> registration.
>
> I'm sorry, but your proposed solution will simply not work.
>
>  -- Justin****
>
> On 05/31/2013 01:56 PM, Phil Hunt wrote:****
>
> Well the only client that wouldn't have a credential is an implicit
> client. An implicit client is transient and so would never update.
>
> Besides, as i have stated, implicit clients should not use dyn reg. ****
>
>
> Phil****
>
>
> On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org> wrote:****
>
> But the outstanding question is: how do you get the access token to access
> the created resource (IE: the Registration Access Token)? You can't use the
> client_credentials flow for a client with no credentials!
>
>  -- Justin
>
>
> ****
>
> On 05/31/2013 12:58 PM, Phil Hunt wrote:****
>
> Yes. I specified the trivial solution to anonymous clients earlier.****
>
>  ****
>
> Even simpler. You don't need an access token to create a new resource. You
> just need one to access one. That is just basic security config. ****
>
>
> Phil****
>
>
> On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org> wrote:****
>
> I agree that we are going in circles, since I just was going to bring up
> my counter argument of "what about clients with no credentials?" again,
> which *still* isn't addressed by what you suggest doing, below. I also
> believe that getting rid of the Registration Access Token but using some
> other token method would actually make the spec larger, though I'd be glad
> to review a concrete counter-proposal if you'd like to write one. And the
> fact that OIDC is doing it this way, and considered but rejected the way
> that you're describing, should say something to the WG here about whether
> or not this is the right choice. Rough consensus and running code, after
> all.
>
> Regardless, I agree to park this issue and leave the text as is. We'll
> move to the next draft in the last call process shortly, as I have a
> handful of non-normative editorial changes that I need to make, thanks to
> feedback from a few folks.
>
> Again, thanks for your thorough review, Phil, and I look forward to future
> feedback.
>
>  -- Justin****
>
> On 05/31/2013 12:28 PM, Phil Hunt wrote:****
>
> I disagree. ****
>
>  ****
>
> There is absolutely no need for a registration access token. ****
>
>  ****
>
> Get rid of it and just use access tokens as per 6749. If you can't follow
> 6749 and need new issuing methods, what are others to say regarding
> inventing new methods?****
>
>  ****
>
> I have not heard a good reason for the special process or one good enough
> to warrant a new method for issuing an access token. Does the broader group
> realize this is what the spec says?****
>
>  ****
>
> Yes, i heard a lot saying OIDC does it this way. But that is a political
> reason, not a technical reason. Still, compatibility is always a strong
> objective.  Even so, oidc could keep using their method just fine. There is
> no obligation here to do the same. ****
>
>  ****
>
> The only reason so far was expiry of client creds. Well, why not require
> the client to update prior to expiry? It makes no sense to have another
> token with longer expiry. B'sides, even expired the client can re-register
> from scratch. ****
>
>  ****
>
> Why force the client to persist multiple tokens and creds? That is far far
> too complex. ****
>
>  ****
>
> Finally if you get rid of registration access token the spec size will
> drop roughly in half IMO. This suggests simplicity to me. ****
>
>  ****
>
> Apologies for my rant. Maybe we should park this for now. We are going in
> circles.
>
> Phil****
>
>
> On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org> wrote:****
>
> Phil,
>
> We *can* keep it straight just fine, but I just need you to be clear about
> which part you're objecting to because the answers are different. Please
> use the terms as defined in the document so that we all know which
> component we're talking about. I'm sure you'd agree than in specification
> work such as this, precision of language and labels is key for
> communication between parties. This is precisely why there's a Terminology
> section right up front, so that when I say "Registration Access Token" you
> can know that I mean a very specific thing, and when I say "Initial
> Registration Token" I mean a very different specific thing. So I'm asking
> you, please, use the defined terms so that we can avoid this unnecessary
> confusion.
>
> But anyway, what you're talking about below, "the token the client uses to
> update is profile" *IS* the Registration Access Token. That's all that that
> token is used for. You're not asking for it to go away, you're asking for
> it to come from the Token Endpoint instead of the response from the
> Registration Endpoint. I don't see how the client *can* get it from the
> normal token process without jumping through specialized hoops to make that
> happen. I've implemented the draft the way that it is right now, both
> client and server side, and it works. Others have implemented it, too.
> We've done interop testing, and it works. This is a proven pattern and from
> where I sit there is both rough consensus and running code.
>
> I believe that I've already pointed out how the solutions you've proposed
> so far won't work in practice, for various reasons, many of which have
> already been brought up and discussed previously. If you have another way
> for the client to get its Registration Access Token, please propose it; but
> I haven't seen anything yet that will fly.
>
>  -- Justin****
>
> On 05/31/2013 11:10 AM, Phil Hunt wrote:****
>
> Justin,****
>
>  ****
>
> This is my primary objection! We can't keep it straight. Their should be
> no such thing as a registrstion access token!  Just the token the client
> obtains to update its profile through the normal token request process.
>
> Phil****
>
>
> On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:****
>
> Which token are you referring to here?
>
> If it's the Initial Registration Token, then you could get that through
> the normal token server no problem. (The lifecycle writeups don't call this
> out explicitly but I would be willing to do so.) Or you could get it
> elsewhere. Doesn't matter, just like it doesn't matter with any other
> OAuth2 protected resource.
>
> If it's the Registration Access Token, then having the token come from the
> token endpoint would require a lot more work and complexity on behalf of
> both of the client and server. Either you end up with public clients
> getting secrets they shouldn't need or with granting clients access to the
> client_credentials flow when they shouldn't actually have it. Plus it adds
> extra round trips which don't buy you anything.
>
>  -- Justin****
>
> On 05/31/2013 10:15 AM, Phil Hunt wrote:****
>
> The preference is to have the access token for registration issued by the
> normal token server rather then by the registration endpoint. ****
>
>  ****
>
> In the current draft it is obtained through a unique process and must
> outlive the client. ****
>
>
> Phil****
>
>
> On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org> wrote:***
> *
>
> I don't understand any of the comments below -- it already *is* an OAuth2
> protected resource without any special handling. Your access tokens can be
> short-lived, long-lived, federated, structured, random blobs ... totally
> doesn't matter. They are access tokens being used to access a normal
> protected resource. Full stop.
>
> Anything else is out of scope. The lifecycle discussions at the beginning
> are merely examples of some ways you *could* use it and are non-normative
> and non-exhaustive.
>
> You seem to be asking for something that's already in the draft.
>
>  -- Justin****
> ------------------------------
>
> *From:* Phil Hunt [phil.hunt@oracle.com]
> *Sent:* Thursday, May 30, 2013 7:31 PM
> *To:* Richer, Justin P.
> *Cc:* John Bradley; oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] review comments on
> draft-ietf-oauth-dyn-reg-11.txt****
>
>
>
> Phil****
>
>
> On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:***
> *
>
> Comments inline, marked by [JR].****
> ------------------------------
>
> *From:* Phil Hunt [phil.hunt@oracle.com]
> *Sent:* Thursday, May 30, 2013 5:25 PM
> *To:* Richer, Justin P.
> *Cc:* John Bradley; oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] review comments on
> draft-ietf-oauth-dyn-reg-11.txt****
>
> See below.****
>
> Phil****
>
>  ****
>
> @independentid****
>
> www.independentid.com****
>
> phil.hunt@oracle.com****
>
>  ****
>
>  ****
>
>  ****
>
> On 2013-05-30, at 2:09 PM, Justin Richer wrote:****
>
>
>
>
> ****
>
> OK, I think see part of the hang up. I have not seen the scenario that you
> describe, where you trade a 3rd party token for a "local" token. I have
> seen where access tokens are federated directly at the PR. (Introspection
> lets you do some good things with that pattern.) ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>