[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Assertions and query architecture proposal
Having read Dave's draft I find that I am in agreement with most of it. Some points: 1) Decision Assertion, This needs to be tied into the request-response protocol since the decision will have no meaning without the context of the request. 2) Nesting I would still prefer to introduce typing at the level of <Claims> and not at the toplevel. I could live with an <AuthorizationClaim>, an <AttributeClaim> structure etc.. 3) Conditions Conditions needs to be in the basic information package. It is basic extension infrastructure. The only reason for excluding it from the basic information package is that the <DecisionAssertion> does not include it. I would prefer to treat decision assertions as part of the request/response protocol, if they are important enough to have the rest of the basic information set then there is reason to expect that condition extensions may be required. In fact a decision assertion is probably more likely to involve the need for an audience restriction than other types of assertion. 4) Permissions It may seem minor but spelling out Read and Write seems a good idea, this is XML after all. More importantly I don't understand the semantics of 'Use' or 'Admin'. The term 'Control' is well defined in VMS - a person with control permission can set access control policy to the resource. Admin could mean 'control access policy' or could mean perform other admin functions on the resource. Equally 'Use' does not seem particularly well defined. 'Edit' and 'Delete' are well defined. 5) Attribute Assertion At present this requires the introduction of a foreigh schema to define any attributes or roles. While I agree that allowing for such schemas is usefull and necessary I think that a lot of milage can be gained from using URIs to represent 'atomic' attributes and roles. 6) Query Language The query language appears to introduce highly structured data that is not formatted in XML. The Query Language appears to me to be very much more complex than regular expressions and involve a lot of unspoken assumptions about policy becomming explicit in the SAML architecture. If I am not allowed my trailing * to indicate 'all the resources within this hierarchy' then I think that the query language has to be excluded. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Orchard, David [mailto:dorchard@jamcracker.com] > Sent: Tuesday, June 05, 2001 12:26 AM > To: security-services@lists.oasis-open.org > Subject: Assertions and query architecture proposal > > > I submit a document, draft-orchard-assertion-proposal-01.doc > to the TC. > It's by no means complete, but it's best to start the ball > rolling with a > concrete proposal. > > I used much from the current assertions draft, and created > some examples > based upon PHB's examples. I also cleaned up some of the > syntactic errors > in the schemas. The schemas and examples in this document are valid, > potentially this is a milestone for SAML. This would have > been much easier > if a complete xml schema had been provided. The examples and > schemas may > look longer than the ones listed in the assertions proposal and the > examples, partially because my proposal is fully namespace > qualified and > validates. > > The motivation for this work is that after much time on S2ML > and SAML, I > still don't understand the work on claims, bindings, objects, > roles, and how > they relate to assertions. I found the assertions structure > difficult to > understand and counter-intuitive. I have been pushing for > top-typing and > use of XML Queries, so I also wanted a concrete proposal. The areas of > extensibility are defined in the proposal. This proposal > also shows some > expected extensions, but I didn't have time to create use-cases and > requirements for them. > > Having said that, I am finding some aspects of PHB's design > to be subtle and > elegent, particularly the combination of assertions and > assertion queries. > At the least, I understand the motivation for some of the > constructs better. > > Dave Orchard > XML Architect > Jamcracker Inc., 19000 Homestead Dr., Cupertino, CA 95014 > p: 408.864.5118 m: 604.908.8425 f: 408.725.4310 > > www.jamcracker.com - Sounds like a job for Jamcracker. > >
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC