OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

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

Subject: Re: [xacml-users] Reg. <ResourceContent>


The context node for the XPath expression in an AttributeSelector is the
entire xacml-context:Request element (XACML 2.0, Section 5.42).  This
means you are free to define new Subject, Action, and Environment
Attributes called, for example, "urn:...:SubjectContent",
"urn:...:ActionContent", and "urn:...:EnvironmentContent", and specify
that these Attributes are for holding XML schema instances that describe
the Subject, Action, and Environment.  You can use AttributeSelectors to
access content from these new Attributes just as you can for an XML
schema instance in the ResourceContent element.  Maybe this is what you
meant by saying "create custom Attributes", but I wasn't sure.

As Daniel says, I believe the main reason we defined a special
ResourceContent element, rather than letting this information be in a
Resource Attribute, is that XACML was originally designed to protect
access to XML documents, and was then extended for more general use.


Prakash Yamuna wrote:
> Well frankly what I would have preferred is having some predefined
> buckets maybe like :
> <Request>
> <SubjectContent>...</SubjectContent>
> <ResourceContent>...</ResourceContent>
> <ActionContent>...</ActionContent>
> <EnvironmentContent>...</EnvironmentContent>
> </Request>
> Then use AttributeSelector that supported retrieving both text
> (attribute, cdata, etc) and elements that also takes in the datatype
> for the XPath - thus retaining typing.
> It lowers the barrier to support XACML and would have kept things very
> simple in my mind - but then again I maybe wrong:-)
> prakash
> On Wed, 30 Mar 2005 22:25:09 -0500, Seth Proctor <Seth.Proctor@sun.com> wrote:
>>On Mar 30, 2005, at 10:12 PM, Daniel Engovatov wrote:
>>>>In general, however, I think this is
>>>>cleaner than defining a catch-all section where you can dump
>>>>XML-encoded data. That's just my opinion..
>>>Actually, IMHO, a catch-all section for the context representation is a
>>>very good idea.   Just stick it separately from Resource and name it
>>I think you conflated two ideas here. I was talking about taking the
>>existing structure, but adding a section to Subject, Action, and
>>Environment that lets you dump _XML_ data. I don't like this idea. I
>>was not talking about changing the complete context representation.
>>>Getting down that road - Subject, Action etc are not really needed
>>>either.  They are just for ease of management. Should be just some,
>>>maybe predefined, extensible "buckets" - to associate with various data
>>>sources.  :)
>>They're not needed, but I think they're very useful in practice. "Ease
>>of management" should not be taken lightly :)

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

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