[WG-UMA] Mozilla BrowserID

Mike Hanson mhanson at mozilla.com
Sat Jul 16 23:24:08 EDT 2011


Hi, John.  I'm the author of the verified email specification that Mozilla implemented (parts of) for BrowserID.  (And hi, Eve - I owe you some feedback, I know!)

I don't know if I'm an "identity person", but I proposed the verified-email-through-the-browser idea at the Identity Commons event in San Francisco last February, demoed the prototype of BrowserID at IIW this spring, and presented the technology at the W3C Identity in the Browser workshop at Mozilla in May.  I was part of Liberty Alliance before 1.0, I've implemented SAML on numerous platforms, and I've implemented and deployed the WS-Security stack multiple times.  I'm not naive - but I am deeply pragmatic.

The idea that led to the BrowserID work was not "how can we fix identity on the web", but "what is the smallest possible claim we could make to make progress on the browser as a claims agent?"  (Or, if you like, an "active client").  

It became clear as I did my research that many OpenID RPs were using OpenID purely to elicit an email address (even when the IdP did a good job anonymizing the claimed ID).   I listened carefully to Kim Cameron's thoughts on why CardSpace failed at the most recent IIW.  And when I saw Google's work on the GIT, which effectively reduced the OpenID AX and SAML flows to a verified email, it was pretty clear that a verified email was the right thing to try to assert first.  

You're welcome to read my paper with the original statement of the problem, and my thoughts on a system to address it, on my blog [1].  


I don't disagree with your criticisms, though I would counter them some practical counter-arguments:

1. Nearly every website on the internet today indexes users by email address, and the web has not yet failed.  Clever sites index users by more than one address and implement various aliasing flows.
2. I address pseudonyms in my paper; with user-agent support the problem is tractable, and requires no changes to RPs.
3. Attribute exchange is deliberately out of scope, yes.  I have a bunch of thoughts on attribute exchange through "web activities" (nee web intents), which you can read about elsewhere on my blog [2].  We are not blind to privacy concerns, though - we are deliberately using short-duration certs to allow the client to perform a holder-of-key assertion without any message traffic back to the IdP, for example.
4. Sorry, I'm not quite sure which (of the several possible) criticisms you're making here, though I think I may address it in item 1 of my security discussion in [1].

To take a BIG step back, though: BrowserID is not about creating the authn-system-to-end-all-authn systems.  It is about "how do we get the user agent into the game?"  The solution space that we tried to hit with our (small!  experimental!) release is intended to give both RPs and users incremental improvement - fewer passwords, fewer SMTP challenges - without increasing the temperature of any oceans.  We work in the open - I welcome your feedback, and would love to make the system better - and any feedback that will help users and developers make a better web is welcome.

Best,
Mike (mhanson at mozilla.com)


[1] www.open-mike.org/entry/verified-email-protocol
[2] http://www.open-mike.org/entry/using-web-applications-for-service-discovery


On Jul 16, 2011, at 9:21 AM, John Bradley wrote:

> They are having the IdP/CA issue a verified email certificate that is stored in their client.
> 
> They are hiding the signature checking by using a callback to browserid.org.
> 
> To do distributed verification the RP needs to validate the mail providers signature.  
> That is a bit underspecified in the spec.
> 
> The problems this has are:
> 1: It is bad to use email addresses as your primary key/ canonical identifier as they are often reassigned.  
> 2: Pseudonymous identifiers would be a challenge to do this way.
> 3: Including other attributes will cause privacy issues. 
> 4: this assumes that the email domain and issuer are the same.
> 
> Think u-prove without the privacy.  
> 
> I don't think they are identity people, more browser people trying to make a better password manager.
> 
> It has some interesting ideas for the user agent that might work with openID Connect.
> 
> They are both using JWT.
> 
> We support a asymmetric signature mode for the id_token but haven't made that the default, due to crypto resistance.
> 
> John B.
> 
> On 2011-07-16, at 11:32 AM, Susan Morrow Avoco Secure wrote:
> 
>> Unless I'm mistaken, the mozillaid doesnt handle claims as such (other than email address). It looks like a very simplified openid. 
>> 
>> I guess it could be used in uma to authenticate the requester, but it seems to me that openid connect has a lot more scope for handling richer claim requests by the AM?
>> 
>> Susan
>> 
>> Sent from my iPad
>> 
>> On 16 Jul 2011, at 16:07, Eve Maler <eve at xmlgrrl.com> wrote:
>> 
>>> Cordny asks on Twitter if the new Mozilla proposal/service for "BrowserID" could be plugged into the UMA landscape:
>>> 
>>> https://browserid.org/
>>> http://arstechnica.com/web/news/2011/07/mozillas-browserid-aims-to-simplify-authentication-on-the-web.ars
>>> 
>>> Anyone want to comment, especially given the Paul/Maciej discussion so far about the need for requesting parties to provide claims in real time and the implications for the AM and for agents?
>>> 
>>>  Eve
>>> 
>>> Eve Maler                                  http://www.xmlgrrl.com/blog
>>> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>>> 
>>> _______________________________________________
>>> WG-UMA mailing list
>>> WG-UMA at kantarainitiative.org
>>> http://kantarainitiative.org/mailman/listinfo/wg-uma
>> _______________________________________________
>> WG-UMA mailing list
>> WG-UMA at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/wg-uma
> 
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20110716/6ed3fcb7/attachment.html 


More information about the WG-UMA mailing list