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] Notes of focus group meeting


Colleagues - I just remembered that one of the reasons for making the <PolicyIssuer> element optional was for backward compatibility with v02.  Are people ready to abandon that?  All the best.  Tim.


From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Friday, April 22, 2005 11:22 AM
To: XACML
Subject: [xacml] Notes of focus group meeting

Notes
 
Meeting: XACML focus group
Date: 21 April 2005
Present: Erik Rissanen, Tim Moses, Ron Williams, Simon Godik, Michiharu Kudo
 
The discussion focused on Erik's email comments on Draft 02 of the administration policy spec. and Draft 03 of the same.
 
There was general agreement that negative administration policies were not required.  That is, there is no requirement to support policies that prevent someone from writing a particular policy.
 
The situation was not so clear when it came to administration "deny" policies.  That is, writing policies that allow someone to write a "deny" access policy.  There could be use for such a "veto" facility.
 
It was clarified that "isolated" access policies are combined according to the PDP's "base" policy (see Section 7.13 of the core spec.).
 
Simon said that he had a great deal of difficulty understanding Draft 03.  He would like to see Frank's description from May '04 included in the "processing model" section.
 
He would like to see the name of the <PolicyIssuerMatch> element changed to <Delegate>.  And it should be of type AttributeValueType.
 
ed.  Should this (like the other contents of the <Target> element) be a <Delegates> element, containing a disjunctive sequence of <Delegate> elements, each of which contains a conjunctive sequence of <SubjectMatch> elements?
 
Simon would like to see the <PolicyIssuer> element be mandatory and define a fixed value (e.g.e "root") for its contents when the PDP is the issuer.
 
We talked a little about Erik's suggestion for an additional <Target> element to place additional constraints on subsequent links in the delegation chain.  His proposal was not fully understood.  So, he offered to prepare an email on the subject.
 
All the best.  Tim.


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