P3WG Meeting Notes 2012-09-20

Owned by Former user (Deleted)
Last updated: Aug 30, 2013 by Former user (Deleted)Version comment
18 min read

Call not at quorum; notes include several quote from mailing list discussion

P3WG Plenary Meeting 20 September 2012

Date and Time

  • Date: Thursday, 20 September 2012
  • Time: 08:00 PT | 11:00 ET | 15:00 UTC (time chart)

  • Dial in info:
    Skype: +99051000000481
    North American Dial-In: +1-805-309-2350
    Conference ID: 402-2737

Agenda

  1. Administration:
    1. Roll Call
    2. Agenda Confirmation
    3. Reviews minutes: P3WG Meeting Minutes 2012-09-06
  2. Privacy Assessment Criteria
  3. AOB
  4. Adjourn

 

Attendees

  • Ann Geyer
  • Mark Lizar
  • Anna Slomovic

Quorum is 4 of 7 as of 23 August 2012.

Staff:

  • Heather Flanagan (scribe)
  • Joni Brennan

Non-Voting

  • Tom Smedinghoff
  • Peter Capek
  • Colin Wallis
  • Nathan Faut

Apologies:

  • Colin Soutar
  • Myisha Frazier-McElveen

Minutes & Notes

Administration

Motion for minutes -

Call not at quorum

 

Discussion

  1. Privacy Assessment Criteria
    1. Email from Ann Geyer to P3WG list:
Questions for discussion
1.  For each of the assessment questions listed below, what level of
assessment do we expect (observer, inquire, inspect)?
2.  Do we want to indicate any "passing critieria" or examples of
acceptable practices for any of the questions listed?
3.  What additional questions or lines of inquiry are warranted?


2.1.1 Adequate Notice  (From the US Fed Profile--Kantara's Additional
Requirements)

Adequate Notice – Identity Provider must provide End Users with
adequate notice regarding federated authentication. Adequate Notice
includes a general description of the authentication event, any
transaction(s) with the RP, the purpose of the transaction(s), and a
description of any disclosure or transmission of PII to any party.
Adequate Notice should be incorporated into the Opt In process.

Existing Assessment Guidance
Suggested Assessment Questions:

1. Is the notice written in plain language so that it is easily
understood by the average user?
2. Does the notice convey what information is being transmitted, the
user’s options, and the outcome of not transmitting the information?
3. Is the user information being transmitted the same information that
is described in the notice? Is  that the only information being
transmitted?
4. Is the notice incorporated into the “opt in” mechanism?
5. If so, is the notice clear, concise, unavoidable, and in real-time?
6. Is the notice merely a linked general privacy policy or terms of service?

Supplemental Explanation:
Adequate notice is a practical message that is designed to help the
average  user understand how to engage in the authentication
transaction, including, what information is being  transmitted about
the user, what options the user has with respect to the transmission
of the information,  and the consequences of refusing any
transmission. For example, if the information to be transmitted is
required by the Relying Party for the authentication, the notice
should make clear that the transmission is  required and refusal will
cancel the transaction and return the user to the Relying Party’s
website for  further assistance. If the information to be transmitted
is not required for authentication, but, for example,  will be
collected by the Relying Party in order to provide the service
requested by the user more  conveniently, the notice should make this
distinction clear and indicate that if the user refuses the
transmission, the user will be able to provide the information
directly on the Relying Party’s website.  Assessors and Auditors
should look for a notice that is generated at the time of the
authentication  transaction. The notice should be in visual proximity
(i.e. unavoidable) to the action being requested, and  the page should
be designed in such a way that any other elements on the page do not
distract the user  from the notice. The content of the notice should
be tailored to the specific transaction. The notice may be divided
into multiple or “layered” notices if such division makes the content
more understandable or  enables users to make more meaningful
decisions. For these reasons, the notice should be incorporated  into
the “opt in” mechanism as set forth below. In sum, an Adequate Notice
is never just a link  somewhere on a page that leads to a complex,
legalistic privacy policy or general terms and conditions.

Response to P3WG list from Nathan Faut, 9/19/2012:

1) Inquire of management whether Adequate Notice is provided for all
transactions
2) Inspect any policies and procedures related to Adequate Notice
2) Observe the notice sent to End Users related to transactions
3) From a selection of transactions, inspect the transaction and compare
with the Adequate Notice information
[[Should we recommend that the assessor inquire, observe, and inspect
other areas, artifacts, etc.?]] >>

Response to P3WG list from Colin Wallis, 9/19/2012:

Good thought Nathan..

This is really going in the right direction - thank you Ann!

And you can see a kind of templated/predictable language and audit chart coming through - great!

Now I'm probably getting picky but I think with above we don't quite finish it..inquire,inspect etc,... for what purpose?

Once we determine that we can template that as well..

So what might the purposes be?

It might be to confirm the existence of something. It might be to confirm that it conveys the intention of the policy, whatever. It might be to confirm the consistent application of something across a range of selected transactions.

Response to P3WG list from Nathan Faut, 9/19/2012

The “Inquire / inspect / observe” language is provided to support the rest of the text that Ann provided.

In a classic APG (at least within KPMG), the criterion/criteria is placed at the top of each set of actions, then the actions are broken into Test of Design (TOD) and the corresponding Test of Operating Effectiveness (TOE). The assumption is that the actions below test the criterion/criteria above at some level.

Are we struggling toward an APG to offer the assessors?

 

Discussion:

  • (Ann) Today, we're at the point where we're looking at the adequate notice section (currently fairly sparse in terms of what we would expect an adequate implementation to address); take the description of adequate notice and break that down in to implementation details
    • (Colin) what do you think about Nathan's suggestion to use the auditing terms (see block quotes above)
    • (Nathan) an AICPA auditor who may or may not be an accredited assessor will create their own audit program guide; we can provide suggestions to them and they can take them or not; any guidance we provide should be reviewed by the assessor with an independent eye to determine what is appropriate in the given circumstance; some assessors will take our word as bible and others will not, and that's ok
    • (Tom) at the end of the day, when the assessor is done and they certify that the assessed has met the requirements, it's up to the assessor to determine which requirements need to be reviewed
    • (Ann) that may create problems from the Kantara point of view, whether or not the auditor has the discretion to de-scope the listed suggestion of things from the guidelines. 
    • (Tom) these are basic privacy requirements, but even the one on Notice is such an amorphous concept that wondering how far we can/should go, how can we determine a notice is readable/understandable/clear?  We are dealing with things not objectively discernible.  Many jurisdictions require notice or consent, with requirements like "clear and conspicuous", "readily available", etc
    • (Mark) been working on a new effort called Open Notice, and under "fairness" there needs to be adequate notice, choice, access, justification; all the privacy instruments there are, the only common denominator is a requirement to have a notice; have been distilling out notice requirements by jurisdiction over the last week, and there is a general term of "adequate notice" but it may be more specific depending on sector/jurisdiction (sending to list)
    • (Ann) there is a certain commonality through the various regulations, and if we look at the 6 suggested assessment questions, some of those principles are covered there; was there general themes in the work done by Mark that are missing from the current guidance? 
      • (Mark) many of the requirements out there have common gaps, things like "correct digital contact information"; have we defined "average user"? in the US that's a grade 11 reading level - is that what we're following? we do need to avoid getting so specific that we'll have to change every time legislation changes
    • (Tom) when you are doing an audit/assessment, if you are doing a check that the notice must be clear, is that sufficiently clear or do you look for more details for guidance? (Nathan) usually handled that "clear and accessible" is sufficient language, and the write up will include details that justify how/why it is/is not clear and accessible
    • (Mark) if it is informed consent, you need one purpose per notice/transaction, and there is a bottleneck in handling things that way; it does make it easier to assess; are we talking about per transaction assessment?
      • (Ann) if we take our starting point as the definition of adequate notice, it is adequate notice for federation, so that should be the area specifically to be assessed; it does seem to be a place to give additional guidance;
      • (Mark) having a limited scope can be very helpful
    • (Anna) IAWG requires a notice as to what a service contains; should we make sure the definition there is cleaner that we're talking about the notice itself as opposed to the service?  Should we have one notice that combines both the service AND the transaction? we should tell the IAWG what the notice should contain re: privacy in the service notice; if we're just talking about the transaction notice, t hen we know what's in the service notice and we can either refer to that, or expand on that, making things relevant and limited to this particular transaction
      • (Ann) expect all the transactions that the IdP needs should be in the purview of this notice; a consumer wouldn't want to be presented with a new notice every single time
      • (Anna) a just-in-time notice is probably better when giving them the right piece at the right time, rather than a one-time notice that never gets presented again; probably a balance between a one-time service notice that may be more comprehensive and the just-in-time notice for the specific transaction
    • (Mark) what is the scope of the Privacy Assessment Criteria and the Privacy Notice?  
      • (Colin) scope is limited to what the FICAM requires
      • (Ann) the section "adequate notice" is just one of 12 sections, and not sure if limited the adequate notice to federation impacts other components of the PAC
      • (Anna) this is just federal government applicable, and (Anna thinks) they only do federated authentication; our job is to get someone to them and is who they claim to be up to LoA #, and from there they can do whatever it is they (the gov't) wants
    • (Anna) Scope: the federal privacy profile applies only to federal authN in to federal gov't systems; it doesn't say what you can do in the non-federal space; the question we haven't answered is the scope of this notice if it applies only to the AuthN transaction itself and not to the credential service provider in the identity framework; don't know how to make those two play well together
      • (Tom) from user's perspective, there are 2 transfers of personal information I care about, one to the IdP, the second of my data from the IdP to the federal gov't in a federated authN transaction; had assumed that the FICAM folks would want to cover both, but maybe not, and that would be a significant narrowing of what we need to cover here
      • (Ann) might be a mistake; the IdP maintains a database of identity, the output of the proofing function that it is doing for the individual, and in some models the individ has a credential used independently of the IdP, and in others the IdP holds the credential on behalf of the individual; if we allow those different models to be in the market, we have only done half the job in the second model
      • (Tom) agreed, just looking this in one way would be a mistake
      • (Ann) what is federated authN mean to this IdP, and what are all the transactions that the IdP will perform on behalf of the individual; understanding all those transactions explains what PII is involved, what is the purpose, what is the RP or credential service provider doing with the data; never see a risk statement and that would be very interesting
      • (Anna) understand the notion of multiple parties, but there are two separate pieces, a credential service provider and the federal gov't as an RP; the gov't has accepted they will accept credentials from certified CSP's, so the CSP does a lot more than authN, also does identity proofing, etc, and all those things require a notice and explanation
      • (Ann) had drawn the box around the scope of the issuance of the credential, and Anna is pointing out that the service being performed by the CSP is more than the issuance of the credential; if that second role, the ongoing validation of the credential, and if that is highly dependent on the transaction, then the endeavor we are engaged in is going to get very complex; if we could define a general set of responsibilities, then we could look at only the privacy implications that need to be validated when that type of ongoing credential validation is occurring; we could provide value without getting in to the specifics of any RP transation

Note to P3WG re: Adequate Notice from Mark Lizar, 9/20/2012

As i mentioned in the call I have been working with a group called Open Notice.  
In this regard we have worked on a problem list for current notice practices, which I believe is out of scope of the PAC works.   As well as an ontological approach to notices, some of which is summarised  below. This provides a another point of approach that may be useful in contrast. 
Ultimately the Open Notice workgroup is trying to address the larger issues that underly some of the issues we are addressing in the PAC. 
Here is some of the work done so far in my research on notice requirements.  (its a work in progress) 
- Mark
  • (Legal) Notice Requirements By Jurisdiction
    • General Requirements
      • Privacy Notice typically Covers Effective Date Scope Information Collected (both actively and passively), Choices Available, How To Modify information or preferences, How to contact or register a dispute, How policy changes will be communicated
    • USA
      • FCRA (Financial Credit Reporting Act)
        • Consumers must receive notice when third party data is used to make adverse decisions
        • Notice Requirements
          • All reporting Must have
            • a permissible purpose,
            • must be Consumer initiated,
            • explicit permission, implied in an application .
              • E.g. for employment consumer has given written permission Certified permissible purpose for access to credit report
      • HIPPA
        • Privacy Notice not necessary when healthcare provider has an indirect treatment relationship.
        • Privacy Rule permits covered agents to use PHI, but also requires entitites to give individuals detailed notice about the intended collection and use of their health information.
      • GLBA
        • Requires the Right to opt out of information sharing practices
        • No private right of action, but financial institutions are obliged to give notice and could face liability under deceptive trade practices statutes if the notice are deceptive or inaccurate.
        • Financial institutions that fail to comply are subject to penalties under Financial Institution Reform Recovery Act (FIRREA) Provided this standard is met Financial institutions may share any information (Notice standard enables the sharing of information - How to make infrastructure to share information?)
      • COPPA
        • Privacy policy link on every page
        • Give parents notice about collection practices
        • Obtain verifiable consent from parent
        • Parents get to delete childs info
        • Parent gets choice about child data being given to 3rd parties and opt out of future use of data
        • Notice to Include
          • contact info
          • Type of info
          • how the info will be used
          • purpose of 3rd parties
          • option of consent to collection but not disclosure
      • TSR (tele-marketing sales rules)
        • Display caller ID
        • Identify themselves
        • Disclose all material information and terms
        • Exceptions
          • Consent in writing from the consumer, stating a number calls can be made and include the signature
          • Consent must be clear and conspicuous
          • DNC Safe Harbour Seller has procedures implemented written and procedures to honour customer requests
      • Unfair and Deceptive Trade Practices (UDTP)
        • Unfair - defined as commercial conduct that intentionally causes substantial injury, without offsetting benefits, and that consumer cannot reasonable avoid (unfair notice-broken consent arguments)
    • Canada
      • Federal Privacy Act
        • gov must inform any individual about collection of PI and the purpose
        • Notice defied as:
          • act of informing indiviuals that personal information about them is being collected,
          • how it will be used, stored and disclosed; and how long the information will be retained
        • Fed Privacy Act 5(2)Notice online needs sufficent information to decide if they want to proceed: use another method for submitting PI (reasonable security); or opt out entirely General Privacy Notice, CLF Standard 5.3http://www.tbs-sct.gc.ca/clf2-nsi2/index-eng.asp
        • A general privacy notice contains only information that is common to the entire website, while a the Privacy Notice Statement provides information that is specific to each point where personal information is collected. (general privacy notice is not enough)
      • PiPPEDA (TBD)
      • Consent
        • Consent is the informed, voluntary agreement of an individual to the collection of his or her perosnal infomration and to the subsequent uses, disclosure and retention of that infomration.
        • “Informed” Consent is only achieved by first providing the individual with appropriate Notice.
        • words privacy notice statement should be linked to the privacy notice statement page Agree button is used to ensure that a person has accessed the Privacy Notice Statement Page
      • Combining Notice & Consent
        • Recommended sequence is that visitors are asked to click (or access keyboard) two times before proceeding further.
          • (Note: Increase access if notice and consent is accessible post transaction)
        • purpsose for the description and collection of personal information should be consistent with info source Model Privacy Statement for Canada.
        • Links:
        • http://www.tbs-sct.gc.ca/pgol-pged/nandc-aetc/nandc-aetc07-eng.asp
        • Privacy Notices often reviewed via Privacy Impact Assessment which is then linked from the privacy notice statement
      • Sample Privacy Statement
        • Title,
        • Explanation of Privacy Notice, Purpose
          • If Using Cookies expirey of cookie,
            • e.g. when (at end of session) Do or dont enable identity of user, Keeps login info Compiled for Statistical For info about cookies - insert link Contact info - right to access and correct process to do this (should be very easy - link to persoanlly kept priv profile)for clarification call-email-tweet to us Cancel at anytimeinfo neeeded to interact with this priv notice in the future
            • (TBD)
    • EU
      • Processed Fairly & Lawfully
        • (note: Challenge fairly)Adequate means to enforce rights? (note: are they adequate? Measurements?)
        • Components of Online Notices
          • Effective Date scope information collected (both active and passive)information uses choices available how to modify information or preferences how to contact or register a dispute how policy changes will be communicated Cookie Policies, Data Breach Information, Data Retention (in canada but not US ??)
        • Common Notice Components of Email
          • (from text p.910) No false or misleading hearder informationNo deceptive subject linesopt out mechanism in each messageNotice that the email contains advertisementinformation about sending organization (weak -not mandatory digital contact method) (OSR)
      • Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data
        • (TBD)
          • UK
          • France
          • Germany
    • APEC
    • Austrailia



 



 

Next call:

Date and Time

  • Date: Thursday, 20 September 2012
  • Time: 08:00 PT | 11:00 ET | 15:00 UTC (time chart)

  • Dial in info:
    Skype: +99051000000481
    North American Dial-In: +1-805-309-2350
    Conference ID: 402-2737