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



I'm sorry, is there an actual document for this profile?
I can't seem to find anything on the website.

Thanks.
Maryann


"Cameron Morris" <cmorris@novell.com>

04/07/2005 11:41 AM

       
        To:        <security-services@lists.oasis-open.org>, <Eve.Maler@Sun.COM>
        cc:        
        Subject:        Re: [security-services] XPath Attribute Profile: XPath as an        Identifier




>>>"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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]