NSTIC has very ambitious privacy goals. Today’s third-party login solutions do not come close to meeting them. Privacy-enhancing technologies that could meet them have yet to be deployed successfully. And Facebook’s social login is preempting the password-reduction benefit of NSTIC while severely reducing privacy. Can NSTIC succeed?
We believe that the key to success is to build privacy-enhancing technologies into the fabric of the Web, so that little effort is required of users, relying parties, identity providers and social sites to take advantage of them. In the white paper
we propose an NSTIC architecture based on extensions of two core protocols of the Web, TLS and HTTP, and we describe a range of use cases to show how it meets the goals of NSTIC.
The paper is still a first draft, and we hope you’ll help us improve it by leaving your comments below.
Hi Francisco,
great initiative.
A good draft with clear explanations of your proposal to build in privacy-enhancing technologies into the fabric of the web: TLS and HTTP.
‘Sounds’ like a good way to exclude 3rd parties from the id.-information the end-user wants to share with a third party.
TLS is already the protocol to secure the connection between web browser and web server, so why not extend this protocol with a resource for privacy enhancing (PE)credentials.
On thing though, I’m no TLS-expert, but I’m always wary of a Man-in-the-Middle or Man-in-the-Browser Attack (see my blogs about it)
I know, you describe encrypted Client-Initiated Exchange, but during Server-Initiated Exchange I read:
‘An issuance protocol can be used to replace a credential present in the browser…
Such a nomenclature can be achieved by using URLs as names’
(draft paper, p.5)
Isn’t using URLs here a security risk?
Account login and session tracking gives, IMHO, too much power to the relying party (RP)by excluding the CA as third party (this is now done by RP)
I don’t know if this is a good idea, we have CA’s to account for that Digital Certificates certifies the ownership of a public key by the named subject of the certificate, and therefore is a trusted 3rd party, trusted by both end-user and RP.
OK, it only uses a PE credential instead of a PKI certificate, which could enhance privacy, but still , IMHO,there is too much power for the RP here. Who says the enduser the login certificate is not tampered? I don’t know if NSTIC doesnt’t want a NSTIC accredition authority here?
That’s it for now, I have more, but I’ll deliver them in a later post.
Francisco, I hope you can answer my questions and hopefully even more people want to join this discussion.
I think it’s a good initiative, but it has to be deepened and perhaps even visualized by diagrams etc. That visualizes your ideas more.
Thank you for sharing your proposal.
The use cases are sufficiently described (details, as already said, are still necessary!!)
Thank you very much for your comments.
URLs are normally used to access Web resources, such as documents. But they can also be used to name things, people, or concepts. For example, both OpenID and WebID use URLs as user IDs. This takes advantage of the domain name system to avoid name collisions. A URL used as name may or may not also be used to access a Web resource.
Examples of credential names could be http://dmv.ca.gov/drivers-license.html and http://dmv.ca.gov/identification-card.html, referring respectively to the driver’s license and the identification card issued by the California Department of Motor Vehicles. Pointing the browser to these URLs could retrieve metadata about the credentials, but doesn’t have to retrieve anything at all.
URLs used as names should probably be called URIs rather than URLs, but the terminology has evolved and is still evolving: see RFC 3305, RFC 3986, and http://info-uri.info/.
Hopefully it’s now clear that using a URL as a name cannot possibly introduce a security risk.
In Section 3.1 we used the term “login certificate” to refer to a certificate that is issued by the relying party itself when the user registers, and submitted to the same relying party, as a TLS client certificate, when the user logs in. A login certificate is used by itself in some of the use cases in the paper, and in conjunction with other credentials in other use cases; there are also uses cases where login certificates are not used.
A login certificate is equivalent to a username-and-password credential, except that it provides much more security. When you log in to a relying party with a username and a password, your knowledge of the password tells the RP that you are the same user who earlier registered with the username. Similarly, when you log in with a login certificate, by demonstrating knowledge of the associated private key, the browser proves to the RP that it is the same browser to which the site issued the certificate. There is no need for a third party to make an assertion about the user, because all the RP wants to know is that it is communicating with the same user who registered.