Technically, I think this is vastly superior to the currently available login solutions. But one of the things I never liked about centralised or even federated auth was all the links between accounts.
One thing I don't like: ideally, all a site should need to know is that I'm the same entity I claimed to be last time. I only want to be locally unique on the site, not a globally unique value which can be correlated between sites. Also, it should be my choice as to whether I disclose my email address to sites.
In practice, email addresses are usually required for signups, and it's easy enough to create throwaways. I can absolutely see why it was designed this way, but it would still be nicer if the protocol did not disclose more than it needed to.
In this case, the email address (and equivalently the public key the browser holds for that email address) can be correlated between sites.
I thought a bit about making a mailinator-like IDP (i.e. a convenient way to hack around this). Unfortunately, I can't see a good way right now to get both these properties at the same time:
a) The IDP doesn't know what site (RP) the user is logging in to
b) The IDP can auto-generate a persistent unique id for each site (RP) (e.g: <type-4-uuid>@idp...)
I guess the degenerate case would be an IDP which signs <anything@idp...>. Not super useful, but OK for sites where you didn't really want to have a login anyway, I guess... true mailinator style, but for logins.
A few other points:
* Would also be good to have a privacy option to force the browser to generate a fresh keypair every time a new user certificate is requested; at least then we can only be tracked by identity and not so much by device over time as well.
* There is the obvious timing attack, where if the RP doesn't cache the IDP's public key, it may disclose what site the user is logging in to, to the IDP.
* Also, verifier.persona.org will know who is logging in where, if you use their JS (since you pass the assertion and the audience via REST).
* I am not 100% sure at this stage what stops a malicious user from simply asking the browser to perform an identity assertion and grabbing email (or clickjacking the user into doing it) when they already have a user cert; haven't looked at it in depth though.
Technically, I think this is vastly superior to the currently available login solutions. But one of the things I never liked about centralised or even federated auth was all the links between accounts.
One thing I don't like: ideally, all a site should need to know is that I'm the same entity I claimed to be last time. I only want to be locally unique on the site, not a globally unique value which can be correlated between sites. Also, it should be my choice as to whether I disclose my email address to sites.
In practice, email addresses are usually required for signups, and it's easy enough to create throwaways. I can absolutely see why it was designed this way, but it would still be nicer if the protocol did not disclose more than it needed to.
In this case, the email address (and equivalently the public key the browser holds for that email address) can be correlated between sites.
I thought a bit about making a mailinator-like IDP (i.e. a convenient way to hack around this). Unfortunately, I can't see a good way right now to get both these properties at the same time:
a) The IDP doesn't know what site (RP) the user is logging in to b) The IDP can auto-generate a persistent unique id for each site (RP) (e.g: <type-4-uuid>@idp...)
I guess the degenerate case would be an IDP which signs <anything@idp...>. Not super useful, but OK for sites where you didn't really want to have a login anyway, I guess... true mailinator style, but for logins.
A few other points:
* Would also be good to have a privacy option to force the browser to generate a fresh keypair every time a new user certificate is requested; at least then we can only be tracked by identity and not so much by device over time as well.
* There is the obvious timing attack, where if the RP doesn't cache the IDP's public key, it may disclose what site the user is logging in to, to the IDP.
* Also, verifier.persona.org will know who is logging in where, if you use their JS (since you pass the assertion and the audience via REST).
* I am not 100% sure at this stage what stops a malicious user from simply asking the browser to perform an identity assertion and grabbing email (or clickjacking the user into doing it) when they already have a user cert; haven't looked at it in depth though.