Skip to end of metadata
  • Created by Former user, last modified by Former user on Aug 30, 2013
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

DRAFT minutes pending P3WG approval

P3WG Plenary Meeting 06 September 2012

Date and Time

  • Date: Thursday, 06 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 Notes 2012-06-28
  2. Presentation
    Presenter:
    Gershon Janssen, Secretary, OASIS Privacy Management Reference Model Technical Committee
    Topic:
    OASIS Privacy Management Reference Model
  3. Privacy Assessment Criteria
    1. Development of US FICAM PAC
  4. AOB
  5. Adjourn

 

Attendees

  • Colin Soutar
  • Susan Landau
  • Ann Geyer
  • Anna Slomovic
  • Mark Lizar

Quorum is 4 of 7 as of 23 August 2012.

Staff:

  • Heather Flanagan (scribe)

Non-Voting

  • Thomas Smedinghoff
  • Nathan Faut
  • Jeff Stollman
  • Gershon Janssen

Apologies:

  • Bill Braithwaite

Minutes & Notes

Administration

Motion for minutes -

Motion to approve by Anna; Jeff seconds; no discussion, minutes approved by unanimous consent

Presentation

Presenter:
Gershon Janssen, Secretary, OASIS Privacy Management Reference Model Technical Committee
Topic:
OASIS Privacy Management Reference Model

Introduction to PMRM - Kantara P3WG.pdf

  • Q&A
    • (Anna) question about scope of specifications - what about actually understanding what policies must be complied with? what about how to verify/connect to systems to verify that conditions are met for the policies? (Gershon) regarding understanding what policies and their interpretations, yes, that is somewhat out of scope though there is a glossary which may help; regarding verify items, it depends on how you mold this within your own system, specific services provide means to analyze what you need to do what to adhere to the policies, but we are not providing the mechanisms; (Susan) regarding the second question, relevance to an ongoing investigation would be out of scope for a PMRM standard; that must be decided by legal people; (Anna) meant more like an API not a human policy
    • (Jeff) this seems basically to be a methodology tailored to a specific implementation. Concern with that approach is that everyone will create their own systems for various use cases which will be internally consistent but will expose bits of information enough to allow for significant correlation of data. Is there any plan to incorporate a larger scope for correlation? (Susan) that's a law and policy, not a technical, and is far out of scope of PMRM; (Gershon) did not get in to enough detail to really be able to define this kind of problem; need more detailed use cases; (Ann) we have been using this time of reference model to drive a privacy architecture in our environment, and its been a very hard sell to get technology people to understand why it is needed and unique, and it sticks to the questions under discussion - the PMRM are good for driving for conversations within an organization

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.
  • Discussion:
    • Can the notice itself be used as an assessment? The first question is the whether the notice itself conforms with the expectations of what should be in a notice (is it accessible, readable, easy to find, etc); whether those practices are any good is a separate question
    • Adequate Notice criteria concern: in the notice we will have to make a point about how crisp/clean/short the notice has to be depending on the type of device to be used to read it; the basic criteria of accessibility, readability, etc still apply but it be answered differently depending on the device
      • agreement that this point must be captured
    • Process: work from the top down, once we have a clear understanding what that is, what the assessor's are therefore are looking for, we can then look at various technology platforms and give more specific guidance; Maybe take these two categories of criteria and also add a type of evidence; want to see "usable readable accessible" - these terms do not exist in the current documents
    • Some of these conversations should flow back to the IAWG; their docs are silent on type of device, so this will be good feedback

 

Call closes @ 12:06 EDT

  • No labels