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


Subject: Re: [xacml] Minutes of XACML TC Meeting - April 13, 2006


I have a small correction on the minutes and some thoughts about
revocation. See below.


Bill Parducci wrote:

> Minutes of April 13, 2006
>
>   #22 Right to revoke: We now have conditions on right to issue a
>       policy, but none on right to revoke a policy.  There are many
>       types of revocation.  Currently the administrator (someone who
>       satisfies a delegate condition in a "supporting" policy) can
>       remove any policy (good for historic attribute support).  A
>       policy that arrives with a request is used to evaluate only
>       that request and is then automatically revoked.  PRP="Policy
>       Revocation Point".  Bill suggested that this is an
>       implementation issue. OPEN.


"Currently the administrator (someone who satisfies a delegate condition
in a "supporting" policy) can  remove any policy ...." is not correct.
Currently, there is no specifictaion on revocation in the draft.

What I was describing was a desired feature in the application I have
been working on. My description on the wiki
http://wiki.oasis-open.org/xacml/RightToRevoke of the revoctation issue
includes an attempt to provide this functionality. At SICS we are
currently experimenting with this model of revocation.

I am not sure whether this model of revocation is what people in general
would like to have or how well it works in reality. Yet. :-)

I also have a feeling that revocation might be implementation specific.
We could define an extension point in the processing model to allow for
revocation. It could be as simple as saying: "A PDP MAY take additional
information on revocation into account and choose to not evaluate some
policies."

This would allow more complicated revocation models, such as the one I
am experimenting with, where the validity of a revocation depends on the
situation. Such models cannot be expressed as simply removing policies
before evaluation begins.

Regards, Erik



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