OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: BTG sequence diagram

This is to respond to David Chadwick's notes [1] and [2] and to try to
explain what I believe is the correct sequence of a BTG episode.

In [1], David describes three evaluation scenarios:

1. "If action = read and role=Doctor and resource=medical record and 
BTGstate = True then grant access"

No problem here--it corresponds to the last user interaction in attached sequence diagram.

2. "If Action=SetBTG and .... then grant with obligation set BTGstate to 
True in StateDB."

I guess it could work this way, but if we identify a "GlassManager"
service, the user would request the GlassManager to break the glass, who
in turn would make an authorization request, verify permission, and take
the action, and return an appropriate message (perhaps including
obligations) to the user.

3. "If Action=ResetBTG and .... then grant with obligation set BTGstate
to False in StateDB"

I did not show this interaction, but it would look like the illustrated
interaction for "breakGlass".

Now, more generally, to respond to [2], refer to the attached sequence
diagram, which represents a rather purified view of the components and
their interactions.  Many variations on this are possible, but the
variations I do not want to sanction with a standard are the ones that
would have the PEP, PDP, or PIP doing things that degrade their
functional independence or extend their specified behavior, or that
would overload the XACML request/response mechanism with additional
meanings.  David's last formal proposal [3] has all of these risks,
although subsequent discussion has mitigated some of them.

One feature of that proposal that has not been discussed much is the
initial BTG obligation (section 2.1).  This would require the PDP not
only to apply the policy to the original request (for data), but also to
find and apply a policy to a hypothetical request to break the glass.  I
don't know of a policy feature to induce this behavior, nor any type of
stanard request that could do this.  The policy could return the state
of the glass as an obligation attribute, but that is all it could do
using standard features.

Maybe if we can agree on the scenarios we want to support (using
sequence diagrams for common understanding) we would have a better
chance of identifying opportunities for standardization around BTG.


[1] http://lists.oasis-open.org/archives/xacml/201104/msg00031.html
[2] http://lists.oasis-open.org/archives/xacml/201104/msg00033.html
[3] http://lists.oasis-open.org/archives/xacml/201102/msg00017.html


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]