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

From: Mike Jones <[email-masked]>
Date: Mon, 21 Jul 2014 19:05:42 +0000

Changes in this version are:

·        Added the Authentication Method Reference Values registry.

·        Renamed the code_for_id_token grant type to urn:ietf:params:oauth:grant-type:code-for-id-token to conform to Section 4.5 of RFC 6749.

                                                            -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 21, 2014 12:00 PM
To: Phil Hunt; Anthony Nadalin; Phil Hunt; Mike Jones; Anthony Nadalin; Mike Jones
Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

A new version of I-D, draft-hunt-oauth-v2-user-a4c-05.txt

has been successfully submitted by Michael B. Jones and posted to the IETF repository.

Name:                  draft-hunt-oauth-v2-user-a4c

Revision:              05

Title:                     Providing User Authentication Information to OAuth 2.0 Clients

Document date: 2014-07-21

Group:                  Individual Submission

Pages:                  19

URL:            http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-05.txt

Status:         https://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c/

Htmlized:       http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-05

Diff:           http://www.ietf.org/rfcdiff?url2=draft-hunt-oauth-v2-user-a4c-05

Abstract:

   This specification defines a way for OAuth 2.0 clients to verify the

   identity of the End-User and obtain consent based upon the

   authentication performed by an Authorization Server.  The

   interactions defined by this specification are intentionally

   compatible with the OpenID Connect protocol.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 21 Jul 2014 22:47:12 +0200

The end of section 2.2 talks about prompt=consent but the value is not
defined above.

Also, I don't understand the note about "pwd" being used by a service. In
which scenario would that happen?

Finally, what's the difference between providing several values for "amr"
with and without including "mfa"? IOW, what's the use case for mfa?
Le 21 juil. 2014 21:06, "Mike Jones" <[email-masked]> a écrit :

> ·        Renamed the code_for_id_token grant type to
> urn:ietf:params:oauth:grant-type:code-for-id-token to conform to Section
> 4.5 of RFC 6749.
>
>                                                             -- Mike
>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-05.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c/
>
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-hunt-oauth-v2-user-a4c-05
>
>
>
> Abstract:
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
>
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 21 Jul 2014 21:52:36 +0000

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.

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.

                                                            -- Mike

From: Thomas Broyer [mailto:[email-masked]]
Sent: Monday, July 21, 2014 1:47 PM
To: Mike Jones
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

The end of section 2.2 talks about prompt=consent but the value is not defined above.

Also, I don't understand the note about "pwd" being used by a service. In which scenario would that happen?

Finally, what's the difference between providing several values for "amr" with and without including "mfa"? IOW, what's the use case for mfa?
Le 21 juil. 2014 21:06, "Mike Jones" <[email-masked]<mailto:[email-masked]>> a écrit :

•        Added the Authentication Method Reference Values registry.

•        Renamed the code_for_id_token grant type to urn:ietf:params:oauth:grant-type:code-for-id-token to conform to Section 4.5 of RFC 6749.

                                                            -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, July 21, 2014 12:00 PM
To: Phil Hunt; Anthony Nadalin; Phil Hunt; Mike Jones; Anthony Nadalin; Mike Jones
Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

Revision:              05

Pages:                  19

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 22 Jul 2014 13:30:42 +0200

On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <[email-masked]>
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.
>
>
>

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 22 Jul 2014 13:54:22 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for your review, Thomas.  The “prompt=consent” definition being missing is an editorial error.  It should be:

consent

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.

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?

--
Thomas Broyer
/tɔ.ma.bʁwa.je/<http://xn--nna.ma.xn--bwa-xxb.je/>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 22 Jul 2014 11:35:14 -0400

+1 to Justin.

2014-07-22 9:54 GMT-04:00 Richer, Justin P. <[email-masked]>:

>  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 <[email-masked]> wrote:
>
>
>
>
>  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.
>
>
>>
>>
>  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

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Phil Hunt <[email-masked]>
Date: Tue, 22 Jul 2014 12:56:59 -0400

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 <[email-masked]> wrote:
> 
> +1 to Justin. 
> 
> 
>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <[email-masked]> wrote:
>>> /tɔ.ma.bʁwa.je/

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 22 Jul 2014 13:29:01 -0400

What about just defining a new grant type in this WG?

2014-07-22 12:56 GMT-04:00 Phil Hunt <[email-masked]>:

>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <[email-masked]
>> > wrote:
>>
>>> 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.
>>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 22 Jul 2014 13:41:55 -0400

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
[email-masked]