Re: [WG-P3] Adequate Notice is Not Enough - Re: ICAM's PAC document

[Rich Furr]

Comopletely concur.  As I have noted a number of times, we need to strike a balanc e betiween what is needed for privacy and what will keep IdP/CSPs from implementing.  Layering on much more significant requirements than already exist will, in my humble opinion, make adoption of any of this less likely, especially if it adds appreciably to cost and drives cost of credentials to consumers to the point nobody buys.  Just a thought.

Rich Furr

Head, Global Regulatory Affairs, Policy & Compliance

Cell: 704-575-1680

Office:  980-236-7576

  SAFE-BioPharma

  SAFE-BioPharma

  SAFE-BioPharma

http://www.diahome.org/en/FlagshipMeetings/27170/Trusted+Identities+for+Cloud+Collaboration

From: Joni Brennan <jo...@ieee-isto.org>
Date: Mon, 2 Apr 2012 13:22:49 -0400
To: Mark Lizar <mark....@gmail.com>
Cc: Kantara P3WG <wg...@kantarainitiative.org>
Subject: Re: [WG-P3] Adequate Notice is Not Enough - Re: ICAM's PAC document

Hello all,

Please take this input purely on process as a I am not a Participant but staff to the organization. 

Kantara as an organization truly appreciates the high level efforts and renewed energy and spirit of the P3 WG and in particular regard to the PAC document moving forward. 

That said, I wanted to personally take a moment to re-capture scope discussion that has taken place previously in P3. 

The group has discussed the scope as developing criteria for Assessors to measure compliance to privacy guidance (in particular for the ICAM guidance when working with in the US jurisdiction).  I believe the P3 group also noted that while the guidance is a starting point, improvements could be made in the future.  Thus I recall the approach was set to work with in the guidance as written today but to provide place holders which would intend to nudge in the directions we believe IcAM would go in the future.  Think of it as areas for 'over-achievers' - things that are good to do but not required today.  Not only could these over-achiever sections be nudges for the US jurisdiction but could be input beyond the US application of such a PAC. 

So just to put a quick pin on this discussion... I can easily see how the guidance today may not 'go far enough on notice' that said there is adopted guidance today and that guidance has no indicators for assessor to apply in a standardized way to test privacy assurance.

So perhaps thinking of the recent input as 'extended' to the 'core' of the document might be helpful to keep the group moving forward with an understanding of how the guidance and standardized programs in general could nudge toward the future (particularly on notice).

Thanks for your consideration,

=Joni

Joni Brennan
Kantara Initiative | Executive Director
IEEE-ISTO
voice:+1 732-226-4223
email: joni @ ieee-isto.org

YouTube: Kantara Initiative - The Bridge to Assurance Communities
http://youtu.be/AHFqMUe04lQ

On Fri, Mar 30, 2012 at 4:53 AM, Mark Lizar <mark....@gmail.com> wrote:

I tend to agree with a lot of what Jeff is saying here.

Especially with Notice.  I do not think this ICAM document describes adequate notice proportional to the use of data and identity.  Notice itself needs a registry and a common format so that it can be centrally managed and accessible post transaction by the data subject.    

This way the data subject is able to get the level of transparency needed to centrally manage use of identity post IdP transaction.   Notice requirements are an excellent point in which the data subject can exercise control, administrate transparency, and make the management of administrative identities transparent. 

After, researching this issue extensively, I would suggest that a separate effort focused on standardising notice in IdP, with a central registry or similar protocol is the needed solution in this context.  Providing much more than the minimum notice required, in fact providing a notice regieme that is well above the minimum legal requirement and useful internationally as standard for identity management that is above compliant with laws in all jurisdictions internationally. 

This ICAM's document of pushing for adequate notice is not nearly enough.  Adequate notice does not resolve issues of activity tracking, although, a central notice repository, in which data subjects can centrally track notices after their use, enables a registry of tracking to be made. 

I also assert that a more advanced notice tracking protocol would reduce the compliance burdens and also dramatically increase the economic performance of administrating identity management. 

I am working on a project called the Surveillance Trust Project which is testing and implementing this model for video surveillance notices, based on this model (a notice registry) for trust frameworks.   The intention is to regulate institutional surveillance practices in Britain by creating a simple notice registry.    If there is more interest in this model I would be happy to discuss an identity management version, which this approach was originally designed for . 

Best Regards, 

Mark

On 29 Mar 2012, at 18:20, j stollman wrote:

All,

While I apologize for being unable to attend today's meeting, I did briefly review the ICAM document and can provide the following feedback:

1. Adequate Notice
1. I think that the requirements for notice need to extend well beyond what is listed in the ICAM document to include such items as how data are stored and protected from insider threats and outside hackers; how data is protected in flight between the user and the IdP and between the IdP and the RP, the retention periods of the IdP, the destruction processes of the IdP, etc.
2. In reality, I believe that we need to establish a separate set of criteria for Notice and Consent independent of the Privacy profile.  In this way, the privacy profile will merely need to reference compliance with the Notice and Consent profile.  The Notice and Consent Profile will then need to be developed by a collaborative IAwg and P3wg team, since it addresses elements of both.
3. As well, I would suggest that this document extend beyond the 3-party model (Subject, IdP, and RP).  It should be robust enough to address other models (e.g., separate IdP and CSP, AP, and the various UMA roles).
2. Minimalism
1. I suspect that trying to assess minimalism for the IdP is a fool's errand.  In ICAM's view, the IdP is the single source of truth for all attributes required by the RP.  In such a model, the IdP would need to anticipate every possible attribute required by any RP in order to fulfill its role.  This is a broken model from the start.
2. One alternative model would be for the IdP to merely assert that the Subject is Joe313452.  Additional attributes would then be obtained from the various Attribute Providers (APs) who can substantiate each attribute claim (e.g., a credit bureau for credit worthiness, a credit-card company for authorization of a particular purchase, etc.  Of course, this can become slow and complex if many APs are required.
3. Still other models may separate the IdP from an AP who aggregates multiple attributes along with their signed substantiation from the AP who substantiates each transaction.  Technologies such as U-Prove make this practical.
4. Of course, once we bring APs into the picture, the same privacy profile will need to apply to them.  Otherwise it is like trying to stop a leak by patching only two of three large holes.
3. Activity Tracking
1. Most of the content of the ICAM document appears to deal with Notice, not with activity tracking.
2. There is an inherent contradiction in not tracking activity and having a log available to support claims of unfair practice.  The ICAM document does not suggest tracking records not be maintained, merely that they not be disclosed to other parties.  The problem inherent in maintaining these data are that they represent a honeypot for both insiders and outside hackers who may seek to profit from the information.  We can regulate and certify business practices, but will that be enough to overcome the skepticism of the public who read continuously about PII being exposed through error or malfeasance?  So it would appear, that -- at a minimum -- there ought to be a maximum retention period established.  
3. In addition, if users decide to stop working with an IdP, they ought to have the right to have their tracking history destroyed (after weighting some defined minimum period to provide the IdP with records needed for audit, etc.).
4. If the same requirements for IdPs are not applicable to other parties in the interaction, have we really fixed anything?
4. Identity Provider Bona Fides
1. The first two items listed under this rubric appear best address in the Notice and Consent profile.

Jeff

On Thu, Mar 29, 2012 at 10:39 AM, Ann Geyer <age...@tunitas.com> wrote:

I found the ICAM Privacy Guidance for Trust Providers.  It looks very
similar to what we are trying to develop for Kantara.  I suggest we
look at this document and see what modifications, if any, are required
for our purpose.


http://kantarainitiative.org/confluence/download/attachments/49775195/ICAM+Privacy+Guidance+for+Trust+Providers.pdf

--
Ann Geyer, ESQ, MBA, MA, CIPP, CISSP, CISM, CPHRM
Managing Director, Tunitas Group
PO Box 278, Mountain Ranch, CA 95246
209-817-1691 (cell)
age...@tunitas.com
www.tunitas.com
_______________________________________________
WG-P3 mailing list
WG...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-p3

--
Jeff Stollman
stoll...@gmail.com
1 202.683.8699

Truth never triumphs — its opponents just die out.

Science advances one funeral at a time.

                                    Max Planck

_______________________________________________
WG-P3 mailing list
WG...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-p3

_______________________________________________
WG-P3 mailing list
WG...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-p3

[Colin Wallis]

+1 to Rich and Joni

All worthy and valid points made by Jeff and Mark, and I (and I'm sure others) can offer up architectural approaches beyond U Prove to attempt to address them. 
But I won't because it is going to take us off course.

To that end, here is the link to the IAF SACs.

http://kantarainitiative.org/confluence/display/certification/ICAM+Approved+Submission

This is at the crux of the problem to be solved.

Read the SACs...particularly the CO (Common Organization) SACs (e.g.for AL2 on Line 351), but even if you go through the subsequent specifc sections like Identity Proffing and Credential Management, there are privacy issues dotted across these as well.  (e.g. Stored Secrets on line 374).

 

Ask yourself if there are sufficient Privacy Assessment Criteria included in these as they stand.  The answer is no.

 

Ideally we want to draft a 'privacy' sentence in each of the SACs where there is a privacy aspect/exposure to be assessed.

 

Alternatively, or perhaps in addition, we want to draft a paragraph on how to assess each of the things in the ICAM Privacy Profile.  The assessor would then have to look for where these components are present in the SACs and apply them, but it would be better than no assessment criteria on privacy exposures thrown up by the SACs as we have it today.

 

Are we clear now?

 

Cheers

Colin 

---

From: rf...@safe-biopharma.org
To: jo...@ieee-isto.org; mark....@gmail.com
Date: Mon, 2 Apr 2012 13:50:58 -0400
CC: wg...@kantarainitiative.org

[Mark Lizar]

Rich, 

I agree with the sentiment, both you and Joni present.  I may of been overly rambunctious in my response. The ICAM document is very narrow in scope, predominantly kept to use of a federal profile, and is specifically for qualified assessors.   ICAM provides P3 with a stable point to start with for assessment criteria.  

I do not wish to detract from the work in progress, I definitely see the prudence in using ICAM's existing document to start with.   Nor is P3 in a position to undertake any R&D.  Like Joni suggests a pin can be put in the issue.  Apologies if I seemed to be creating obstacles. 

In fact, as the PAC is not intended for a data subject to use,  I see why more than 'adequate notice' is not a pressing priority for assessment criteria.  At this stage more attention should be paid to to purpose specification, having a linkable contact information,  and specifying data retention periods.  Which, IMO is the Information that is needed  to create 'adequate notice'. 

Merely pointing out that 'Adequate Notice' in the ICAM doc seems to be defined for  industrial age  information management practices and not digital identity management is probably enough at this stage. :-)  

Best Regards,

Mark

On 2 Apr 2012, at 18:50, Rich Furr wrote:

Comopletely concur.  As I have noted a number of times, we need to strike a balanc e betiween what is needed for privacy and what will keep IdP/CSPs from implementing.  Layering on much more significant requirements than already exist will, in my humble opinion, make adoption of any of this less likely, especially if it adds appreciably to cost and drives cost of credentials to consumers to the point nobody buys.  Just a thought.

Rich Furr

Head, Global Regulatory Affairs, Policy & Compliance

Cell: 704-575-1680

Office:  980-236-7576

  SAFE-BioPharma

  SAFE-BioPharma

  SAFE-BioPharma

http://www.diahome.org/en/FlagshipMeetings/27170/Trusted+Identities+for+Cloud+Collaboration