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

["Eve L. Maler" <Eve.Maler@Sun.COM>]

Hi Cameron-- You might be going farther than I intended to go.  What 
I mean by a URI "representing" these meanings is just that the 
NameFormat is supposed to explain how to interpret the Name, and it 
doesn't, in standalone fashion, have to actually convey the set of 
valid/possible names -- it just has to convey that such a set 
exists.  In other words, it's just a category.

So if you see a NameFormat of "urn:fooW3Cwhatever:XPath1.0", you 
know that the name might be an arbitrary XPath V1.0 path into some 
document, potentially with no connection to valid DST usage.  If you 
see a NameFormat of "urn:fooLibertywhatever:aDSTflavorofXPath" you 
know that the Name will be an XPath derived from a set governed by 
the relevant DST resource's metadata.

	Eve

Cameron Morris wrote:
> 
> 
>  >>>"Eve L. Maler" <Eve.Maler@Sun.COM> 04/06/05 11:46 am >>>
>  >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"
> Excellent.  I had it in my head that we should use the urn NameFormat, 
> since that's what the other attribute profiles do.  But this is better.
>  
>  >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?)
> This would be great.  Would we have define one or could we use the 
> URL="_/http://www.w3.org/TR/1999/REC-xpath-19991116/_"; and the similar 
> one for xpath 2 when it comes out?  
> 
>  >- 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)
> 
> For an SP to query for attributes, this minimum set will have to be 
> known. Yes, the DST does not define any minimum subset, but each service 
> that implements it does.  So if the SP can discover which services are 
> available (I'm thinking metadata) then the minimum subset could be derived.
>   
> However, once we have the attribute with an XPath name in it, we no 
> longer need to know the subset of supported xpaths.
> 
>  >- Some URI representing "the precise set of XPaths explicitly
>  >authorized for this resource by the DST framework"
>  
> Again, once an SP has attributes with the XPath name in it, the 
> supported xpaths are no longer relevant.  So I don't think this should 
> be defined here.  
> 
> I'm not exactly sure how, but I was thinking this could be done by 
> metadata.  The metadata use case is one we haven't really explored.  But 
> here is a proposal: Let the metadata enumerate the supported xpaths 
> (Minimum allowed or all supported, I'm not sure)
> 
> Wow, It's amazing to me how difficult it can be to define a few 
> attributes.  I thought this work was going to be trivial :)  However, 
> this does make me appreciate the magnitude of work that goes into 
> creating specs as large as SAML.
>  
> - Cameron

-- 
Eve Maler                                      eve.maler @ sun.com
Sun Microsystems - Business Alliances     x40976 / +1 425 947 4522