OASIS eXtensible Access Control Markup Language (XACML) TC

Re: [xacml] Draft BTG Profile

  • 1.  Re: [xacml] Draft BTG Profile

    Posted 11-30-2010 08:37
    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
    > 
    >>