Re: [security-services] Groups -draft-saml-xpath-attribute-profile-05.pdf(draft-saml-xpath-attribute-profile-05.pdf) modified

[Cameron Morris <cmorris@novell.com>]

On Mon, 2005-08-15 at 14:05 -0700, Eve L. Maler wrote:
> Some relatively lightweight comments:
> 
> - In the Introduction, I'd quibble with the description of XPath; 
> since you're deliberately not using it as the fragment identifier on 
> a URI (because of the ResourceIdentifier field you're introducing), 
> nor as some kind of application-specific query at the end of a URI, 
> the description as "a compact URI structure to reference parts, and 
> query for parts, of an XML Document" seems inapt.  If it said "a 
> compact URI-friendly structure to reference parts of an XML 
> document" I would stop quibbling.
> 
Okay

> - The document should probably explain that it's talking only about 
> XPath 1.0 (e.g., including "1.0" in the profile URI identifier), or 
> else include XPath 2.0 coverage as well.  I recommend not making 
> XPath 2.0 support required for conformance to this profile, though!
> 
Okay

> - The first sentence of Section 2.3, regarding the requirement to 
> use xmlns:, reads confusingly.  I think you mean: "A 
> <saml:Attribute> or element that has an XPath-formatted SAML 
> attribute name must have, within its scope, one or more XML 
> namespace declarations (xmlns:) that declare all namespace prefixes 
> used in the XPath."
Okay - I just wanted to make clear that the xmlns doesn't have to be
directly inside the Attribute element.  

> 
> - Same section: You don't say where the ResourceIndicator attribute 
> should be used, nor in the schema snippet do you show the element(s) 
> that contain or reference this attribute.  Also, language here is 
> fairly confusing on the XML vs. SAML attribute front.  Finally, it 
> might be safest if the combination of ResourceIndicator and 
> XPath-formatted attribute name is described in terms of how to 
> properly turn it into a valid URI.

Well, the schema snippet is really the whole schema.  The saml:attribute
element already has an 'anyAttribute' so there isn't anything else to do
schema-wise.  So to clarify the text how about something like the
following:

Current: "The attribute ResourceIndicator MAY specify the URI of a
specific document."

How about: "SAML <Attribute> elements MAY add a ResourceIndicator
attribute to specify the URI of a specific document."

> - Using "xpath:" in the example section for ResourceIndicator is 
> misleading; a canonical prefix like "xpathprof:" or "samlxpath:" or 
> something might be clearer.
Okay

> 
> - The thread from June about providing an entire XML "record" 
> illustrated that, for some, having XML content in the AttributeValue 
> is just what they want.  Since this profile doesn't preclude that, 
> it would be nice to have a mention or example of it in the doc.
I had thought about doing just that. I'll add an example

> 
> And a more heavyweight comment:
> 
> - I'm still worried about interoperability with various XPath 
> subsets.  If the DST is really the one dominating use case here, I'd 
> feel more comfortable with an attribute profile that identifies 
> specific DST-oriented interop/conformance needs, and would at least 
> want to make Section 2.4 a "Conformance" section.  Do we want to get 
> into a situation where there are many non-interoperable subsets of 
> this attribute profile, or would we prefer there to be a series of 
> XPath-based attribute profiles that are specific about their 
> limitations?

I thought we side-stepped this issue by stating that a Liberty
implementation of the XPath attribute profile must implement the minimum
subset required by liberty for conformance (plus the text nodes).

If a Liberty service does not define a minimum subset, then all xpaths
must be supported (that is all absolute, fully qualified xpaths)

I think renaming interoperability to conformance is fine