How to meet privacy goals of NSTIC
Session Topic: How to meet the privacy goals of NSTIC?
Convener: Francisco Corella (firstname.lastname@example.org)
Notes-taker(s): Karen Lewison (email@example.com)
Tags for the session - technology discussed/ideas considered: NSTIC, social log-in, privacy enhancement
A high-level architecture designed to meet the privacy goals of NSTIC in the short term was outlined, including 3 use cases (see Power Point at http://pomcor.com/documents/NSTICProtocolSteps.ppt and a revised White Paper at http://pomcor.com/whitepapers/NSTICWhitePaper.pdf )
Points raised during the discussion period included:
--Identical privacy goals to NIST's were described by the OECD over 30 years ago, but not enforced.
--Also, in Europe, the concept of trust networks to ensure a chain of responsibility for user's data has been important in developing regulations.
--Some audience members from Europe were interested in the exact official formulation of NSTIC's privacy goals; they were directed to the official website at http://www.nist.gov/nstic/news.html
--Other issues with the proposed architecture were the resultant increased costs (which would lead to cost redistribution to users), and decreased access speed.
--The proposed protocol is best seen as an enabling technology tool, to demonstrate to policymakers a short-term implementation of most of the privacy goals of NSTIC.
--Question whether this is a possible building block to fit into OAuth 2.0, versus an OAuth killer? Answer is: likely neither.
--Audience members raised the issues of whether the UMA protocol, or a browser-based authentication app from the group at Newcastle University have already solved these problems.
--Another acknowledged objection was that this architecture requires extensions of the HTTP protocol to enhance the role of the browser in increasing privacy of double-redirection log-in protocols (possibly to be discussed later this month at the W3C Workshop on Identity in the Browser).
--As pointed out by Kim Cameron at the end of the discussion, if the RP and IdP collude, they could find out the identity of the user. On subsequent consideration, this is not an issue in social log-in, but is a shortfall in other use cases. Hence, this is more of an interim short-term solution, outside of social log-in, and the definitive solution likely lies in using anonymous credentials based on zero-knowledge proofs.