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 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



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


David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5


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