Responses inline...<br><br><div class="gmail_quote">On Sat, May 2, 2009 at 8:45 AM, Chris Messina <span dir="ltr"><<a href="mailto:chris.messina@gmail.com">chris.messina@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On Fri, May 1, 2009 at 6:19 PM, DeWitt Clinton <span dir="ltr"><<a href="mailto:dewitt@unto.net" target="_blank">dewitt@unto.net</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>Something as simple as:<br><code style="font-family: courier new,monospace;"><br> <form <b>type="login"</b> method="POST" action="<a href="http://example.com/login/" target="_blank">http://example.com/login/</a>"></code><code style="font-family: courier new,monospace;"><br>
<!-- regular HTML username and password form here --></code><code style="font-family: courier new,monospace;"><br> </form><br><br></code></div>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.<br>
<div><div></div></div></blockquote><div><br></div><div>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).</div>
<div></div></div></blockquote><div><br>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.<br>
<br>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." <br>
<br>
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).<br>
<br>
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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>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). </div>
<div></div></div></blockquote><div><br>I agree this is necessary. I suggested using HTTP auth headers, but a combination of HTTP headers and a meta tag would be good. <br><br>-DeWitt<br><br></div></div>