[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Groups -draft-saml-xpath-attribute-profile-05.pdf(draft-saml-xpath-attribute-profile-05.pdf) modified
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. - 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! - 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." - 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. - Using "xpath:" in the example section for ResourceIndicator is misleading; a canonical prefix like "xpathprof:" or "samlxpath:" or something might be clearer. - 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. 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? Eve cmorris@novell.com wrote: > Information about the document named > draft-saml-xpath-attribute-profile-05.pdf > (draft-saml-xpath-attribute-profile-05.pdf) has been modified by Mr Cameron > Morris. > > Document Description: > PDF version of sstc-saml-2.0-xpath-attribute-profile-draft.sxw > > View Document Details: > http://www.oasis-open.org/apps/org/workgroup/security/document.php?document_id=14043 > > Download Document: > http://www.oasis-open.org/apps/org/workgroup/security/download.php/14043/draft-saml-xpath-attribute-profile-05.pdf > > > PLEASE NOTE: If the above links do not work for you, your email application > may be breaking the link into two pieces. You may be able to copy and paste > the entire link address into the address field of your web browser. > > -OASIS Open Administration -- Eve Maler +1 425 947 4522 Technology Director eve.maler @ sun.com CTO Business Alliances group Sun Microsystems, Inc.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]