OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]