Re: [xacml] Draft BTG Profile

[Ludwig Seitz <ludwig@axiomatics.com>]

On Thu, 2010-11-25 at 14:36 +0000, David Chadwick wrote:
> Hi Ludwig
> 
> answers below
...
> >
> > Hi David,
> >
> > I have some questions related to the proposed approach:
> >
> > 1.) You propose to introduce a new status code. Why not simply use
> > Advice instead? It seems a bit superfluous to add new elements to the
> > standard when there are suitable elements in the standard already.
> 
> the whole purpose of standardising the status code is so that different 
> implementations can interwork without having to find out what the status 
> code or Advice element is that is being set by a particular PDP.
> 

Yes but you can achieve the same effect by just standardizing Advice-ids
in a profile, without adding new elements to the XACML-schema and
without requiring new behavior.

> > 2.) You propose to introduce a new element called<Consequences>. Why
> > not use either Advice or Obligation with AttributeAssignments instead?
> 
> We have used the syntax of Obligations, because this is what they are. 
> But with one difference. They are future obligations that will come into 
> effect if some future event happens. We did not want to call them 
> obligations, since the semantic of these is quote "An operation 
> specified in a policy or policy set that should be performed by the PEP 
> in conjunction with the enforcement of an authorization decision"

Ok I guess then your approach with the "future obligations" is the one I
don't see as necessary.

Why not use this procedure:

1. Return an Advice "user can BTG" with the Deny decision
2. Offer the user to perform the BTG action. If the user chooses to do
so, a new attribute for that user is created.
3. Resubmit the original request with the new attribute
4. Other policies matching the BTG attribute now permit access (possibly
with Obligations requiring special auditing).

> > General question:
> >  From the document you provided I cannot see the necessity for
> > introducing new elements into the standard. Could you try to explain
> > which functionality are you want to achieve that cannot be realized with
> > the existing features of the standard?
> 
> 1. A standard way of specifying this response type. By its very nature 
> it needs to be in the standard.
> 
> 2. A standard way of indicating future obligations.

I still don't see the necessity for changing the standard to implement
this use-case. In fact Swedish healthcare implements BTG policies using
XACML and the approach sketched above. So I'll try to clarify my
question:

Given the fact that standardizing BTG in a profile is useful, why can it
not be done without introducing new elements/functionality/behavior in
the standard?

 
/Ludwig

-- 
Ludwig Seitz, PhD             |   Axiomatics AB
Training & Development        |   Skeppsbron 40
Phone: +46 (0)760 44 22 91    |   SE-111 30 Stockholm
Mail: ludwig@axiomatics.com   |   Sweden

This is a digitally signed message part