[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] XPath Attribute Profile: XPath as an Identifier
Thanks, John. So, given this and the fact that Cameron is explicitly trying to connect this SAML usage with the broader DST usage, a naked XPath would be sufficient because the XML resource it addresses into is identified by the surrounding framework. So (keeping in mind that we keep rushing towards solutions in order to better understand the problem!) this alternative would be preferable among the two I presented: NameFormat="TheNameIsAnXPathBlahBlahBlah" Name="/pp/LegalName/CommonName" There would be three obvious options for the NameFormat: - Some URI representing arbitrary XPaths as allowed by the XPath spec (it would have to be versioned! 1.0 or 2.0?) - Some URI representing a subset of XPaths we think should be mandatory to support (e.g., streaming, or the subset XSD defines, or whatever -- it would be handy if DST had already done the work to define a relevant subset all services must support) - Some URI representing "the precise set of XPaths explicitly authorized for this resource by the DST framework" Eve John Kemp wrote: > 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 -- Eve Maler eve.maler @ sun.com Sun Microsystems - Business Alliances x40976 / +1 425 947 4522
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]