Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
Sergey Beryozkin <sberyozkin@gmail.com> Mon, 13 October 2014 20:25 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 3407B1A0056 for <oauth@ietfa.amsl.com>; Mon, 13 Oct 2014 13:25:02 -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 RzG-qfvqiuLS for <oauth@ietfa.amsl.com>; Mon, 13 Oct 2014 13:24:56 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12DF1A006D for <oauth@ietf.org>; Mon, 13 Oct 2014 13:24:51 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id y10so9323255wgg.3 for <oauth@ietf.org>; Mon, 13 Oct 2014 13:24:50 -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=47AK1BedKphZWtKHc4bYPWM9DNysf2J+xzbXIkQT6lY=; b=yYoRaDFI2DZieQa9A95qLqXTPGz84nM6no9o6D6AgFgyhiivFJWvcfNXzGctcsjzKO wbYL/PcQpoXpdbN90ntMLRvCPrdq1yT6IzpI1CNoOfirF20LtSUTgNSvH4RuCsZEMtsS fGR2POo6CaT1dJM3mT4FFwnpZHGi+/758DuV0mQJ5n+u7iNUeT4JWoiieJbNrGwe0D1Q 1hybr9wlGSTW1PDyZwMVuOxMt4tmnH8yRbyyooZ1mhnfMBSt4IQU6+iKVHb89Z0jVPTl Q9pwzeaDQr7mcXhBtlx3vfUzWC5EH0Bszhpx5NCrrQTO3vgt5qpofdklhJ8DBF2N+8Rv SiwA==
X-Received: by 10.180.149.130 with SMTP id ua2mr1169422wib.31.1413231890426; Mon, 13 Oct 2014 13:24:50 -0700 (PDT)
Received: from [192.168.2.7] ([109.255.231.6]) by mx.google.com with ESMTPSA id q5sm17778881wja.49.2014.10.13.13.24.48 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Oct 2014 13:24:49 -0700 (PDT)
Message-ID: <543C3510.7070201@gmail.com>
Date: Mon, 13 Oct 2014 21:24:48 +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>
In-Reply-To: <44A3CD9F-9E2E-4746-A5B1-47984BBE973C@oracle.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-WTOJo79XzKiXb2KcfQcknis_co
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: Mon, 13 Oct 2014 20:25:02 -0000
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... > 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 >
- [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