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: [xacml] We resolve ...


Title: We resolve ...

Colleagues - Here are some candidate resolutions for consideration between now and the Face-to-face.  Naturally, I expect others to submit resolutions that support contradictory positions.  We can use the intervening period to discuss the issues and select a subset of the resolutions for voting at the Face-to-face.  Have a great weekend.  All the best.  Tim.


Resolution 1: The XACML syntax will differentiate between model entities (principal, resource, etc.) in its attribute elements, rather than in its rule elements. [PM-4-01]

Resolution 2: An XACML "applicable policy" will not reference external "applicable policies".  However, it may "incorporate" external "applicable policies". [PM-2-01] [PM-3-01] [PM-5-03]

Resolution 3: An XACML "applicable policy" shall be capable of referencing an external "applicable policy", providing explicit rules for combining such policies. [PM-2-01] [PM-3-01] [PM-5-03]

Resolution 4: An XACML "applicable policy" will contain its own security features (e.g. signature), rather than relying on an encapsulating saml assertion.

Resolution 5: XACML valueRef elements shall be of type "saml:AttributeValueType".

Resolution 6: XACML shall address the requirement for "negative rules" by means of an "and-not-or" construct. [PM-1-01]

Resolution 7: XACML shall require the PDP/PEP to execute just those post-conditions that accompany the rules that contribute to the "permit" decision. [PM-1-02]

Resolution 8: The XACML syntax shall not address the question of which actions are valid for a particular resource classification.  This matter shall be left for implementations to solve in a non-standard way. [PM-2-03]

Resolution 9: The XACML specification shall provide normative, but non-mandatory to implement, text that profiles LDAP for distribution of XACML instances. [PM-2-04]

Resolution 10: The XACML specification shall provide normative, but non-mandatory to implement, text that profiles "the Web" for distribution of XACML instances. [PM-2-04]

Resolution 11: The XACML syntax shall not address the question of ensuring that "applicable policy" is complete.  This matter shall be left for PRP implementations to solve in a non-standard way. [PM-2-05]

Resolution 12: The XACML specification shall specify when a PDP should return saml:decision attributes with the values "permit" and "deny".  If the PDP is unable to render a decision, then a saml status code shall be returned.  No decision value shall be supplied in this case. [PM-3-02]

Resolution 13: The XACML specification shall be closely coupled to saml entities.  However, the use of saml namespace identifiers is not intended to imply that all attributes must be retrieved from saml messages and assertions. [PM-5-01]

Resolution 14: The XACML syntax shall use registered URIs to identify algorithms for processing resource classification wildcards. [PM-5-02]

-----------------------------------------
Tim Moses
Tel: 613.270.3183



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


Powered by eList eXpress LLC