How about:
'The verification code received from the Consumer is has been verified'
EHL
From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Dirk
Balfanz
Sent: Wednesday, May 06, 2009 7:18 PM
To: oauth@googlegroups.com
Subject: [oauth] Re: OAuth Core 1.0 Rev A, Draft 2
On
James, thanks for adding the proposal and offering deeper insight into its
details. I would like to ask you to add it to the wiki page so we have it
documented.
I would like to ask people if they have strong views for or against this
proposal. So far a few people raised concerns which James tri
Thanks for the note, Eve, and for receiving the award on our behalf!
Is there anything else we should know about the award?
Chris
On Wed, May 6, 2009 at 8:20 PM, Eve Maler wrote:
>
> Congrats to the entire OAuth community! OAuth won an award for "best
> new/improved standard in IAM & GRC" (tha
Brian,
There are two attacks: attacker gets victim's access; and login CSRF.
They are distinct attacks, causing different damage, and with different
defences -- but they are both sort of related to session fixation.
Consequently, I find the term "session fixation" a bit ambiguous in these
disc
On Tue, May 5, 2009 at 11:49 PM, Eran Hammer-Lahav wrote:
> Can you live with the current language or do you still want to see it
> change?
>
>
Well I think the language is broken, but in the grand scheme of things I
think I'll live.
Dirk.
>
>
> EHL
>
>
>
> *From:* oauth@googlegroups.com [mail
On May 6, 2009, at 5:28 PM, Allen Tom wrote:
> Brian Eaton wrote:
>> Use case is consumers and service providers trying to transition to
>> OAuth 1.0a in parallel without creating down time or needing to "all
>> hold hands and jump together".
>
> I still don't quite see the problem. If the issue
I agree, the consumer should be informed whether the service provider
is 1.0 or 1.0a, before it redirects the user for authorization. In
addition to the reasons noted above, it enables a consumer to protect
the user from the security hole in 1.0, by refusing to work with a 1.0
service provider.
-
Brian Eaton wrote:
>
> Use case is consumers and service providers trying to transition to
> OAuth 1.0a in parallel without creating down time or needing to "all
> hold hands and jump together".
I still don't quite see the problem. If the issue that that the Consumer
doesn't know if the SP suppo
Yahoo only prompts for the password (the username is prefilled) if the
user already is signed into Yahoo when doing the OAuth dance.
Allen
Stephane Daury wrote:
> Unless I missed something, Yahoo (and I think Google) only prompts for
> the password when a session is already active, displaying
Eran,
As I and many others have already mentioned, CSRF/XSRF attacks are
especially well suited for attacking OAuth and should most certainly
be mentioned Security Consideration portion.
I would like to propose the following language:
Cross-Site Request Forgery (CSRF) Attacks
Cross-Site Reques
On Wed, May 6, 2009 at 9:54 AM, Eran Hammer-Lahav wrote:
>
> No. That's what we are discussing... the need to add something like that.
While it is true that the absence of a discovery system does make it less
critical for a consumer to be able to automatically detect the new flow, it
still appea
We have identified a few new attack vectors since the spec was originally
written and would like to address them in the Security Consideration section.
Please reply with proposals for such texts. Ideally we can reach some consensus
on these by Fri, but if not, we can add it a bit later since it
Congrats to the entire OAuth community! OAuth won an award for "best
new/improved standard in IAM & GRC" (that's "identity and access
management" and "governance, risk, and compliance"). If you're
curious what this conference and the awards are all about, people have
been tweeting it pre
On Tue, May 5, 2009 at 9:34 PM, Manger, James H
wrote:
> I would prefer to fix OAuth security issue 2009-1 without unnecessarily
> preventing
> state-management options that previously worked, and without requiring
> cookies where
> they were not previously necessary.
I'm pretty sure that any
No. That's what we are discussing... the need to add something like that.
EHL
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Jonathan Sergent
> Sent: Wednesday, May 06, 2009 9:48 AM
> To: oauth@googlegroups.com
> Subject: [oauth] Re: OA
The callback_accepted parameter isn't part of the draft spec, is it?
On Wed, May 6, 2009 at 9:40 AM, John Kemp wrote:
>
> On May 6, 2009, at 11:49 AM, Brian Eaton wrote:
>
> [...]
>
>> However, existing clients have hardcoded callback URLs on their
>> approval URLs. If the consumer code can det
On May 6, 2009, at 11:49 AM, Brian Eaton wrote:
[...]
> However, existing clients have hardcoded callback URLs on their
> approval URLs. If the consumer code can detect that the service
> provider supports OAuth 1.0a, it can automatically correct that
> problem by stripping the callback URL off
Not trying to play down your use case but I think this would be limited to
Shindig (and OpenSocial implementations).
So your idea is for the client to always try 1.0a first, and if the server
returns an error or does not acknowledge the callback parameter, to fallback to
1.0?
EHL
> -Orig
On Tue, May 5, 2009 at 10:43 PM, Eran Hammer-Lahav wrote:
> This seems to suggest the client needs a way to detect which version the
> server
> is using. How about check the documentation? We don't have discovery yet which
> is going to solve the flow versioning problem. I am not sure what use c
Just checked in Tweetdeck and @Oauth still works, it's just the URL
that is b0rked.
Tane Piper
http://digitalspaghetti.me.uk - Blog
http://learningandroid.org - Learning Android
email/gtalk: t...@digitalspaghetti.me.uk
mobile: +447815 101802
twitter: http://twitter.com/tanepiper
This email is:
Hey,
Just in passing I was on the site and I wanted to make sure I was
following the OAuth twitter when I saw the link on the Google Code
site.
But it looks like Twitter, rather than check that OAuth had an
account, have taken the URL for themselves for their own service.
Now going to http://tw
Unless I missed something, Yahoo (and I think Google) only prompts for
the password when a session is already active, displaying the username
instead of giving the user a form field to fill.
A phisher would have the hardest time doing that (if at all).
But I do see your point.
Stephane
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Manger, James H
> Sent: Wednesday, May 06, 2009 12:23 AM
> Scalability of consumers should have been part of the protocol design,
> even if only implicitly, because scalability is a general c
> 1. The ability to encode the request token and secret into the callback
> for client statelessness was not part of the protocol design. It is a nice
> side-effect at best.
There have been lots and lots of discussions about scalability and stateless
operation in OAuth. It has mostly been about e
24 matches
Mail list logo
