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: [xacml] Change request: separating round, abs,floor and othe r function.

>I don't care about extension functions. Once you've gone beyond the
>specified ones, the whole evaluation stragegy is up to you and you can do
>what ever you want.

I remember us agree, in L.A., that the extension functions are an important
aspect of XACML, and we need to support it.

> I don't want people writing policies relying on exceptional ERRORs.

It is not relying on ERRORs in any form.  There is no exceptions or
evaluation interruption
It is clearly identifying situations when dynamically presented context can
not be used for 
computing, and communicating this state clearly.  We do have INDETERMINATE
result - and we 
agreed it is necessary to support

Another issue is:
if length(age) = 1 and first-of(age) = 30
will yield false if age atribute has two values.
if age = 30
with equality function defined to accept single<integer> will yield an

I do think that the second case is more useful - as the inability to compute
is communicated - rule is INDETERMINATE rather then NONAPPLICABLE, and I
think it
is the very reason to have that as two separate states.

The fact that the length of the sequence "age" is checked at runtime is no
bigger deal that
the syntax is checked at runtime to be an integer.

And one still can write the first way, if needed, and use ordered-and, so
nothing is taken away.

> XACML function can be interpreted INTERNALLY, within implementation,
> to have such length enforcement logic - PAP can deal with that if
> needed.

>I'm looking for a formal language that can be verified, typechecked, and
>reasoned about. No PDPs, no PAPs, no PEPs. Just language.

There are multiple languages that can do that, and even more then do not.
It does not look like XACML is a language in this sense, at all.
We do already have PDPs, PAPs, PEPs, external data sources, client
applications and
extensions, and we have to deal with it.

Extension will not be written in the language of our choice, nor will they
follow easily expressible logic for ability-to evaluate.  Not having an
as a reserved result will require each extension to define its own mnemonics
to communicate
computation failure, which is not user friendly at least.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC