<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Chris,<div><br></div><div><div><blockquote type="cite"><div dir="ltr"><div>It's unclear what you're proposing or suggesting...! Still, I have some feedback...</div></div></blockquote><div><br></div><div>I was emphasizing why the proposed best practices wouldn't work for us. My own position is there are lots of mechanisms, none of which is inherently globally superior to the others, or the inevitable one way. It depends on application design and integration, security requirements, and user base, among others.</div><br><blockquote type="cite"><div dir="ltr"><div>Nothing about including email identifiers as valid OpenID identifiers requires you that you use email as your primary identifier. It simply enables the use of email addresses for signing in to services. So many sites (in the wild) now immediately ask you for your email address after you sign up with OpenID that it seems counter-productive NOT to support email addresses... especially since they often require you to confirm your email address via token (which, if it were part of the OpenID spec, could be done entirely within the browser).</div></div></blockquote><div><br></div><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">It's also conceivable that someone could delegate an email address to a third-party OpenID provider, rather than their email provider... so if were to use <a href="mailto:chris@example.com">chris@example.com</a> as my email address, <a href="http://example.com">example.com</a> would be able to redirect (302) to my actual OpenID URL: <a href="http://realopenid.com/chris">realopenid.com/chris</a>. </span></blockquote><div><br></div><div>Email is certainly the primary identifier by which users know themselves today, which made us strongly consider the kind of discovery you mention. There are at least 3 reasons we reluctantly turned it down from major consideration.</div><div><br></div><div>We don't want to be the only provider of identity data a user might have. If they're trained to always enter their email address on all federated sites, and that email address always comes to us, then we have to be. We'd rather supply the data we're authoritative for, and let other sites handle the data they want to.</div><div><br></div><div>We also then must rely on the identification and general data stewardship of the email provider (e.g. they do the redirect right every time, and don't track personal usage patterns, etc.). With current business models, and the preponderance of email providers out there that students like to pick from, it'd be a leap of faith at this point.</div><div><br></div><div>And, again, immediately asking for email can give away a user's identity immediately, which for us (FERPA) is just not acceptable.</div><div><br></div><div>That said, I've long seen the "tacking on" of additional data by a provider to another IdP's assertion a key future use case that would be a quantum step forward for federated identity. I know people will work hard on it when the time comes, so I want protocols that will support it without too much modification.</div><br><blockquote type="cite"><div dir="ltr"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">I think you bring up some useful experiences in the wild, and I'm just trying to focus your feedback... can you be specific about what of the research is good and useful and what of it would not work given your restrictions?</span></div></div></blockquote></div><div><br></div><div>As one example, applications that have login systems already often just want to graft a link to the federated SSO system right next to existing login boxes. We've pushed back at this half-measure, and now we have solid data that it was the right choice to do so. The link is often not noticed, or the user enters their campus ID/password directly into the text boxes. For these systems, presenting instead a list of acceptable IdP's and nothing else has been pretty successful.</div><div><br></div><div>Many applications that have a preponderance of access from one IdP will have a button, or a default page. Placing the logo of the primary IdP -- usually a university -- along with a "Not from Podunk University? Select your school from this list." option has been successful. Thanks to college sports, many students would sooner die than use a login page or button branded by a rival. ;D</div><div><br></div><div>These aren't good interfaces, but more importantly, they're not dangerous interfaces. We can afford a little more frustration from users because the trusted identity data we're able to deliver has high value to applications. We'd still like to improve the situation with better alternatives, and give deployers a more comprehensive guide as to which to pick in any given situation.</div><div><br></div><div>Hope this clarifies things,</div><div>Nate.</div></div></body></html>