This post is in response to a tweet by @francesIDexpert who asked: “For those of you following #NSTIC, what do you think about this http://t.co/zUErAzZ”, where the shortened link refers to an article on BrowserID.
Here is my take on BrowserID and the Verified Email Protocol that it is based on. The functionality provided by an “IDBrowser Primary Authority” is equivalent to the functionality that would be provided by a certificate authority (CA) that would issue to a user a PKI certificate binding a public key to an email address, the CA being the email service providing the address.
I see two positives and one negative in BrowserID. The positives are:
- Having an email service provider issue email-address certificates, and
- Having the certificates issued automatically.
Now to NSTIC.
An explicit privacy goal of NSTIC is that colluding relying parties should not be able to use the user’s credentials to track the user. That is, two different relying parties should not be able to tell that the same user has logged in to both of them by comparing their login logs. Using an email address as an identifier is incompatible with this goal.
One could argue that relying parties need the user’s email address anyway. That’s true today, because email is often used to recover from forgotten passwords. But another goal of NSTIC is to provide alternatives to passwords. Without passwords, many relying parties will have no valid reason to ask for an email address. (And there will consequently be less spam.)
So an email-address certificate is a good way of demonstrating ownership of an email address to a relying party with a legitimate need to know the address. Actually, I will incorporate that idea into our proposed NSTIC architecture (with proper credit, of course) at the very next revision of the white paper. But an email address is not a good idea as a universal identifier for the Web.