Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
Justin Richer <jricher@mit.edu> Mon, 13 October 2014 11:54 UTC
Return-Path: <jricher@mit.edu>
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 C8C901A899B for <oauth@ietfa.amsl.com>; Mon, 13 Oct 2014 04:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.329
X-Spam-Level:
X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 xWo0DqGDuZMh for <oauth@ietfa.amsl.com>; Mon, 13 Oct 2014 04:54:00 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1B61A8998 for <oauth@ietf.org>; Mon, 13 Oct 2014 04:53:58 -0700 (PDT)
X-AuditID: 1209190c-f795e6d000006c66-87-543bbd550f92
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id DA.2F.27750.55DBB345; Mon, 13 Oct 2014 07:53:57 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9DBrugA005424; Mon, 13 Oct 2014 07:53:56 -0400
Received: from [IPv6:2607:fb90:290e:a269:c9f6:dc58:6e6a:2a61] ([172.56.23.220]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9DBrU95023278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Oct 2014 07:53:40 -0400
Date: Mon, 13 Oct 2014 07:53:24 -0400
Message-ID: <jk8a1ejl57hageurahygfkys.1413201204906@email.android.com>
Importance: normal
From: Justin Richer <jricher@mit.edu>
To: Sergey Beryozkin <sberyozkin@gmail.com>, oauth@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_447835122614160"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixG6nrhu61zrEoP+LiMXJt6/YLP4ttXdg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MvpeZRVsXy1YserEBpYGxpWfBLoYOTkkBEwk tv+dygJhi0lcuLeerYuRi0NIYDaTxKaH7xghnI2MEm/PrWGFcA4ySfya+4YVpIVFQFVi9ZVl QFUcHMICtRIv91WDmLwCbhL/JieBmJwCQhJduyRAitmAiqevaWECsUUErCVuPJ7OCGLzCghK nJz5BOwGZoEQic/bXjBPYOSdhSQ1C0kKwlaX+DPvEpStKDGl+yH7LKBtzAJqEstalZCFFzCy rWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11MvNLNFLTSndxAgKUU5Jnh2Mbw4qHWIU4GBU4uGV KLMOEWJNLCuuzD3EKMnBpCTK678JKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEN2INUI43JbGy KrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYK3dw9Qo2BRanpqRVpmTglCmomD E2Q4D9DwsyA1vMUFibnFmekQ+VOMilLivCt3AyUEQBIZpXlwvbAU8opRHOgVYd4ZIO08wPQD 1/0KaDAT0ODXxWCDSxIRUlINjLUH951z3Bo2/YjRCq9H8Xd+RxScmajDsNla/8Ieo/c8NqkJ kxL0tiupiAUVuOuw6U6Z+1hwoXIOB1cIJ9sZlyNH6ss2f95mv+P2lTl8es//ZkV9Y2JmbHhy Kyous9Bs+jl9xTCt+Tej3ymUGHReuVDG9PqCdrvLdOHINUExVgfyg269+r6lVomlOCPRUIu5 qDgRAAW4QyD8AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HRXrN2yVcVCRCkVfheTk8Yl0bxA
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 11:54:10 -0000
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. 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. :-) -- 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 <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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-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