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

From: Phil Hunt <[email-masked]>
Date: Tue, 27 Aug 2013 09:52:24 -0700

FYI.  Based on feedback from Berlin, Tony and I have revised the draft to include:

* Alignment with OpenID Connect (using id_token)
* Always returns a JWT
* Minimum assertion level on request
* Return information about the type of authentication performed

Thanks for your input.

Phil

@independentid
www.independentid.com
[email-masked]

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt
> Date: 27 August, 2013 8:56:45 AM PDT
> To: Phil Hunt <[email-masked]>, Anthony Nadalin <[email-masked]>, Tony Nadalin <[email-masked]>
> 
> 
> A new version of I-D, draft-hunt-oauth-v2-user-a4c-01.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
> 
> Filename:	 draft-hunt-oauth-v2-user-a4c
> Revision:	 01
> Title:		 OAuth 2.0 User Authentication and Consent For Clients
> Creation date:	 2013-08-27
> Group:		 Individual Submission
> Number of pages: 10
> URL:             http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c
> Htmlized:        http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-hunt-oauth-v2-user-a4c-01
> 
> Abstract:
>   This specification defines a new OAuth2 endpoint that enables user
>   authentication session and consent information to be shared with
>   client applications.
> 
> 
> 
> 
> 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: John Bradley <[email-masked]>
Date: Tue, 27 Aug 2013 19:27:52 -0400

It is better.  We need to talk about what you have done with "min_alv" vs "acr" from  connect which is extensible via a IANA registry of Authentication contexts.

If it came down to reserving the strings 1 2 3 4 for the ISO29115 reference that could probably be arranged.

I don't know that throwing an error if the min can't be supported is the correct thing.  We had a lot of debate about that and decided that returning the actual acr and letting the client decide was better than an error.

Also remember that the request is not signed so someone could modify it to remove min_alv and spoof a RP that expects all positive results to meet what it asked for.

More discussion on min_alv is required.

John B.

On 2013-08-27, at 12:52 PM, Phil Hunt <[email-masked]> wrote:

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 27 Aug 2013 16:37:18 -0700

See below.
Phil

@independentid
www.independentid.com
[email-masked]

> I don't know that throwing an error if the min can't be supported is the correct thing.  We had a lot of debate about that and decided that returning the actual acr and letting the client decide wa…
[PH[ I agree.
> More discussion on min_alv is required.
[PH] Yes. Returning what actually was done without an error is a better approach.

Also, just noticed that the "hint" parameter should be "login_hint". 

I think we also need to discuss how the client detects the profile API type and whether the AS can return multiple endpoints (and is that even a good thing).  A structured attribute giving endpoint type and URL might be the way to go.

---

From: John Bradley <[email-masked]>
Date: Tue, 27 Aug 2013 19:51:42 -0400

I thought you wanted to keep the profile endpoint (user_info) out of this.    
Once you have a user-info type endpoint you get into defining scopes for claims and I thought Tony wanted to avoid this and have it be only session authentication.

Connect publishes its idp config in the .well-known directory of "iss"  that allows all the endpoints to be discovered.

Over time the Authorization endpoint URI will change and will contain query parameters etc.  tying iss to a logical name like a SAML entityID that could provide the other endpoint information was a more familiar pattern to people.   

In some ways Connect duplicates one of the entity-id to meta-data discovery methods in SAML meta-data that never got traction (other than perhaps in ADFS).

John B.

---

From: Mike Jones <[email-masked]>
Date: Wed, 28 Aug 2013 00:08:36 +0000

I'm concerned that the current "alv" and "min_alv" text wouldn't survive IESG review since depending up NIST SP-800-63-2 is US-centric.  The point of OpenID Connect "acr" (authentication context class reference) claim using RFC6711 is that the authentication context values used are internationalized.

I agree that using the strings "1", "2", "3", and "4" to refer to the ISO 29115 authentication level values would be preferable to the current "alv" text, since that approach is much more likely to survive IESG review and result in an approved RFC.  I'd therefore suggest making this change sooner rather than later.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Tuesday, August 27, 2013 4:37 PM
To: John Bradley
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

See below.
Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On 2013-08-27, at 4:27 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.

On 2013-08-27, at 12:52 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for your input.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt
Date: 27 August, 2013 8:56:45 AM PDT
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>, Anthony Nadalin <[email-masked]<mailto:[email-masked]>>, Tony Nadalin <[email-masked]<mailto:[email-masked]>>

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: Phil Hunt <[email-masked]>
Date: Tue, 27 Aug 2013 17:28:19 -0700

John,

I do not what to do anything to specify the profile endpoint.  The big problem is there are already many APIs -- user_info is but one.

The problems in the IETF OAuth space, is that the URL the client "thinks" is the authenticated user is not guaranteed to be the user.  For example, the clients assume "facebook.com/me" is the authenticated user -- and in that case it is.  But for other APIs there are no aliases.  For example, my client could be requesting information about your Facebook endpoint and because I am a friend, the client thinks it just authenticated you.  The point of returning the profile url is to ensure that the client knows what the authenticated user's profile URL is.

I raised the question of whether returning multiple URLs is useful since many cloud providers are actually offering multiple APIs for the same user information. My feeling is that that client already knows what it wants and is merely checking that the value matches its expectations.

I think the .well-known might be useful, but since this may change on a user-by-user basis, it is problematic.  For example, the authenticated user may be federated. What then?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Tue, 27 Aug 2013 21:03:28 -0400

The authenticated user is the "sub" scoped to "iss" not the profile URL.  A profile URL is informational and may change for the user.    I think making it a structured element describing the API is going beyond the "Simple" 

I was assuming that the profile URI would be under the control of the AS/Issuer and there would be one endpoint per AS like Connect which has a single .well-known for the issuer.

Per user discovery uses webfinger to point to public info.  now that webfinger is a RFC you could return the users acct: URI for webfinger do the client can get public info.

If you want to specify arbitrary protected resources as the profile URI then you are opening a big can of complexity that Connect saves for the Advanced profile with distributed claims, not something you want in the simple profile.

You want to avoid the RP using profile url or email as the identifier for the subject. 

Connect defines its subject tightly in that it must be A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length. The value is a case sensitive string.

Keeping PII out of the subject also saves a lot of grief,  and numbers don't have the same pressure for reassignment as other nicknames.

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 28 Aug 2013 02:27:02 +0000

So these are not authentication context. It does more harm than good to have an extensible IANA registry of values that have no discernable meaning, with the ISO 29115 values you can go an acutually understand the values and have something to potentially interop on

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Tuesday, August 27, 2013 4:28 PM
To: Phil Hunt
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-01.txt

John B.

Thanks for your input.

Phil

@independentid

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 28 Aug 2013 10:02:08 +0100

Minor typo is in section 2,

"The Authentication Code Grant type is used in exactly the same manor
    as the Authorization Code Grant Section 4.1 [RFC6749] and has the
    same features and conditions.  The *Authorization* Code Grant 
extends..."

Cheers, Sergey
On 28/08/13 00:37, Phil Hunt wrote:
> See below.
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>
>
>> It is better.  We need to talk about what you have done with "min_alv"
>> vs "acr" from  connect which is extensible via a IANA registry of
>> Authentication contexts.
>>
>> If it came down to reserving the strings 1 2 3 4 for the ISO29115
>> reference that could probably be arranged.
>>
>> I don't know that throwing an error if the min can't be supported is
>> the correct thing.  We had a lot of debate about that and decided that
>> returning the actual acr and letting the client decide was better than
>> an error.
> [PH[ I agree.
>>
>> Also remember that the request is not signed so someone could modify
>> it to remove min_alv and spoof a RP that expects all positive results
>> to meet what it asked for.
>>
> I think we also need to discuss how the client detects the profile API
> type and whether the AS can return multiple endpoints (and is that even
> a good thing).  A structured attribute giving endpoint type and URL
> might be the way to go.
>
>>
>> John B.
>>
>>> www.independentid.com <http://www.independentid.com/>
>>> [email-masked] <mailto:[email-masked]>
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> *From: [email-masked] <mailto:[email-masked]>
>>>> *Subject: **New Version Notification for
>>>> draft-hunt-oauth-v2-user-a4c-01.txt*
>>>> *Date: *27 August, 2013 8:56:45 AM PDT
>>>> *To: *Phil Hunt <[email-masked] <mailto:[email-masked]>>,
>>>> Anthony Nadalin <[email-masked]
>>>> <mailto:[email-masked]>>, Tony Nadalin <[email-masked]
>>>> <mailto:[email-masked]>>
>>>>
>>>>
>>>> Filename:draft-hunt-oauth-v2-user-a4c
>>>> Revision:01
>>>> Title:OAuth 2.0 User Authentication and Consent For Clients
>>>> Creation date:2013-08-27
>>>> Group:Individual Submission
>>>> Number of pages: 10
>>>> URL:
>>>> http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-01.txt
>>> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listi

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 28 Aug 2013 10:27:07 +0100

Hi Phil,

A have a question, re:

"The authorization server MUST:

  -Perform the normal OAuth2 authorization process,
  -MAY elect not to request consent if no access token is to be
       issued (i.e. this is an authentication only request),
"

This last statement confuses me, given that the Authentication Response
"is identical to the one described in Section 4.1.2 [RFC6749]."

In other words, the client may only request the login but get the 'code' 
back without the user consent ? This seems wrong but may be I'm missing 
something ?

Thanks, Sergey

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 09:45:58 -0700

Sergey,

I agree, the text may still be a bit awkward.  What I was trying to open the door to is that some client may not actually want access to the resource in question -- they just want to authenticate the user.

So, if the client has an empty scope, the AS could interpret that as an authentication only request and it doesn't have to return an access token.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-08-28, at 2:27 AM, Sergey Beryozkin <[email-masked]> wrote:

> In other words, the client may only request the login but get the 'code' back without the user consent ? This seems wrong but may be I'm missing something ?
> 
> Thanks, Sergey
> 
> 
> 
>>