[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Questions on "Introducing attribute categories"
1. Yes, this is for multiple resources profile. 2. I thought that the main use case is for a resource being a general XML document - we also refer to this in hierarchical resources profile. It seems to me that this is a use case that is quite distinct. As far as specifying it as an attribute value - interesting - but for the rest of attributes we usually do have an atomic data type defined, while this is complex content. How would you refer to its data type in the designator? P.S. My personal preference is for this to be defined as a completely separate piece: you have a request document specifying attributes to be retrieved by an attribute designator, and you provide an arbitrary XML document separately that is the base for attribute selector. That gets rid of "any" content, also makes strong typing for this XML context evidence easier to define. I do not have a strong opinion on this issue though - let's keep it open until we are ready to edit the hierarchical resources profile. Daniel; -----Original Message----- From: Anne Anderson [mailto:Anne.Anderson@sun.com] Sent: Thursday, March 16, 2006 8:44 AM To: OASIS XACML TC Subject: [xacml] Questions on "Introducing attribute categories" RE: http://lists.oasis-open.org/archives/xacml/200603/msg00002.html Two comments, plus one stated by Erik: 1. Section 2.2 says [Current specification ... defines] "Resource category Multiple resource groups may be specified in request" Is this referring to the "Multiple resources profile"? Otherwise the current specification allows for only one group of attributes for one resource. 2. Section 4.1 says [In this proposal, in the Request schema] "<Resource> and <ResourceContent> elements are preserved, so that path expressions used to identify parts of the resource content in XACML 2.0 need not be changed." I don't see why these are kept when <Subject>, <Action>, etc. are changed, and path expressions used to identify parts of XML element-valued Attributes in those other sections will have to change. While we are at it, is there a good reason why "ResourceContent" can't be an XML element-valued Attribute just as Subject, Action, and Environment Attribute values that are XML elements are? 3. This comment comes from Erik: For the delegate category, we need a way to distinguish a category not being present from a particular Attribute not being present. Lack of a delegate category is how an access policy is distinguished from an administrative policy. -- 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]