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