Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

Phil Hunt <phil.hunt@oracle.com> Tue, 22 July 2014 17:42 UTC

Return-Path: <phil.hunt@oracle.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 B7DE21A01B0 for <oauth@ietfa.amsl.com>; Tue, 22 Jul 2014 10:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 e8afAX77O7jz for <oauth@ietfa.amsl.com>; Tue, 22 Jul 2014 10:42:01 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88951B2AE8 for <oauth@ietf.org>; Tue, 22 Jul 2014 10:42:00 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6MHfwu1031152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jul 2014 17:41:58 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6MHfvBg020383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2014 17:41:58 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6MHfv7i020371; Tue, 22 Jul 2014 17:41:57 GMT
Received: from dhcp-a0cc.meeting.ietf.org (/31.133.160.204) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Jul 2014 10:41:57 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_B6FC3A28-B86E-46DC-BDF1-C4D642447D61"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <CABzCy2DnhpiUCv_F8xH_2nAu37=bEy9TiuUBbnwPmg7sjtB8YQ@mail.gmail.com>
Date: Tue, 22 Jul 2014 13:41:55 -0400
Message-Id: <AE959AC7-8D45-413A-B81F-6FD2B6C83D16@oracle.com>
References: <20140721185955.29738.31476.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439ADDA25E@TK5EX14MBXC294.redmond.corp.microsoft.com> <CAEayHEO-_i+cB6mtb_OUaXF4OfyTrYwfv1mn2EYS-KEzTKY1GA@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439ADDAA2D@TK5EX14MBXC294.redmond.corp.microsoft.com> <CAEayHEO1W3axmpiKYGvGRn7vnS7NDNi41t4cAukMBKSB783yUw@mail.gmail.com> <CA1810B0-6ED0-456F-8989-6B7EF73930D9@mitre.org> <CABzCy2DZT3kuTPRjr8cmXKXKS2wmZiBC_ySckhFFPzY0_kfuDA@mail.gmail.com> <CB59055C-BDD3-472D-A777-B65F8F5FB1DB@oracle.com> <CABzCy2DnhpiUCv_F8xH_2nAu37=bEy9TiuUBbnwPmg7sjtB8YQ@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0cF09_AzfsLQ8u4sj7sY5Poum3w
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: Tue, 22 Jul 2014 17:42:02 -0000

Speaking for myself, yes.  Defining the simple ID_token grant showing how an ID token only can be returned is my minimum objective.

I think there needs to be some discussion in the WG on certain features which may be better suited only within OIDC and those features which fit better as a foundational piece in IETF OAuth WG.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



On Jul 22, 2014, at 1:29 PM, 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/
>>> _______________________________________________
>>> 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