OASIS eXtensible Access Control Markup Language (XACML) TC

All,

I have looked into how to map the delegation model in the new format
with the open attribute categories. It turns out to work very well and
the categories simplify the delegation specification a lot. Everything
can be done with the normal matching rules and there is no need for any
special delegation treatment, except for the process which generates the
administrative requests. (I hope I am not overlooking anything here.)
There is only one issue with indirect delegates. I have added issues
49-52 in the issues list to cover what I have done so far:

http://wiki.oasis-open.org/xacml/IssuesList

I suggest that, if people like this, I will update the delegation
profile draft accordingly.

What I have done solves issue 33 (how to match any delegate), so if
people like my proposals, we could close that issue.

Also, should we reopen issue 9, backwards compatibility? It is marked as
closed since everything so far has been backwards compatible. The open
categories are not directly backwards compatible, so that is not true
anymore.

Best regards,
Erik

I know it is "messy", but would it make sense to try to support both 
formats, just for backwards compatibility?  I know we have specified an 
exact equivalence between each of the old category formats and a 
corresponding id for a new category, but would it be possible to 
actually support the old category formats in addition?

Just a thought and a question...

Regards,
Anne

Erik Rissanen wrote On 09/20/06 08:55,:
> All,
> 
> I have looked into how to map the delegation model in the new format
> with the open attribute categories. It turns out to work very well and
> the categories simplify the delegation specification a lot. Everything
> can be done with the normal matching rules and there is no need for any
> special delegation treatment, except for the process which generates the
> administrative requests. (I hope I am not overlooking anything here.)
> There is only one issue with indirect delegates. I have added issues
> 49-52 in the issues list to cover what I have done so far:
> 
> http://wiki.oasis-open.org/xacml/IssuesList
> 
> I suggest that, if people like this, I will update the delegation
> profile draft accordingly.
> 
> What I have done solves issue 33 (how to match any delegate), so if
> people like my proposals, we could close that issue.
> 
> Also, should we reopen issue 9, backwards compatibility? It is marked as
> closed since everything so far has been backwards compatible. The open
> categories are not directly backwards compatible, so that is not true
> anymore.
> 
> Best regards,
> Erik
> 
> 

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Do you mean that both 

Erik,

Erik Rissanen wrote On 09/20/06 09:24,:
> Do you mean that both 

Anne Anderson - Sun Microsystems wrote:
> Erik,
>
> Erik Rissanen wrote On 09/20/06 09:24,:
>
>> But I am not sure what the gain would be. XACML 3.0 policies would not
>> be understandable by a 2.0 PDP in any case. A 3.0 implementation can
>> internally translate 2.0 policies into 3.0 form, so it could load both
>> types of policies. Am I correct?
>>
> The gain is that every 3.0 PDP could load 2.0 policies, and not just
> those that choose to do internal translations.  We would essentially
> be making support by 3.0 PDP's for 2.0 policies mandatory.  The
> internal implementation would probably be a translation, but that is
> up to the 3.0 PDP implementer.
>
> Regards,
> Anne

I agree that there is a point in making 3.0 PDPs support 2.0. But
wouldn't it be easier to say that a 3.0 implementation MUST be able to
translate 2.0 policies? I doubt we need the ability to mix 2.0 and 3.0
in the same document.

Regards,
Erik

Good point.  I concede :-)

Regards,
Anne

Erik Rissanen wrote On 09/20/06 09:36,:
> Anne Anderson - Sun Microsystems wrote:
> 
>>Erik,
>>
>>Erik Rissanen wrote On 09/20/06 09:24,:
>>
>>
>>>But I am not sure what the gain would be. XACML 3.0 policies would not
>>>be understandable by a 2.0 PDP in any case. A 3.0 implementation can
>>>internally translate 2.0 policies into 3.0 form, so it could load both
>>>types of policies. Am I correct?
>>>
>>
>>The gain is that every 3.0 PDP could load 2.0 policies, and not just
>>those that choose to do internal translations.  We would essentially
>>be making support by 3.0 PDP's for 2.0 policies mandatory.  The
>>internal implementation would probably be a translation, but that is
>>up to the 3.0 PDP implementer.
>>
>>Regards,
>>Anne
> 
> 
> I agree that there is a point in making 3.0 PDPs support 2.0. But
> wouldn't it be easier to say that a 3.0 implementation MUST be able to
> translate 2.0 policies? I doubt we need the ability to mix 2.0 and 3.0
> in the same document.
> 
> Regards,
> Erik
> 
> 

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692