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
- From: Maryann Hondo <mhondo@us.ibm.com>
- To: "Cameron Morris" <cmorris@novell.com>
- Date: Thu, 7 Apr 2005 12:15:28 -0400
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]