Re: [security-services] XPath Attribute Profile

["Conor P. Cahill" <concahill@aol.com>]

Cameron Morris wrote on 6/1/2005, 12:19 PM:

 > On Wed, 2005-06-01 at 11:38 -0400, Conor P. Cahill wrote:
 >
 > > So, to clarify, I'm proposing that we:
 > >       * name the attribute using the namespace (or, prerhaps the
 > >         schema) for the service
 > >       * place service document into the attribute value rather than
 > >         making this look like single valued attribute.
 > > Conor
 >
 > That certainly can be done.  It doesn't really solve the used cases I
 > originally intended to solve with this proposal (See use cases here:

I don't believe this is true.  Any piece of data, from one to many
can easily be represented in the Attribute value.  Saying you can't do
this is like saying that I can't query the PP for the user name and
get back the user name.  Doesn't make sense to me.

It may be a bit more verbose this way, since you would have the
actual XML tree with the data within it, but that XML is probably
parsed when the assertion is parsed so getting to the elements
within the tree would be very easy and much more natural.

With the proposed xpath method, I have to do some special
parsing of the name of the attribute, then get the data that's
in the attribute value and somehow deal with all the possible
attributes that may have been on that element in its native
format within the service (e.g. the name could have an
attribute that indicates the last time it was changed --
not an easy way to show this in the proposed model, but it
is easy in the alternative I mentioned).

 > Here are some reasons:
 > - Different access rights can apply to different parts of the document.
 > So I'd like to be able to assert parts of the document and not the whole
 > thing.

You can absolutely do that with the solution I presented (note that
I did *not* require that you must return the entire document, just
that you must return the data in the document structure -- this is
the same structure as that used on a pp:Query response).

 > - Liberty data services suggest using xpath for queries.  Supporting
 > xpath in SAML makes an easy pass through to call Liberty services.

This isn't a query, this is a query response.  I'd be fine with
having the attribute query match the pp:Query format.  I'm saying
that the format used in carrying the assertion should be in the
pp:QueryResponse format.

 > - Leaf/text nodes are what I'm after here, I don't want other service
 > providers to have to know what an EP or PP document looks like in order
 > to use the values in them.  (Thus, the document defines that the
 > supported set of xpaths must include all text nodes.  If an SP does have
 > special knowledge of EP or PP then the SP can request additional xpaths,
 > including the root node for the entire document)

What do you mean you don't want them to know?  They get that data in
the xpath anyway, so they do know it.  I also don't think you can
appropriately evaluate many fields in the data without knowing
the location in the document data structure (e.g. there are several
zip code fields in the PP document -- the SP needs to know which
one you are sending back and does with either proposal).

Conor