Re: [security-services] XPath Attribute Profile: XPath as an Identifier

[John Kemp <john.kemp@nokia.com>]

ext Eve L. Maler wrote:

> This thread is helping me understand better what the goal is with this
> profile.  But given that, I have the same (or similar) confusions as
> Scott does.
>
> One thing I'm not fully understanding, which is perhaps a further
> subtlety on Scott's point about XPath addressing into a document, is
> the difference between an attribute name that's theoretically "stable"
> and an XPath that happens to be expressed in a way that breaks
> easily.  Just counting down to the "third <thing>" or whatever may
> silently break the attribute value, if more <thing>s got added to the
> source document and got, say, sorted alphabetically by content.  I'm
> not familiar enough with the Liberty DST so maybe the answer is
> spelled out there, but: What's the persistence of the source
> document?  When and why does it change?

The Liberty DST provides a template for the definition of a service
specification. A DST-based service specification has the notion of a
"virtual" XML document - it may or may not actually exist and be
maintained by the service, but there's a schema which identifies the
datatypes you should use, WSDL describing the messages and so on, and
then a set of processing rules. In general a DST-based service will
specify a set of supported XPaths - these will be the ones that a
consumer can expect to result in reasonable values - they are part of
the specification of the service. A service can choose to support some
larger set of XPaths, but that will then be service instance specific.
So far, the XPaths specified for DST services have been very simple. In
general, I think most such services won't support the full range of
jiggery-pokery possible with XPath. Now, does a SAML Attribute Authority
have to support all of XPath to offer this proposed protocol profile?

BTW the actual "virtual" XML document being "XPathed" is explicitly
identified via a ResourceID sent in the request message. The virtual
document may be modified at will by a (qualified) requester, or by the
service itself. A conforming service just needs to abide by the rules in
the appropriate service specification in what it presents to requesters.

- JohnK

>
> Also, I'm confused as to why you'd jam the actual XPath into a URN.
>  Why not have a NameFormat URN urn:foobarbaz:xpath, and then have the
> Name be the XPath (assuming an XML document whose location is
> implicitly known or provided out of band)?
>
> NameFormat="TheNameIsAnXPathBlahBlahBlah"
> Name="/pp/LegalName/CommonName"
>
> Alternatively, you could have a NameFormat of
> urn:oasis:names:tc:SAML:2.0:attrname-format:uri and make the Name be a
> URI reference (likely http:) to a resource with an XML-related media
> type, with an XPointer-based fragment identifier on it (which could
> use any of the XPointer schemes, though likely you'd want to limit
> them to, say, xpath() and element() or something).
>
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> Name="http://www.example.com/User123.xml#xpath(/pp/LegalName/CommonName)"
>
> Some spec references for the XPointer-curious:
>
> http://www.w3.org/TR/xptr-framework/
> http://www.w3.org/TR/xptr-element/
> http://www.w3.org/TR/xptr-xpointer/ (not a W3C Recommendation)
> http://www.simonstl.com/ietf/draft-stlaurent-xpath-frag-00.html (not
> even a product of the W3C)
>
>     Eve
>
> Scott Cantor wrote:
>
>>> Other thoughts: - "urn:xpath" as a prefix: Is it safe to just use
>>> xpath directly (name="/pp/LegalName/CommonName") or does it need to
>>> have some clarifying prefix
>>> (name="urn:some_name_clarifying_that_this_is_an_xpath_name:/pp
>>> /LegalName/CommonName").  I suppose the problem is that XPath is a
>>> uri and I'm trying to put it into a urn. 
>>
>>
>>
>> Well, I think the problem is that XPath is (generally) a relative
>> URI, and
>> you want an absolute URI. Whether it's a URN or a URL isn't the point,
>> there's no "base" to resolve the thing with.
>>
>> I'm wondering where XPointer fits into this.
>>
>> Lest I be accused of just arguing over naming before we have the use
>> case
>> nailed down, I think this *is* part of the use case. We have to
>> understand
>> how we would interpret the notion of an XPath as a "name" when it really
>> connotes a node set in a particular document, so understanding the thing
>> we're implicitly pointing into is really the starting point.
>>
>> I know XACML has XPath bits in it, but what's the "source" document into
>> which the path is evaluated? Is that just specified along with the
>> XPath?
>>
>> To put it another way, is it worth instead addressing XPath requirements
>> more in terms of how to incorporate attributes by reference, as XACML
>> does,
>> rather than as a simple translation of one thing into another inline
>> format?
>> That seems somewhat more powerful, even if it does introduce the usual
>> question of what it means to sign an assertion that amounts to a
>> pointer to
>> something that the signature doesn't cover.
>>
>> -- Scott
>