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>

On Mar 30, 2005, at 9:32 PM, Prakash Yamuna wrote:
> Section 6.4 states:
> [...]
> The key phrase that struck me was - "notional placeholder for the
> content of the resource" - hence my assumption that <ResourceContent>
> can be used only for xml content representation of resources.

Your assumption is correct. Sort of. The ResourceContent element is the 
standard place to include some or all of the content (ie, the resource) 
that you're trying to access. Since it's being provided in XML 
(typically), the content must be represented here in XML. That does not 
mean, of course, that the original document must be in XML. It only 
means that it must be representable here (as you say) in XML, so that 
it can be queried. For that matter, the context does not physically 
need to be XML, it just needs to hold to the required semantics, but in 
practice the Request is often an XML document.

What's the point? You may want to include rules in your policy that are 
based on elements of the resource being accessed. One way to do this is 
with designators, and then you either include the values in your 
Request or have some custom handler in your context (in my 
implementation, this is called an AttributeFinderModule) to pull the 
value from the document. In an XML world it may be more natural to use 
XPath, so a selector can be used instead, and the normative place to 
look for values is in the ResourceContent.

As Daniel said in his last email, there is no notion of a 
SubjectAttributeSelector (etc.) since the ResourceContent values may be 
applied as any kind of attribute.

Getting back to your original question, I'm not entirely sure I 
understand where you're going. What would a SubjectContent look like? 
Or are you trying to create a new place to hold arbitrary subject 
attributes in structured XML?


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