[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 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 > > > -- ***************************************************************** 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]