Dawn – I’m sorry for not replying sooner – my “day job” has taken its toll on my time, but we should discuss the questions you raise.
Just a few comments we have always (within ISTPA) viewed the “touch point” concept as generalized, and applicable to any material interaction between/among actors (defined broadly). Happy to discuss top make that clear, but one idea we explored in the past (prompted by some of Peter Alterman’s suggestion), was that an initial use case mapping of privacy requirements to services occurs at the policy level – se we initially deal with policy management/maintenance across the PII lifecycle. The services then serve to establish where policy instances are set, migrate to and through other touch points; where policy instances emerge at touch points as PII flows (and may be aggregated with other data, for example); where there are policy conflicts; where there are defined policy statements that can be referenced across an infrastructure, etc. The second level analysis would be the architecture needed to manage all of this – this also could be a policy architecture of sorts; the next step would be the operational architecture, where the specific mechanisms (e.g., an email notice of a disclosure) would be shown as a more detail document.
On the issue of Control vs. usage – the core ideas was that Control is the central policy engine. However, as data flows outside an operational boundary (e.g., Hospital A in Maryland to clinic B in Delaware) the Usage service defines the mechanisms needed to ensure that required policies initially established (for example by patient consent directives) are honored. Clinic B in Delaware must also have policies and the Control service in their environment would dictate those – so there would need to be a way to map policies (e.g., Usage might run an online check against Hospital A control service-stored policies) to determine what actions are allowed, prohibited or need to be reconciled.
The Interaction service would establish the mechanisms by which Hospital A policies are accessed by Clinic B’s Usage service, and clearly there would be dynamic linkages to other services.
It gets complicated pretty quickly, but abstracting a use case to the model level at least enables us to depict the touch points (actors, systems etc.) and the implication for various services. A real challenge is to make this abstraction understandable visually.
John
John Sabo
CA Technologies
Director, Global Government Relations
Tel: +1 202-513-6304
Mobile: +1 443-629-6198
john.t.sabo@ca.com
From: Dawn Jutla [mailto:dawn.jutla@gmail.com]
Sent: Monday, April 18, 2011 11:29 AM
To: Gail Magnuson
Cc: Michael Willett; micheledrgon@dataprobity.com; pmrm@lists.oasis-open.org
Subject: Re: [pmrm] Publically-Accessible Smart Grid Use Cases
Hi Gail, Michele, Michael, John, and all:
Michele and Gail, it is indeed a nice repository. It would be very useful if you can select a list of specific use cases out of the Smart Grid Repository that you would like us to focus on to assess as inputs. Secondly, from your knowledge of the domain, if you can further select a representative use case that invokes other use cases, that would be really helpful too.
I scanned a few of the Smart Grid Use Cases and it may be possible for us to construct a full life cycle view of the PI flow in some cases (with guesses), but also there is difficulty for some as flow information is missing in some cases. What I like about having the scenario or interaction diagrams is that they are useful in showing the communications among actors (including persons (job roles), systems, devices, and agents clearly. That is, we can easily identify the touchpoints amongst the actors and hence see where implementation-based control mechanisms and responsibilities change, and imaginably, where higher-level policy mechanisms need to provide oversight. One issue we may still have in all available use cases is where the data in message or other exchanges are not fully specified. But that may be OK, we can fill in gaps for illustrative purposes..
We need to be clear on our definition of a touchpoint. The definition of a touchpoint is limited to, for example the AGREEMENT Service, as Gail points out below, (and ACCESS and AGENT services), only if we restrict the definition of a touchpoint to mean the point/interface at which the owner of the PI and PII interacts with an organization's channel (web site, in person, fax, phone, agent etc) or her/his personal agent. If instead, we define a touchpoint more generally as the interface where one actor hands off PI to another actor (recall that actors can be person (job role), system, device, agent, another organization etc), then many more of PMRM services will provide oversight on touchpoints. The general definition is less restrictive and more powerful. It includes the first.
On another note, as I mentioned at our last call, I also scanned the PMRM Services Chart to assess the level of detail we would require as input to do the PMRM analysis. Here are some preliminary observations on the PMRM Services Chart as the latter is also an important input.
(1) The CONTROL Core Policy Service appears to overlap in functionality with the USAGE service. Is there some documentation that you can point to that clearly delineates their distinct core functionalities? Ditto with respect to CONTROL and ENFORCEMENT.
(2) Information Quality appears to be missing as an underlying principle/practice in the documentation for the AGREEMENT Service. Data minimization particularly (implied in the given definition of Information Quality) should occur at the data collection/agreement stage. Similar observations may be made for sensitivity, consent, openness, enforcement etc. as missing from CONTROL, Use limitation etc. missing from VALIDATION and so on.
(3) There is no distinction made between a user's personal agent and an organization's agent in the AGENT service. The blending can be problematic in some areas - e.g. in how we define touchpoints or more importantly, where organizational vs personal responsibility lies.
(4) How the USAGE service interacts with other services, e.g. Agreement for data minimization, should be defined. To generalize, the PMRM model may want to illustrate the possible invocation (relations) of its services from within its other services. For example, it appears likely that the USAGE Services may be invoked from other PMRM services. It is less clear, but likely, that the CONTROL Service is intended to be a high-level coordinating service for the models's described services. A model description should illustrate relations/flows/dependencies among its components. Is such a description available?
John, do you think it may be useful for you to divide the group's efforts into three parts with three assigned subgroups who can synchronize at our monthly calls? For example (1) Methodology for the PMRM analysis as per Gail's efforts below, (2) Determination of what the use case input should ideally look like for PMRM input (also selection of the use cases), and (3) a sub-group that addresses high-level issues in the PMRM framework, if necessary, and transforms it into a full description of a model with relations and dependencies.
Best,
Dawn.
On Fri, Apr 15, 2011 at 2:01 PM, Gail Magnuson <gail.magnuson@gmail.com> wrote:
Michael and all,
The landlord/tenant use case is described in the Privacy Chapter of the NISTR document published last year. The NISTR privacy team focused on one/two use cases that had definite privacy issues associated with them so that the group might focus on highlighting the key issues. There was no actual formal use case from which we did our analysis, rather a description of the situation and an application of the FIPPs to the situation.
I do agree that with this material, we have some solid starting points.
Also, I have been reflecting on our call yesterday while making edits to the Methodology Template and have the following thoughts to offer up:
1. First, Privacy by Design (PbD) has changed the name of the game, especially with it's principle #2: Privacy as the Default Setting. It is no longer just FIPPs, but FIPPS + PbD. These must be integrated into our Methodology Template http://www.ipc.on.ca/images/Resources/7foundationalprinciples.pdf
2. Second, compliance is now much more than FIPPs, PbD and policy. It includes detail regulations, standards and industry best practices to at name a few.
3. Third, the focus on accountability and enforcement is increasing globally
4. Fourth, the PMRM analysis process will need to work at multiple levels. It will need to produce policy; guidelines; standards; controls, innovative designs and other privacy mechanisms. It also will also need to work for multiple environments, such as an organization, its vendors and sub-vendors; a government agency, it's sister agencies, other agencies and the public; and so on
5. Fifth, as we have discussed, it is recursive
6. Finally, it might be best to focus on testing out what was so eloquently produced, being careful not to revise the PMRM analysis process before testing it.
That said, I offer up a set of charts recently developed by an intensive research and analysis process at Nymity in conjunction with its global customers and contributors, to define Demonstating Accountability, separate and apart from Understanding Compliance Criteria and Privacy Program Tools (attached)
I am also going to finish the Methodology Template revisions, focusing on the observations above. The revisions will include
- upgrades to the Scope section to define the purpose, objective and deliverables of the PMRM Analysis (eg policy, controls, or privacy as a default design)
- a change to the title of 2, to Prepare for the PMRM Analysis Effort, as it will not necessarily be to begin with a set of Use Case(s)
- adding to section 2 the accumulation of the additional Compliance Criteria necessary carry out the PMRM Analysis Effort
- the very BOLD step of creating ONE recursive process that takes us directly into exercising the PMRM Analysis using the original ISPTA model, with the idea that perhaps Actors/Touch Points are in part one and the same type of thing and Policy and Controls are as well. Actors and Touch Point both 'touch' the data. They both do so using the Agreement. Perhaps the one key difference is that the recursive nature of the process might allow us to set aside some of the Actors/Touch Points for a recursive round. I do this because I think it is important to refine the model, embrace the terminology, establish synonyms that make it more useable and understand how to use it at multiple levels to produce different results.
I may be wrong about this so I welcome your thoughts.
Meanwhile, enjoy the charts and if you have any feedback, please let me know.
Best, Gail
On Fri, Apr 15, 2011 at 10:14 AM, Michael Willett <mwillett@nc.rr.com> wrote:
Michele - wow!
That certainly is a LARGE set of Use Cases, sub-dividing
the Smart Grid domain into focused use cases.
Even better, the Use Cases are expressed in a formal "structure"
that explicitly provides the interactive 'requirements' needed
for input to the PMRM part (operational) of our Methodology.
Gail: You referred to the "landlord/tenant" Use Case?
I browsed the several use case categories, but did not see
one that sounded like that. Would it be a composite?
Or a transform of the given use cases?
The formal structure seems to provide a similar setup of the Smart Grid
use cases as does Scenario Diagrams that Dawn referenced for Emergency
Responder.
Net: We seem to have the necessary prerequisites for proceeding
with either/both Smart Grid and/or Emergency Responder.
Opinions?
Michael
-----Original Message-----
From: micheledrgon@dataprobity.com [mailto:micheledrgon@dataprobity.com]
Sent: Thursday, April 14, 2011 7:28 PM
To: pmrm@lists.oasis-open.org
Cc: micheledrgon@dataprobity.com
Subject: [pmrm] Publically-Accessible Smart Grid Use Cases
http://www.smartgrid.epri.com/Repository/Repository.aspx
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Gail Ann Magnuson
Mobile: 1.704.232.5648
Residence: Chardon Ohio 44024
Mailing Address
11224 Mayfield Road
Chardon, OH 44024
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
______________________________________
Dr. Dawn Jutla, PhD
Professor, Dept. of Finance, Information Systems, and Management Science
SOBEY SCHOOL OF BUSINESS
Saint Mary's University, Halifax, NS, B3H 3C3
Phone: 1 902 420 5157
Sobey School: http://www.smu.ca/academic/sobey/bios/faculty/Jutla_Dawn.html
CUSP Project: http://web.cs.dal.ca/~bodorik/Cusp.htm
CONFIDENTIALITY NOTICE: This email and any attachments may contain confidential information that is protected by law and is for the sole use of the individuals or entities to which it is addressed. If you are not the intended recipient, please notify the sender by replying to this email and destroying all copies of the communication and attachments. Further use, disclosure, copying, distribution of, or reliance upon the contents of this email and attachments is strictly prohibited.