[OpenID] Flex OpenID Component
Peter Williams
pwilliams at rapattoni.com
Fri Feb 20 21:27:41 UTC 2009
It's doing a popup, for the user auth and assertion delivery experience. That requires a trusted desktop/browser, so that the auth flow initiated from one thread (talking initially to the appspot.com domain) can be supported from an assertion communicated from another popup-window/thread (talking to OP, and then to the SP realm).
The initial browser window does seem to retain cookies on the OP, after the destruction of the popup. It has to be passing the RP session to the initiating window, obviously.
There seems a lot of trust assumptions about the browser being made here. Not sure I like one window security context having (indirect) control over the DOM of another. Makes many assumptions about the window manager's inter-window communications security model.
> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of SitG Admin
> Sent: Friday, February 20, 2009 1:10 PM
> To: Chris Messina
> Cc: general at openid.net
> Subject: Re: [OpenID] Flex OpenID Component
>
> >Thought you couldn't do OpenID in Flash? Apparently you can... sort
> of. ;)
>
> I was just reading about a similar 'enhancement':
> http://openid-demo.appspot.com/
> And they are enhancements - but only when used to *enhance*. OpenID
> still has the advantage of maintaining compatibility with *old*
> browsers, or users who insist on disabling scripting (for
> security/privacy reasons), because it uses Redirect functionality
> that has been around for a long time; if RP's implement OpenID
> support that *requires* additional functionality, they may lose out
> on (or at least annoy) users. Which is fine, if they want to (*I'm*
> fine with insisting on cookies to help me distinguish between users
> so I can manage them in regards to their ACL), but let's not be so
> carried away with fancy ways of presenting OpenID that we forget to
> teach people the basics: it only takes a bit of code on the
> web-admin's part to make sure a fallback mode is available for users
> who can't handle the fancy stuff, so unless the site has good reason
> *not* to, it should support users in whatever level of functionality
> *they* can utilize. The technology and the user, together, should
> define the minimum threshold for useability - OpenID should not
> become an argument that everyone, in this day and age, MUST support
> scripting/Flash if they want to do anything.
>
> I'm wary of Flash for another reason, related to privacy; I've
> noticed that Flash games reload in Firefox (I regularly flush every
> aspect of my cache, etcetera, to reset Firefox), but then they
> *remember my progress* - as if Firefox is preserving some *settings*
> for that Flash application, and these aren't affected by any reset I
> know how to do. This sounds like interactive Flash, and *that* (the
> idea that it could communicate back to a server information like
> whether the user had newly entered their URI or had it stored from
> previous activity) seems very risky to me.
>
> -Shade
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
More information about the general
mailing list