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)



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