Mozilla BrowserID

Dick Hardt dick.hardt at gmail.com
Thu Jul 21 02:33:09 UTC 2011


Ah. You misunderstood what I meant by "more than one IdP"

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 gov.ca, am dick at blame.ca, and a California resident from the state of CA.

Here is a more near term scenario:

I sign up to newservice.com and want to use my dick at blame.ca identity to prove who I am later on, and give newservice.com to post to Twitter, Facebook, LinkedIn and Google+ so that I can spread all my goodness from newservice.com everywhere. A user-centric design lets my identity agent get OAuth tokens from Twitter, Facebook, LinkedIn and Google+ and select my dick at blame.ca address all in one permissions page. Currently I have to bounce to each of those providers. What a pain! :)

-- Dick

On 2011-07-20, at 9:16 PM, Allen Tom wrote:

> 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 <dick.hardt at gmail.com> 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20110720/b1f8114d/attachment.html>


More information about the specs mailing list