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>

Thanks for your answer Seth.

Sometimes Subjects are Subjects and sometimes Subjects are resources:-)

Ideally I would stick the xml representation of the "subject" if used
as resource in <ResourceContent> or in <SubjectContent> as the case
may be...

Hope that gives some idea of where I was heading with my question...


On Wed, 30 Mar 2005 21:52:28 -0500, Seth Proctor <Seth.Proctor@sun.com> wrote:
> 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?
> seth

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