That seems reasonable to me. We should make sure to distill this discussion
into a "security considerations" section for that profile.
On Mar 10, 2010, at 8:55 AM, Dick Hardt wrote:
> +1
>
> On 2010-03-10, at 8:51 AM, Allen Tom wrote:
>
>> +1
>>
>> I'd like to keep the existing username/passw
+1
On 2010-03-10, at 8:51 AM, Allen Tom wrote:
> +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
>
>
> On 3/9/1
+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
On 3/9/10 9:32 PM, "Brian Eaton" wrote:
> On Tue, Mar 9, 2010 at 12:02 PM,
On Tue, Mar 9, 2010 at 12:02 PM, David Recordon wrote:
> I'd rather support the client secret and document the hell out of the
> 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
, how can the
> client add data to it?
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> David Recordon
> Sent: Monday, March 08, 2010 10:33 PM
> To: oauth-wrap...@googlegroups.com
> Cc: oauth@ietf.org
> Subject: Re
I'd rather support the client secret and document the hell out of the
security considerations for the profile.
On Tue, Mar 9, 2010 at 10:57 AM, Allen Tom wrote:
> The problem with using a client secret for trusted devices is that these
> secrets usually get extracted over time. For obvious reason
On Tue, Mar 9, 2010 at 9:46 AM, David Recordon wrote:
> @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).
That sounds a lot like DRM + hardware support. And other folks on
this thread have
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 secr
@ietf.org
Subject: Re: [OAUTH-WG] [WRAP] Username and Password Profile
@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
@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
On Tue, Mar 9, 20
On Mon, Mar 8, 2010 at 10:33 PM, David Recordon wrote:
> Yes. I was agreeing with your point and suggesting that the profile
> 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 folk
;
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> Behalf Of David Recordon
> Sent: Monday, March 08, 2010 10:33 PM
> To: oauth-wrap...@googlegroups.com
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] [WRAP] Username and Password Pro
TH-WG] [WRAP] Username and Password Profile
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 wrote:
> In the Spec (as of 0.9.7.2) for 5.3 (Username and Password profile) it sa
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
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 wrote:
> 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
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)
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
On Mon, Mar 8, 2010 at 8:22 PM, Jason Hullinger wrote:
> If one were to obtain the client id of a partner, un
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
On Mon, Mar 8, 2010 at 8:01 PM, Allen Tom wrote:
> Hi Ethan -
>
> In Yahoo's case, we
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 t
On Sun, Mar 7, 2010 at 10:25 PM, Allen Tom wrote:
> 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
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
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" wrote:
>
> However, for rich apps, requiring the app to
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 th
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
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) --
+ietf list
On Mar 4, 2010, at 8:16 PM, Jason Hullinger 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 protoco
26 matches
Mail list logo
