RE: Assertions and query architecture proposal

[Phillip Hallam-Baker <pbaker@verisign.com>]

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