[WG-P3] For your consideration
anna.slomovic at equifax.com
Sun May 22 18:41:47 EDT 2011
Before the next meeting we need to think through a way forward for P3WG and the Privacy Framework. We are about to hold elections for P3WG co-chair and secretary, and the way we address the issues below can potentially influence who will wish to take these positions.
The analysis below is based on the past week’s correspondence with various members of other Kantara groups. I raised two questions: whether Kantara will require some form of privacy protection/certification as part of its overall certification criteria, and what is the process for getting privacy incorporated into the certification process/requirements.
The first question is whether privacy protection, at any level, will be required for entities that use Kantara recognized credentials. (I’m sorry if this is not the exact term. I mean credentials that are issued by an IDP which is certified under Kantara IAF or a federation that adopts Kantara-certified trust framework.) Based on my correspondence with others, the answer appears to be that privacy requirements should be optional, up to each federation. Since it is possible to imagine an identity federation that does not involve privacy (Colin mentioned security forces in the Middle East as a possible such federation), Kantara’s certification requirements would not include privacy requirements. Although this is not an "official" Kantara position, the initial certifications, which are already in the pipeline will not include privacy elements with a proviso that privacy requirements may be added at a later date. The ultimate decision would be made by ARB and the Kantara BOT, which determine what is included in the certification process. We would need to present work to them and make a case for including privacy requirements, either mandatory or optional.
Given that there are, in fact, federations that require the incorporation of privacy protection (FICAM, for instance) and that NSTIC makes FIPPs part of the US national strategy for electronic identity, there is a reason to develop a generic privacy framework even if Kantara considers such a framework optional. The question is what shape such a framework could or should take. As far as I know, there is no work yet that lays out what privacy protection means for identity transactions within a federated identity system. NSTIC simply lists the generic principles; the ICAM Privacy Profile has some very specific requirements, such as Informed Consent, Optional Participation, and a prohibition against tracking of credential use (i.e., disclosing information about use of credential use on government sites to any other credential users).
Based on this and the e-mail exchanges I have had in the past week, here are some questions that we should consider as a group in order to determine a way forward.
1. Should we continue to pursue a principles-based framework? I suggested such a framework because there is general, worldwide agreement on privacy principles, and Kantara would like its credentials to operate in all countries and under all legal regimes. NSTIC and FICAM already incorporate some version of these principles. Mark has suggested a Notice-based framework as an alternative, which may be easier to do but, in my view, would put too much weight on Notice and would not adequately cover other principles.
2. Should we attempt to “reverse engineer” a privacy framework from the requirements that we know already exist in NSTIC and ICAM since both have actual privacy requirements? Both NSCTIC and ICAM are US-based. In fact, ICAM is applicable only to the federal government, and the privacy profile limits the “Do Not Track” provision to visits to US government sites. Nevertheless, NSTIC covers all privacy principles, so it might be worthwhile to spend some time on expanding the definitions to include those outside US frameworks (as we have been doing) and then analyzing/interpreting how the principles apply specifically to identity transactions. This would become the principles-based Privacy Framework, which could be further developed into profiles like the one required by ICAM.
3. Should we work on creating some set of Levels of Privacy Protection? Proposals on the table include Level of Protection and Level of Control, which we have discussed. Levels of Privacy Protection will be pretty much orthogonal to LOAs as currently implemented in the IAF. I.e., at every LOA, privacy protection levels can vary from none to very strong. At the moment, no privacy protection “levels” exist. Should this group try to create a level-based structure so that entities subject to different privacy requirements can have an easier conversation about interoperability of credentials?
If we do go forward with creating a Privacy Framework, in whatever form, we need commitments from the members of P3WG and PF to doing actual work, not just meeting participation and comments. There is much too much work for three people, who have been active contributors to date and all of whom have paying jobs that require their attention. If such commitments are not forthcoming from at least three to five more people, I recommend that PF work be terminated and that P3WG revert to a group for sharing current privacy-related and identity-related developments every other week.
I look forward to our next conversation on Thursday.
Chief Privacy Officer
1010 N. Glebe Road
Arlington, VA 22201
This message contains information from Equifax Inc. which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e-mail postmaster at equifax.com.
More information about the WG-P3