On Mon, Nov 9, 2009 at 2:53 PM, Roy Smith wrote:
> Thanks for the suggestions. My problem (and from reading the groups, other
> people's too) is just where to start.
> I've looked at OpenSocial but all I find is stuff about Myspace and reading
> friends lists.
> I'm happy to take my question ther
On Sat, Nov 7, 2009 at 10:57 AM, Roy wrote:
> Having tried all the alternatives, I figured that OAuth is probably
> the answer, but I am really struggling to get a toe hold on the
> technology. In particular I really can't figure out what the different
> roles of the actors are, and eg. is my req
On Sun, Nov 8, 2009 at 3:23 PM, Paul Madsen wrote:
> FYI, we had an initial discussion of possibilities for a 'SAML & OAuth
> Hybrid' at last week's IIW.
Thanks for sending out this slide deck, Paul. I wanted to go to this
session but missed it.
One question about use cases... today most SAML
On Wed, Nov 4, 2009 at 10:06 AM, Paul Walker wrote:
> I would like a user to be able to select a file in a HTML form and input the
> SHA-1 hash of the file body only and have this request come across according
> to the spec (hidden inputs would contain the necessary oauth_ parameters).
Whoa. Th
I'd be willing to take it on so long as someone else also volunteers.
On Mon, Nov 2, 2009 at 7:47 PM, Eran Hammer-Lahav wrote:
>
> Over the past year I have been moderating all new posts from new members.
> Once the first post is approved, the member can go and post freely without
> any modera
On Wed, Sep 16, 2009 at 4:12 PM, Hans Granqvist wrote:
>
> BTW, this sentence in
> http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oauth-bodyhash.html#when_to_include
>
> "
> # OAuth Consumers MUST NOT include an oauth_body_hash parameter on
> requests with form-encoded request bodies.
>
On Wed, Sep 16, 2009 at 4:06 PM, Hans Granqvist wrote:
> We're going live with some new PUT-based APIs. The body is not name/value
> pairs and thus not application/x-www-form-urlencoded.
>
> Can anybody shed some light on the status of
> http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oaut
On Wed, Aug 19, 2009 at 4:01 AM, Carl H. wrote:
> I am currently working on an OAuth provider for Android. As such any
> application could use the OAuth application across the device
> ecosystem. The idea would be that the OAuth application has already
> been authorized to a majority of OAuth enab
On Fri, Aug 14, 2009 at 12:44 PM, Mike Malone wrote:
> Seth, I actually think that enforcing nonces should make this attack
> impossible for guessing OAuth signatures (assuming you enforce nonces
> for malformed requests). If you can only get a good/bad response once
> then you're out of luck.
Ag
On Sun, Jul 5, 2009 at 11:47 PM, jaswinder
singh wrote:
> I have a oAuth provider (sparklr) and I want to access it through the
> gaget I added in igoogle,
Doc is here: http://code.google.com/apis/gadgets/docs/oauth.html
Cheers,
Brian
--~--~-~--~~~---~--~~
You re
On Mon, Jun 8, 2009 at 8:37 AM, Blaine Cook wrote:
> FWIW, the approach of using your server to sign requests for a flex
> app ultimately (though probably not in practice) has exactly the same
> effect as distributing those consumer keys in plain text, except that
> you need to do the signature w
On Tue, Jun 2, 2009 at 1:28 PM, Justin Richer wrote:
> What would the callback url be? A web server run locally by the app
> itself? A web site about the app? You can definitely do it, but I'd
> argue that most desktop apps have nothing to call back *to*, since by
> their nature they're off-brows
Hi Justin -
Nice, thoughtful e-mail. A few questions inline.
On Wed, May 27, 2009 at 10:46 AM, Justin Richer wrote:
> Whatever keywords are chosen to fill the role [of identifying desktop apps],
> this set
> would have an implicit callback URL of "oob"
You lost me here. Lots of desktop apps
On Fri, May 29, 2009 at 5:25 PM, Andrew Arnott wrote:
> I don't think the spec addresses the question at all, but my reading from
> section 5.2 suggests that no parameters in the POST entity should be signed
> unless the content type is application/x-www-form-urlencoded, which means
> that parame
On Thu, May 28, 2009 at 3:42 PM, jr conlin wrote:
>
> Nathan Beach wrote:
>> Google has enhanced our OAuth approval flow to significantly improve
>> the user experience for installed applications that use OAuth to
>> access our GData APIs.
> Perhaps I'm missing something, but doesn't this kinda s
On Thu, May 28, 2009 at 11:18 AM, Johannes Ernst
wrote:
> Any thoughts on how oauth could work for various command-line tools
> that today usually need a username and password?
> Perhaps even the mysql client?
>
> Or even better, anybody working on this?
Yep:
- http://sites.google.com/site/oauth
Some discussion about various SP behaviors happened here:
http://www.mail-archive.com/oauth@googlegroups.com/msg2.html.
In general SP behavior on resource requests is out of scope for the
OAuth spec. It's the Wild Wild Web.
On Thu, May 14, 2009 at 2:55 AM, Jack wrote:
> The specifications
On Thu, May 14, 2009 at 2:45 AM, Jack wrote:
> 1) How would the consumer know what spec is used on the service
> provider? i.e. should it throw an exception if the
> oauth_callback_confirmed is missing or set to anything but "true" ?
If the SP does not return oauth_callback_confirmed=true, the c
On Tue, May 12, 2009 at 2:17 PM, Eran Hammer-Lahav wrote:
>> Alternatively, we should give consumers a way to detect SP version, by
>> having the SP return oauth_callback_accepted=1 in the request token
>> response. I think this might be a better answer.
>
> We need to reach quick consensus on t
;> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>> Of Brian Eaton
>> Sent: Monday, May 11, 2009 1:41 PM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: Request for new Security Considerations text
>>
>>
>> Wikipedia is about as for
e your reference to [1]?
>
> EHL
>
>> -Original Message-
>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>> Of Brian Eaton
>> Sent: Monday, May 11, 2009 12:59 PM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: Request
e-
>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>> Of Brian Eaton
>> Sent: Monday, May 11, 2009 11:52 AM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: Request for new Security Considerations text
>>
>>
>> There were two ot
?
>
> EHL
>
>> -Original Message-
>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>> Of Brian Eaton
>> Sent: Friday, May 08, 2009 3:39 PM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: Request for new Security Consi
On Fri, May 8, 2009 at 5:31 PM, Manish Pandit wrote:
> However, when it comes to web based
> consumers with callbacks, even with the oauth_verifier, the process
> ends up linking the good guy with the bad guy's request token at the
> provider.
Sweet. Last time somebody said this it was late on
ntion at all OAuth endpoints.
>
> CSRF attacks on OAuth callback URLs hosted by Consumers are also
> possible. Consumers should prevent CSRF attacks on OAuth callback URLs
> by verifying that the user at the consumer site intended to complete
> the OAuth negotiation with the servic
On Fri, May 8, 2009 at 3:16 PM, Darren Bounds wrote:
> While that's nice to have, I do not believe it's necessary to foil the
> attack. Acting purely on the identity of the user completes the OAuth
> dance is enough and can still be considered a secure consumer
> implementation.
Not unless there
is the same
> entity who completes it.
>
>
>
> On Fri, May 8, 2009 at 3:11 PM, Brian Eaton wrote:
>>
>> [trimmed a bit of language that seemed redundant, added a bit to
>> explain about attacks on the OAuth callback, but I don't really love
>> the sente
ces:
> http://en.wikipedia.org/wiki/Cross-site_request_forgery
> http://www.owasp.org/index.php/Cross-Site_Request_Forgery
>
>
> On Fri, May 8, 2009 at 2:52 PM, Brian Eaton wrote:
>>
>> Consumers should XSRF protect the callback process.
>> [assuming others will fill
Consumers should XSRF protect the callback process.
[assuming others will fill in detail here]
Service providers should XSRF protect the approval process.
[assuming others will fill in detail here]
[I really don't think we should recommend particular XSRF prevention
mechanisms, because that's an
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
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
On Tue, May 5, 2009 at 5:54 PM, Manger, James H
wrote:
> The Consumer App includes the Callback URI when obtaining an Access Token,
> instead of including the Callback URI when obtaining a Request Token.
>
> The Service Provider checks that the Callback URI in the request for an
> Access Token ma
On Tue, May 5, 2009 at 7:15 PM, Josh Roesslein wrote:
> We would either have to increment the wire version OR the SP would have to
> use different end points for the two flows.
WTF? No.
Just pass *one* extra bit of data in the request token step "do you
support callback tokens?" and get back *
AFAICT there is no difference in the amount of state consumers need to
maintain between OAuth 1.0, the signed callback proposal, and the
approval URL verification proposal. There may be some good reason to
prefer either signed callbacks or approval URL verification, but I
don't think consumer sta
The attack fails.
On Tue, May 5, 2009 at 6:08 PM, Owen Evans wrote:
> Doesn't really solve the problem:
> (malicious) User A gets the "Authorisation URL" from an application that
> has received a request token.
> User A replaces call-back parameter with malicious or spoof site instead of
> origi
Line 837:
"to indicates"
s.b.
"to indicate"
Section 6.2:
Consumers that need to maintain compatibility with both 1.0 and 1.0a
service providers are going to send oauth_callback on this step. We
should be explicit about how to handle backwards compatibility here or
we are going to end up with i
:oa...@googlegroups.com] On Behalf
>> Of Brian Eaton
>> Sent: Monday, May 04, 2009 11:22 AM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: Security Fix Charter
>>
>>
>> On Mon, May 4, 2009 at 11:14 AM, Eran Hammer-Lahav
>> wrote:
>> >
On Mon, May 4, 2009 at 11:14 AM, Eran Hammer-Lahav wrote:
>
> Clients are always limited to what the server decides to support. If a server
> only supports 1.0a, the client has no other options. So as long as servers
> support both versions, clients will be able to use both versions... or am
> I
On Mon, May 4, 2009 at 11:07 AM, Eran Hammer-Lahav wrote:
>> I think there should be a 6th charter item: allow consumers to support
>> both the broken and the fixed protocols.
>
> You mean #4?
I read #4 as "service providers", so long as it includes consumers I'm
good with it.
>> This will requ
On Mon, May 4, 2009 at 9:40 AM, Eran Hammer-Lahav wrote:
> The charter for this work is:
>
> 1. Fully address the security hole identified in the OAuth Core 1.0
> specification
> 2. Provide a solution in the form of a new specification in a short period of
> time (2-4 weeks)
> 3. Narrowly addre
On Fri, May 1, 2009 at 1:25 AM, Blaine Cook wrote:
> 1. "1.0 Rev A" with no version string change (i.e., oauth_version=1.0)
> 2. "1.0a" (with oauth_version=1.0a)
> 3. "1.1"
Option 1. Version string should not change unless we hate developers.
--~--~-~--~~~---~--~---
On Fri, May 1, 2009 at 1:43 AM, Blaine Cook wrote:
> 1. None. Applications that cannot receive callbacks (or that have
> static callback endpoints) should be configured as such in an
> out-of-band flow, along with the service provider issues the consumer
> key and secret.
Just because the callba
On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein wrote:
> Here is some pseudo python code of what I have in mind for a more higher
> level library: http://pastie.org/464241
This is similar to an API we put together for gadgets:
http://code.google.com/apis/gadgets/docs/oauth.html
http://wiki.ope
On Wed, Apr 29, 2009 at 2:23 PM, John Kemp wrote:
> The oauth_verifier is to be linked by the SP to the request token and
> the consumer key. So this ensures that the consumer is the same
> consumer which applied for the request token on behalf of the user-
> agent which is being led around all o
Thanks for the feedback.
On Wed, Apr 29, 2009 at 11:35 AM, John Kemp wrote:
> Nit: this checklist would be a bit less confusing if the order for
> each item remained constant (item 2 of the comparison has 'approval'
> and 'callback' in a different order than the other items).
Fixed.
> i) It se
On Wed, Apr 29, 2009 at 5:58 AM, Dossy Shiobara wrote:
>
> On 4/29/09 4:17 AM, Blaine Cook wrote:
>> What if, in the case of "Login with Twitter", the "identity" of the
>> user logging in is a random cookie string?
>
> As long as it's random every time - i.e., a nonce.
Nit: nonce is probably not
Are you proposing this for the existing protocol, or for a fixed version?
For the existing protocol, seems reasonable.
For the fixed version, we need to take into considerations cases where
a user needs to manually type the callback token and they make a
mistake: http://groups.google.com/group/o
On Tue, Apr 28, 2009 at 11:00 AM, John Kemp wrote:
> All of these protocols are for Web-browser based SSO, and establish
> the trust between the consumer and SP (using the OAuth terminology) by
> relying on Web-browser technologies (ie. an HTTP redirect sent through
> the user's browser assures t
On Tue, Apr 28, 2009 at 7:32 AM, Dossy Shiobara wrote:
> And yes, making request tokens one-time only is a MUST, IMHO.
This is a terrible idea for consumers that can't receive callback
URLs. For those consumers users are going to have to manually type in
a callback token. There will be typos.
On Mon, Apr 27, 2009 at 8:25 PM, pkeane wrote:
> I'm happy with OAuth for the typical sorts of social networking,
> photo-sharing, etc. use cases, and I use it for that. But I'd very
> much like to be able recommend it for more highly secure scenarios
> here on campus (I work in higher ed) that
On Sun, Apr 26, 2009 at 6:29 PM, Peter Keane wrote:
>> b) that's what the unpredictable callback token is for.
>
> Does that demonstrate it is the same user? I believe it makes it
> highly likely, but not "verifyable" (in standard authentication terms.
> Nothing is 100% verifyable).
The request
On Sun, Apr 26, 2009 at 11:42 AM, pkeane wrote:
> I would just mention that this proposal (essentially making the
> callback url immutable)
a) that proposal does not make the callback URL "immutable".
Consumers and SPs can both mess with it. It just makes sure the user
at the browser doesn't me
On Sun, Apr 26, 2009 at 11:14 AM, Dossy Shiobara wrote:
>> Open questions:
>>
>> 1. Am I missing a completely different alternative? If yes, please
>> create a new wiki page and point to it (if you don't have access ask
>> or email it to someone who does).
>
> Requiring SP to authenticate user _b
On Sat, Apr 25, 2009 at 1:33 PM, Jonathan Sergent wrote:
> (These names are a bit unfortunate - the callback URL gets signed in
> either case, just as part of a different request.)
I agree, just couldn't think of anything better.
--~--~-~--~~~---~--~~
You receive
On Sat, Apr 25, 2009 at 1:35 PM, Josh Roesslein wrote:
> Plus we can require that you only get once try to swap the callback for an
> access token. After that it is invalidated and no longer useful.
You can't actually do that in the flow you proposed. In order to
limit the number of attempts yo
On Sat, Apr 25, 2009 at 1:04 PM, Brian Eaton wrote:
> On Sat, Apr 25, 2009 at 12:26 PM, Josh Roesslein wrote:
>> Thanks for posting that Brian.
>>
>> I'm leaning towards signed approval URLs. Seems the best way to go IMO.
>> Seems to solve the issues and al
On Sat, Apr 25, 2009 at 1:19 PM, Josh Roesslein wrote:
> Yes we would need a way to still allow for manually providing these device
> the callback token.
>
> The user can directly visit an authorization URL since their will be no
> callback.
> Example: http://service.example.com/authorize/testcon
On Sat, Apr 25, 2009 at 1:11 PM, J. Adam Moore wrote:
> The problem itself is REALLY
> specific: Phishing. Like fish in a barrel phishing. The solution is to
> take away their bullets, and is not to try and harden the barrels or
> educate the fish to dodge bullets.
The problem is very similar to
On Sat, Apr 25, 2009 at 12:26 PM, Josh Roesslein wrote:
> Thanks for posting that Brian.
>
> I'm leaning towards signed approval URLs. Seems the best way to go IMO.
> Seems to solve the issues and also helps simplify the OAuth flow.
The major pain point of signed approval URLs is that we would l
On Sat, Apr 25, 2009 at 10:46 AM, Chris Messina wrote:
> I'd like to point out that anyone can organize one of these events wherever
> they are — this need not happen in the Bay Area exclusively!
We had a meeting in Mountain View on Friday, our notes are here:
https://oauth.pbwiki.com/OAuth-Sess
No, we haven't, and in fact we can't with the protocol as it stands
today. Please go read Eran's blog post explaining the attack:
http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html#more
On Fri, Apr 24, 2009 at 9:30 AM, Zachary Voase
wrote:
>
> But we
On Thu, Apr 23, 2009 at 6:16 PM, Dossy Shiobara wrote:
> I won't go into those details until a reasonable fix is available. :-)
The details are on Eran's blog.
>> 1) Keep using OAuth 1.0.
>> SPs can tell users that they are authorizing an application on
>> their desktop. There is some ris
On Thu, Apr 23, 2009 at 5:57 PM, Dossy Shiobara wrote:
> Alice (attacker) and Bob (victim).
The current version of the protocol is susceptible to a very similar
attack for web applications, which is why people are so upset and
working on a fix.
For desktop apps, it's hard to do better, and ev
On Thu, Apr 23, 2009 at 5:35 PM, Dossy Shiobara wrote:
>
> On 4/23/09 8:30 PM, Brian Eaton wrote:
>> Malicious software on the user's computer does not need to steal
>> access tokens. It steals passwords, bank account numbers, and
>> confidential documents.
&g
On Thu, Apr 23, 2009 at 3:54 PM, Dossy Shiobara wrote:
> If the consumer is a desktop app., then the attacker has access to the
> token secret through application memory inspection.
Malicious software on the user's computer does not need to steal
access tokens. It steals passwords, bank account
On Thu, Apr 23, 2009 at 12:10 PM, Mike Malone wrote:
> Er, right. Sorry. I was thinking of the Netflix style case. You're right,
> for many Desktop apps manual entry of the request token key is not required.
>
> I wrote the Pownce iPhone app. It used the web application token exchange
> flow by r
On Thu, Apr 23, 2009 at 11:54 AM, Mike Malone wrote:
> In the manual case the user is already typing the request token key
> manually.
The manual case is not a good user experience, and it isn't necessary
for the vast majority of installed applications:
https://sites.google.com/site/oauthgoog/UX
On Thu, Apr 23, 2009 at 11:46 AM, Mike Malone wrote:
> The other difference is that it seems you're not issuing a callback token
> for the manual case, where there's no callback URL. I think you need a
> callback token either way. There's still a timing attack for the manual case
> because the at
y differ though.
>
>
> James Manger
> james.h.man...@team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
>
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of
> Brian Eaton
> Sent: Friday,
t;
> Can this wait until v.NEXT? This didn't really go through the v0.9 process
> I'd rather not open the door for out-of-band proposals now.
>
> -Lane
>
> On Thu, Apr 2, 2009 at 6:11 PM, Brian Eaton wrote:
>
> [+oauth mailing list]
>
> Seems like the r
[+oauth mailing list]
Seems like the right thing to do.
I'm going to declare
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/8/draft-eaton-oauth-bodyhash.html
final tomorrow.
Changes since the last revision:
- omit oauth_body_hash on all request token and access token requests;
th
While reading Eran's recent blog post [1] about clarifying certain
requirements for OAuth service providers I remembered an old
discussion about whether xoauth* parameters should be allowed to go in
the Authorization header. As far as I can tell, the letter of the
spec says they shouldn't. The s
On Tue, Mar 31, 2009 at 10:31 PM, wrote:
> Sorry I'm not familiar with the MySpace service provider.
I am familiar with the MySpace service provider, and I haven't seen it
require anything like putting oauth parameters in the request body.
Their testing tool doesn't even support that option:
h
at 7:00 PM, Zhihong wrote:
>
> The spec must have been changed. This sentence sounds correct to me,
>
> The Consumer SHALL then generate a Nonce value that is unique for
> all requests with that timestamp.
>
> Thanks!
>
> Zhihong
> On Mar 26, 5:48 pm, Brian Eaton w
On Thu, Mar 26, 2009 at 2:22 PM, Zhihong wrote:
> We can't afford to ignore nonce. Timestamp can't prevent replay. We
> allow clock skew up to 1 min so there is a 2-min window, in which the
> message can be replayed. This is a risk we don't want to take.
OK, this is challenging then. I think yo
Check that the timestamp is recent. Ignore the nonce.
The nonce checking language in the OAuth spec is fundamentally broken,
it requires infinite server-side storage.
On Thu, Mar 26, 2009 at 7:29 AM, Zhihong wrote:
>
> Our system is geo-distributed and all our traffic is localized, until
> we
http://codereview.appspot.com/28042/show
http://codereview.appspot.com/28075/show
Cheers,
Brian
On Wed, Mar 18, 2009 at 9:26 AM, Brian Eaton wrote:
> Yes, we're pushing this to be an optional, backwards-compatible, part
> of the OAuth specification. I've gotten good feedbac
gt; -Original Message-
> From: opensocial-and-gadgets-s...@googlegroups.com
> [mailto:opensocial-and-gadgets-s...@googlegroups.com] On Behalf Of Brian
> Eaton
> Sent: Thursday, March 12, 2009 9:29 AM
> To: oauth@googlegroups.com; oauth-extensi...@googlegroups.com;
>
Hi folks -
I've neglected the body signing specification for a few months and I'd
like to wrap it up. A fresh draft is here:
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/3/spec.html
Changes:
- language cleaned up to be more precise
- more detailed example
Things that have not
On Tue, Mar 10, 2009 at 6:02 AM, Marc Worrell wrote:
> And keeping it simple might mean transcoding all your UTF-whatever
> into an octet stream before pushing it into your transport-layer-with-
> oauth-signing.
>
> Which makes it completely according to the specs, but without the
> complications
Ah, I totally forgot about the whole "consumer key" nomenclature.
It would make me incredibly happy if OAuth talked about "consumer
name" and "consumer secret", because crypto geeks and others tend to
think that "keys" are secrets. The OAuth consumer key is not secret,
thus leading to confusion.
On Fri, Feb 27, 2009 at 11:36 AM, rawc wrote:
> I don't see a huge problem with the 'request token' phrasing
> (especially since it is clearly described in the spec) and
> 'intermediate token' probably wouldn't make things any more clear as
> to the function of the token. If it was changed, thou
On Tue, Feb 24, 2009 at 3:25 PM, Eran Hammer-Lahav wrote:
> Please reply to this thread so we have a public inventory of OAuth FAILs.
The nonce and timestamp checking language in the OAuth core spec would
require infinite storage to implement. It should be removed entirely
or rephrased to somet
Hey John -
A while back I needed to tack OAuth support on to a general purpose
HTTP client API. The goals were two-fold:
1) Do magic whenever possible. Request token and access token
requests happen under the covers. Adding the session extension
support was magic, it required no changes to ca
On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist wrote:
> Sometimes I feel like we (people who have interest in the two concepts)
> maintain there is a difference to justify standards' existence, even if
> it's largely an academic difference with no pragmatic real meaning.
There are good reasons
On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher wrote:
> The request is only valid if the receiving
> authentication system can generate the signature using the password for
> that user.
Lots of authentication servers can't do that, because they do not keep
a clear-text version of the user's pa
On Sun, Jan 4, 2009 at 6:12 AM, Mads Mayntz Kierulff
wrote:
> There
> are two alternatives that we've found: either run all our gadgets in
> Shindig, and then somehow authenticate against Google and run their
> gadgets in our Shindig site OR use iGoogle as a container and
> authenticate against o
On Fri, Dec 12, 2008 at 11:12 AM, Sam Quigley wrote:
> I'm just sort of curious -- what are the use-cases where body signing
> makes sense, but where SSL doesn't? It seems like this is almost
> exactly the same as Oauth-over-SSL, where the SSL uses the NULL
> encryption algorithm and the SHA1 MA
On Thu, Dec 11, 2008 at 5:35 PM, Krishna Sankar (ksankar)
wrote:
>a) Header signing? Yes/No. I assume Yes - from your last
> e-mail. If not we should continue that thread .
>b) Assuming yes for #1 above, SP selects headers to sign.
> Yes/No. I assume No and that the spec
that,
> the optional parameters would be very popular)
>
>Agreed on minimal normalization.
>
>I also want the HMAC-AES as one of the mechanisms, but haven't
> worked through the analysis of the bootstrap and the MEPs to make a
> definite pitch for that fe
reasonable?
On Tue, Dec 9, 2008 at 11:54 AM, John Hayes <[EMAIL PROTECTED]> wrote:
> Inline:
>
> On Tue, Dec 9, 2008 at 10:51 AM, Brian Eaton <[EMAIL PROTECTED]> wrote:
>>
>> [+marcw]
>>
>> Thanks for the feedback.
>>
>> On Tue, Dec 9, 2008 a
On Tue, Dec 9, 2008 at 10:37 PM, Manger, James H
<[EMAIL PROTECTED]> wrote:
>> Anybody have a real web app that relies on the integrity
>> of content headers for security?
>
> There have been various attacks using the UTF-7 charset (eg an XSS attack
> against Google in 2005). The attack works whe
On Tue, Dec 9, 2008 at 6:50 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
>> Anybody have a real web app that relies on the integrity of content
>> headers for security?
>
> Not that it applies to the OS use case, but wouldn't anything that relies on
> cookies qualify?
Most web apps rely on the conf
On Tue, Dec 9, 2008 at 5:52 PM, Krishna Sankar (ksankar)
<[EMAIL PROTECTED]> wrote:
> Have been watching this discussion. Something is puzzling me - the spec
> [1] talks about integrity of the body nothing else. The only thing it
> says is that the body has not been altered since it left the consu
On Tue, Dec 9, 2008 at 12:13 PM, Marc Worrell <[EMAIL PROTECTED]> wrote:
>> Is there a realistic threat here?
>
> I can see a possible scenario where all of the following conditions are
> true:
>
> 1. The provider trusts the consumer completely (ie doesn't do any checks
> apart from the OAuth sign
On Tue, Dec 9, 2008 at 12:38 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> It seems that everyone is agreeing on this conceptually. Where we're running
> into problems is with character data, which is of course the common case. If
> we mandate that the content's encoding be included in the Content-
On Tue, Dec 9, 2008 at 11:54 AM, John Hayes <[EMAIL PROTECTED]> wrote:
> Another problem with RFC 2616 (call this 3a) is that it says the byte order
> of the hash depends on the byte order in the content type (so uploading a
> JPEG is big-endian while text is undefined). This standard should speci
[+marcw]
Thanks for the feedback.
On Tue, Dec 9, 2008 at 9:15 AM, John Hayes <[EMAIL PROTECTED]> wrote:
> 1. Include HTTP entity headers: Content-Type, Content-Range, Content-MD5,
> Content-Language; they should be combined into a normalized base string, URL
> encoded to ascii and concatenated a
Thanks for the feedback.
On Tue, Dec 9, 2008 at 1:51 AM, Marc Worrell <[EMAIL PROTECTED]> wrote:
> 1. Why use sha1 and not hmac-sha1 (or the signing method of the request)?
I don't want to use HMAC-SHA1 because that would require signing an
uninterpreted string of bytes. Signing raw byte strea
Hi folks -
Existing proposals for signing non-form-encoded request bodies can't
be safely used with OpenSocial. I've written up a draft OAuth
extension that describes why xoauth_body_signature isn't safe and
provides a simple alternative:
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/d
1 - 100 of 104 matches
Mail list logo
