Stuart –
Thanks for your review and input.
See my reactions below.
Michael
From: Shapiro, Stuart S. [mailto:sshapiro@mitre.org]
Sent: Friday, August 19, 2011 11:15 AM
To: Michael Willett; pmrm@lists.oasis-open.org
Subject: Re: [pmrm] PMRM TC: possible simplifications in the original PMRM Services
A lot of good ideas here. Specific reactions inline.
Stuart
On 8/18/11 6:39 PM, "Michael Willett" <mwillett@nc.rr.com> wrote:
John S and I have assembled a number of comments
from PMRM TC members over time and have discussed
at length possible simplifications in the PMRM Services
that may address some of your concerns (and confusion).
The objective is to make the Methodology/PMRM
as simple as possible, but not any simpler (to quote Einstein).
In the original work that led to the current 10 Services,
the Agent, Usage, and Access services were ‘different’
in their nature, being services that largely invoked other services.
Consideration:
- Agent: Acts as the ‘persona’ for the underlying Actor/system.
Consider expanding the Interaction service to include
the Agent capability.
Agree
- Usage: handles ‘subsequent’ handling of PI.
Consider absorbing that capability into the Control service.
- Control: Manages agreements/permissions re: PI.
But, the term ‘control’ is already over-loaded; eg,
we talk about privacy ‘controls’, which are at a
different logical level in the architecture.
Consider changing the name of Control to something else:
one possibility is Usage, expanded meaning (above).
I think it makes more sense to merge Control into Usage rather than merge Usage into Control.
Michael: You cut right to the result! I had said “merge Usage into Control and rename it Usage”.
I did not think about what I concluded. Better said your way: Merge Control into Usage.
Same result.
Anyone have a better name suggestion?
“Manage” is way too broad.
- Access: Grant subject access to PI held by other Actors.
One consideration is to collapse Access into Interaction.
But, Access is a fundamental function. Let’s keep
it distinct for the moment.
How atomic is Access? My feeling is that essentially atomic services should be merged into other services. Alternatively, see if there’s a more balanced division possible between Interaction and Access.
Michael: Good thought. We want to balance simplicity with operational detail. If we merged ALL Services together into one big ultra-“do privacy management”,
we would then have the issue of creating and grouping “related” operations at the next level down. Access is not ‘atomic’, consisting of several
Processes: ‘ individuals to review their PI’ and ‘individuals to submit changes to their PI’, along with two Input types.
By merging Access with Interaction, we would ‘expand’ Interaction, but would want to call out its Access ability, since
Access is one of the few Services that is also (directly) a FIPPs. Because Access is fundamental in that sense, we
proposed keeping it as a separate Service, for now.
- Security: Elevate Security to Service status.
Agree
- Audit: Manages the ‘log’. Absorb Audit into Enforcement.
Agree
Net: New Services –
Core Policy Services. 19 <#_Toc241486134>
Agreement 19 <#_Toc241486135>
20 <#_Toc241486136> Usage (new = Control + Usage)
Security
Privacy Assurance Services 21 <#_Toc241486137>
Validation. 21 <#_Toc241486138>
Certification. 22 <#_Toc241486139> .............................................................................................................................. <#_Toc241486140>
Enforcement 25 <#_Toc241486141> (absorb Audit)
Presentation and Life Cycle Services. 26 <#_Toc241486142>
Interaction. 26 <#_Toc241486143> (including Agent)
Access
Now, consider the 7 function-category set under each Service:
1. DEFINE [SVC] operational requirements
2. SELECT [SVC] (input, process, and output) information and parameters
3. INPUT [SVC] information and parameter values in accordance with Select
4. PROCESS [SVC] information and parameter values within Functions
5. OUTPUT [SVC] information, parameter values, and actions
6. LINK [SVC] to other (named) Services
7. SECURE [SVC] with the appropriate security functions
Define and Select are all part of setting up the invocation of the Service,
whose calculation is included in the (multiple) Process calls/invocations.
Think like programmers: Services are “called” by other Services (like programming ‘procedures’
in my day). So, Link is part of what the privacy management system does among Services.
And, given that Security is a Service, any Service can ‘link’ to Security. That is,
Security need not be called out explicitly.
Net:
The fundamental Function categories under each Service are (just like for procedures) :
- Setup
- Input
- Process
- Output
Agree with the simplification
Do you have a better word for Setup? Maybe, Configure?
I certainly prefer Configure to Setup. Possible alternative: Instantiate.
Michael: So far, we have Setup, Configure, Initialize, and Instantiate. The envelope, please!
We solicit your opinions on any/all of the suggestions above? Yea? Nay? Better ideas?
While I have your attention:
We use the terms Actor, Touch Point, and System. Can someone suggest
a precise definition for each that shows their mutual relationships?
The challenge: make them distinct.
Thanks…
Michael
=====================
Dr. Stuart S. Shapiro
Principal Information Privacy and Security Engineer
The MITRE Corporation | www.mitre.org/privacy
M/S S145 | 202 Burlington Road | Bedford, MA 01730
Voice 781-271-4676 | Fax 781-271-3957
sshapiro@mitre.org | s_shapiro@acm.org (permanent)
"Privacy is worth taking seriously because it is among
the rights, duties, or values of any morally legitimate
social and political system." -- Helen Nissenbaum