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!!)