Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
Thomas Broyer <t.broyer@gmail.com> Wed, 23 July 2014 16:30 UTC
Return-Path: <t.broyer@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 DE0FB1A0084 for <oauth@ietfa.amsl.com>; Wed, 23 Jul 2014 09:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaPuLWuRHEAb for <oauth@ietfa.amsl.com>; Wed, 23 Jul 2014 09:30:39 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6EE1A0409 for <oauth@ietf.org>; Wed, 23 Jul 2014 09:30:38 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id s7so1123131lbd.14 for <oauth@ietf.org>; Wed, 23 Jul 2014 09:30:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0b8uMnOAb3CXiL/ioiMoclYBGqrLQ8HrwUO+rJTYt0o=; b=ZIESLn1clr6ruLXj3yctKr3whiSTIHZluqcvErXYwRboG8psf0gEB9usPpaFK+2Q2X v1cniE/Z1N5cHEESTjiClJQT00jrz2B8to0AltNiNcXzMk7E4nPm7lu4aFKI2gEPlmJE o53bLgc/HMjommEhTNDk6/2pnFm2aXSOnGQMG8QsHrPJFkC7u6LAaMxVOt7WeWluWzsd VMQq76pxo1AfYPxfBLIYcir3fXWn816O21n29w7JgyRFmaUtd8yNvdwzdEx6FV4gnY6K 6hLKBWCzNK399yZemjbb5EFLoTiesF0bV9LczM2R9fWIegN2EYR4/DmMU0iSryud22mc odkQ==
X-Received: by 10.152.37.194 with SMTP id a2mr2784882lak.29.1406133036470; Wed, 23 Jul 2014 09:30:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.113.73 with HTTP; Wed, 23 Jul 2014 09:30:16 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com>
References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <CABzCy2CxNQ2d3=m9Bvc0+k6ikqZkwb940HwskvnAGvKoGnteSw@mail.gmail.com> <DE16B8D3-3590-45B3-BE08-D1A7CF9EF0FB@oracle.com> <CABzCy2B_iB1ZBskFJObKJjnftEH1STVyhx1-AE6Chrj76-se8g@mail.gmail.com> <F7F8C65F-C805-4C29-86F0-1835B7A80E3F@oracle.com> <4E1F6AAD24975D4BA5B16804296739439ADDD8F2@TK5EX14MBXC294.redmond.corp.microsoft.com>
From: Thomas Broyer <t.broyer@gmail.com>
Date: Wed, 23 Jul 2014 18:30:16 +0200
Message-ID: <CAEayHEM4SAM_2DwF8ceC4sen++o7azZnP16xDR8EodqSkxFajA@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="089e013d1656255aaa04fededc2d"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/PUVGZltaBV6SnF7jPz40uez7tnE
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jul 2014 16:30:46 -0000
Except that these are about not using the Token Endpoint at all, whereas the current proposal is about the Token Endpoint not returning an access_token field in the JSON. On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <Michael.Jones@microsoft.com> wrote: > The response_type “none” is already used in practice, which returns no > access token. It was accepted by the designated experts and registered in > the IANA OAuth Authorization Endpoint Response Types registry at > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint. > The registered “id_token” response type also returns no access token. > > > > So I think the question of whether response types that result in no access > token being returned are acceptable within OAuth 2.0 is already settled, as > a practical matter. Lots of OAuth implementations are already using such > response types. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Wednesday, July 23, 2014 7:09 AM > *To:* Nat Sakimura > *Cc:* <oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > Yes. This is why it has to be discussed in the IETF. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@gmail.com> wrote: > > > > Reading back the RFC6749, I am not sure if there is a good way of > suppressing access token from the response and still be OAuth. It will > break whole bunch of implicit definitions like: > > > > authorization server > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization. > > > > After all, OAuth is all about issuing access tokens. > > > > Also, I take back my statement on the grant type in my previous mail. > > > > The definition of grant and grant_type are respectively: > > > > grant > > credential representing the resource owner's authorization > > > > grant_type > > (string representing the) type of grant sent to the token endpoint to > obtain the access token > > > > Thus, the grant sent to the token endpoint in this case is still 'code'. > > > > Response type on the other hand is not so well defined in RFC6749, but it > seems it is representing what is to be returned from the authorization > endpoint. To express what is to be returned from token endpoint, perhaps > defining a new parameter to the token endpoint, which is a parallel to the > response_type to the Authorization Endpoint seems to be a more symmetric > way, though I am not sure at all if that is going to be OAuth any more. One > straw-man is to define a new parameter called response_type to the token > endpoint such as: > > > > response_type > > OPTIONAL. A string representing what is to be returned from the token > endpoint. > > > > Then define the behavior of the endpoint according to the values as the > parallel to the multi-response type spec. > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > > > > Nat > > > > > > > > > > 2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>: > > The draft is very clear. > > Phil > > > On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@gmail.com> wrote: > > The new grant type that I was talking about was > > "authorization_code_but_do_not_return_access_nor_refresh_token", so to > speak. > > It does not return anything per se, but an extension can define something > on top of it. > > > > Then, OIDC can define a binding to it so that the binding only returns ID > Token. > > This binding work should be done in OIDF. Should there be such a grant > type, > > it will be an extremely short spec. > > > > At the same time, if any other specification wanted to define > > other type of tokens and have it returned from the token endpoint, > > it can also use this grant type. > > > > If what you want is to define a new grant type that returns ID Token only, > > then, I am with Justin. Since "other response than ID Token" is only > > theoretical, this is a more plausible way forward, I suppose. > > > > Nat > > > > 2014-07-22 14:30 GMT-04:00 Justin Richer <jricher@mit.edu>: > > So the draft would literally turn into: > > "The a4c response type and grant type return an id_token from the token > endpoint with no access token. All parameters and values are defined in > OIDC." > > Seems like the perfect mini extension draft for OIDF to do. > > --Justin > > /sent from my phone/ > > > On Jul 22, 2014 10:29 AM, Nat Sakimura <sakimura@gmail.com> wrote: > > > > What about just defining a new grant type in this WG? > > > > > > 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>: > >> > >> That would be nice. However oidc still needs the new grant type in > order to implement the same flow. > >> > >> Phil > >> > >> On Jul 22, 2014, at 11:35, Nat Sakimura <sakimura@gmail.com> wrote: > >> > >>> +1 to Justin. > >>> > >>> > >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@mitre.org>: > >>>> > >>>> Errors like these make it clear to me that it would make much more > sense to develop this document in the OpenID Foundation. It should be > something that directly references OpenID Connect Core for all of these > terms instead of redefining them. It's doing authentication, which is > fundamentally what OpenID Connect does on top of OAuth, and I don't see a > good argument for doing this work in this working group. > >>>> > >>>> -- Justin > >>>> > >>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.broyer@gmail.com> > wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones < > Michael.Jones@microsoft.com> wrote: > >>>>>> > >>>>>> Thanks for your review, Thomas. The “prompt=consent” definition > being missing is an editorial error. It should be: > >>>>>> > >>>>>> > >>>>>> > >>>>>> consent > >>>>>> > >>>>>> The Authorization Server SHOULD prompt the End-User for consent > before returning information to the Client. If it cannot obtain consent, it > MUST return an error, typically consent_required. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I’ll plan to add it in the next draft. > >>>>> > >>>>> > >>>>> It looks like the consent_required error needs to be defined too, > and you might have forgotten to also import account_selection_required from > OpenID Connect. > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> I agree that there’s no difference between a response with multiple > “amr” values that includes “mfa” and one that doesn’t. Unless a clear use > case for why “mfa” is needed can be identified, we can delete it in the > next draft. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> How about "pwd" then? I fully understand that I should return "pwd" > if the user authenticated using a password, but what "the service if a > client secret is used" means in the definition for the "pwd" value? > >>>>> > >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come > back ;-) ) > >>>>> > >>>>> -- > >>>>> Thomas Broyer > >>>>> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>> > >>> > >>> > >>> -- > >>> Nat Sakimura (=nat) > >>> Chairman, OpenID Foundation > >>> http://nat.sakimura.org/ > >>> @_nat_en > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > -- > > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > > > > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
- [OAUTH-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