> It's very like OAuth in some respects. Just because I have signed in to two services with Twitter, does not mean that one of those services can access the oth

> It's very like OAuth in some respects. Just because I have signed in to two services with Twitter, does not mean that one of those services can access the other in my name. Who cares? Twitter can still access both in your name, without your intervention. This system will have the same weakness, because it doesn't provide a means of allowing users to retain or leverage secrets. Your password and the mandatory second factor are all 'secrets' known to your identity provider. BrowserID has/had the same lovely privacy properties but still gives your identity provider (e.g. Mozilla if you were to use Persona) complete access, even if they don't know when or to whom that access is being granted when you're using it. If you can show me technical details regarding the zero-knowledge proofs being exchanged in the protocol then I'm all ears, but afaik, in current browsers, it's simply not feasible without resorting to Javascript. The Web Crypto API + DH primitives might be enough to construct such a protocol, but if you're cobbling together the client side implementation using those primitives and running it from server-supplied Javascript then you're already lost. All federated login systems are fundamentally flawed outside of a close-knit contexts where shared authentication makes sense (like universal login for all .gov.uk websites), because you're delegating control over multiple services to an identity provider. Freedom to choose an identity provider in this case bullshit because there's a fixed set of organisations who actually have access to passport data, the electoral roll etc. This system is just giving those (some government run) organisations further power