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

[John Bradley <[e-mail]>]

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.

On 2013-08-27, at 8:28 PM, Phil Hunt <[e-mail]> wrote:

> 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
> [e-mail]
> 
> 
> 
> 
> 
> 
> 
> On 2013-08-27, at 4:51 PM, John Bradley <[e-mail]> wrote:
> 
>> 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.
>> 
>> On 2013-08-27, at 7:37 PM, Phil Hunt <[e-mail]> wrote:
>> 
>>> See below.
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> [e-mail]
>>> 
>>> 
>>> 
>>> On 2013-08-27, at 4:27 PM, John Bradley <[e-mail]> wrote:
>>> 
>>>> 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.
>>>> 
>>>> 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.
>>> 
>>>> 
>>>> John B.
>>>> 
>>>> On 2013-08-27, at 12:52 PM, Phil Hunt <[e-mail]> wrote:
>>>> 
>>>>> 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
>>>>> [e-mail]
>>>>> 
>>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>>> From: [e-mail]
>>>>>> 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 <[e-mail]>, Anthony Nadalin <[e-mail]>, Tony Nadalin <[e-mail]>
>>>>>> 
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>> 
>> 
>