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.
In the case where the email provider has not yet implemented BrowserID, the client uses browserid.org 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. 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. Maybe I'm totally wrong about how BrowserID works. Allen On Wed, Jul 20, 2011 at 7:01 PM, Dick Hardt <[email protected]> wrote: > > On 2011-07-20, at 8:47 PM, Allen Tom wrote: > > 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. > > > You will need to elaborate on that so that I understand where the extra IdP > comes from. > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
