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


Subject: Re: Issue: Request query language


At 03:08 PM 5/1/01 -0400, Orchard, David wrote:
>As described in the SAML spec "Request Message" section, starting on roughly
>line 632, there are 2 types of queries listed:
>1) A new request language specified by name/value pairs
>2) A new request language specified by a "template", that is filled in in
>some pre-determined language.
>
>I offer two additional alternatives
>3) XPath/XPointer[1]
>4) XML Query [2]
>
>It is my belief that we do not want to create a query language.  The
>creation of operations that intersect with the constraints expressible can
>be very difficult.   I'd rather re-use portions of an existing language so
>we don't have to explain our grammer, rules, operations, and parser.  I
>assert (albeit weakly at this time) that XML Query should be examined for
>this.  I believe we will define a model - perhaps as a virtual document -
>that can be queried against - assertions of different types in a collection
>- where we will want powerful expression capabilities.  I don't think we
>would need all of XML Queries abilities - such as defining functions or
>manipulation of the output.
>
>Using a W3C query syntax would also assist in deploying SAML in the W3C when
>the W3C decides to define or specify best practices for security in web
>services.

I think it's definitely worthwhile examining all these possibilities.  I'm 
relatively comfortable with the notion of "inventing a query syntax."  Our 
"queries" could be thought of as "requests" of a very specific type rather 
than as generalized queries.  Also, I find that it's sensible to think of 
data models and query languages as pairs; with SAML seen as a higher-level 
"data model" expressed in XML, it might very well want a specialized query 
language.  But doing the analysis in the way you've laid this out will 
probably (I hope!) pop out the right answer.

A few more comments below:

>To illustrate, let's try a sample query:
>"Is carol allowed to access resource Y when using an x509 cert?", with a
>response of yes.
>
>In all examples, I'll exclude the end-tags for brevity.
>
>Now Phil's vmodel core document expresses these as:
>
>Request:
><AssertionQuery>
>    <Resources>
>       <string>http://store.carol.test/finance
>    <Subject>
>       <ds:KeyInfo>
>          <ds:X509Data>...

Phill's version actually seems like the most compact/efficient of all the 
XML options you've listed!

>Response:
><SAML>
>    <AssertionID>http://www.bizexchange.test/assertion/AE0221
>    <Issuer>URN:dns-date:www.bizexchange.test:2001-01-03:19283
>    <ValidityInterval><NotBefore><NotOnOrAfter>
>    <Conditions><Audience>http://www.bizexchange.test/rule_book.html
>    <Subject><ds:KeyInfo><ds:X509Data>...
>    <Resources>
>       <string>http://store.carol.test/finance
>
>So here's how I think the queries would look given the 4 alternatives:
>1)
><requestidentifier>
><PrototypeAssertionsList>
><PrototypeAssertion>
><FieldType>AssertionResource
><FieldValue>http://store.carol.test/finance
><PrototypeAssertion>
><Fieldtype>AssertionSubject
><FieldValue><ds:KeyInfo><ds:X509Data>...
>
>2)
><requestidentifier>
><PrototypeAssertionsList>
><PrototypeAssertion>
><AssertionID>
><Issuer>
><Subject><ds:KeyInfo><ds:X509Data>...
><Resources><string>http://store.carol.test/finance
>
>3)
><requestidentifier>
><Resource
>expr="VirtualAssertionList.xml#SAML/Resource[@string=http://store.carol.test
>/finance]/../Subject/KeyInfo/X509Data[@someinternalelement=carol]">
><!-- See how the request is constructed as a string rather than a set of
>nodes.  Therefore booleans can content values can be done -->
><!-- Note that I'm not completely sure if this is valid XPath syntax, Eve
>would know for sure -->

Not exactly (though I'd have to spend more time than I have right now to 
look into fixing it!), and you've also turned it into a pseudo-XPointer, 
which I suspect isn't warranted in the SAML case.  But people will get the 
drift from this.

Both this option and option #4 use a non-XML syntax to express the "guts" 
of the request, which seems not quite right to me.  XML syntaxes are being 
proposed for XPath (informally) and for XQuery (formally through W3C), so 
we should keep an eye on these developments.

>4)
><requestidentifier>
>FOR $S IN document("VirtualAssertionList.xml")//SAML
>WHERE $S/Resource/string = "http://store.carol.test/finance"
>AND $S/Subject/KeyInfo/X509Data/someinternalelement = "carol"
>RETURN $S
>
><!-- now we're cooking with gas as we can do just about any type of
>expression possible, and we haven't created a new syntax -->
>
>It all depends upon how complex the queries and results will be.  I have a
>feeling people are wanting complex queries - which leans to more of an
>XQuery language.  If it turns out that all of our queries are fairly simple,
>then I'm more comfortable with inventing a simple syntax.

I'm with you on this.

>[1]http://www.w3.org/TR/xpath.html
>[2]http://www.w3.org/TR/xquery/

         Eve
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com



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


Powered by eList eXpress LLC