Mozilla BrowserID

Dick Hardt dick.hardt at gmail.com
Wed Jul 20 16:10:51 UTC 2011


On 2011-07-20, at 10:28 AM, John Kemp wrote:

> Hi Dick,
> 
> Comments inline below:

responses inline below them :)

>>>> With OAuth2 (and hence OpenID Connect, I assume) the RP needs to be registered with the IdP. It is not user-centric because the user cannot arbitrarily choose an IdP -- they can only choose an IdP with whom the RP is registered, which may well mean only one of a handful of major IdPs.
>>> 
>>> Oh - I guess I had thought from reading the protocol that I would be required either to choose my email provider as an IdP (only they can verify that I "own" that email address, and assert it reasonably to an RP) or to get browserid.org to verify and assert my email address "on behalf" of my email provider to RPs?
>>> 
>>> I guess I can always assert my email address to an RP myself, and even create my own POP/SMTP server so that I can back up that assertion with the "verified email protocol" proposed by BrowserID?
>>> 
>>> But I assume that the value of this protocol is not too different than that proposed value of OpenID (Connect); that is, an IdP will *assert* the email address of a user at the IdP to RPs, and that it will carry weight because of some relationship between the IdP and RP (either because the IdP Is Famous, or because there is a crypto-based relationship, either dynamic -- DH association a la OpenID, or static like the PKI-based solution possible in SAML for example). BrowserID seems to offer the same possibility - https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest#Recommended_public_key_discovery_mechanisms - that RPs will validate the IdPs signature over the assertion...
>> 
>> 
>> The user may (and should) have different email addresses. BrowserID enables the user to choose which one to use at an RP. OpenID Connect will hand one or them all over -- and you have to trust the OpenID Connect provider that the email is truly yours unlike with BrowserID.
> 
> As far as I understand the protocol written in the spec I linked to (see step 4 of https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest#Assertion_Verification), the identity assertion should be signed by an IdP - at least RPs are told that the signature over the assertion "must be verified with the public key contained in the certificate".

The IdP is the mail provider. browserid.org is a stop gap provider to fall back on if your mail provider does not support BrowserID

> 
>> 
>>> 
>>>> BrowserID is user-centric in that the RP can verify the signature of whichever email provider the user chooses. It doesn't rely on a prior agreements between the RP and IdP.
>>> 
>>> I agree with your specific statement - so I won't quibble over whether this is necessarily "user-centric" or not ;)
>> 
>> I think that is one of the key aspects of user-centricity. The user is making choices on which attributes to share. The user is determining "who" she wants to be in a given RP context.
> 
> Yes, I understand what you mean. I'm just personally not sure that BrowserID is really so much more "user-centric" in the way you mean than OpenID (Connect).

The flow is moving from my agent (the browser) to the RP rather than from the IdP to the RP.


More information about the specs mailing list