Hi Erik
Having read Rich's post again, one way of interpreting it is that
nothing needs to be done to the XACML standard since it does not need to
understand BTG or do anything special for it. It only requires the
policy writer to create some application specific obligations that
indicate BTG related actions. I agree that this is one way of tackling
BTG, and this is what we have already done in our existing
implementation (since we had no alternative!).
However, this does not make things easy for applications since they need
to do all the BTG processing themselves. Our objectives in standardising
BTG are two fold:
i) to make it very easy for applications to support BTG
ii) to make BTG supporting PDPs portable by defining a standard way of
supporting BTG.
Using a standardised obligation to signal a BTG response would be (part
of) the solution for ii) so this could work. Defining a standard BTG
action as well would complete ii). We already have the machinery to do
i) by using an XACML PDP wrapper
regards
David
On 29/11/2010 13:38, Erik Rissanen wrote:
> Hi David,
>
> There is also the approach suggested by Rich, which might solve it for
> you: use obligations. It would mean that the PEPs must understand the
> obligation since they cannot ignore it, but it would work in either 2.0
> or 3.0. Would this work for you?
>
> There is no standard negotiation protocol about XACML v2 vs v3 between
> PEP and PDP.
>
> Best regards,
> Erik
>
>
> On 2010-11-29 12:46, David Chadwick wrote:
>> Hi Erik
>>
>> On 29/11/2010 08:58, Erik Rissanen wrote:
>>> Ni David,
>>>
>>> Yes, it is true that XACML 2.0 does not have advice.
>>>
>>> However, the problem with the BTG-status code is that your proposal does
>>> not define in any manner what happens within the PDP to maintain the
>>> state of BTG or to perform the calculations to emit the BTG status code.
>>
>> This is correct. This is because, when Seth was involved in the
>> discussions last year, it was not agreed which component should be
>> responsible for maintaining the BTG state, and flexibility should be
>> maintained here. It could be the PEP, the context handler or PIP (ie.
>> some intermediate component between the PEP and PDP), or the PDP.
>> Consequently the draft profile was written allowing for all three
>> possibilities.
>>
>>
>>> In your proposal the PDP is a black box,
>>
>> again correct, because we make no assumptions about the policy
>> language that is supported by the PDP - the XACML request context is a
>> good standard for interfacing to any PDP that supports any policy
>> language.
>>
>>
>> and although we would define
>>> the status code, there would be no way to write an XACML policy, in
>>> either 2.0 or 3.0 to actually emit the code.
>>
>> This is also correct. Until an XACML PDP is state based I think this
>> will continue to be the case. (In our particular implementation we
>> maintain the state in the context handler/PIP component, and use the
>> existing XACML request context to talk to an XACML PDP, but we need
>> the enhanced XACML request context to talk to the PEP).
>>
>>
>>>
>>> Would it be problematic for you to use the 3.0 schema and advice?
>>
>> Theoretically no, we could use this for the request/response context,
>> but practically it would mean that our PEPs would need to be enhanced
>> to support XACMLv3. The lack of backwards compatibility between V3 and
>> V2 request contexts is a problem. Do you have a version negotiation
>> mechanism specified for PEPs talking to remote PDPs? Or are they
>> supposed to know beforehand which protocol to talk?
>>
>> regards
>>
>> David
>>
>>
>> That
>>> way your (non XACML I presume) PDP can emit the advice in a proprietary
>>> manner, and the 3.0 policy schema can be used to emit the advice by an
>>> XACML 3.0 PDP.
>>>
>>> Best regards,
>>> Erik
>>>
>>> On 2010-11-26 17:41, David Chadwick wrote:
>>>> Hi Erik
>>>>
>>>> Unfortunately this has not answered the fundamental difference -
>>>> Advice does not apply to XACMLv2.
>>>>
>>>> On 26/11/2010 10:26, Erik Rissanen wrote:
>>>>> 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.
>>>>
>>>> But it is sufficient for our needs. So that is OK. You cannot argue
>>>> that a single bit is limited if all you need to represent is a boolean.
>>>>
>>>>
>>>>> Only a couple of error codes are defined and there are no standard
>>>>> expressions to control how the status detail is constructed.
>>>>
>>>> we dont require status detail either.
>>>>
>>>> Plus using a status code provides backwards compatibility for PEPs
>>>> that dont understand the new status value.
>>>>
>>>> So it seems like a perfect vehicle for passing back the new response
>>>> type.
>>>>
>>>> regards
>>>>
>>>> David
>>>>
>>>>
>>>> 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"