Subject: Re: [OAUTH-WG] [WRAP] Username and Password Profile

From: David Recordon <[email-masked]>
Date: Thu, 4 Mar 2010 20:37:22 -0800

+ietf list

On Mar 4, 2010, at 8:16 PM, Jason Hullinger <[email-masked]> wrote:

> I think there are probably going to be more instances of providers  
> needing this than otherwise. The current Username and Password  
> profile is not a solution in a for every sense, and there clearly is  
> a need for a secure protocol where you can validate that the client  
> is who they say they are in a profile such as on a phone or desktop  
> application.
>
> ~/Jason Hullinger
>
> On Thu, Mar 4, 2010 at 7:30 PM, Luke Shepard <[email-masked]>  
> wrote:
> Is Facebook the only one who needs this?
>
> Sent from my iPhone
>
> On Mar 4, 2010, at 6:41 PM, "Dick Hardt" <[email-masked]> wrote:
>
>> The spec allows the AS to define additional parameters, so for  
>> these specialized use cases, Facebook could ask Microsoft and Sony  
>> to include an identifier in the request.
>>
>> Is that adequate?
>>
>> On Thu, Mar 4, 2010 at 6:28 PM, David Recordon  
>> <[email-masked]> wrote:
>> Devices such as an XBox or PS3 can keep secrets which is primarily
>> where we envision using the username/password profile.
>>
>> On Thu, Mar 4, 2010 at 5:52 PM, Dick Hardt <[email-masked]>  
>> wrote:
>> >
>> > On 2010-03-04, at 3:58 PM, Luke Shepard wrote:
>> >
>> >> On Mar 4, 2010, at 3:42 PM, Marius Scurtescu wrote:
>> >>
>> >>> On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger <[email-masked] 
>> > wrote:
>> >>>>
>> >>>> wrap_client_id - Required. The client identifier
>> >>>> wrap_username - Required. The User’s username
>> >>>> wrap_password - Required. The User’s password
>> >>>> wrap_scope - Optional. Authorization scope values defined by  
>> the server
>> >>>> Additional parameters - Any additional parameter defined by the
>> >>>> authorization server
>> >>>>
>> >>>> From the above parameters there is no way of insuring that a  
>> client is ever
>> >>>> who they say they are because a user could easily obtain the  
>> wrap_client_id
>> >>>> and make requests using that. Does anyone have an  
>> implementation of this or
>> >>>> any recommended additional parameters?
>> >>>
>> >>> I don't think you need to trust this client itself in any way,  
>> the
>> >>> user trusted the client and provided his/her username and  
>> password,
>> >>> that's all that counts. The should just verify these  
>> credentials and
>> >>> then issue refresh and access tokens.
>> >>
>> >> It's pretty important to Facebook that we be able to validate  
>> who the client is when they pass in user credentials. We have  
>> pretty strict restrictions on the ability for apps to take user  
>> credentials directly and we need to be able to enforce those  
>> restrictions. I would like to see the ability to authenticate the  
>> app as well in this profile.
>> >
>> > This profile was motivated by the use case of rich clients where  
>> redirection of a browser is challenging. ie. a twitter app on a  
>> phone.
>> >
>> > Per previous discussions in OAuth, it is not feasible with  
>> current platforms for an app running on a user machine to keep  
>> secrets from malicious users. A web app of course can keep a secret  
>> from the user, but use of this profile by a web app does not seem  
>> to make sense.
>> >
>> > -- Dick
>> >
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the  
>> Google Groups "OAuth WRAP WG" group.
>> > To post to this group, send email to oauth-wrap- 
>> [email-masked].
>> > To unsubscribe from this group, send email to [email-masked] 
>> .
>> > For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en 
>> .
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google  
>> Groups "OAuth WRAP WG" group.
>> To post to this group, send email to [email-masked].
>> To unsubscribe from this group, send email to [email-masked] 
>> .
>> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en 
>> .
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google  
>> Groups "OAuth WRAP WG" group.
>> To post to this group, send email to [email-masked].
>> To unsubscribe from this group, send email to [email-masked] 
>> .
>> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en 
>> .
>
> -- 
> You received this message because you are subscribed to the Google  
> Groups "OAuth WRAP WG" group.
> To post to this group, send email to [email-masked].
> To unsubscribe from this group, send email to [email-masked] 
> .
> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en 
> .
>
> -- 
> You received this message because you are subscribed to the Google  
> Groups "OAuth WRAP WG" group.
> To post to this group, send email to [email-masked].
> To unsubscribe from this group, send email to [email-masked] 
> .
> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en 
> .

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Mar 2010 21:37:29 -0800

As was discussed on the OAuth list, desktop apps can NOT be secured, so there is no way to ensure it really is the desktop app you think it is. For most phone platforms, this is also the case. For totally locked platforms where the app is part of the OS (xbox, PS3, some phones, settop boxes) -- then one can have high confidence the app is the app. So far I consider these the exception rather than the rule.

-- Dick

On 2010-03-04, at 8:37 PM, David Recordon wrote:

>> I think there are probably going to be more instances of providers needing this than otherwise. The current Username and Password profile is not a solution in a for every sense, and there clearly is a need for a secure protocol where you can validate that the client is who they say they are in a profile such as on a phone or desktop application.
>> 
>> ~/Jason Hullinger
>> 
>> On Thu, Mar 4, 2010 at 7:30 PM, Luke Shepard <[email-masked]> wrote:
>>> The spec allows the AS to define additional parameters, so for these specialized use cases, Facebook could ask Microsoft and Sony to include an identifier in the request.
>>> 
>>> Is that adequate?
>>> 
>>> On Thu, Mar 4, 2010 at 6:28 PM, David Recordon <[email-masked]> wrote:
>>> On Thu, Mar 4, 2010 at 5:52 PM, Dick Hardt <[email-masked]> wrote:
>>> >
>>> >>> On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger <[email-masked]> wrote:
>>> >>>>
>>> >>>> wrap_scope - Optional. Authorization scope values defined by the server
>>> >>>> From the above parameters there is no way of insuring that a client is ever
>>> >>>> who they say they are because a user could easily obtain the wrap_client_id
>>> >>>> and make requests using that. Does anyone have an implementation of this or
>>> >>> I don't think you need to trust this client itself in any way, the
>>> >>> user trusted the client and provided his/her username and password,
>>> >>> that's all that counts. The should just verify these credentials and
>>> >> It's pretty important to Facebook that we be able to validate who the client is when they pass in user credentials. We have pretty strict restrictions on the ability for apps to take user credentials directly and we need to be able to enforce those restrictions. I would like to see the ability to authenticate the app as well in this profile.
>>> >
>>> > This profile was motivated by the use case of rich clients where redirection of a browser is challenging. ie. a twitter app on a phone.
>>> >
>>> > Per previous discussions in OAuth, it is not feasible with current platforms for an app running on a user machine to keep secrets from malicious users. A web app of course can keep a secret from the user, but use of this profile by a web app does not seem to make sense.
>>> >
>>> > -- Dick
>>> >
>>> >
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
>>> > To unsubscribe from this group, send email to [email-masked].
>>> > For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>> >
>>> >
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
>>> To unsubscribe from this group, send email to [email-masked].
>>> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>> 
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
>>> To unsubscribe from this group, send email to [email-masked].
>>> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
>> To unsubscribe from this group, send email to [email-masked].
>> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
>> To unsubscribe from this group, send email to [email-masked].
>> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
> To unsubscribe from this group, send email to [email-masked].
> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

---

From: Jason Hullinger <[email-masked]>
Date: Fri, 5 Mar 2010 00:17:07 -0800

If it's impossible to validate who a client is for even one particular
protocol in the spec, doesn't this leave a provider's web service open to
anyone making an authentication/login request to that implemented profile in
the spec? Unless I'm missing something, this is a problem because a provider
would be opening themselves up to likely phishing attacks, and no way to
stop it except by shutting down the entire protocol that allowed it. Perhaps
this is just a documentation issue because implementing this portion of the
spec could potentially make a provider less secure with no real way of
stopping it after it's implemented.

~/Jason Hullinger

On Thu, Mar 4, 2010 at 9:37 PM, Dick Hardt <[email-masked]> wrote:

> As was discussed on the OAuth list, desktop apps can NOT be secured, so
> there is no way to ensure it really is the desktop app you think it is. For
> most phone platforms, this is also the case. For totally locked platforms
> where the app is part of the OS (xbox, PS3, some phones, settop boxes) --
> then one can have high confidence the app is the app. So far I consider
> these the exception rather than the rule.
>
> -- Dick
>
>
> On Mar 4, 2010, at 8:16 PM, Jason Hullinger < <[email-masked]>
> [email-masked]> wrote:
>
> I think there are probably going to be more instances of providers needing
> this than otherwise. The current Username and Password profile is not a
> solution in a for every sense, and there clearly is a need for a secure
> protocol where you can validate that the client is who they say they are in
> a profile such as on a phone or desktop application.
>
> ~/Jason Hullinger
>
> On Thu, Mar 4, 2010 at 7:30 PM, Luke Shepard < <[email-masked]><[email-masked]>
> [email-masked]> wrote:
>
>> On Mar 4, 2010, at 6:41 PM, "Dick Hardt" < <[email-masked]><[email-masked]>
>> [email-masked]> wrote:
>>
>> The spec allows the AS to define additional parameters, so for these
>> specialized use cases, Facebook could ask Microsoft and Sony to include an
>> identifier in the request.
>>
>> Is that adequate?
>>
>> On Thu, Mar 4, 2010 at 6:28 PM, David Recordon < <[email-masked]><[email-masked]><[email-masked]>
>> [email-masked]> wrote:
>>
>>> On Thu, Mar 4, 2010 at 5:52 PM, Dick Hardt < <[email-masked]><[email-masked]><[email-masked]>
>>> [email-masked]> wrote:
>>> >
>>> >>> On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger <<[email-masked]><[email-masked]><[email-masked]>
>>> [email-masked]> wrote:
>>> >>>>
>>> >> It's pretty important to Facebook that we be able to validate who the
>>> client is when they pass in user credentials. We have pretty strict
>>> restrictions on the ability for apps to take user credentials directly and
>>> we need to be able to enforce those restrictions. I would like to see the
>>> ability to authenticate the app as well in this profile.
>>> >
>>> redirection of a browser is challenging. ie. a twitter app on a phone.
>>> >
>>> > Per previous discussions in OAuth, it is not feasible with current
>>> platforms for an app running on a user machine to keep secrets from
>>> malicious users. A web app of course can keep a secret from the user, but
>>> use of this profile by a web app does not seem to make sense.
>>> >
>>> > -- Dick
>>> >
>>> >
>>> >
>>> > --
>>> > To post to this group, send email to <[email-masked]><[email-masked]><[email-masked]>
>>> [email-masked].
>>> > To unsubscribe from this group, send email to
>>> <[email-masked]><[email-masked]><[email-masked]>
>>> [email-masked].
>>> > For more options, visit this group at
>>> <http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en>
>>> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>> >
>>> >
>>>
>>> --
>>> To post to this group, send email to <[email-masked]><[email-masked]><[email-masked]>
>>> [email-masked].
>>> To unsubscribe from this group, send email to
>>> <[email-masked]><[email-masked]><[email-masked]>
>>> [email-masked].
>>> For more options, visit this group at
>>> <http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en>
>>> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>>
>>>
>>
>> --
>> To post to this group, send email to <[email-masked]><[email-masked]>
>> [email-masked].
>> To unsubscribe from this group, send email to
>> <[email-masked]><[email-masked]>
>> [email-masked].
>> For more options, visit this group at
>> <http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en>
>> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>
>>
>> --
>> To post to this group, send email to <[email-masked]><[email-masked]>
>> [email-masked].
>> To unsubscribe from this group, send email to
>> <[email-masked]><[email-masked]>
>> [email-masked].
>> For more options, visit this group at
>> <http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en>
>> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>
>
>
> --
> To post to this group, send email to <[email-masked]>
> [email-masked].
> To unsubscribe from this group, send email to
> <[email-masked]>
> [email-masked].
> For more options, visit this group at
> <http://groups.google.com/group/oauth-wrap-wg?hl=en>
> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>
>
> --
> To unsubscribe from this group, send email to
> [email-masked].
> For more options, visit this group at
> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 5 Mar 2010 00:22:35 -0800

You are correct. If a AS, supports the username and password profile, that means it can be used by any client. Clearly the user has made a trust decision about the client in this case, assuming there really is a user running the client.

One option for a provider to minimize their exposure is they may not issue Access Tokens that have as much power to Clients using the Username and Password profile.

This is a good point to call out in the currently un-written security considerations.

-- Dick

On 2010-03-05, at 12:17 AM, Jason Hullinger wrote:

> If it's impossible to validate who a client is for even one particular protocol in the spec, doesn't this leave a provider's web service open to anyone making an authentication/login request to that implemented profile in the spec? Unless I'm missing something, this is a problem because a provider would be opening themselves up to likely phishing attacks, and no way to stop it except by shutting down the entire protocol that allowed it. Perhaps this is just a documentation issue because implementing this portion of the spec could potentially make a provider less secure with no real way of stopping it after it's implemented.
> 
> ~/Jason Hullinger
>

---

From: Allen Tom <[email-masked]>
Date: Sun, 07 Mar 2010 19:41:07 -0800

Correction: I meant to say that popping open a browser does NOT protect the
user from malicious rich apps. If the user downloaded and installed the
malicious app on their system, its too late already.

Allen

On 3/7/10 7:25 PM, "Allen Tom" <[email-masked]> wrote:

> 
> However, for rich apps, requiring the app to pop open a browser does protect
> the user from malicious apps,
> 
> 
>

---

From: Allen Tom <[email-masked]>
Date: Sun, 07 Mar 2010 19:25:53 -0800

This is why the username/password profile is intended for rich client apps,
where invoking a browser is not feasible. Given that the user already
downloaded and installed the rich app, popping open a browser is not going
to protect the user from a malicious app  for instance, a malicious app
could have installed a keylogger before invoking the browser.

Under no circumstances should web applications use the username/password
profile. Obviously, a browser is available in this scenario.

However, for rich apps, requiring the app to pop open a browser does protect
the user from malicious apps, and that¹s why it is OK for these apps to
directly ask the user for their password. However, it¹s generally much
better to invoke a browser  for instance, CAPTCHA and other anti-password
cracking defenses and be deployed without having to rewrite clients that are
already in the field. Also, some users may need to authenticate with more
than just a password  for instance users might have hardware/sms tokens or
might need to answer a secret question.

Allen

On 3/5/10 12:17 AM, "Jason Hullinger" <[email-masked]> wrote:

> would be opening themselves up to likely phishing attacks, and no way to stop
> it except by shutting down the entire protocol that allowed it. Perhaps this
> is just a documentation issue because implementing this portion of the
>> As was discussed on the OAuth list, desktop apps can NOT be secured, so there
>> is no way to ensure it really is the desktop app you think it is. For most
>> phone platforms, this is also the case. For totally locked platforms where
>> the app is part of the OS (xbox, PS3, some phones, settop boxes) -- then one
>> can have high confidence the app is the app. So far I consider these the
>> exception rather than the rule.
>> 
>> -- Dick
>> 
>> 
>>> On Mar 4, 2010, at 8:16 PM, Jason Hullinger < <mailto:[email-masked]>
>>>> On Thu, Mar 4, 2010 at 7:30 PM, Luke Shepard <
>>>> <mailto:[email-masked]>  <mailto:[email-masked]>
>>>>> On Mar 4, 2010, at 6:41 PM, "Dick Hardt" < <mailto:[email-masked]>
>>>>> <mailto:[email-masked]> [email-masked]> wrote:
>>>>> 
>>>>>> specialized use cases, Facebook could ask Microsoft and Sony to include
>>>>>> an identifier in the request.
>>>>>> 
>>>>>> Is that adequate?
>>>>>> 
>>>>>> On Thu, Mar 4, 2010 at 6:28 PM, David Recordon <
>>>>>> <mailto:[email-masked]>  <mailto:[email-masked]>
>>>>>> <mailto:[email-masked]> [email-masked]> wrote:
>>>>>>> On Thu, Mar 4, 2010 at 5:52 PM, Dick Hardt <
>>>>>>> <mailto:[email-masked]>  <mailto:[email-masked]>
>>>>>>> <mailto:[email-masked]> [email-masked]> wrote:
>>>>>>>> >
>>>>>>>>>> >>> On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger <
>>>>>>>>>> <mailto:[email-masked]>  <mailto:[email-masked]>
>>>>>>>>>> <mailto:[email-masked]> [email-masked]> wrote:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> wrap_username - Required. The User¹s username
>>>>>>>>>>> >>>> wrap_password - Required. The User¹s password
the
>>>>>>>>> >> It's pretty important to Facebook that we be able to validate who
>>>>>>>>> the client is when they pass in user credentials. We have pretty
>>>>>>>>> strict restrictions on the ability for apps to take user credentials
>>>>>>>>> directly and we need to be able to enforce those restrictions. I would
>>>>>>>>> like to see the ability to authenticate the app as well in this
>>>>>>>>> profile.
>>>>>>>> >
>>>>>>>> malicious users. A web app of course can keep a secret from the user,
>>>>>>>> but use of this profile by a web app does not seem to make sense.
>>>>>>>> >
>>>>>>>> > -- Dick
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > --
>>>>>>>> > To post to this group, send email to
>>>>>>>> <mailto:[email-masked]>
>>>>>>>> <mailto:[email-masked]>
>>>>>>>> <mailto:[email-masked]> [email-masked].
>>>>>>>> <mailto:[email-masked]>
>>>>>>>> <mailto:[email-masked]>
>>>>>>>> <mailto:[email-masked]>
>>>>>>> To post to this group, send email to
>>>>>>> <mailto:[email-masked]>
>>>>>>> <mailto:[email-masked]>
>>>>>>> <mailto:[email-masked]> [email-masked].
>>>>>>> <mailto:[email-masked]>
>>>>>>> <mailto:[email-masked]>
>>>>>>> <mailto:[email-masked]>

---

From: Ethan Jewett <[email-masked]>
Date: Mon, 8 Mar 2010 21:51:48 -0500

On Sun, Mar 7, 2010 at 10:25 PM, Allen Tom <[email-masked]> wrote:
> to protect the user from a malicious app – for instance, a malicious app

I disagree. There are a large and growing number of platforms on which
I can install a rich client application and be confident that it will
not be able to recover my username and password when I type them into
my web browser. To name a few that I use every day:

1. My iPod Touch (non-jail-broken, admittedly)
2. Adobe AIR on my Windows XP system
3. Mac OS X (users and applications do not run as administrators by default)

On a related note - What stops a provider from implementing the
username/password pattern on top of normal OAuth or WRAP (thereby
losing my business ;-)? The token can be pretty much any string of
text, so the client could embed the username and password into the
token.

Ethan

---

From: Allen Tom <[email-masked]>
Date: Mon, 08 Mar 2010 20:01:20 -0800

Hi Ethan -

In Yahoo's case, we only allow the username/password profile for a very
small number of applications written by Yahoo or by partners under contract,
and only when opening a web browser is not feasible or desirable. We
strongly discourage apps from using this profile, and it's unlikely that
it'll ever be a public interface.

We have a very strong preference that rich client apps invoke a browser
window for the user to authorize the app.

Other Service Providers have similar policies for their equivalent
username/password profile.

Allen

---

From: Jason Hullinger <[email-masked]>
Date: Mon, 8 Mar 2010 20:22:57 -0800

If one were to obtain the client id of a partner, under the vanilla
username/password profile, how would a provider prevent non-partners from
connecting to a provider who has implemented this profile?

~/Jason

---

From: David Recordon <[email-masked]>
Date: Mon, 8 Mar 2010 20:37:10 -0800

You wouldn't.  The profile should include the client secret as well in
the initial request.  You could always issue a client a different
secret for use with this profile as well.

--David

---

From: Jason Hullinger <[email-masked]>
Date: Mon, 8 Mar 2010 21:12:29 -0800

In the Spec (as of 0.9.7.2) for 5.3 (Username and Password profile) it say's
to make an HTTPS request using POST with the following parameters:

wrap_client_id (the clients id)
wrap_username (the users username)
wrap_password (the users password)
wrap_scope (optional scope defined by the provider)

Are we talking about the same profile?

~/Jason

On Mon, Mar 8, 2010 at 8:37 PM, David Recordon <[email-masked]> wrote:

> > [email-masked]<[email-masked]>
> .

---

From: David Recordon <[email-masked]>
Date: Mon, 8 Mar 2010 22:33:00 -0800

Yes.  I was agreeing with your point and suggesting that the profile
have the client secret added to the request. :)

On Mon, Mar 8, 2010 at 9:12 PM, Jason Hullinger <[email-masked]> wrote:
>> >> >> This is why the username/password profile is intended for rich
>> >> >> client
>> >> >> apps,

---

From: Jason Hullinger <[email-masked]>
Date: Tue, 9 Mar 2010 00:03:59 -0800

Ah, gotcha, sorry for the misunderstanding. :)

One thing I had thought of to mitigate the risk to the client, or at least
allow the client the ability to see what data is going to be sent to the
provider as "them" would be this: The user connects as 5.3 specifies, upon
success the user is given a token. If the provider and client agree that the
user now has authority to act as though all requests are coming from the
client, the token is an access token. Otherwise, the client is given the
option of being a proxy to all requests. The proxy would be an HTTP post
from server to server in which the requested data would include the token
the user received and the client's id and password. The client would then
have the option of inspecting the data and allowing or denying requests that
will be assumed to be made upon the clients behalf.

I realize that this is probably far more complex than desired. If, however,
it is agreed that there is no way to assure that the client is ever who they
say they are with this profile, at least giving the client the last
authority on what is requested on their behalf could be optionally included.

~/Jason

On Mon, Mar 8, 2010 at 10:33 PM, David Recordon <[email-masked]> wrote:

> >> >> >> downloaded and installed the rich app, popping open a browser is
> not
> >> >> >> going
> >> >> >> to protect the user from a malicious app  for instance, a
> malicious
> >> >> >> app

---

From: Justin Smith <[email-masked]>
Date: Tue, 9 Mar 2010 16:23:42 +0000

Part of the motivation behind that profile was to allow an autonomous client (no end-user identity passed to the AS) the ability to access a web service. In that case, I don't see what the client secret (along with the username and password) would be adding.

Ethan - assuming the token is signed by the authorization server, how can the client add data to it?

---

From: Luke Shepard <[email-masked]>
Date: Tue, 9 Mar 2010 08:29:37 -0800

Can you clarify what you mean by autonomous? Isn't the wrap_username  
an end user identity?

Sent from my iPhone

On Mar 9, 2010, at 8:25 AM, "Justin Smith" <[email-masked]>  
wrote:

> Part of the motivation behind that profile was to allow an  
> autonomous client (no end-user identity passed to the AS) the  
> ability to access a web service. In that case, I don't see what the  
> client secret (along with the username and password) would be adding.
>
>>>> username/password profile, how would a provider prevent non- 
>>>> partners
>>>> from
>>>>> strongly discourage apps from using this profile, and it's  
>>>>> unlikely
>>>>> that
>>>>>>> downloaded and installed the rich app, popping open a browser  
>>>>>>> is not
>>>>>>> going
>>>>>> 3. Mac OS X (users and applications do not run as  
>>>>>> administrators by
>>>>>> default)
>>>>>>

---

From: Brian Eaton <[email-masked]>
Date: Tue, 9 Mar 2010 09:24:30 -0800

> have the client secret added to the request. :)

Just so we're clear on use cases...  is the primary use case here DRM,
verifying software on client machines?

Or do folks want to use this for server-to-server calls?

I am not an expert on DRM, but if we're going to try to do DRM in WRAP
I think we should
a) learn from prior experience
   and
b) get experts involved to write that section of the spec
   and
c) call it out as a separate use case and profile, so that people
don't get confused and misuse the spec in dangerous ways.

Cheers,
Brian

---

From: David Recordon <[email-masked]>
Date: Tue, 9 Mar 2010 09:46:17 -0800

@Justin, there's a separate client key and secret profile for making
requests not within the context of a given user.

@Brain, I'm not focused on using this profile for DRM.  Rather for
trusted devices (ideally with TPM) which do not open web browsers
(such as the XBox).

--David

---

From: Justin Smith <[email-masked]>
Date: Tue, 9 Mar 2010 17:59:08 +0000

Yep - mistake on my part. I the discussion was around section 5.1 and 5.2 on OAuth WRAP v0.9.7.2.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Recordon
Sent: Tuesday, March 09, 2010 9:46 AM
To: [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] [WRAP] Username and Password Profile

--David

---

From: Allen Tom <[email-masked]>
Date: Tue, 09 Mar 2010 10:57:44 -0800

The problem with using a client secret for trusted devices is that these
secrets usually get extracted over time. For obvious reasons, I'd rather not
get into the details, but there are many examples of devices whose secrets
are not secret.

The motivation for deliberately excluding the client secret from the
username/password profile was to prevent having the illusion that clients
can be authenticated.

I personally have no objection to adding a client secret to the
username/password profile, however, as we've seen with OAuth, doing so will
give the illusion that downloadable apps can be authenticated.

Allen

---

From: Brian Eaton <[email-masked]>
Date: Tue, 9 Mar 2010 11:07:42 -0800

> trusted devices (ideally with TPM) which do not open web browsers

That sounds a lot like DRM + hardware support.  And other folks on
this thread have mentioned platforms with no hardware support.

Note that the proposal to use a client secret is not compatible with a
TPM.  To make this work with a TPM you'd need to use public key
cryptography.

Cheers,
Brian

---

From: David Recordon <[email-masked]>
Date: Tue, 9 Mar 2010 12:02:14 -0800

I'd rather support the client secret and document the hell out of the
security considerations for the profile.

---

From: Ethan Jewett <[email-masked]>
Date: Tue, 9 Mar 2010 18:09:16 -0500

Sorry, I jumped the gun on my "related note". I don't think I really
understood what was being discussed. So ... er ... ignore that
suggestion please.

Ethan

---

From: Brian Eaton <[email-masked]>
Date: Tue, 9 Mar 2010 21:32:22 -0800

> security considerations for the profile.

Thinking out loud... what if we called it the "server you trust to use
username and password profile" instead of the client app profile?

That would actually meet the xbox use case, as follows:

1) Microsoft uses magic security sauce to authenticate the xbox to
their servers.
    This magic security sauce will be obscure, will probably change
frequently, and is probably going to rely on hardware security
modules.  It makes no sense to standardize this, because the goal is
specifically to avoid interoperable implementations. =)

2) Their servers hold the client secret, and use it to authenticate to
whatever service they are using for password validation.
    Note that they can actually change this secret, because it is
stored server-side.

I'm sure that people are going to run off and use this profile to
hard-code secrets in their iphone apps, and if the secrets are
important they will be reverse-engineered and abused.  But that's what
happens when you take a profile intended for one kind of deployment
environment and use it in a very, very different environment.

(Also note that the user experience/completion rate for the
browser-redirect flows on thick clients can actually be pretty good.
We've done usability studies, and it works:
http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps.  For
trusted partners you can customize the login and approval screen as
well.)

Cheers,
Brian

---

From: Allen Tom <[email-masked]>
Date: Wed, 10 Mar 2010 08:51:54 -0800

+1

I'd like to keep the existing username/password profile as it currently is,
with the understanding that Service Providers may add additional proprietary
parameters and secret sauce to authenticate the client.

Allen

---

From: Dick Hardt <[email-masked]>
Date: Wed, 10 Mar 2010 08:55:39 -0800

+1

---

From: Luke Shepard <[email-masked]>
Date: Wed, 10 Mar 2010 09:00:32 -0800

That seems reasonable to me. We should make sure to distill this discussion into a "security considerations" section for that profile.