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] | [Elist Home]


Subject: RE: access control information (formerly... Strawman)


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


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