Re: Browser ID

Lots of myths being restated (rsa is CPU bound, ssl is hard on servers, crl caching is hard (whereas a trillion web page caches are not). After 20 Yeats of hearing it, I recognize why the rationales are stated.

Short lived certs are old hat. Some ssl ciphersuites even use them, minted by the server/browser.

The issue is needing independence from the Idp. If one must go back to an Idp each day, the Idp gets the same power over the user as visa/paypal has over Wikipedia. The ttp gets to mediate between user and rp (and govern both). 

You see most of the us ISPs doing everything they can to insert themselves between the parties (rather than act as a mere authentication authority).

Same old story. 

Sent from my iPhone

On Jul 16, 2011, at 3:20 PM, Ben Adida <ben@adida.net> wrote:

> On 7/16/11 9:17 AM, Kingsley Idehen wrote:
>> User logs into IdP provided data space and deletes their problematic
>> public keys.
> 
> That makes me nervous. You're asking a lot of users. The most a user tends to do (if you're lucky) is change one or two important passwords.
> 
>> What happens when someone steals a PC/Laptop/Tablet with the private key
>> associated with the public key in a BrowserID scenario? The statement
>> above tells you what can happen re. WebID.
> 
> I don't think so. From what I understand WebID uses long-lived keypairs. BrowserID uses short-lived keypairs that expire in a matter of hours (we're thinking at most a day). Our goal is to not have to deal with revocation, which is incredibly problematic.
> 
>> Re. BrowserID is the mailto: URI to public key relation 1:1 or 1:N ?
>> This too has implications.
> 
> 1:N. Each device generates its own keys. But they expire quickly.
> 
>>> Can you trigger cert re-generation automatically and silently? I don't
>>> think so.
>> 
>> Of course!
> 
> Are you sure that's true? I'm pretty sure that keygen in the browser requires user interaction.
> 
> -Ben
> 
>

Received on Saturday, 16 July 2011 22:45:26 UTC