MySpace OpenID Popup spotted in the wild

Chris Messina chris.messina at
Sat May 2 15:45:18 UTC 2009

On Fri, May 1, 2009 at 6:19 PM, DeWitt Clinton <dewitt at> wrote:

> I agree that browser support is ultimately the best way to address the
> issue.

Well, I think it's one essential way, for sure, but I think getting
widespread deployment of such support will come in fits and starts, and so
therefore can't be waited on. I know you know that, but it bears repeating.

> At SW Foo we briefly discussed an idea to drive client adoption of this not
> through openid, per se, but rather by trying to standardize the flow by
> enhancing HTML5 itself.

This is certainly interesting — and something that — if it improves security
in general — seems worth pursuing.

> Something as simple as:
>   <form *type="login"* method="POST" action="">
>     <!-- regular HTML username and password form here -->
>   </form>
> Where the type="login" establishes a contract that allows the browser to
> replace the inner HTML with an implementation of choice that will POST a
> user's credentials, after the user allows it, to the action URL in a
> standardized format.   ... The important thing is to standardize both the
> hint to the browser that it is a login form (i.e., the invented
> type="login") and the format of the data that is ultimately POSTed to the
> server.

I wonder about this "bait and switch" approach. Something about it just
doesn't seem reasonable for a browser to do — it's basically defying the
intentions of the site owner (then again, they'd have to adopt the
"type=login" code).

Perhaps an alternative would be a meta tag or something like a
rel-authenticate, to indicate that the page could be authenticated against?
In this way, the browser could pop a dialog like "would you like to
signin/connect to this site?" Once the user closes the browser or indicates
a desire to end her session, the browser would be able to sign the user out
of all their active sessions; upon resuming, the browser could
auto-authenticate the user the next time they revisit the page (similar to
Luke's proposal to auto-sign you in today).

This seems more appropriate — as the signin stuff perhaps shouldn't be in
the webpage at all, but brought to the browser layer, where this will ALWAYS
be a user present.


> On Fri, May 1, 2009 at 10:47 AM, Brendan O'Connor <openid at>wrote:
>> On Fri, May 1, 2009 at 1:35 PM, Johannes Ernst
>> < at> wrote:
>> > If we could get the browser developers to add anything we wanted to
>> their
>> > browsers, what *exactly* would we want them to implement?
>> > This is not outlandish. The Mozilla folks asked repeatedly in the past
>> (and
>> > we never knew what to say in response) and the security of a billion
>> OpenIDs
>> > is not a set of user requirements that's easily dismissed either.
>> > It appears that it would be some kind of user interface element (think
>> > "popup" for a minute) that could display the OP's authentication
>> ceremony.
>> > But where the browser would somehow "certify" that it was not a phishing
>> > attempt and came from one of the user's trusted OPs. In a way that is
>> better
>> > than having the user to do a string compare on the URL shown in the
>> address
>> > bar.
>> > What would such a user interface element look like? That's not limited
>> to
>> > what we can do without cooperation from the browser guys.
>> > In Firefox, it could be sitting in the side bar for example. (where the
>> > bookmarks are) Or ...?
>> Why not Seatbelt? I mean, naturally, a reimplemented version, but it
>> seems to solve the UI/UX issues pretty nicely. It just sits quietly
>> down in my status bar, and only pops up if I try to log in somewhere--
>> and it always displays my current logged in / logged out status. And
>> it can be configured for any OP.
>> <>
>> ---Brendan O'Connor
>> _______________________________________________
>> user-experience mailing list
>> user-experience at
> _______________________________________________
> user-experience mailing list
> user-experience at

Chris Messina
Open Web Advocate // // //
This email is:   [ ] bloggable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the user-experience mailing list