Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
Tim Bray <twbray@google.com> Wed, 05 June 2013 21:00 UTC
Return-Path: <twbray@google.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD39721F8E12 for <oauth@ietfa.amsl.com>; Wed, 5 Jun 2013 14:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaSra4aFJ5PM for <oauth@ietfa.amsl.com>; Wed, 5 Jun 2013 14:00:13 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4C71A21F8E8C for <oauth@ietf.org>; Wed, 5 Jun 2013 14:00:12 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id ar20so2362249iec.7 for <oauth@ietf.org>; Wed, 05 Jun 2013 14:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/zJYCmehR2J4LCNjvqITBv4Rsxu540eELPe6sDTgE+8=; b=SUeGKWzJKMoRXXPn3a5KINE6Gfd5HMqvbTtzIqyF5gY0HDEs17v/SWCV65w53JX8dw QV8pSqJIqphusVFmjfI3LF/CZd/AgchG+m1/YfTnHdUBC9fQ8Zdiv4tNHG0nLuVCu5zR yyK5YxdphIxosFpC8NQlxoAOV+ZcHbiAtchK5Gt1M0GMvjk1g3kKAZz/F19ffFni3BDf D0+FkVXstHaIXlavVhunc4I3PIxanzXbb64gVnPe+dqVOBlYjrBDuosr96p8RDmcviEF D7d5Kp6meGWbmyVMEpcpTthg9paC/JaFPsZCXsm3snXicFWIaduvsxMYahq2skknSOUE PCdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=/zJYCmehR2J4LCNjvqITBv4Rsxu540eELPe6sDTgE+8=; b=oPvpICs/0uNNZnSPdjSyOm8tB2u4XaOdtWIGNhJjRCFfd5l9xvqAlt4bHp6a9nXFuk dK7I1sv9ebdBgcqTjwGFV4YWwvm3xFy6SNMxkyT9/8TMbqLTWTYUKI1Qv3ve8SoqeJ0J zgJN70mXtSoqSUVX177OEBvLeyfNgxYfURInxQfHUETYX3Vw24/qop5y2LkTCDesMiew dXxNnk5sDZDuHGjMM3hVEkxFiPr8XHuHYmYU6jeNGGUA7fSxVWX88bhSqxTCLUkbjZ8U lJuHnjIpY7aUDOiMEKOiF5PpRc7uQFvp5VG8BtDQqGlf8lNnIYNNAJJSdYlk3RuVmBxQ 9v1g==
X-Received: by 10.50.40.34 with SMTP id u2mr4121086igk.16.1370466012448; Wed, 05 Jun 2013 14:00:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.23.103 with HTTP; Wed, 5 Jun 2013 13:59:42 -0700 (PDT)
In-Reply-To: <004401ce5e3a$01854b70$048fe250$@reminetworks.com>
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> <B33BFB58CCC8BE4998958016839DE27E08F97708@IMCMBX01.MITRE.ORG> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <F293690C-1E82-4350-80D4-2E2C0EF86E55@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <F319CA95-B5A8-4BD5-A8BA-F57BCBA6806B@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com>
From: Tim Bray <twbray@google.com>
Date: Wed, 05 Jun 2013 13:59:42 -0700
Message-ID: <CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA@mail.gmail.com>
To: Donald F Coffin <donald.coffin@reminetworks.com>
Content-Type: multipart/alternative; boundary="089e0122f84cd9b72904de6e7bec"
X-Gm-Message-State: ALoCoQlIqrPviDtaE+vn7r1Vgto5EbkceIe3gpD7bg1la97ebWCoX3UCi3Ew3uUgqw9LeC9fYBnVvrmsO4e5T/wMjyALCT+Wa7o1GGjrsGAKtTy6EtjyMzJsQCWVWSQQgEQ7ci9UecZKMNgNikSKDBt7Wr/scThSgHK3bDsOdSDKhk+V+HQ28HTmtCJy4/y9pZvqI4LCrmKr
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 21:00:16 -0000
FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful. - A developer manually registers and then is able to request “Initial tokens” tokens for a dynamic-app-registration-scope, - you use that “Initial token” token to register, in exchange you get the client-id & so on, and also a a per-registration “Registration token” for updating that particular registration information - you fetch/update/delete your registration information with that registration token. The first part, where the developer registers & gets a token for a scope, is vanilla OAuth 2. (right?) The bit about getting an access token specific to that registration is a new flow (right?), but it seems convenient. From an OAuth 2 point of view, there's nothing special about how you get or use the Initial token, but giving it a special name makes explaining a plausible workflow easier. Having said that, I have trouble imagining the scenario where you'd use the 1.4.1 flow, but that may be because of my Google-centric worldview. And I’m not sure 1.4.3 adds any value at all. It just seems to be a matter of different ways you could get and make use of the registration access token; and I'm sure there are various interesting combinations that haven't been thought of there. I'd just lose 1.4.3. -T On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin < donald.coffin@reminetworks.com> wrote: > See my comments inline [DFC]**** > > ** ** > > Best regards,**** > > Don**** > > Donald F. Coffin**** > > Founder/CTO**** > > ** ** > > REMI Networks**** > > 22751 El Prado Suite 6216**** > > Rancho Santa Margarita, CA 92688-3836**** > > ** ** > > Phone: (949) 636-8571**** > > Email: donald.coffin@reminetworks.com**** > > ** ** > > *From:* Justin Richer [mailto:jricher@mitre.org] > *Sent:* Friday, May 31, 2013 12:40 PM > *To:* Phil Hunt > *Cc:* Donald F Coffin; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] review comments on > draft-ietf-oauth-dyn-reg-11.txt**** > > ** ** > > I feel the need to clarify a couple erroneous things in Phil's statement: > > > * To be clear, Draft 11 has the same Registration Access Token system > that has been in place since draft 01, it is not inventing something new at > the last minute as could be inferred from the statement below.**** > > [DFC] I agree with Justin. There is nothing new in draft 11 regarding > Registration Access Tokens that wasn’t in the initial draft. It appears > because Phil hasn’t been following the proposed drafts until the last call > he is now raising an issue no one in the WG saw as an issue. That’s not to > say his point isn’t valid, but the discussion continues to go all over the > map between “local” and “federated” tokens, usage of the RFC6749 “Token” > endpoint, etc. It would be great if all of Phil’s points could be > addressed in priority > without the threads becoming so convoluted no one is able to make sense or > even comprehend the point being discussed.**** > > > * DynReg is using an absolutely standard OAuth 2 Bearer token as the > Registration Access Token, it's just not coming from a Token Endpoint. > However, since an OAuth Protected Resource doesn't care where its tokens > come from so long as it can validate them, I don't see this as a problem -- > this is a key point where Phil and I disagree.**** > > [DFC] I understand the disagreement, but I have not seen a proposal from > Phil that would describe the differences between the two perspectives other > than to say that the Dynamic Registration should use the Token endpoint > defined in RFC6749, which does not discuss dynamic registration. Phil’s > point as I understand it is that there should be no difference between an > access token used to access resource owner protected data and the > registration structure, which I do not agree with. As I said in the > previous > response, my users do NOT want to provide implied access to > resource owner protected data just because a client is creating a > registration with an AS. This would be the situation if the client > credential flow is used to register an application. Since our > implementation does NOT support the implicit flow, that use > case is one we have elected NOT to support.**** > > [DFC] I repeat my initial comment, this conversation has been > a circular exchange now for the past few days without any appearance of an > alternative option to resolve the issues.**** > > > -- Justin**** > > On 05/31/2013 03:33 PM, Phil Hunt wrote:**** > > Don,**** > > ** ** > > I am not proposing any change in meaning. If registration acces token > issues by normal token server with scope registration everything is clear > as it is for any other protected API. Draft 11 invents a whole new system. > I strongly disagree with this. > > Phil**** > > > On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@reminetworks.com> > wrote:**** > > For something that was agreed to be parked a few hours ago, there sure > seems to still be a lot of circular discussion. Should we ask a mediator > to intervene?**** > > **** > > FWIW I believe that is a significantly strong reason to differentiate an > access token that can access the registration information without having > the ability to access protected data. Especially given the implied > strength of the “client credential” obtained access token. I have found it > extremely confusing to users when explaining the difference between an > access token obtained thorough an authorization code flow and a client > credential flow, simply because they are both called an “access token”. > Changing the meaning of an access token obtained through the client > credential flow to mean it has the ability to update a registration, when a > user may not want it to have access to protected data will only increase > both the complexity of the access tokens as well as make their usage harder > to explain to non-technical individuals who have to understand the > differences between the access tokens obtained through the various flows.* > *** > > **** > > Just my two cents.**** > > **** > > Best regards,**** > > Don**** > > Donald F. Coffin**** > > Founder/CTO**** > > **** > > REMI Networks**** > > 22751 El Prado Suite 6216**** > > Rancho Santa Margarita, CA 92688-3836**** > > **** > > Phone: (949) 636-8571**** > > Email: donald.coffin@reminetworks.com**** > > **** > > *From:* Phil Hunt [mailto:phil.hunt@oracle.com <phil.hunt@oracle.com>] > *Sent:* Friday, May 31, 2013 11:11 AM > *To:* Justin Richer > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] review comments on > draft-ietf-oauth-dyn-reg-11.txt**** > > **** > > To be clear. **** > > **** > > It is two separate issues. **** > > **** > > 1. Anonymous clients can easily be handled through policy config. **** > > **** > > 2. Support for implicit clients needs to be discussed. The current > proposal creates large negative value for the service provider and most > would never allow in current form. Yes it gives each execution instance a > new id, but that isnt what sp's want. It is a huge attack and management > headache. Eliminate or propose a different solution. > > Phil**** > > > On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:**** > > I'm not willing to write out an entire class of clients from this spec, > especially when we have stated use cases for them doing dynamic > registration. > > I'm sorry, but your proposed solution will simply not work. > > -- Justin**** > > On 05/31/2013 01:56 PM, Phil Hunt wrote:**** > > Well the only client that wouldn't have a credential is an implicit > client. An implicit client is transient and so would never update. > > Besides, as i have stated, implicit clients should not use dyn reg. **** > > > Phil**** > > > On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org> wrote:**** > > But the outstanding question is: how do you get the access token to access > the created resource (IE: the Registration Access Token)? You can't use the > client_credentials flow for a client with no credentials! > > -- Justin > > > **** > > On 05/31/2013 12:58 PM, Phil Hunt wrote:**** > > Yes. I specified the trivial solution to anonymous clients earlier.**** > > **** > > Even simpler. You don't need an access token to create a new resource. You > just need one to access one. That is just basic security config. **** > > > Phil**** > > > On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org> wrote:**** > > I agree that we are going in circles, since I just was going to bring up > my counter argument of "what about clients with no credentials?" again, > which *still* isn't addressed by what you suggest doing, below. I also > believe that getting rid of the Registration Access Token but using some > other token method would actually make the spec larger, though I'd be glad > to review a concrete counter-proposal if you'd like to write one. And the > fact that OIDC is doing it this way, and considered but rejected the way > that you're describing, should say something to the WG here about whether > or not this is the right choice. Rough consensus and running code, after > all. > > Regardless, I agree to park this issue and leave the text as is. We'll > move to the next draft in the last call process shortly, as I have a > handful of non-normative editorial changes that I need to make, thanks to > feedback from a few folks. > > Again, thanks for your thorough review, Phil, and I look forward to future > feedback. > > -- Justin**** > > On 05/31/2013 12:28 PM, Phil Hunt wrote:**** > > I disagree. **** > > **** > > There is absolutely no need for a registration access token. **** > > **** > > Get rid of it and just use access tokens as per 6749. If you can't follow > 6749 and need new issuing methods, what are others to say regarding > inventing new methods?**** > > **** > > I have not heard a good reason for the special process or one good enough > to warrant a new method for issuing an access token. Does the broader group > realize this is what the spec says?**** > > **** > > Yes, i heard a lot saying OIDC does it this way. But that is a political > reason, not a technical reason. Still, compatibility is always a strong > objective. Even so, oidc could keep using their method just fine. There is > no obligation here to do the same. **** > > **** > > The only reason so far was expiry of client creds. Well, why not require > the client to update prior to expiry? It makes no sense to have another > token with longer expiry. B'sides, even expired the client can re-register > from scratch. **** > > **** > > Why force the client to persist multiple tokens and creds? That is far far > too complex. **** > > **** > > Finally if you get rid of registration access token the spec size will > drop roughly in half IMO. This suggests simplicity to me. **** > > **** > > Apologies for my rant. Maybe we should park this for now. We are going in > circles. > > Phil**** > > > On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org> wrote:**** > > Phil, > > We *can* keep it straight just fine, but I just need you to be clear about > which part you're objecting to because the answers are different. Please > use the terms as defined in the document so that we all know which > component we're talking about. I'm sure you'd agree than in specification > work such as this, precision of language and labels is key for > communication between parties. This is precisely why there's a Terminology > section right up front, so that when I say "Registration Access Token" you > can know that I mean a very specific thing, and when I say "Initial > Registration Token" I mean a very different specific thing. So I'm asking > you, please, use the defined terms so that we can avoid this unnecessary > confusion. > > But anyway, what you're talking about below, "the token the client uses to > update is profile" *IS* the Registration Access Token. That's all that that > token is used for. You're not asking for it to go away, you're asking for > it to come from the Token Endpoint instead of the response from the > Registration Endpoint. I don't see how the client *can* get it from the > normal token process without jumping through specialized hoops to make that > happen. I've implemented the draft the way that it is right now, both > client and server side, and it works. Others have implemented it, too. > We've done interop testing, and it works. This is a proven pattern and from > where I sit there is both rough consensus and running code. > > I believe that I've already pointed out how the solutions you've proposed > so far won't work in practice, for various reasons, many of which have > already been brought up and discussed previously. If you have another way > for the client to get its Registration Access Token, please propose it; but > I haven't seen anything yet that will fly. > > -- Justin**** > > On 05/31/2013 11:10 AM, Phil Hunt wrote:**** > > Justin,**** > > **** > > This is my primary objection! We can't keep it straight. Their should be > no such thing as a registrstion access token! Just the token the client > obtains to update its profile through the normal token request process. > > Phil**** > > > On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:**** > > Which token are you referring to here? > > If it's the Initial Registration Token, then you could get that through > the normal token server no problem. (The lifecycle writeups don't call this > out explicitly but I would be willing to do so.) Or you could get it > elsewhere. Doesn't matter, just like it doesn't matter with any other > OAuth2 protected resource. > > If it's the Registration Access Token, then having the token come from the > token endpoint would require a lot more work and complexity on behalf of > both of the client and server. Either you end up with public clients > getting secrets they shouldn't need or with granting clients access to the > client_credentials flow when they shouldn't actually have it. Plus it adds > extra round trips which don't buy you anything. > > -- Justin**** > > On 05/31/2013 10:15 AM, Phil Hunt wrote:**** > > The preference is to have the access token for registration issued by the > normal token server rather then by the registration endpoint. **** > > **** > > In the current draft it is obtained through a unique process and must > outlive the client. **** > > > Phil**** > > > On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org> wrote:*** > * > > I don't understand any of the comments below -- it already *is* an OAuth2 > protected resource without any special handling. Your access tokens can be > short-lived, long-lived, federated, structured, random blobs ... totally > doesn't matter. They are access tokens being used to access a normal > protected resource. Full stop. > > Anything else is out of scope. The lifecycle discussions at the beginning > are merely examples of some ways you *could* use it and are non-normative > and non-exhaustive. > > You seem to be asking for something that's already in the draft. > > -- Justin**** > ------------------------------ > > *From:* Phil Hunt [phil.hunt@oracle.com] > *Sent:* Thursday, May 30, 2013 7:31 PM > *To:* Richer, Justin P. > *Cc:* John Bradley; oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] review comments on > draft-ietf-oauth-dyn-reg-11.txt**** > > > > Phil**** > > > On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:*** > * > > Comments inline, marked by [JR].**** > ------------------------------ > > *From:* Phil Hunt [phil.hunt@oracle.com] > *Sent:* Thursday, May 30, 2013 5:25 PM > *To:* Richer, Justin P. > *Cc:* John Bradley; oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] review comments on > draft-ietf-oauth-dyn-reg-11.txt**** > > See below.**** > > Phil**** > > **** > > @independentid**** > > www.independentid.com**** > > phil.hunt@oracle.com**** > > **** > > **** > > **** > > On 2013-05-30, at 2:09 PM, Justin Richer wrote:**** > > > > > **** > > OK, I think see part of the hang up. I have not seen the scenario that you > describe, where you trade a 3rd party token for a "local" token. I have > seen where access tokens are federated directly at the PR. (Introspection > lets you do some good things with that pattern.) **** > > **** > > **** > > **** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
- [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