[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: access control information (formerly... Strawman)
On Tue, 12 Jun 2001, Simon Y. Blackwell wrote: > !!! I had almost introduced the concept of Horn Clauses a few days ago, but > I figured it might be too obscure. I do think it is something we should > explore when defining the policy language. However, coming to agreement on > the standard set of primitive predicates will be a substantial rub! Well, that's what I am doing and it seems to work quite nicely. The only problem you have, is that many people haven't taken classes in logic. :( Just as an aside, I find out that you have to restrict the Horn clauses you write, due to somebody handing you a rouge certificate containing an unterminating recursive definition. Kind of a bad thing,And of course, you need some standard primatives so you don't have entire character based prolog programs inside certificates. However, you can get alot done with just a few, and a full procedure. And you have a well defined evaluation semantics. Cheers, -Polar > > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@syr.edu] > > Sent: Tuesday, June 12, 2001 5:37 AM > > To: bill parducci > > Cc: 'xacml@lists.oasis-open.org' > > Subject: Re: access control information (formerly... Strawman) > > > > > > > > You could go for a strictly logical approach, i.e. Prolog like Horn > > Clauses. Then you have a semantics. You just have to standardize the > > primative predicates. > > > > -Polar > > > > > > On Mon, 11 Jun 2001, bill parducci wrote: > > > > > "Simon Y. Blackwell" wrote: > > > > > > > > The problem with "insufficient funds to access" is it requires an > > > > understanding of the meaning of the constraint "balance > > > $5,000". (Yes, I > > > > know by policy example was not precisely in this form > > ...). To avoid the > > > > requirement that the policy engine actually understand > > the semantics of the > > > > constraint, I suppose it could return "balance < > > ?required-amount" which > > > > would only require programming the policy engine such > > that it understood the > > > > semantics of some finite set of operators. It still gets > > pretty ugly though. > > > > > > ugly indeed. no matter which way you take this there are issues of > > > 'ugliness'. on one hand you are faced with developing a library of > > > discrete responses that could be virtually limitless in > > number if they > > > are to provide usable information to all known test cases. > > on the other > > > hand, as you point out, application specific responses are likely to > > > require some sort of out-of-band (predefined) understanding of > > > semantics, etc. to react properly to the message (otherwise > > you are no > > > better off receiving a detailed response vs. 'no. go away'.) > > > > > > perhaps the middle ground is the development of some generalized > > > semantics based upon the content of the request. > > > > > > <winging it/> suppose a doc had <balance> as a field, your response > > > above would be a valid message ("balance < > > ?required-amount"). in other > > > words, responses would be based upon some generic > > expressions (<, >, <>, > > > =, +/-, etc.) and are limited to those fields presented in > > the request > > > itself. of course a document could be submitted that is missing > > > necessary information, in which case you would be stuck > > responding with > > > 'all necessary information not present' or some such, but > > as mentioned > > > above, it is hard to think of a scenario whereby a valid > > requestor can > > > be totally ignorant of the recipient's requirements and > > still be able to > > > act in any meaningful way to the response codes reagardless of their > > > content. > > > > > > b > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC