I agree with your statements below. I would remove the CAPTCHA concept
from the document.
Ciao
Hannes
>-Original Message-
>From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
>On Behalf Of ext David Recordon
>Sent: 09 March, 2010 06:54
>To: OAuth WG
>Subject: [OAUTH-WG] The ver
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)
I'm spending some time with the spec this evening and am having a hard time
understanding the need for the verification URL and CAPTCHA responses which are
part of the username and password profile.
My criteria for using this profile is that 1) the authorization server
generally trusts the clie
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
Though not of course the body of a POST, unless it is form encoded
data, which merely pushes the problem of canonicalization (and thus
interoperability) outside the spec.
On Monday, March 8, 2010, Dick Hardt wrote:
>
> On 2010-03-08, at 6:39 PM, Ethan Jewett wrote:
>
>> Request hijacking: I actua
On 2010-03-08, at 6:39 PM, Ethan Jewett wrote:
> Request hijacking: I actually significantly understated the protection
> against request hijacking that that the HMAC-SHA1 method of OAuth 1.0a
> provides. In the worst case, a MITM can hijack a request but cannot
> change the request method, URL,
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
I'm glad I managed to prompt some discussion on the topic!
In order to avoid responding to several individual messages in this
thread, I'll compile points:
Use cases: The request was for use cases where signatures a la OAuth
1.0a might be required. I've tried to provide some, along with
reasoning
On 2010-03-05, at 6:57 AM, Eve Maler wrote:
> More below...
>
> On 4 Mar 2010, at 5:43 PM, Dick Hardt wrote:
>
>> Thanks Eve, comments inserted ...
>>
>> On 2010-03-04, at 12:51 PM, Eve Maler wrote:
>>
>>> As requested on today's call, here's a description of the places where UMA
>>> seems
On 2010-03-08, at 1:09 PM, John Kemp wrote:
>
> On Mar 8, 2010, at 3:35 PM, Dick Hardt wrote:
>>
>>
>> 2) Client signed tokens are no more secure in MITM attacks than bearer
>> tokens for on-the-fly attacks. If the attacker can disrupt the channel, the
>> attacker can take the signed token a
On Mar 8, 2010, at 3:35 PM, Dick Hardt wrote:
>
>
> 2) Client signed tokens are no more secure in MITM attacks than bearer tokens
> for on-the-fly attacks. If the attacker can disrupt the channel, the attacker
> can take the signed token and use it to make a valid call just as if it was a
> b
Dick Hardt wrote:
2) Client signed tokens are no more secure in MITM attacks than bearer tokens for on-the-fly attacks. If the attacker can disrupt the channel, the attacker can take the signed token and use it to make a valid call just as if it was a bearer token.
I don't understand. How wil
On 2010-03-07, at 12:13 PM, Ethan Jewett wrote:
> My point is only that bearer-tokens over an insecure channel seem to
> be always *less* secure or *as* secure (but never *more* secure) than
> using a signature approach over an insecure channel. As such, I'm
> uncomfortable taking away an existin
Hi Brian,
On Mon, Mar 8, 2010 at 8:46 PM, Brian Eaton wrote:
> On Mon, Mar 8, 2010 at 11:21 AM, Jochen Hiller
> wrote:
> > The
> > required time has been reduced about 1 sec (exact time depends on device
> and
> > hardware capabilities), resulting in absolute processing times in range
> of
> >
On Mon, Mar 8, 2010 at 11:21 AM, Jochen Hiller wrote:
> The
> required time has been reduced about 1 sec (exact time depends on device and
> hardware capabilities), resulting in absolute processing times in range of
> about 100-200 ms, not seconds (depends mainly on server and token
> requirements
On Mon, Mar 8, 2010 at 6:58 PM, John Panzer wrote:
> On Mon, Mar 8, 2010 at 5:38 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> ...
>>>
>>> 1. Connection latency to bootstrap the connection (from the
>>> asymmetric/public-key encryption operations)
>>>
>>
>> Bootstrapping a SSL
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
On Mon, Mar 8, 2010 at 5:38 AM, Torsten Lodderstedt wrote:
> ...
>> 1. Connection latency to bootstrap the connection (from the
>> asymmetric/public-key encryption operations)
>>
>
> Bootstrapping a SSL sessions is expensive. But every session can be
> used for multiple HTTPS-Connections. Thus an
Hi Ethan,
The most important and unavoidable tradeoff is performance. The
IMHO the comparison is asymmetric. You compare SSL, which offers
various security
measures, with just signatures on plain HTTP requests. Sure, validating a
(HMAC) signature is cheap, but signatures only give you sen
I would like to add another use case:
In the "How to get a token" scenario, usage of public key consumer
authentication would require to use signatures in order to prove
private key ownership.
___
OAuth mailing list
OAuth@ietf.org
https://www.ie
Just a reminder that the deadline for submitting Internet-Drafts before
Anaheim occurs about 12 hours from now.
http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
___
I've added a use case page and a terminology comparison table to the tools
wiki. The latter needs some review, given the differences between Oauth 1.0a,
draft-oauth, and WRAP.
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthTerms
Wolfgang
--
Deutsche Telekom Netzproduktion GmbH
Zentrum Te
26 matches
Mail list logo
