Hacker News Reader

Comment by mcpherrinm | Hacker News Reader

Ben Adida, one of the developers, wrote a post on the subject here: http://identity.mozilla.com/post/7669886219/how-browserid-di...

In short, three big differences:

1. Identifiers are email addresses, not strange URI things, which is good because users are already comfortable with emails identifying them.

2. Privacy: Your OpenID provider can see what services you log into. Not true with Personas, which was a big deal for Mozilla and for me.

3. Browser integration: The APIs are currently implemented with a javascript shim, but the browser can step in (either via native support or an extension) to provide new, exciting types of authentication -- dongles, certificates, interpretive dance via a kinect, etc.

View on HN

How does Persona avoid the identity provider seeing what services you log into? (Assuming the provider has implemented the distributed version of the protocol, not Mozilla's fallback IdP)

Check out around the 16:00 mark in this video: https://www.youtube.com/watch?v=nJff23UdNAI

Notice that provisioning (steps 1 and 2) and logging into a site (steps 3 and 4) are two completely independent processes, with the browser mediating any identifiable identity-provider-to-target-site communication.

Persona stores a signed statement from the IdP in your browser (currently using localStorage). Once you get the statement from your IdP verifying your identity, you can log in using the same proof many times without contacting the IdP, until it expires.

The service you log into knows the identity provider's public key and a cert for the user (the user's public key signed by the identity provider).

The service can verify the user's cert against the identity provider's public key with this information. The service initially contacts the identity provider to get the provider's public key, so the identity provider can infer that someone is attempting to log into the service as one of its users.

Once the service has the provider's public key, it can be cached by the service until it expires, and while it's cached, the service can verify logins without contacting the server again by checking that the cert presented by the user to the service has a legitimate signature from the identity provider's public key.

So if someone logs into HN using their Gmail ID (assuming both services grow support for the protocol), all Gmail knows is that at least one person attempted to log into HN using a gmail address. Who was trying to log in, whether that login was successful, and the number of other people who logged into HN with Gmail after that, are all facts that would be completely hidden from Google.

Does this mean that your browser can cache the signed cert and log in to websites automatically without needing to even contact the provider again?

I'm guessing there's some sort of timestamp there, to prevent someone from just stealing the cert and logging in to whatever they want as that user.

not different from someone stealing your cookies.

Cookies can be invalidated. Signatures, not so much.

It's possible to revoke a certificate. Not sure if that's what you're supposed to do in this case, but it's possible.

Yes, that is exactly right, and it's also why certs are short-lived (hours). When certs are renewed, the site the user plans on logging into is not revealed to the Identity Provider.

By my understanding, yes and yes. The third-party service caches the public key (with timestamp) and the browser caches the signed certificate (with timestamp). The timestamp gives the credentials a relatively short TTL to prevent a stolen cert from being used indefinitely.

This is an incomplete definition of privacy. If the service and server collude, you are hosed. There are cryptographic constructions(anonymous credentials) that have been around for over a decade that prevent this. IBM and Microsoft both have (unfortunately incompatible) libraries that do this. If we really are trying to build the id scheme of the future, why not use these?

Can you provide links?

Sure, though unfortunately I know of none that provide a decent balance between high level explanations and cryptographic depth.

The main actual deployed usage of the technique is in TPM's for direct anonymous attestation. http://en.wikipedia.org/wiki/Direct_Anonymous_Attestation

IBM explains their project here http://www.zurich.ibm.com/idemix/details.html

The original academic work its based on is this http://cs.brown.edu/~anna/papers/cl01a.pdf

A different(and older) technique which, by my understanding, is mainly useful for smart cards, is deployed in a prototype system from microsoft : http://research.microsoft.com/en-us/projects/u-prove/

https://developer.mozilla.org/en-US/docs/Persona/Protocol_Ov...

In short, your browser asks the identity provider to sign a certificate proving that you are someone@example.com. The browser will then use that certificate to authenticate you on the site. The site can check this certificate by getting the pubkey from the identity provider. You are never associated with the site you are authenticating against (except on very low traffic identity providers)

Reply on news.ycombinator.com