Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
Nat Sakimura <sakimura@gmail.com> Wed, 23 July 2014 18:48 UTC
Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5C81A0162 for <oauth@ietfa.amsl.com>; Wed, 23 Jul 2014 11:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlfA2pSsm5lB for <oauth@ietfa.amsl.com>; Wed, 23 Jul 2014 11:48:30 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE7E1A0193 for <oauth@ietf.org>; Wed, 23 Jul 2014 11:48:29 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id e16so1239443lan.25 for <oauth@ietf.org>; Wed, 23 Jul 2014 11:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D2wMy7hmQ8qd8cACXQtPA3su0ulOMJnNYGiG+w1emn8=; b=Y+6ZghtyV71ODXHQIABJsWl7lqh4HOzY+SpC1EeXu0dkoAnq0JOkzEAbSjErbJzTrN rtQqus3rdmp+PhIRBD/rEVbjTGk4QHn7FHW85Cl/t1UbvS7fP8O8USLc4q+cKMwH/KF4 3Qmm9goUvE5sQu8wDz9jblR0FXS2uS8bCGDjYdfwUsc5gkWV3VhkNfFf9IO+OQno6G8T 9dHkgIkK/uc1aliL11A+Uqmkzz7V78rnsBVU/8wQpMVyn8UMNgTEKkKhz6dUQKousDFz 7Tu8M+Zeu/gNBIDQS04a5W61wGq9OU9FJLQghm8Dl/h0QcDyIkjsKkOybQJiNTDPDCpT lrCg==
MIME-Version: 1.0
X-Received: by 10.112.54.197 with SMTP id l5mr3279889lbp.103.1406141307527; Wed, 23 Jul 2014 11:48:27 -0700 (PDT)
Received: by 10.112.150.233 with HTTP; Wed, 23 Jul 2014 11:48:27 -0700 (PDT)
In-Reply-To: <CAGpwqP9H-FWqezXcMegbX4P5K9sbhQXVz8tZt5-uX57Znu880Q@mail.gmail.com>
References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <CABzCy2CxNQ2d3=m9Bvc0+k6ikqZkwb940HwskvnAGvKoGnteSw@mail.gmail.com> <DE16B8D3-3590-45B3-BE08-D1A7CF9EF0FB@oracle.com> <CABzCy2B_iB1ZBskFJObKJjnftEH1STVyhx1-AE6Chrj76-se8g@mail.gmail.com> <F7F8C65F-C805-4C29-86F0-1835B7A80E3F@oracle.com> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com> <CAEayHEM4SAM_2DwF8ceC4sen++o7azZnP16xDR8EodqSkxFajA@mail.gmail.com> <04E6EF5C-F36C-4987-9BA6-AF92408EEFCE@mitre.org> <CAEayHENPDasnJ8JBgxRuZSkcWg3+=1g6gOJzodWAJtHqMmc_Ww@mail.gmail.com> <CABzCy2CWN81to7nAtxsnCjSiXFhzh+iOu-2zyg+cjfCSgQZqbQ@mail.gmail.com> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <CAGpwqP9H-FWqezXcMegbX4P5K9sbhQXVz8tZt5-uX57Znu880Q@mail.gmail.com>
Date: Wed, 23 Jul 2014 14:48:27 -0400
Message-ID: <CABzCy2B2gPHGX+aY5RkXFZ0Eyo8E7yQ6+trstji1gvKCL9SsJQ@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Takahiko Kawasaki <daru.tk@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c3e85223a93604fee0c9cc"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4MvxH91L9X1vyGFQD8E76dNbSQQ
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Jul 2014 18:48:35 -0000
Thanks Takahiko. Good analysis. 2014-07-23 14:12 GMT-04:00 Takahiko Kawasaki <daru.tk@gmail.com>: > Hello, > > (1) RFC 6749 > grant_type=authorization_code > response={"access_token":...} > > (2) OpenID Connect Core > grant_type=authorization_code > response={"access_token":..., "id_token":...} > > (3) Currently being discussed > (3)-1 > grant_type=authorization_code > response_type=id_token (a new parameter for the token endpoint) > response={"id_token":...} > > (3)-2 > grant_type=something_new (a new value for the token endpoint) > response={"id_token":...} > > (3)-3 > response_type=something_new (a new value for the authz endpoint) > grant_type=something_new > > However, taking a logical expansion below into account, > > (4) Not being discussed yet, but logically possible > grant_type=password > response={"id_token":...} > > it seems "grant_type" should be treated as a parameter to specify > just a 'flow'. IMHO, what tokens should be included in the response > from the token endpoint should be specified by another different means. > For example, "response_type" (a new parameter for the *token* endpoint) > as suggested by Nat. > > Nat> response_type > Nat> OPTIONAL. A string that expresses what tokens are to be returned > Nat> from the Token Endpoint. Extension specifications may use this > Nat> parameter to explicitly expressing the desire to obtain a > Nat> particular type of token. > > If asked, I would add the following: > > The default value of "response_type" is "token" which means that > an access token is requested. However, when the following conditions > are satisfied, the default value is "token id_token". > > Condition-1: > grant_type=authorization_code > > Condition-2: > The authorization code was issued at the authorization endpoint > with 'openid' scope. > > -- > Best Regards, > Takahiko Kawasaki > > > > 2014-07-24 2:39 GMT+09:00 Mike Jones <Michael.Jones@microsoft.com>: > > You need the alternative response_type value (“code_for_id_token” in >> the A4C draft) to tell the Authorization Server to return a code to be used >> with the new grant type, rather than one to use with the >> “authorization_code” grant type (which is what response_type=code does). >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley >> *Sent:* Wednesday, July 23, 2014 10:33 AM >> *To:* torsten@lodderstedt.net >> >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] New Version Notification for >> draft-hunt-oauth-v2-user-a4c-05.txt >> >> >> >> If we use the token endpoint then a new grant_type is the best way. >> >> >> >> It sort of overloads code, but that is better than messing with >> response_type for the authorization endpoint to change the response from >> the token_endpoint. That is in my opinion a champion bad idea. >> >> >> >> In discussions developing Connect we decided not to open this can of >> worms because no good would come of it. >> >> >> >> The token_endpoint returns a access token. Nothing requires scope to be >> associates with the token. >> >> >> >> That is the best solution. No change required. Better interoperability >> in my opinion. >> >> >> >> Still on my way to TO, getting in later today. >> >> >> >> John B. >> >> >> >> >> >> Sent from my iPhone >> >> >> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote: >> >> The "response type" of the token endpoint is controlled by the value of >> the parameter "grant_type". So there is no need to introduce a new >> parameter. >> >> wrt to a potential "no_access_token" grant type. I do not consider this a >> good idea as it changes the semantics of the token endpoint (as already >> pointed out by Thomas). This endpoint ALWAYS responds with an access token >> to any grant type. I therefore would prefer to use another endpoint for the >> intended purpose. >> >> regards, >> Torsten. >> >> >> >> Am 23.07.2014 13:04, schrieb Nat Sakimura: >> >> IMHO, changing the semantics of "response_type" @ authz endpoint this >> way is not a good thing. >> >> >> >> Instead, defining a new parameter "response_type" @ token endpoint, as I >> described in my previous message, >> >> probably is better. At least, it does not change the semantics of the >> parameters of RFC6749. >> >> >> >> Nat >> >> >> >> 2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.broyer@gmail.com>: >> >> No, I mean response_type=none and response_type=id_token don't generate a >> code or access token so you don't use the Token Endpoint (which is not the >> same as the Authentication Endpoint BTW). >> >> With response_type=code_for_id_token, you get a code and exchange it for >> an id_token only, rather than an access_token, so you're changing the >> semantics of the Token Endpoint. >> >> >> >> I'm not saying it's a bad thing, just that you can't really compare none >> and id_token with code_for_id_token. >> >> >> >> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <jricher@mitre.org> >> wrote: >> >> It's only "not using the token endpoint" because the token endpoint >> copy-pasted and renamed the authentication endpoint. >> >> >> >> -- Justin >> >> >> >> On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote: >> >> >> >> Except that these are about not using the Token Endpoint at all, >> whereas the current proposal is about the Token Endpoint not returning an >> access_token field in the JSON. >> >> >> >> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microsoft.com> >> wrote: >> >> The response_type "none" is already used in practice, which returns no >> access token. It was accepted by the designated experts and registered in >> the IANA OAuth Authorization Endpoint Response Types registry at >> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint. >> The registered "id_token" response type also returns no access token. >> >> >> >> So I think the question of whether response types that result in no >> access token being returned are acceptable within OAuth 2.0 is already >> settled, as a practical matter. Lots of OAuth implementations are already >> using such response types. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt >> *Sent:* Wednesday, July 23, 2014 7:09 AM >> *To:* Nat Sakimura >> *Cc:* <oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] New Version Notification for >> draft-hunt-oauth-v2-user-a4c-05.txt >> >> >> >> Yes. This is why it has to be discussed in the IETF. >> >> >> >> Phil >> >> >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> >> >> >> On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> wrote: >> >> >> >> Reading back the RFC6749, I am not sure if there is a good way of >> suppressing access token from the response and still be OAuth. It will >> break whole bunch of implicit definitions like: >> >> >> >> authorization server >> The server issuing access tokens to the client after successfully >> authenticating the resource owner and obtaining authorization. >> >> >> >> After all, OAuth is all about issuing access tokens. >> >> >> >> Also, I take back my statement on the grant type in my previous mail. >> >> >> >> The definition of grant and grant_type are respectively: >> >> >> >> grant >> >> credential representing the resource owner's authorization >> >> >> >> grant_type >> >> (string representing the) type of grant sent to the token endpoint to >> obtain the access token >> >> >> >> Thus, the grant sent to the token endpoint in this case is still 'code'. >> >> >> >> Response type on the other hand is not so well defined in RFC6749, but it >> seems it is representing what is to be returned from the authorization >> endpoint. To express what is to be returned from token endpoint, perhaps >> defining a new parameter to the token endpoint, which is a parallel to the >> response_type to the Authorization Endpoint seems to be a more symmetric >> way, though I am not sure at all if that is going to be OAuth any more. One >> straw-man is to define a new parameter called response_type to the token >> endpoint such as: >> >> >> >> response_type >> >> OPTIONAL. A string representing what is to be returned from the token >> endpoint. >> >> >> >> Then define the behavior of the endpoint according to the values as the >> parallel to the multi-response type spec. >> >> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >> >> >> >> Nat >> >> >> >> >> >> >> >> >> >> 2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>: >> >> The draft is very clear. >> >> Phil >> >> >> On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote: >> >> The new grant type that I was talking about was >> >> "authorization_code_but_do_not_return_access_nor_refresh_token", so to >> speak. >> >> It does not return anything per se, but an extension can define something >> on top of it. >> >> >> >> Then, OIDC can define a binding to it so that the binding only returns ID >> Token. >> >> This binding work should be done in OIDF. Should there be such a grant >> type, >> >> it will be an extremely short spec. >> >> >> >> At the same time, if any other specification wanted to define >> >> other type of tokens and have it returned from the token endpoint, >> >> it can also use this grant type. >> >> >> >> If what you want is to define a new grant type that returns ID Token >> only, >> >> then, I am with Justin. Since "other response than ID Token" is only >> >> theoretical, this is a more plausible way forward, I suppose. >> >> >> >> Nat >> >> >> >> 2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>: >> >> So the draft would literally turn into: >> >> "The a4c response type and grant type return an id_token from the token >> endpoint with no access token. All parameters and values are defined in >> OIDC." >> >> Seems like the perfect mini extension draft for OIDF to do. >> >> --Justin >> >> /sent from my phone/ >> >> >> On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote: >> > >> > What about just defining a new grant type in this WG? >> > >> > >> > 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>: >> >> >> >> That would be nice. However oidc still needs the new grant type in >> order to implement the same flow. >> >> >> >> Phil >> >> >> >> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote: >> >> >> >>> +1 to Justin. >> >>> >> >>> >> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>: >> >>>> >> >>>> Errors like these make it clear to me that it would make much more >> sense to develop this document in the OpenID Foundation. It should be >> something that directly references OpenID Connect Core for all of these >> terms instead of redefining them. It's doing authentication, which is >> fundamentally what OpenID Connect does on top of OAuth, and I don't see a >> good argument for doing this work in this working group. >> >>>> >> >>>> -- Justin >> >>>> >> >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> >> wrote: >> >>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < >> Michael.Jones@microsoft.com> wrote: >> >>>>>> >> >>>>>> Thanks for your review, Thomas. The "prompt=consent" definition >> being missing is an editorial error. It should be: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> consent >> >>>>>> >> >>>>>> The Authorization Server SHOULD prompt the End-User for consent >> before returning information to the Client. If it cannot obtain consent, it >> MUST return an error, typically consent_required. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I'll plan to add it in the next draft. >> >>>>> >> >>>>> >> >>>>> It looks like the consent_required error needs to be defined too, >> and you might have forgotten to also import account_selection_required from >> OpenID Connect. >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I agree that there's no difference between a response with >> multiple "amr" values that includes "mfa" and one that doesn't. Unless a >> clear use case for why "mfa" is needed can be identified, we can delete it >> in the next draft. >> >>>>> >> >>>>> >> >>>>> Thanks. >> >>>>> >> >>>>> How about "pwd" then? I fully understand that I should return "pwd" >> if the user authenticated using a password, but what "the service if a >> client secret is used" means in the definition for the "pwd" value? >> >>>>> >> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come >> back ;-) ) >> >>>>> >> >>>>> -- >> >>>>> Thomas Broyer >> >>>>> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> >> >>>>> _______________________________________________ >> >>>>> OAuth mailing list >> >>>>> OAuth@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> OAuth mailing list >> >>>> OAuth@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/oauth >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Nat Sakimura (=nat) >> >>> Chairman, OpenID Foundation >> >>> http://nat.sakimura.org/ >> >>> @_nat_en >> >>> >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > -- >> > Nat Sakimura (=nat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> >> >> >> >> >> -- >> Nat Sakimura (=nat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> >> -- >> Nat Sakimura (=nat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Thomas Broyer >> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Thomas Broyer >> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> -- >> Nat Sakimura (=nat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
- [OAUTH-WG] FW: New Version Notification for draft… Mike Jones
- Re: [OAUTH-WG] FW: New Version Notification for d… Thomas Broyer
- Re: [OAUTH-WG] FW: New Version Notification for d… Mike Jones
- Re: [OAUTH-WG] FW: New Version Notification for d… Thomas Broyer
- Re: [OAUTH-WG] New Version Notification for draft… Richer, Justin P.
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Mike Jones
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Thomas Broyer
- Re: [OAUTH-WG] New Version Notification for draft… Richer, Justin P.
- Re: [OAUTH-WG] New Version Notification for draft… Thomas Broyer
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… torsten
- Re: [OAUTH-WG] New Version Notification for draft… Mike Jones
- Re: [OAUTH-WG] New Version Notification for draft… John Bradley
- Re: [OAUTH-WG] New Version Notification for draft… Mike Jones
- Re: [OAUTH-WG] New Version Notification for draft… Takahiko Kawasaki
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Thomas Broyer
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Thomas Broyer
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… John Bradley
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… John Bradley
- Re: [OAUTH-WG] New Version Notification for draft… Anthony Nadalin
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Anthony Nadalin
- Re: [OAUTH-WG] New Version Notification for draft… Mike Jones
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Anthony Nadalin
- Re: [OAUTH-WG] New Version Notification for draft… Richer, Justin P.
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… John Bradley
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… John Bradley
- Re: [OAUTH-WG] New Version Notification for draft… torsten
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Dale Olds
- Re: [OAUTH-WG] New Version Notification for draft… Bill Burke
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Anthony Nadalin
- Re: [OAUTH-WG] New Version Notification for draft… John Bradley
- Re: [OAUTH-WG] New Version Notification for draft… Bill Mills
- Re: [OAUTH-WG] New Version Notification for draft… Bill Mills
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Anthony Nadalin
- Re: [OAUTH-WG] New Version Notification for draft… Sergey Beryozkin
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Sergey Beryozkin
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Sergey Beryozkin
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Sergey Beryozkin
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Sergey Beryozkin
- Re: [OAUTH-WG] New Version Notification for draft… Sergey Beryozkin