<div dir="ltr">Hi Nate,<div><br></div><div>It's unclear what you're proposing or suggesting...! Still, I have some feedback...<br><br><div class="gmail_quote">On Mon, Oct 13, 2008 at 8:05 PM, Nate Klingenstein <span dir="ltr"><<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">...the suggested approaches that you describe aren't sufficient to meet<br>
key discovery needs in most academic communities. These are four<br>
primary reasons why:<br>
<br>
2) The user's IdP is not necessarily associated with their email<br>
provider. Specifically, some new students don't care to use a<br>
university-issued email account, while many services most interested<br>
in federated identity need authoritative data from the university,<br>
e.g. studenthood. We've worked hard to allow for the distinction<br>
between email and identity, and we'd like to preserve it, because it<br>
gives our users personal choice while we still manage key education-<br>
oriented information.<br>
3) We're required legally and ethically, particularly in the EU, to<br>
protect the user's identity whenever possible. Asking the user to<br>
enter a primary identifier like email address for discovery makes<br>
protection of privacy impossible in some ways.<br></blockquote></div><div><br></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><br></div><div>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>. </div>
<div><br></div><div>This is what the EAUT protocol specifies:</div><div><br></div><div><a href="http://eaut.org">http://eaut.org</a><br clear="all"><br></div><div>Of course you can also just use identifier select and provide your typical OpenID URL (<a href="http://realopenid.com">realopenid.com</a>) and never reveal your email address, but that's no different from what we have today, except for the usability hurdle of learning URLs for self-identification.</div>
<div><br></div><div>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?</div>
<div><br></div><div>Chris</div><div><br>-- <br>Chris Messina<br>Citizen-Participant &<br> Open Technology Advocate-at-Large<br><a href="http://factoryjoe.com">factoryjoe.com</a> # <a href="http://diso-project.org">diso-project.org</a><br>
<a href="http://citizenagency.com">citizenagency.com</a> # <a href="http://vidoop.com">vidoop.com</a><br>This email is: [ ] bloggable [X] ask first [ ] private<br>
</div></div>