Re: [xacml] Draft BTG Profile

[Erik Rissanen <erik@axiomatics.com>]

Hi David,

There are a couple differences. Advice has an explicit expression syntax 
in the XACML policy schema, so the behavior of it can be controlled in 
the policy. The status code facility is much more limited in the spec. 
Only a couple of error codes are defined and there are no standard 
expressions to control how the status detail is constructed. The status 
code mechanism was defined before I joined the TC, so I don't know the 
original motivation behind it, but I have always viewed it as a way for 
an implementation to signal errors in the processing. It's not intended 
to be used as part of normal policy decisioning. That is what advice is for.

Best regards,
Erik


On 2010-11-25 18:57, David Chadwick wrote:
> I dont see the difference between standardising a status code in a 
> profile and standardising an Advice in a profile, except for one thing
>
> Advice is not available to XACMLv2 implementations
>
> regards
>
> david
>
>
>
> On 25/11/2010 15:29, Doron Grinstein wrote:
>> 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
>>
>> ---------------------------------------------------------------------
>>
>>
> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>>
>