Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
Justin Richer <jricher@mitre.org> Thu, 06 June 2013 17:37 UTC
Return-Path: <jricher@mitre.org>
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 0F0D421F9A15 for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 10:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.198
X-Spam-Level:
X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
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 5ynbsujfy8B2 for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 10:37:22 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3F14121F9A11 for <oauth@ietf.org>; Thu, 6 Jun 2013 10:37:22 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D93611F062C; Thu, 6 Jun 2013 13:37:21 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B0FE51F041C; Thu, 6 Jun 2013 13:37:21 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 13:37:21 -0400
Message-ID: <51B0C8A0.2020306@mitre.org>
Date: Thu, 06 Jun 2013 13:36:32 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt <phil.hunt@oracle.com>
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.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> <CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA@mail.gmail.com> <51B0BDA2.7010705@mitre.org> <7B00614C-6B25-4951-B004-C17932432D17@oracle.com> <51B0C6D4.804000! 9@mitre.org> <F4DE1CDB-20F3-4106-8875-A88B3FB78712@oracle.com>
In-Reply-To: <F4DE1CDB-20F3-4106-8875-A88B3FB78712@oracle.com>
Content-Type: multipart/alternative; boundary="------------090808010105030201060307"
X-Originating-IP: [129.83.31.56]
Cc: Donald F Coffin <donald.coffin@reminetworks.com>, "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: Thu, 06 Jun 2013 17:37:28 -0000
... because it already *is* a REST protected API. It's protected with the Registration Access Token. Which is an OAuth 2.0 Bearer token. The *only* difference is how you get the token, which has nothing to do with the REST protected API that it's protecting. -- Justin On 06/06/2013 01:35 PM, Phil Hunt wrote: > Nobody has explained why using a normal REST protected API won't work. > You keep saying that and that you won't go back. But that doesn't > explain the issue. > > Phil > > @independentid > www.independentid.com <http://www.independentid.com> > phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> > > > > > > On 2013-06-06, at 10:28 AM, Justin Richer wrote: > >> I feel we're still just going in circles with these arguments, but my >> comments are inline: >> >> On 06/06/2013 01:17 PM, Phil Hunt wrote: >>> >>> Phil >>> >>> @independentid >>> www.independentid.com <http://www.independentid.com/> >>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> >>> >>> >>> >>> >>> >>> On 2013-06-06, at 9:49 AM, Justin Richer wrote: >>> >>>> Tim, thanks for your review! Comments inline. >>>> >>>> On 06/05/2013 04:59 PM, Tim Bray wrote: >>>>> 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?) >>>> >>>> Yes, it can be vanilla Oauth2 or it can be the developer (or >>>> someone) getting a token through some other means, like browsing to >>>> a developer portal and getting a Bearer token. I've edited the >>>> example in 1.4.3 in the latest (unpublished) text so that the >>>> developer is literally doing OAuth2 to get the initial token. It's >>>> important to note that this could be any flavor of OAuth2 token, >>>> though Bearer tokens are of course the most common. >>>> >>>>> The bit about getting an access token specific to that >>>>> registration is a new flow (right?), but it seems convenient. >>>> >>>> Right, it's a new way to get a bearer token so that you can use it >>>> at the protected resource. We wanted to re-use the token endpoint >>>> for this, but couldn't come up with a reasonable way of doing so >>>> (as has been discussed on the list. >>> >>> [PH] We still greatly disagree on this. >>> >>> *Use the normal token issuing process.* One reason given was what >>> about anonymous clients? The answer is, they don't have to do >>> anything. Remember that you have defined TWO endpoints. The >>> "registration endpoint" and the "configuration endpoint". A server >>> accepting anonymous registration simply accepts anonymous access at >>> the "registration endpoint". Clients wanting to update their >>> profiles do the normal client token request flow to the token >>> endpoint to obtain a normal access token useable at the >>> "configuration endpoint". >>> >> >> [JR] But then you're opening up the client_credentials flow to >> anonymous clients, or you've got to be able to lock down >> client_credentials as a flow to only a special (service-specific) >> scope for client configuration purposes. This, I think, is much more >> complicated to implement and much more error prone. I don't think >> it's even possible in the software stack we're building on top of. >> And furthermore, you're not letting public clients dynamically >> register anymore, since you'd be forcing everyone to have a client >> secret. Your dynamic public clients would have to save the client >> secret but know to only use it at the registration endpoint, and not >> the token endpoint where they're used to. This way, it's clear. You >> get a token that you use at a given endpoint, the end. >> >>> As soon as you do this, other things simplify. >>> >>> 1. No need to keep "registration access token" around indefinitely. >>> It's just an access token. In fact it is only needed for minutes >>> since it will likely only be used to read or update profiles or to >>> perform client initiated credential rotation. >> >> [JR] You *can* throw away your registration access tokens if you want >> to, or have them expire, if you want to limit the lifespan of your >> clients. It's only the security considerations section that suggests >> against expiring the tokens, and for good reason. But it's your >> choice to change that if you don't want longstanding read/edit access >> to a client's configuration. >> >>> 2. No need to have a special token issuing method. Creating a new >>> issuing process suggests that the WG can't drink its own koolaid. >>> Because at the first seeming challenge, the WG create a new flow. >>> How do we expect implementers to behave? >> >> [JR] That particular koolaid wasn't the right drink here, to stretch >> your analogy. Bearer tokens were, which is also the group's koolaid. >> We tried to go down the road you suggest and it was a dead end. Why >> do you think it will work better this time? And I'd like to point out >> a decision from several years ago now to separate the notion of "how >> you get a token" from "how you use a token" in OAuth2. OAuth1 had all >> of these rolled in together, and deployment experience showed us that >> people didn't really want to use it that way. People want components >> that make sense on their own that let you build systems like this >> that also make sense. >> >> Forced uniformity isn't necessarily a good thing. >> >>> 3. The registration/configuration API is JUST a normal OAuth2 >>> protected API. >> >> [JR] It already is. Protected resources don't care where you get your >> tokens from, just that you have them, so from that perspective it is >> just a protected resource. Our implementation here literally just >> looks for the token on the way in in the auth layer and makes sure >> it's got a special service-specific scope that handles registration. >> >>> >>> If the draft drops "registration access tokens", a lot of the text >>> in the draft disappears. The whole spec is much simpler. >> >> [JR] Much simpler, perhaps, but much less functional and useful. And >> honestly, not much of the text actually goes away. Most of the draft >> isn't about dealing with the registration access token, it's about >> dealing with the client metadata and the RESTful protocol for >> managing that. The registration access token is a mechanism for doing so. >> >>> >>>> >>>>> 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. >>>> >>>> Right, and I've admitted that "Initial Access Token" a crappy name, >>>> but I haven't heard a better suggestion yet. >>>> >>>>> >>>>> 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. >>>> >>>> Could be -- but if Google wants to be an open-registration identity >>>> provider (like it has been with OpenID 2.0), it will need to handle >>>> this flow as well. This is the client acting on its own behalf, >>>> showing up and saying "hi, I'm a client!" and that's that. I think >>>> this is a very important case for interoperability of dynamic >>>> registration. >>>> >>>>> >>>>> 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. >>>>> >>>> >>>> 1.4.3 in -11 is too close to 1.4.2, so what I've done in the >>>> current working text is make the initial process of getting the >>>> Initial Access Token different (the developer now uses OAuth2 to >>>> configure their build environment). The *real* important difference >>>> that's being shown here, though, is that the client doesn't call >>>> the registration endpoint, the developer (and their build >>>> environment) does. So yes, it's exactly all about how you get and >>>> use the registration access token. There are plenty of other ways >>>> to do it as well, so that's why this section was a non-normative >>>> set of examples. To facilitate that understanding, I've moved it to >>>> an appendix in the working copy of draft -12. >>>> >>>> Thanks, >>>> -- Justin >>>> >>>>> -T >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin >>>>> <donald.coffin@reminetworks.com >>>>> <mailto: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 <tel:%28949%29%20636-8571> >>>>> >>>>> Email: donald.coffin@reminetworks.com >>>>> <mailto:donald.coffin@reminetworks.com> >>>>> >>>>> >>>>> *From:*Justin Richer [mailto:jricher@mitre.org >>>>> <mailto:jricher@mitre.org>] >>>>> *Sent:* Friday, May 31, 2013 12:40 PM >>>>> *To:* Phil Hunt >>>>> *Cc:* Donald F Coffin; oauth@ietf.org <mailto: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 >>>>> <mailto: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 <tel:%28949%29%20636-8571> >>>>> >>>>> Email: donald.coffin@reminetworks.com >>>>> <mailto:donald.coffin@reminetworks.com> >>>>> >>>>> >>>>> *From:*Phil Hunt [mailto:phil.hunt@oracle.com] >>>>> *Sent:* Friday, May 31, 2013 11:11 AM >>>>> *To:* Justin Richer >>>>> *Cc:* oauth@ietf.org <mailto: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 <mailto: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 <mailto: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 >>>>> <mailto: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 >>>>> <mailto: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 >>>>> <mailto: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 >>>>> <mailto: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 >>>>> <mailto:phil.hunt@oracle.com>] >>>>> *Sent:* >>>>> Thursday, >>>>> May 30, >>>>> 2013 7:31 PM >>>>> *To:* >>>>> Richer, >>>>> Justin P. >>>>> *Cc:* John >>>>> Bradley; >>>>> oauth@ietf.org >>>>> <mailto: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 >>>>> <mailto:jricher@mitre.org>> >>>>> wrote: >>>>> >>>>> Comments >>>>> inline, marked >>>>> by [JR]. >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> *From:*Phil >>>>> Hunt >>>>> [phil.hunt@oracle.com >>>>> <mailto:phil.hunt@oracle.com>] >>>>> *Sent:* Thursday, >>>>> May >>>>> 30, >>>>> 2013 >>>>> 5:25 PM >>>>> *To:* >>>>> Richer, Justin >>>>> P. >>>>> *Cc:* >>>>> John >>>>> Bradley; >>>>> oauth@ietf.org >>>>> <mailto: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 >>>>> <http://www.independentid.com/> >>>>> >>>>> phil.hunt@oracle.com >>>>> <mailto: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 <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>> >> >
- [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-1… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-r… Richer, Justin P.
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-r… Phil Hunt
- [OAUTH-WG] review comments on draft-ietf-oauth-dy… Torsten Lodderstedt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Torsten Lodderstedt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Richer, Justin P.
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… John Bradley
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… George Fletcher
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… John Bradley
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… John Bradley
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Richer, Justin P.
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Richer, Justin P.
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Donald F Coffin
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Donald F Coffin
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Tim Bray
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Manger, James H
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Tim Bray
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Manger, James H
- [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer to… Manger, James H
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Tim Bray
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Manger, James H
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Justin Richer
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Justin Richer
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Phil Hunt
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Phil Hunt
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Justin Richer
- Re: [OAUTH-WG] review comments on draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Phil Hunt
- Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and beare… Justin Richer