Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
Justin Richer <jricher@mitre.org> Thu, 06 June 2013 17:57 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 5298521F8470 for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 10:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
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 nhvsxtPQfXtF for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 10:57:05 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 47A1D21F84A1 for <oauth@ietf.org>; Thu, 6 Jun 2013 10:57:04 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E38E11F0625; Thu, 6 Jun 2013 13:57:03 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C44A42260059; Thu, 6 Jun 2013 13:57:03 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 13:57:02 -0400
Message-ID: <51B0CD3D.8070907@mitre.org>
Date: Thu, 06 Jun 2013 13:56:13 -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> <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> <51B0CB18.50! 90003@mitre.org> <FCAFE2AE-BDAD-4576-BF9C-E6AD01AFAF2B@oracl! e .com> <51B0CBC5.5090509@mitre.org> <0314A5D5-A6B1-4D05-B348-AC17AA30F61B@oracle.com>
In-Reply-To: <0314A5D5-A6B1-4D05-B348-AC17AA30F61B@oracle.com>
Content-Type: multipart/alternative; boundary="------------090707000100020606000304"
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:57:05 -0000
Before they register, they're neither public nor private. After they register, they're either public or private depending on if they want to/can use a client secret or equivalent to talk to the token endpoint. Also, having a client register and allowing it to get a token through the client_credentials flow (without a user in the loop) is potentially dangerous unless things are very carefully scope-limited anyway. -- Justin On 06/06/2013 01:51 PM, Phil Hunt wrote: > When they are issued their client credential after successfully > registering….isn't that the whole point of the process? > > Once they register, they are no longer public. After that, they just > get a token like everyone else. > > Phil > > @independentid > www.independentid.com <http://www.independentid.com> > phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> > > > > > > On 2013-06-06, at 10:49 AM, Justin Richer wrote: > >> Then how do they get their equivalent of a registration access token >> to manage their configurations? >> >> The draft proposes that they get this token right from the >> registration endpoint. You're proposing that they get this from the >> token endpoint. >> >> The initial access token isn't even in play here. >> >> -- Justin >> >> On 06/06/2013 01:49 PM, Phil Hunt wrote: >>> Huh? >>> >>> There's no need for public clients to access the token endpoint as >>> they can register anonymously. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com <http://www.independentid.com/> >>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> >>> >>> >>> >>> >>> >>> On 2013-06-06, at 10:47 AM, Justin Richer wrote: >>> >>>> 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