<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Allen,<div><br></div><div>If your use case has now become, in its entirety, email verification, rather than federated authentication or transport of trusted attributes between domains, then I think our needs have diverged significantly. We of course handle and perform email verification daily using Shibboleth deployments, but it's a small facet of what we need to do. If that becomes what OpenID is intended solely to do in the future...</div><div><br></div><div>I think you'd still be interested in trusted attributes about users from other providers at some point in the future, but if not, that's a substantial difference in requirements that it's very good to reveal now.</div><div><br></div><div>Take care,</div><div>Nate.</div><div><br></div><div><div><div>On 14 Oct 2008, at 06:56, Allen Tom wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">I think there's a very interesting opportunity to use OpenID as a browser based email verification protocol. The emphasis is on verifying the user's email, not signing in.<span class="Apple-converted-space"> </span></font></p> </blockquote></div><br></div></body></html>