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: Re: [xacml] Draft BTG Profile


I agree with Ludwig. An Advice with a standard ID defined in a profile allows for interoperability. The PEP can enforce that the caller presents the necessary and expected attributes in order to perform the BTG. In addition the PEP should LOG the BTG operation so that an alert can be initiated, auditors will be advised, etc.

Doron Grinstein
CEO
BiTKOO



On Nov 25, 2010, at 7:06 AM, "Ludwig Seitz" <ludwig@axiomatics.com> wrote:

> 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


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