Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
Sergey Beryozkin <sberyozkin@gmail.com> Tue, 14 October 2014 09:27 UTC
Return-Path: <sberyozkin@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 3B4611A6FFF for <oauth@ietfa.amsl.com>; Tue, 14 Oct 2014 02:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 8E7rj_Hrfz0s for <oauth@ietfa.amsl.com>; Tue, 14 Oct 2014 02:27:01 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D831A6FEC for <oauth@ietf.org>; Tue, 14 Oct 2014 02:26:59 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id p9so7687026lbv.21 for <oauth@ietf.org>; Tue, 14 Oct 2014 02:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jl+SN2PFbh/dkxHP1yRsSOyp09+buvhvg4XMphnNnrA=; b=Wa04gMMw5GDJXt4m5LjrswmBZD1mPWYjqnH5xit6SKWcMnXsQQlYDBEoorQdsDeWWQ d4RyhVoHfTaZl7P1WO3wQyjEob0YyesW+PC/iuTfZsgnWEcJQ/T6opQxcig/KJoPsgoI UK1q89dQcsktt30O7wiCvA5ug1WWBaMqOLprwMKRNTT35kpubenULr6Lq45ozuRKcTD1 hR6Hk93bN+OpD8jy3rXOYHK4K8/lBaKHfaswKGbhPHFhvu/8eso5bstgqsh1oa+ArCb/ YbkJpf+cQYYSYtOiLfcvZjuROTxKPhnyb5GQBbgFpR7hZj3ZsBBTe6Plk38Y/qeVS8XW GD+Q==
X-Received: by 10.152.7.7 with SMTP id f7mr3926939laa.57.1413278818161; Tue, 14 Oct 2014 02:26:58 -0700 (PDT)
Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id s8sm5390376las.29.2014.10.14.02.26.56 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Oct 2014 02:26:57 -0700 (PDT)
Message-ID: <543CEC5F.6010100@gmail.com>
Date: Tue, 14 Oct 2014 10:26:55 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Phil Hunt <phil.hunt@oracle.com>
References: <jemi4jaauwuimcebbyrr7fbl.1413209870041@email.android.com> <543BE1A1.6020902@gmail.com> <44A3CD9F-9E2E-4746-A5B1-47984BBE973C@oracle.com> <543C3510.7070201@gmail.com> <9C1B0B29-47AB-4057-96B4-BA18E116B5B1@oracle.com> <543CEBF6.4090407@gmail.com>
In-Reply-To: <543CEBF6.4090407@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JKPnju6GgRPBVFb1rp-zqdYVgco
Cc: 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: Tue, 14 Oct 2014 09:27:08 -0000
Sorry for the noise, On 14/10/14 10:25, Sergey Beryozkin wrote: > Hi Phil, All, > > Thanks for your positive feedback and further comments below. > My goal was really about trying to make a clear picture in my mind about > what OIDC is with respect to OAuth2, and specifically supporting the > point about OIDC not being just OAuth2. > > As such, the idea of a specific OIDC profile where no access token was > used appealed to me but really in light of supporting the same point > that OIDC being not just OAuth2. I understand it 'breaks' the clean OIDC > OAuth2-based model. Hence I also tried to suggest that even though OIDC > does return an access token, this token does not have to be a > full-powered token that a client can use to access something else but a > user profile endpoint (unless custom scopes are also used). So the > access token is there but it's only usable in the OAuth2 world. > meant to say in the OIDC world and as such it is a limited token > I respect the effort done in the a4c draft - I'm just not sure really it > has to be a separate effort (as opposed to it being an OIDC 'exception' > light weight profile - can be simpler for users like me to have it all > comprehended when it is a single family of docs) should the experts like > yourself and others really like the idea of having a pure authentication > flow supported. > > But I'll be watching with the interest how it all evolves now :-) > > Thanks, Sergey > > On 13/10/14 22:17, Phil Hunt wrote: >> Sergey, >> >> Actually, I think your comments are fine. They add to the discussion >> on why A4C is distinct from OIDC’s larger IDP role in an OAuth style >> flow and why *both* are needed. >> >> Comments in line. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Oct 13, 2014, at 1:24 PM, Sergey Beryozkin <sberyozkin@gmail.com> >> wrote: >> >>> Hi Phil >>> >>> Thanks for the clarifications, >>> On 13/10/14 20:18, Phil Hunt wrote: >>>> The point to be made is if the client’s objective is to authenticate >>>> the User, the base 6749 spec does not guarantee this at all. >>>> >>>> It simply authorizes the client to access a resource and nothing more. >>>> >>>> It turns out that a significant part of the time authentication does >>>> occur, but the client does not have access to that information. Nor >>>> can it specifically request re-authentication. >>>> >>>> Further, if the client doesn’t wield the access token, its might not >>>> be proof that the token received was actually an authorization. >>>> >>>> OpenID gives you both authen information and authorization profile >>>> information (as a resource). >>>> >>> Yes, I experimented with it. >>>> This thread was more about how to do just authentication ONLY. What >>>> are the requirements for a client to know a User *was* authenticated >>>> and when. While some flows of OpenID can achieve this, its not >>>> clear that it addresses all cases. Furhter there is discussion (as >>>> Justin mentions) that a flow that does not produce an access token >>>> is not an authorization flow and is not OAuth. I agree. >>> Sure. >>>> It an authentication flow and should be distinct IMHO. >>>> >>> I guess that is why the idea of having an OIDC profile dedicated to >>> the authentication alone (no access token) which I believe was >>> suggested here caught my attention. But then it is not OAuth2 and >>> hence not OIDC. The chicken in the egg situation :-). As I said in >>> the prev email, having an access token which is really restricted to >>> the OIDC resource (profile) seems like a good compromise… >> >> [PH] We discussed this in Toronto and OIDC can’t do this and be >> compliant woith OAuth. It wouldn’t be OAuth. Someone also pointed out >> that the OAuth WG isn’t chartered to do authentication and that kind >> of killed the discussion leaving the issue hanging unresolved. >> >> If you look at draft 00 of the A4C draft you will note that I >> originally proposed it as a new end-point. My feeling it should NOT be >> an OAuth flow - because as Justin says, if you aren’t returning an >> access token, you aren’t doing OAuth. The issue is that the technical >> redirect flow for authentication and authorization share the same >> security risks and counter-measures. It would be good therefore to >> build “in-parallel” or “underneath” OAuth to define an authn flow. >> >> I would still recommend OIDC as a layer on top of OAuth that defines >> the standard way to get profile claims (the full OAuth style IDP >> functionality). >> >>> >>>> That said, I am in the minority with this opinion and I acknowledge >>>> as being as such. >>>> >>> >>> Sorry if I hijacked this thread and started the off-topic 'flow'...I >>> guess my reasoning here is a bit all over the place, but I'm pretty >>> sure now I see the big picture better >>> >>> Thanks, Sergey >>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin <sberyozkin@gmail.com> >>>> wrote: >>>> >>>>> On 13/10/14 15:17, Justin Richer wrote: >>>>>> You certainly can do authentication without using an access token, >>>>>> but >>>>>> then I would argue that's no longer OAuth. Basically you're making >>>>>> tofu >>>>>> carob fudge. >>>>> >>>>> Right, the access token is there for a client to get to the >>>>> UserInfo endpoint, as far as OIDC is concerned. What if the info in >>>>> the id_token is sufficient ? >>>>> I guess as far as a typical OAuth2 client is concerned, requesting >>>>> "openid profile" only effectively gives one an access token that >>>>> can only be used with the UserInfo endpoint. >>>>> >>>>> So yes, may be even though OIDC has an access token returned, >>>>> unless other custom scopes are used, the access token would be >>>>> pretty much of use in the OIDC context only if a client chooses to >>>>> work with the UserInfo...I guess the id_token/at_hash is useful on >>>>> its own >>>>> >>>>> >>>>> Cheers, Sergey >>>>> >>>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>> / Sent from my phone / >>>>>> >>>>>> >>>>>> -------- Original message -------- >>>>>> From: Sergey Beryozkin <sberyozkin@gmail.com> >>>>>> Date:10/13/2014 9:00 AM (GMT-05:00) >>>>>> To: Justin Richer <jricher@mit.edu>, oauth@ietf.org >>>>>> Cc: >>>>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> Hi Justin, >>>>>> On 13/10/14 12:53, Justin Richer wrote: >>>>>>> You are correct in that OAuth 2 and OpenID Connect are not the same >>>>>>> thing, but your user is correct that OIDC adds a few pieces on >>>>>>> top of >>>>>>> OAuth to add authentication capabilities. OIDC was designed very >>>>>>> explicitly to be compatible with vanilla OAuth, partially do that >>>>>>> people >>>>>>> would be able to deploy it on top of existing OAuth >>>>>>> infrastructure and >>>>>>> code. But the very fact that OIDC adds a few things on top of >>>>>>> OAuth to >>>>>>> give more functionality should be sufficient evidence that >>>>>>> they're not >>>>>>> equivalent. >>>>>>> >>>>>>> It's more proper to say that OpenID Connect is an extension and >>>>>>> application of OAuth. One that provides an authentication and >>>>>> identity API. >>>>>>> >>>>>> I agree and this is more or less how I answered. >>>>>> >>>>>> Though the 'borders' can be blurred, one can claim that if a user >>>>>> actually logs on into a confidential OAuth2 client web application >>>>>> which >>>>>> redirects this user to AS requesting a code with some scopes such >>>>>> as "a >>>>>> b" then when it uses "a b openid profile" it is basically does a pure >>>>>> OAuth2 code flow where the client requests 'a b' plus also a scope >>>>>> allowing it later to query the identity system on behalf of a user. >>>>>> >>>>>> I like the "The extension and application of OAuth2" >>>>>> characteristic of >>>>>> OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO >>>>>> into non-OAuth2 servers, when it is the case then there's no >>>>>> 'feeling' >>>>>> that OIDC is just a case of the confidential client adding the extra >>>>>> scopes and getting the extra (authentication) info back. A standalone >>>>>> OIDC RP protecting such non OAuth2 servers is very much about the >>>>>> authentication/identity. >>>>>> >>>>>> I also thought that having some OID profile (as opposed updating >>>>>> OAuth2 >>>>>> to support no access tokens) where no access but only id token was >>>>>> returned (as suggested in this thread) would probably make sense too. >>>>>> >>>>>>> The way I like to explain it (which I stole from someone else) is >>>>>>> that >>>>>>> OAuth is like chocolate and authentication is like fudge. They >>>>>>> are not >>>>>>> the same thing. You can make chocolate into fudge out you can >>>>>>> make it >>>>>>> into something else or you can just have it on its own. You can make >>>>>>> fudge with chocolate or you can make it with peanut butter or you >>>>>>> can >>>>>>> make it with potatoes if you want to, but it needs a couple >>>>>>> ingredients >>>>>>> and a very common one is chocolate. OpenID Connect is a recipe for >>>>>>> chocolate fudge that a lot of people like. And it makes my fudge >>>>>>> compatible with your fudge, which is where the metaphor breaks >>>>>>> down. :-) >>>>>>> >>>>>> Thanks for sharing this colourful explanation :-). Perhaps I should >>>>>> borrow it :-), >>>>>> Cheers, Sergey >>>>>> >>>>>> >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> / Sent from my phone / >>>>>>> >>>>>>> >>>>>>> -------- Original message -------- >>>>>>> From: Sergey Beryozkin <sberyozkin@gmail.com> >>>>>>> Date:10/13/2014 6:33 AM (GMT-05:00) >>>>>>> To: oauth@ietf.org >>>>>>> Cc: >>>>>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> We've had a user asserting that "OAuth2 == OpenidConnect", >>>>>>> referring to >>>>>>> the fact that the 'only' thing OIC adds on top of the >>>>>>> authorization code >>>>>>> flow is the client specifying few extra scopes like 'openid' and >>>>>>> 'profile' and the authorization service returning an extra >>>>>>> property, the >>>>>>> id_token which can be sufficient in order to get the authenticated >>>>>>> user's info. >>>>>>> >>>>>>> My understanding "OAuth2 != OpenidConnect", the latter utilizes the >>>>>>> former and is an authentication mechanism which is not what >>>>>>> OAuth2 is >>>>>>> (may be except for the client credentials). But I don't feel like >>>>>>> it is >>>>>>> a convincing enough argument. >>>>>>> >>>>>>> I thought this thread was relevant, sorry if not, would have no >>>>>>> problems >>>>>>> starting a new one. >>>>>>> >>>>>>> Basically, I wonder what is the proper line of argument for a >>>>>>> position >>>>>>> such as "OAuth2 != OpenidConnect" and also what was the action to >>>>>>> the >>>>>>> list of options suggested by John below. Is having an OID profile >>>>>>> where >>>>>>> no access token is returned would be the cleanest action as far as >>>>>>> breaking the ambiguity/confusion is concerned ? >>>>>>> >>>>>>> Cheers, Sergey >>>>>>> >>>>>>> On 24/07/14 15:25, John Bradley wrote: >>>>>>> > I am not against discussion in the WG. >>>>>>> > >>>>>>> > I happen to agree with Phil's fundamental premise that some >>>>>>> developers >>>>>>> > are using OAuth in a insecure way to do authentication. >>>>>>> > >>>>>>> > That raises the question of how to best educate them, and or >>>>>>> address >>>>>>> > technical barriers. >>>>>>> > >>>>>>> > It is on the second point that people's opinions seem to divide. >>>>>>> > >>>>>>> > Some people thing that if we have a OAuth flow that >>>>>>> eliminates the >>>>>>> > access token (primarily to avoid asking for consent as I >>>>>> understand it) >>>>>>> > and just return a id_token from the token endpoint that can be >>>>>> done in a >>>>>>> > spec short enough to het people to read. The subtext of >>>>>>> this is that >>>>>>> > the Connect specification is too large that it scare people, >>>>>>> and they >>>>>>> > don't find the spec in the first place because it is not a RFC. >>>>>>> > >>>>>>> > An other common possession is that if you don't want to >>>>>>> prompt the >>>>>> user >>>>>>> > for consent then don't ask for scopes. Twisting the OAuth >>>>>>> spec to not >>>>>>> > return an access token is not OAuth, yes you could use a >>>>>>> different >>>>>>> > endpoint rather than the token endpoint, but that is not OAuth. >>>>>>> > Connect was careful not to break the OAuth spec. As long >>>>>>> as you are >>>>>>> > willing to take a access token with no scopes (the client >>>>>>> needs to >>>>>>> > understand that there are no attributes one way or another >>>>>>> anyway >>>>>> or it >>>>>>> > will break) then you don't need to change OAuth. You can >>>>>>> publish a >>>>>>> > profile of connect that satisfies the use case. >>>>>>> > >>>>>>> > I think Mike has largely done that but it might be better >>>>>>> being less >>>>>>> > stingy on references back to the larger spec. >>>>>>> > >>>>>>> > The questions are do we modify OAuth to not return an access >>>>>> token, and >>>>>>> > if so how, and if we do is it still OAuth. >>>>>>> > >>>>>>> > The other largely separable question is do we create >>>>>>> confusion in the >>>>>>> > market and slow the the adoption of identity federation on >>>>>>> top of >>>>>> OAuth, >>>>>>> > or find a way to make this look like a positive alignment of >>>>>>> interests >>>>>>> > around a subset of Connect. >>>>>>> > >>>>>>> > There are a number of options. >>>>>>> > 1: We can do a profile in the OIDF and publish it as a IETF >>>>>>> document. >>>>>>> > Perhaps the cleanest from an IPR point of view.However >>>>>>> > 2:We can do a profile in the OAuth WG referencing connect. >>>>>>> > 3:We can do a AD sponsored profile that is not in the OAuth WG. >>>>>>> > 4:We can do a small spec in OAuth to add response_type to the >>>>>>> token >>>>>>> > endpoint. in combination with 1, 2, or 3 >>>>>>> > >>>>>>> > I agree that stoping developers doing insecure things needs >>>>>>> to be >>>>>>> > addressed somehow. >>>>>>> > I am not personally convinced that Oauth without access >>>>>>> tokens is >>>>>>> sensible. >>>>>>> > >>>>>>> > Looking forward to the meeting:) >>>>>>> > >>>>>>> > John B. >>>>>>> > On Jul 24, 2014, at 6:52 AM, Brian Campbell >>>>>> <bcampbell@pingidentity.com >>>>>>> > <mailto:bcampbell@pingidentity.com>> wrote: >>>>>>> > >>>>>>> >> I'd note that the reaction at the conference to Ian's >>>>>>> statement was >>>>>>> >> overwhelmingly positive. There was a wide range of industry >>>>>>> people >>>>>>> >> here - implementers, practitioners, deployers, strategists, >>>>>>> etc. >>>>>> - and >>>>>>> >> it seems pretty clear that the "rough consensus" of the >>>>>>> industry at >>>>>>> >> large is that a4c is not wanted or needed. >>>>>>> >> >>>>>>> >> >>>>>>> >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura >>>>>>> <sakimura@gmail.com >>>>>>> >> <mailto:sakimura@gmail.com>> wrote: >>>>>>> >> >>>>>>> >> And here is a quote from Ian's blog. >>>>>>> >> >>>>>>> >> And although the authentication wheel is round, that >>>>>>> doesn’t >>>>>>> >> mean it isn’t without its lumps. First, we do see some >>>>>>> >> reinventing the wheel just to reinvent the wheel. OAuth >>>>>> A4C is >>>>>>> >> simply not a fruitful activity and should be put down. >>>>>>> >> >>>>>>> >> (Source) >>>>>>> >> >>>>>>> >>>>>> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html >>>>>> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> 2014-07-23 16:53 GMT-04:00 John Bradley <ve7jtb@ve7jtb.com >>>>>>> >> <mailto:ve7jtb@ve7jtb.com>>: >>>>>>> >> >>>>>>> >> I thought I did post this to the list. >>>>>>> >> >>>>>>> >> I guess I hit the wrong reply on my phone. >>>>>>> >> John B. >>>>>>> >> Sent from my iPhone >>>>>>> >> >>>>>>> >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net >>>>>>> >> <mailto:torsten@lodderstedt.net> wrote: >>>>>>> >> >>>>>>> >>> we are two, at least :-) >>>>>>> >>> >>>>>>> >>> Why didn't you post this on the list? >>>>>>> >>> >>>>>>> >>> When will be be arriving? >>>>>>> >>> >>>>>>> >>> Am 23.07.2014 16:39, schrieb John Bradley: >>>>>>> >>> >>>>>>> >>>> Ian Glazer mentioned this in his keynote at CIS >>>>>>> yesterday. >>>>>>> >>>> His advice was please stop, we are creating >>>>>>> confusion and >>>>>>> >>>> uncertainty. >>>>>>> >>>> We are becoming our own wort enemy. ( my view though >>>>>> Ian may >>>>>>> >>>> share it) >>>>>>> >>>> Returning just an id_ token from the token >>>>>>> endpoint has >>>>>>> >>>> little real value. >>>>>>> >>>> Something really useful to do would be sorting out >>>>>>> >>>> channel_id so we can do PoP for id tokens to make >>>>>>> them and >>>>>>> >>>> other cookies secure in the front channel. I think >>>>>> that is >>>>>>> >>>> a better use of time. >>>>>>> >>>> I may be in the minority opinion on that, it >>>>>>> won't be the >>>>>>> >>>> first time. >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> John B. >>>>>>> >>>> Sent from my iPhone >>>>>>> >>>> >>>>>>> >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt >>>>>>> >>>> <torsten@lodderstedt.net >>>>>>> <mailto:torsten@lodderstedt.net>> >>>>>>> >>>> wrote: >>>>>>> >>>> >>>>>>> >>>>> You are right from a theoretical perspective. >>>>>>> Practically >>>>>>> >>>>> this was caused by editorial decisions during the >>>>>>> creation >>>>>>> >>>>> of the RFC. As far as I remember, there was a >>>>>> definition of >>>>>>> >>>>> the (one) token endpoint response in early versions. >>>>>> No one >>>>>>> >>>>> every considered to NOT respond with an access >>>>>>> token from >>>>>>> >>>>> the token endpoint. So one might call it an implicit >>>>>>> >>>>> assumption. >>>>>>> >>>>> I'm worried that people get totally confused if an >>>>>>> >>>>> exception is introduced now given the broad >>>>>>> adoption of >>>>>>> >>>>> OAuth based on this assumption. >>>>>>> >>>>> regards, >>>>>>> >>>>> Torsten. >>>>>>> >>>>> >>>>>>> >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer >>>>>>> >>>>> <t.broyer@gmail.com <mailto:t.broyer@gmail.com>>: >>>>>>> >>>>> >>>>>>> >>>>>> Is it said anywhere that ALL grant types MUST >>>>>>> use Section >>>>>>> >>>>>> 5.1 responses? Each grant type references Section >>>>>> 5.1, and >>>>>>> >>>>>> "access token request" is only defined in the >>>>>>> context of >>>>>>> >>>>>> the defined grant types. Section 2.2 doesn't >>>>>>> talk about >>>>>>> >>>>>> the request or response format. >>>>>>> >>>>>> >>>>>>> >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" >>>>>> <sakimura@gmail.com >>>>>>> >>>>>> <mailto:sakimura@gmail.com>> a écrit : >>>>>>> >>>>>> >>>>>>> >>>>>> Is it? Apart from the implicit grant that does >>>>>> not use >>>>>>> >>>>>> token endpoint, all other grant references >>>>>> section 5.1 >>>>>>> >>>>>> for the response, i.e., all shares the same >>>>>>> response. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer >>>>>>> >>>>>> <t.broyer@gmail.com >>>>>>> <mailto:t.broyer@gmail.com>>: >>>>>>> >>>>>> >>>>>>> >>>>>> I hadn't realized the JSON response that >>>>>>> requires >>>>>>> >>>>>> the access_token field is defined per >>>>>>> grant_type, >>>>>>> >>>>>> so I'd be OK to "extend the semantics" >>>>>>> as in the >>>>>>> >>>>>> current draft. >>>>>>> >>>>>> That was actually my main concern: that >>>>>>> the token >>>>>>> >>>>>> endpoint mandates access_token; but its >>>>>>> actually >>>>>>> >>>>>> not the case. >>>>>>> >>>>>> >>>>>>> >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" >>>>>>> >>>>>> <sakimura@gmail.com >>>>>> <mailto:sakimura@gmail.com>> a >>>>>>> >>>>>> écrit : >>>>>>> >>>>>> >>>>>>> >>>>>> I agree with John that overloading >>>>>>> >>>>>> response_type @ authz endpoint is a >>>>>>> bad idea. >>>>>>> >>>>>> It completely changes the semantics >>>>>>> of this >>>>>>> >>>>>> parameter. NOTE: what I was >>>>>>> proposing was not >>>>>>> >>>>>> this parameter, but a new parameter >>>>>>> >>>>>> response_type @ token endpoint. >>>>>>> >>>>>> I also think overloading grant_type >>>>>>> is a bad >>>>>>> >>>>>> idea since it changes its semantics. >>>>>>> I quote >>>>>>> >>>>>> the definition here again: >>>>>>> >>>>>> grant >>>>>>> >>>>>> credential representing the >>>>>>> resource >>>>>>> >>>>>> owner's authorization >>>>>>> >>>>>> grant_type >>>>>>> >>>>>> type of grant sent to the token >>>>>>> endpoint to >>>>>>> >>>>>> obtain the access token >>>>>>> >>>>>> It is not about controlling what is >>>>>>> to be >>>>>>> >>>>>> returned from the token endpoint, >>>>>>> but the >>>>>> hint >>>>>>> >>>>>> to the token endpoint describing the >>>>>>> type of >>>>>>> >>>>>> credential the endpoint has >>>>>>> received. It >>>>>> seems >>>>>>> >>>>>> the "control of what is being >>>>>>> returned from >>>>>>> >>>>>> token endpoint" is just a side effect. >>>>>>> >>>>>> I am somewhat ambivalent[1] in >>>>>>> changing the >>>>>>> >>>>>> semantics of token endpoint, but in as >>>>>> much as >>>>>>> >>>>>> "text is the king" for a spec., we >>>>>>> probably >>>>>>> >>>>>> should not change the semantics of >>>>>>> it as >>>>>>> >>>>>> Torsten points out. If it is ok to >>>>>>> change >>>>>> this >>>>>>> >>>>>> semantics, I believe defining a new >>>>>>> parameter >>>>>>> >>>>>> to this endpoint to control the >>>>>>> response >>>>>> would >>>>>>> >>>>>> be the best way to go. This is what >>>>>>> I have >>>>>>> >>>>>> described previously. >>>>>>> >>>>>> Defining a new endpoint to send code to >>>>>> get ID >>>>>>> >>>>>> Token and forbidding the use of it >>>>>>> against >>>>>>> >>>>>> token endpoint would not change the >>>>>>> semantics >>>>>>> >>>>>> of any existing parameter or >>>>>>> endpoint, which >>>>>>> >>>>>> is good. However, I doubt if it is >>>>>>> not worth >>>>>>> >>>>>> doing. What's the point of avoiding >>>>>>> access >>>>>>> >>>>>> token scoped to UserInfo endpoint >>>>>>> after all? >>>>>>> >>>>>> Defining a new endpoint for just >>>>>>> avoiding the >>>>>>> >>>>>> access token for userinfo endpoint >>>>>>> seems way >>>>>>> >>>>>> too much the heavy wait way and it >>>>>>> breaks >>>>>>> >>>>>> interoperabiliy: it defeats the >>>>>>> purpose of >>>>>>> >>>>>> standardization. >>>>>>> >>>>>> I have started feeling that no >>>>>>> change is the >>>>>>> >>>>>> best way out. >>>>>>> >>>>>> Nat >>>>>>> >>>>>> [1] If instead of saying "Token >>>>>>> endpoint - >>>>>>> >>>>>> used by the client to exchange an >>>>>>> >>>>>> authorization grant for an access >>>>>>> token, >>>>>>> >>>>>> typically with client >>>>>>> authentication", it >>>>>> were >>>>>>> >>>>>> saying "Token endpoint - used by the >>>>>> client to >>>>>>> >>>>>> exchange an authorization grant for >>>>>>> tokens, >>>>>>> >>>>>> typically with client authentication", >>>>>> then it >>>>>>> >>>>>> would have been OK. It is an >>>>>>> expansion of the >>>>>>> >>>>>> capability rather than changing the >>>>>> semantics. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones >>>>>>> >>>>>> <Michael.Jones@microsoft.com >>>>>>> >>>>>> <mailto: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 >>>>>>> >>>>>> <mailto:oauth-bounces@ietf.org>] >>>>>>> *On >>>>>>> >>>>>> Behalf Of *John Bradley >>>>>>> >>>>>> *Sent:* Wednesday, July 23, 2014 >>>>>>> 10:33 AM >>>>>>> >>>>>> *To:* torsten@lodderstedt.net >>>>>>> >>>>>> <mailto:torsten@lodderstedt.net> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> *Cc:* oauth@ietf.org >>>>>> <mailto: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 >>>>>>> >>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>>> <mailto: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 >>>>>>> >>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>>> <mailto: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 >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> <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 >>>>>>> >>>>>> >>>>>>> <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 >>>>>>> >>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>>> <http://www.independentid.com/> >>>>>>> >>>>>> >>>>>>> >>>>>> phil.hunt@oracle.com >>>>>>> >>>>>> >>>>>>> <mailto:phil.hunt@oracle.com> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Jul 23, 2014, at 9:43 >>>>>>> AM, Nat >>>>>>> >>>>>> Sakimura >>>>>>> <sakimura@gmail.com >>>>>>> >>>>>> >>>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>>> <mailto:phil.hunt@oracle.com>>: >>>>>>> >>>>>> >>>>>>> >>>>>> The draft is very clear. >>>>>>> >>>>>> >>>>>>> >>>>>> Phil >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Jul 23, 2014, at >>>>>>> 0:46, Nat >>>>>>> >>>>>> Sakimura >>>>>>> <sakimura@gmail.com >>>>>>> >>>>>> >>>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>>> <mailto:sakimura@gmail.com>> >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> >> >>>>>>> >>>>>> >>> +1 to Justin. >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>> 2014-07-22 9:54 >>>>>>> GMT-04:00 >>>>>>> >>>>>> Richer, Justin P. >>>>>>> >>>>>> <jricher@mitre.org >>>>>>> >>>>>> >>>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>>> <mailto:t.broyer@gmail.com>> >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> On Mon, Jul >>>>>>> 21, 2014 at >>>>>>> >>>>>> 11:52 PM, Mike Jones >>>>>>> >>>>>> >>>>>>> <Michael.Jones@microsoft.com >>>>>>> >>>>>> >>>>>>> <mailto: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 >>>>>>> >>>>>> <mailto:OAuth@ietf.org> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> >>>> OAuth mailing list >>>>>>> >>>>>> >>>> OAuth@ietf.org >>>>>>> >>>>>> <mailto: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 >>>>>>> >>>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>> <mailto:OAuth@ietf.org> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> OAuth mailing list >>>>>>> >>>>>> OAuth@ietf.org >>>>>> <mailto:OAuth@ietf.org> >>>>>>> >>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> OAuth mailing list >>>>>>> >>>>>> OAuth@ietf.org >>>>>>> <mailto: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 >>>> >>> >>> >> > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
- [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