[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pmrm] PMRM TC: possible simplifications in the original PMRM Services
Susan – Thanks for the comments. See my reaction below. Michael From: Susan Landau [mailto:susan.landau@privacyink.org] Some suggestions inline. I hope they are useful. 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. - 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). Anyone have a better name suggestion? “Manage” is way too broad. How about "Data Manager"? Or "Attribute Manager"? Michael: Control/Usage manages PI and agreements. So, ‘data’ and ‘attribute’ might not be exact. Also, for purity, we wanted to stay with one-word Services. Do you think that Usage does not suggest the right meaning? - 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. - Security: Elevate Security to Service status. - Audit: Manages the ‘log’. Absorb Audit into Enforcement. I think this is problematic, unless by "absorb," you mean as a separate entity explicitly defined within Enforcement. If so, makes sense. Michael: Sorry; absorb was not the best word. I meant what you suggest: The functions of Audit are explicitly listed in the expanded set for Enforcement. Audit in a operational sense was always just a particular tool/mechanism (log +) that fits in the larger sense of Enforcement: audit triggers are set within Enforcement; if the triggers are realized, then overt reaction (enforcement) ensues. Net: New Services – 20Usage (new = Control + Usage) Security Certification. 22.............................................................................................................................. Enforcement 25 (absorb Audit) Presentation and Life Cycle Services. 26 Interaction. 26 (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. I'm confused, but it might just be a simple issue. Shouldn't one of the inputs to services 1-7 be time? Michael: The original Select/Input handled any and all ‘information and parameter values’ that were pertinent to the particular application. ‘Time’ could well be one of the customization parameters. For the general definition, we could not spell out all the possibilities. And, given that Security is a Service, any Service can ‘link’ to Security. That is, Security need not be called out explicitly. I'm really confused here. I would think we would want Security explicitly called out. Perhaps I am missing the picture of what is happening. Michael: Originally, we “embedded” Security inside each Service call (see 7: Secure above). But, Security was simply another callable service. So, why have special handling for Security, especially if we want to standardize and automate the Methodology as much as possible? As you suggest, Security will be “explicitly called out”, as an invocation from each/every other Service. Some Service calls in some Use Case instances may not have explicit security requirements. In that case, better to have Security as a peer callable Service and not embedded in each Service. Net: The fundamental Function categories under each Service are (just like for procedures) : - Setup - Input - Process - Output Do you have a better word for Setup? Maybe, Configure? How about "Initialize"? Michael: I will add “Initialize” to the candidate list; thanks. 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. Actor: Active people, devices, systems that initiate actions. Michael: “people, devices, systems” is a good itemized list of ‘actor’ candidates. By listing candidates explicitly, would it ever be complete? “Initiate actions”: Is ‘transfer/pass-through PI” an initiated action? “Action” includes? Is PI always involved with an actor? The essence of an ‘actor’ seems to be “handles PI”.
Michael: Our original word for Service invocation was “link”, as in 6 above. “touchPOINT” suggests someTHING, not an action. Your definition suggestions bring out some of the subtleties with the words we are using. Thanks for the review and input. Michael |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]