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

[Prakash Yamuna <techpy@gmail.com>]

Frankly I am not convinced the attributes are buying all that much anyway...

prakash
On Wed, 30 Mar 2005 19:45:55 -0800, Prakash Yamuna <techpy@gmail.com> wrote:
> Well it doesn't add too much structural complexity but yeah if want
> just <CONTENT> - even better I suppose:-)
> 
> Basically one can easily write XSLT transformations to convert current
> authorization requests to XACML authorization requests...right now it
> is a bit hard to be able to plug them into the attributes!
> 
> 
> prakash
> 
> On Wed, 30 Mar 2005 19:39:56 -0800, Daniel Engovatov <dengovatov@bea.com> wrote:
> > I am not sure how imposing additional structural complexity will "lower
> > the barrier to support XACML" :)
> >
> > Oh, well.  We have what we have now - for 3.0 this may be considered,
> > but I would speculate that having a single XML content root will have
> > more support.
> >
> > D;
> >
> > -----Original Message-----
> > From: Prakash Yamuna [mailto:techpy@gmail.com]
> > Sent: Wednesday, March 30, 2005 7:36 PM
> > To: Seth Proctor
> > Cc: Daniel Engovatov; xacml-users@lists.oasis-open.org
> > Subject: Re: [xacml-users] Reg. <ResourceContent>
> >
> > 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
> > > > <CONTENT>.
> > >
> > > 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 :)
> > >
> > >
> > > seth
> > >
> > >
> >
> >
>