Re: [pmrm] Publically-Accessible Smart Grid Use Cases

[Gail Magnuson <gail.magnuson@gmail.com>]

Dear Dawn,

Great observations! 

It certainly is possible to construct a full life cycle view of the PI flow in the US Smart Grid, especially if reads the privacy chapter of the NISTR published last year as it does describe some of the overall flows. The Canadian and Netherlands flows are very different. The emerging view of the Canadian flows can be found in part documented on the www.privacybydesign.ca site as there has been significant collaboration with the Commissioner from Ontario on this matter. I am still looking for the flows from the Netherlands because these flows were also revised with privacy in mind.

The 'AGREEMENTS' enforce in these three information models are strikingly different. The US one is even more different because of the advent of the third party solutions offered outside of the Smart Grid and the blended services where companies like Google have a third party solution and have also become a 'utility' in some capacity.

Dawn, I would love to see or be directed to your control-level diagrams and/or material.  This will help me further understand your perspective. 

Also, your observations regarding the services I think are very important, because they echo some of my experiences from 2010, which is why I so firmly believe it is important to test the services themselves, incorporating the more current principles surrounding designing a system/process with privacy in mind. 

I also was struck with your observation about the difference between types of agents. Some years ago I read a book 'What happens after what comes next: The 500 year delta" by Watts Wacker and James Taylor. He spoke about, in Chapter 7 of the Privacy Editor; the Privacy Agent and the Privacy Sheriff. None of these are corporate entities. This work still resonates in many ways as a way to differentiate the types of 'agents' there are at the personal level and even the corporate level.

While, I do agree that we ultimately need to take multiple paths, I remain steadfast to making certain that these paths converge, which is short hand for saying...lets be certain our mission is clear.

Best to all, Gail

On Mon, Apr 18, 2011 at 11:28 AM, Dawn Jutla <dawn.jutla@gmail.com> wrote:

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.

--
Gail Ann Magnuson
Mobile: 1.704.232.5648
Residence: Chardon Ohio 44024

Mailing Address
11224 Mayfield Road
Chardon, OH 44024