----- Original Message ----
> From: Brian Eaton <[email protected]>
> To: Oleg Gryb <[email protected]>
> Cc: Naitik Shah <[email protected]>; OAuth WG <[email protected]>
> Sent: Wed, August 11, 2010 11:03:12 AM
> Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query
>
> On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb <[email protected]> wrote:
> > The thing is that each time when a web app with sensitive info can be run
in
> > a frame, security people would advice to break that
> > frame-reads-other-frame-data logic, because it can lead to violation of
>same
> > origin policy.
>
> This is incorrect. The security of this flow is based entirely on the
> same-origin policy.
It is not: you get an access token from authz server and want to share it with
thirdparty.com domain, which is in a different domain. You do it through frames
running in a browser. Do a threat modeling as others suggested here. Why the
access token needs to be shared with thirdparty.com is still not clear.
> Note that both the web-server and the user-agent flows are entirely
> about passing information to third-party web sites, so suggesting that
> these flows should not pass information across domains is not really
> helpful. =)
There are two kinds of information here: thirdparty.com state (e.g. list of
selected photos on Facebook) and access token, which is really a printing.com
secret. If you store access token in a printing.com cookie you don't need to
share it with thirdparty.com.
> > Yes, but you'll need a web server client for that. I'm saying that UA
>profile can
> > be POST based too.
>
> (a) The POST would bust the browser cache.
> (b) Javascript can't read POST bodies. (At least not to my knowledge.
No, it can't and I never said it could. Busting the browser cache by writing a
server side logic doesn't look like a big issue or performance lost to me. You
could aqcwire access token once, persist it (e.g. through a cookie in
printing.com domain) and reuse until it's expired.
> If we were willing to accept the performance penalty of busting the
> browser-cache, we would use the web-server flow.
I'm still struggling to undertand what you're trying to achieve with UA
profile.
If it's getting rid of web server client, you didn't aachieve it, because you
still have thridparty.com, which is actually a web server client.
Here are some qs to the existing spec (v.10) related to that:
"The user-agent profile is suitable for client applications residing
in a user-agent, typically implemented in a browser using a scripting
language such as JavaScript"Client application (JavaScript) resides and is
implemented on thrirdparty.com. Browser only executes it, so you actually do
have a web server client, it just you don't want to use server side code and
server side objects, right? If this is the case, why don't you say it
explicitly?
"These clients cannot keep client
secrets confidential"What is wrong with cookies?
I think, in your UA flow you'll also need to reflect:
1. thirdparty.com and it's role.
2. the cross-domain secret sharing logic that we've discussed here and why you
need it.
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
