<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ah. You misunderstood what I meant by "more than one IdP"<div><br></div><div>I mean that more than one Authoritative Party will have claims in an identity transaction. For example, I can provide a claim that I am a Canadian Citizen with a claim from <a href="http://gov.ca">gov.ca</a>, am <a href="mailto:dick@blame.ca">dick@blame.ca</a>, and a California resident from the state of CA.</div><div><br></div><div>Here is a more near term scenario:</div><div><br></div><div>I sign up to <a href="http://newservice.com">newservice.com</a> and want to use my <a href="mailto:dick@blame.ca">dick@blame.ca</a> identity to prove who I am later on, and give <a href="http://newservice.com">newservice.com</a> to post to Twitter, Facebook, LinkedIn and Google+ so that I can spread all my goodness from <a href="http://newservice.com">newservice.com</a> everywhere. A user-centric design lets my identity agent get OAuth tokens from Twitter, Facebook, LinkedIn and Google+ and select my <a href="mailto:dick@blame.ca">dick@blame.ca</a> address all in one permissions page. Currently I have to bounce to each of those providers. What a pain! :)</div><div><br></div><div>-- Dick</div><div><br><div><div>On 2011-07-20, at 9:16 PM, Allen Tom wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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. <a href="http://BrowserID.org">BrowserID.org</a> 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>
</blockquote></div><br></div></body></html>