Hi John
In an earlier posting John Davis identified 4 use cases, which are worth
repeating again here
a) those who have permission to access the resource (e.g., ANY
permission that grants access)
b) those who are denied access to the resource (e.g., possess NO
permission for the resource)
c) those who are normally denied access but may choose to BTG and gain
access if they deem it appropriate (e.g. they break the barrier by
"choice" not by asserting any further/special permissions).
d) those who are normally denied access but may gain access by
elevating privilege
We both agree that c) is BTG, but we still dont agree on the mechanism;
specifically, whether a permission to perform the BTG action is needed
or not. I believe in the general case it is, John believes it is not and
that it can be implied by context.
There is also the issue of whether overriding access control is a
different use case to BTG or is the same as the BTG use case above. I
believe it is the same as the BTG use case. You believe it is different.
Therefore it would be good if you could add a fifth use case to the
above 4 which describes why override is different to them.
On 29/11/2010 17:24, Moehrke, John (GE Healthcare) wrote:
> I agree with much of the sentiment that we need to make sure we
> understand the problem well before we solve it. I do however believe
> that we have multiple useful use-cases. Some environments do indeed
> want to have a permission that is only assigned to senior clinicians
> where they are privileged to override. I do agree with Mike that this
> should not be called BTG, as I agree with Mike that we should be
> consistent with our understanding of what BTG is vs other use-cases.
> We have tried to come up with just as catchy names of these other
> use-cases.
>
> Another aspect of these set of use-cases that I am not seeing is that
> in the case where a user override would allow something, there is a
> predicate communication that likely preceded this. For example, how
> did the clinician know that a document existed for which they are
> being denied access with an override possibility?
A normal intuitive guess is one answer. Here is one example of this. The
doctor has a patient in A&E. The doctor looks up the patient name in the
DB, and then asks to read the patient record. This is returned. He then
asks to retrieve the DNA records (or other sensitive data such as AIDS
etc.) and is denied access with a BTG response. He enters a reason
(person is bleeding in A&E) and breaks the glass. He is then granted
access. We have another live demo example and test here
https://authz.tas3.kent.ac.uk:8443/btg/
Typically this
> predicate transaction needs also to understand that access is
> contingent on future state change. If the user could not use an
> override, then the predicate transaction should not return the
> result. (note that this is also regionally defined in policy; as I do
> know of regions/organizations that do want to tempt their clinicians
> with objects that they couldn't get access to at all; whereas other
> regions do not ever want to tempt their clinicians.)
>
> So, this is not just the use-case of the transaction where BTG flag
> would be submitted, but this also affects other transactions too. I
> don’t think this changes the potential solutions, but does broaden
> the description when we get around to that.
this does indeed broaden the potential use cases considerably if we are
concerned with an action now that can effect another action many steps
down in a workflow. I must admit that we have not yet considered such
use cases
regards
David
>
> John
>
>>