[WG-P3] [SG-P3PF] For your consideration

j stollman stollman.j at gmail.com
Mon May 23 07:38:52 EDT 2011


All,

Comments in line.

Jeff

On Mon, May 23, 2011 at 3:54 AM, Rainer Hörbe <rainer at hoerbe.at> wrote:

>
> Am 23.05.2011 um 00:41 schrieb Anna Slomovic/Equifax:
>
> Everyone,
>
> 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.
>
>
> How does the work in P3WG done so far compare to the ISO 2910x draft? Do
> the principles match? To what extent is the terminology aligned? Could the
> Kantara PF be crafted as instance of a 29101-compatible framework?
>
> On the long term Kantara will have to provide the full set of principles
> that reach beyond US eGovernment use cases.
>

One comment I might make here is that we might be careful in limiting to
scope of a Privacy Framework to "Privacy" and not to "everything that hasn't
been covered by Identity Assurance."  I think that this is a multi-faceted
issue and just because only one facet has been documented (the IAF), does
not mean that we should expand the definition of privacy to include
everything else.  I think that Notice is a separate issue.  It is no less
important, but it has its own parameters.  The same is true about
Enforcement (controls) and Manageability.  Others may choose to break the
problem down differently, but I think it is a mistake to assume the mantle
of carrying "everything else" under the auspices of "privacy."  This should
be one of the lessons to come out of Rainer's Trust Framework meta model
working group.

>
>
> 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.
>
>
> I suggest to take wider base, using both existing federations (e.g. R&E
> federations and other industries) and a few countries. Without going into
> too much detail, some controls beyond privacy principles like enforcement
> could be covered. On deciding what factors to research it might help to draw
> from former efforts like worldbank<http://www1.worldbank.org/finance/assets/images/Regulation_of_Personal_Data_Protection.pdf>
>  or EU <http://www.privireal.org/index.php>.
>
> Personally, I cringe at merely trying to organize the requirements of FICAM
or NSTIC and calling it a privacy policy.  It doesn't leverage the broader
knowledge and perspective of P3.  And, while I acknowledge that the US
represents a large market that may represent a significant short-term
"stopgap" opportunity, I we be concerned that Kantara would lose credibility
by limiting its focus to tightly.  The board consists of multi-nationals who
would be ill-served by such a limited approach.  We may have to carve out a
"special case" of a larger global standard to address FICAM.  (I am not
suggesting we ignore it.)


>
> 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?
>
>
> Levels of privacy protection and entity authentication assurance are
> orthogonal only as they are not separated by actors. So it depends on the
> use case. In the most common case where the user is the PII subject and the
> service provider the relying party, both levels fall apart.
>
> Regarding the use of levels I think that we need those, as argued in Assurance
> Metrics<http://kantarainitiative.org/confluence/display/TFMMWG/Assurance+Metrics+%28Outline%29>.
> Experts need to read the policy in full detail, professionals need a
> standardized policy with average granularity ("fit on one page"), consumers
> need a binary indicator or simple scale at most, even if this means to mix
> apples and pears.
>
> - Rainer
>
> I agree with Rainer that we need to provide Levels.  I do not see most
protections as binary.  They need for protection of certain information is
higher than for other information -- though, admittedly, the distinctions
are blurry and made even moreso by the ability to aggregate and correlate
less important information to get to more important information.  Perhaps
there are some lessons to be learned from the defense community on this
issue.  They have the same problem that Confidential information in
aggregate may become Secret or even Top Secret. This is an area that I would
offer to pursue further in my current period of limited availability.

>
> 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.
>
> Anna
>
>
> Anna Slomovic
> Chief Privacy Officer
> Equifax, Inc.
> 1010 N. Glebe Road
> Suite 500
> Arlington, VA 22201
>
> T: 703.888.4620
> F: 703.243.7576
>
> 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
> .
> _______________________________________________
> WG-P3 mailing list
> WG-P3 at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-p3
>
>
>
> _______________________________________________
> SG-P3PF mailing list
> SG-P3PF at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/sg-p3pf
>
>


-- 
Jeff Stollman
stollman.j at gmail.com
1 202.683.8699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-p3/attachments/20110523/f68019e8/attachment.html 


More information about the WG-P3 mailing list