Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
Justin Richer <jricher@mitre.org> Thu, 06 June 2013 17:48 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 89CF821F9A80 for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 10:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.186
X-Spam-Level:
X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=-0.188, 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 oj24vmS2g8ON for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 10:48:00 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 847D821F9A79 for <oauth@ietf.org>; Thu, 6 Jun 2013 10:47:59 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 355541F041C; Thu, 6 Jun 2013 13:47:54 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 05C52226004A; Thu, 6 Jun 2013 13:47:54 -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:47:53 -0400
Message-ID: <51B0CB18.5090003@mitre.org>
Date: Thu, 06 Jun 2013 13:47:04 -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> <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> <51B0C8A0.2020306@mitre.org> <C6D96900-B0F9-4B5B-B5D4-D2470D5B9EFE@oracle.com>
In-Reply-To: <C6D96900-B0F9-4B5B-B5D4-D2470D5B9EFE@oracle.com>
Content-Type: multipart/alternative; boundary="------------050007050005000608040809"
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:48:05 -0000
Because anonymous *registration* and public client *access* to the token endpoint are two different things. -- Justin On 06/06/2013 01:43 PM, Phil Hunt wrote: > *why* will the 6749 standard flows (specifically 4.4) not work? > > The registration endpoint can allow anonymous access to permit > anonymous registration. > > This means the configuration endpoints can use normal access tokens > obtained through RFC6749 section 4.4 (Client Auth) flows. > > Phil > > @independentid > www.independentid.com <http://www.independentid.com> > phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> > > > > > > On 2013-06-06, at 10:36 AM, Justin Richer wrote: > >> ... 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