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)


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