MySpace OpenID Popup spotted in the wild

DeWitt Clinton dewitt at
Sat May 2 16:05:50 UTC 2009

Responses inline...

On Sat, May 2, 2009 at 8:45 AM, Chris Messina <chris.messina at>wrote:

> On Fri, May 1, 2009 at 6:19 PM, DeWitt Clinton <dewitt at> wrote:
>> 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).

Not "bait and switch" at all.  The site owner is the one that says
type="login", thereby explicitly asking the client to inject the user's
preferred identity if possible.

Though your comment makes me realize that this isn't exactly login.  It's
more the site saying "I need an identity here.  If you, the browser, can
supply one on behalf of the user, please do.  Otherwise, you can have them
fill out whatever HTML form exists here and I'll do it myself."

Also note that this inner HTML form can itself be a RPX-style delegated
identity flow if the site wants to support it for legacy clients (as they
presumably would).

So I amend my proposal to instead call this type="identity" rather than
type="login".  The contract that would need to be established is what form
that identity is passed back to the server.  It would need to be something
specific enough that servers would derive value from it, but not so specific
that it would lock people into a particular protocol forever.

> 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).

I agree this is necessary.  I suggested using HTTP auth headers, but a
combination of HTTP headers and a meta tag would be good.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the user-experience mailing list