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

Justin Richer <jricher@MIT.EDU> Tue, 22 July 2014 18:30 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 DF5FD1A0AA9 for <oauth@ietfa.amsl.com>; Tue, 22 Jul 2014 11:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 9H0pvT3fkkKM for <oauth@ietfa.amsl.com>; Tue, 22 Jul 2014 11:30:43 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8971B2BA0 for <oauth@ietf.org>; Tue, 22 Jul 2014 11:30:41 -0700 (PDT)
X-AuditID: 1209190d-f79c06d000002f07-49-53ceadd039d6
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 37.13.12039.0DDAEC35; Tue, 22 Jul 2014 14:30:40 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6MIUdfx004480; Tue, 22 Jul 2014 14:30:39 -0400
Received: from [162.162.97.63] ([172.56.39.13]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6MIUYrf031075 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Jul 2014 14:30:37 -0400
Message-Id: <201407221830.s6MIUYrf031075@outgoing.mit.edu>
Date: Tue, 22 Jul 2014 11:30:30 -0700
From: Justin Richer <jricher@MIT.EDU>
To: Nat Sakimura <sakimura@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrHth7blgg5c3+SxOvn3FZrFgfiO7 xZlbKxgdmD12zrrL7rFkyU8mj49Pb7EEMEdx2aSk5mSWpRbp2yVwZSy/3MFesEql4uPM7+wN jBuUuxg5OSQETCQ2r7nPCGGLSVy4t56ti5GLQ0hgNpPEwpWTmSGcjYwSS26eYwGpEhJYyCRx +7MWiM0rYCUxa/p6dhCbRUBVYvmDg2CThAWiJCbt/QgWZwOKz195iwnEFgGym/YeZgWxmQU8 JSZNfcwEMUdQ4uTMJywQcXWJP/MuMUPYihJTuh+yT2Dkm4WkbBaSsllIyhYwMq9ilE3JrdLN TczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQIDkZJ3h2M7w4qHWIU4GBU4uEtqDkXLMSaWFZc mXuIUZKDSUmUt3YlUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb3QrUI43JbGyKrUoHyYlzcGi JM771toqWEggPbEkNTs1tSC1CCYrw8GhJMHLAIw6IcGi1PTUirTMnBKENBMHJ8hwHqDhVWtA hhcXJOYWZ6ZD5E8x6nJs6z3WxiTEkpeflyolzvsSpEgApCijNA9uDiyJvGIUB3pLmPcmSBUP MAHBTXoFtIQJaElR5mmQJSWJCCmpBsa1Pw4mW1lsCpvXlZ2sutJA4pp5L3vd8fmuxTK8HQuX WBYVnFx58kL3wu8rraN8nm+PX73AdnPyDOsWjaef/7CdSVecevTnjNUZKvxbwhJrOnJLhLQd vBVKZrj+XiPXFVRbaSBlVnBh/QavvPqGf1bu71Lc/rhu0dqWyqWcO5GBTaJsue3Xc0osxRmJ hlrMRcWJAKd65pv9AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Gp7zvjBKS1KsCD7h9heEq_oG3kg
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 18:30:47 -0000

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/
>>>>> _______________________________________________
>>>>> 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