Stream: Security and Privacy
Topic: Consent Provision type
Mohammad Jafari (Jan 26 2020 at 01:12):
The Consent.provision is defined as An exception to the base policy of this consent. An exception can be an addition or removal of access permissions. The description for Consent.provision.type indicates that it should specify a permit or deny - when the rule conditions are met. Not permitted in root rule, required in all nested rules.
- Does root rule here mean the root Provision? If this means that the root
provisionmust not have a type, some of the Consent examples (e.g., this one) do not conform to this constraint. - Moreover, how must one interpret a base policy of
OPT-IN(perpolicyRuleattribute) with a root provision without atype? How is this exception to the general opt-in must be interpreted? Is it implied that the the provision is describing a set of conditions to deny? Iftypeis implied to be the opposite of the outer element, then why do we need it at all?
I think the language and examples around the provisions needs some clarification and improvement, perhaps a diagram that can demonstrate the relationship between policyRule, root provision and the nested provisions (which also makes me wonder why there is a policyRule and why the root provision is not used to record what policyRule is capturing to simplify the model).
I am happy to contribute the CRs if we can clarify the semantics here.
David Pyke (Jan 26 2020 at 14:41):
We would appreciate your input into clarifying. If you will be at the WGM, we can discuss it there, otherwise, please put in a CR and we can discuss it after the WGM
Mohammad Jafari (Jan 27 2020 at 00:11):
Thanks @David Pyke I am happy to put in some CRs but wanted to make sure I understand the intentions and nuances behind the current structure (I'm hoping maybe @John Moehrke clarify some of the questions I raised as he has done before).
I will definitely put together some CRs to add diagrams, clarifications, and hopefully fix any non-conforming example.
John Moehrke (Jan 27 2020 at 02:27):
I am not a fan of the current model with a zeroth provision as a context setting ... I have argued against this model since it first happened. The context setting should be root elements, with the provisions starting with exceptions to that context. As it stands, I think that the model sets up the zeroth provision as nothing more than setting the context. Thus it is most clear when the policyRule is a policy written in PERMIT terms. Thus the current discussion about what it means to have a policyRule that is negative (e.g. OPT-OUT) with a root provision of PERMIT? I would far prefer we go back to separation of context setting, from rules.
David Pyke (Jan 27 2020 at 13:00):
Your objections have been noted. Thank you for your input.
Mohammad Jafari (Jan 27 2020 at 16:18):
Thanks @John Moehrke .
Do you think our effort should be focused on clarifying the existing semantics by adding more documentation and fixing the examples, or should we focus on improving the model based on John's concerns and mine? Depending on what direction we lean towards, I will start working on CRs and will report here.
David Pyke (Jan 27 2020 at 16:35):
John's concerns have been discussed and we have decided to not restructure the model. Please focus on the documentation
John Moehrke (Jan 29 2020 at 14:25):
everyone is free to enter their concerns as Change Requests. That my concerns have been dismissed should not prevent others from bringing up their concerns. This resource is FMM 2, so it should be considered very open to change
David Pyke (Jan 29 2020 at 14:30):
We certainly accept CRs and encourage them. However, as we're shooting for Normative for R5, we are carefully considering breaking changes.
John Moehrke (Jan 29 2020 at 14:31):
THAT is not governance for FMM2. That is the governance that kicks in at FMM5.
David Pyke (Jan 29 2020 at 14:37):
I didn't say we were not accepting breaking changes, just carefully considering them. They will need a strong case before they're accepted simply because we don't want to refactor everything because someone doesn't like the current structure
Lloyd McKenzie (Jan 29 2020 at 16:41):
It's not a question of "like", it's a question of "does it work" and "is it as easy to use/understand as we can make it"? I would be surprised to see Consent on the normative track for R5 because I haven't seen it in nearly the same level of widespread use that most of the other resources being contemplated for Normative are (e.g. AllergyIntolerance, Condition, Procedure, Practitioner, etc.) Changes should be evaluated based on their merits, not based on a work group's preferred timelines for maturity progression. If the resource currently meets the criteria for level 4 or 5, the work group can certainly solicit implementer feedback about a proposed change using the established mechanisms. If there's a better way and the community agrees that the new way is better, then the change should be made - even if that extends the time before the resource can hit normative. (On the other hand, if the community doesn't feel the change is worth the impact on existing systems, we need to take that into account.)
David Pyke (Jan 29 2020 at 16:47):
So far, we have had a few discussions on the merits of John's suggestion and, each time, it has been decided that it's not the way we want to go. If someone has a business case that shows a different need, we will always give it further consideration. So far, it's been only academic discussion
Jose Costa Teixeira (Jan 29 2020 at 16:49):
I still see Consent being twisted to play the role of Permission. I'd like to figure that out before thinking normative. I'm more conservative on going Normative and I think that Consent is too important. I'd say hold on until the neighbor resource types are clear.
John Moehrke (Jan 29 2020 at 16:54):
So far, we have had a few discussions on the merits of John's suggestion and, each time, it has been decided that it's not the way we want to go. If someone has a business case that shows a different need, we will always give it further consideration. So far, it's been only academic discussion
There has been only one meeting where this was discussed and it was when I was not available. Since then my issues have been swept away with the statement that they were previously discussed with a different group of people who have never shown up again.
Jose Costa Teixeira (Jan 29 2020 at 17:17):
I'm not comfortable with needing a strong case for breaking changes. Now is the time to evaluate and redesign if needed. Otherwise we are saying our initial design was the best and we had a strong case to make it like this, when perhaps it was just the consensus at the time with a given scope.
Jose Costa Teixeira (Jan 29 2020 at 17:17):
I remember suggesting renaming and rescoping medicationPrescription to medicationOrder and being told that this would never happen because 'this has been discussed at length and we cannot change the name and cope of a resource like that'.
David Pyke (Jan 29 2020 at 18:17):
The consent resource has evolved frantically from John's original design and we continue to make changes. John's request is a breaking change that we have discussed more than once and rejected. We are not adverse to change but if it's breaking, it needs a real world use case after 2.5 years of revisions
Jose Costa Teixeira (Jan 29 2020 at 18:52):
true, but I recall that medicationPrescription did change the name.. :)
Mohammad Jafari (Jan 30 2020 at 00:55):
I agree that before cementing the structure we need to make sure that it works at least for some implementers. I am in the course of implementing a consent processor module and I found the design counter-intuitive. But the lack of documentation and some (perhaps legacy) non-conforming examples makes it very confusing and impossible to understand if I were to only rely on the specs.
I think the relevant question at this point in the thread is the experience of other implementers with the current provision structure, particularly the way the top provision is interpreted. Has anyone implemented this part? Does it work? Would it work better if it were to change?
Last updated: Apr 12 2022 at 19:14 UTC
