I only skimmed the BrowserID proposal, but my impression is that the user's email provider is the IdP, assuming that the provider implements the BrowserID protocol. <br><br>In the case where the email provider has not yet implemented BrowserID, the client uses <a href="http://browserid.org">browserid.org</a> as a fallback IdP. BrowserID.org asserts verified email addresses after verifying the user's email. This is only an interim step and is removed from the loop as soon as the user's email provider natively supports BrowserID.<br>
<br>Therefore, any email provider can be an IdP,  and there's an interim solution to support users whose email providers haven't yet supported  BrowserID. <br><br>Maybe I'm totally wrong about how BrowserID works.<br>
<br>Allen<br><br><div class="gmail_quote">On Wed, Jul 20, 2011 at 7:01 PM, Dick Hardt <span dir="ltr"><<a href="mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On 2011-07-20, at 8:47 PM, Allen Tom wrote:</div><br><blockquote type="cite">That's why I like how BroswerID uses the email address as the identifier - if the user's email provider was the IdP, then we'd be able to scale past more than one IdP. <font color="#000000"><font color="#144FAE"><br>
</font></font></blockquote><div><br></div></div>You will need to elaborate on that so that I understand where the extra IdP comes from.</div><br></div></blockquote></div>