RE: Top down or bottom up

["Orchard, David" <dorchard@jamcracker.com>]

It's clear that this discussion isn't going very far on debating the merits
of toppish versus bottomish.  I have decided to combine all of my thoughts
on assertions structure and request/response into a coherent proposal.  I
submit this shortly, so we can then debate objectively by comparing syntax
of queries and structures.  

I do have a suspicion that I look at an assertion as a toppish "claim" and
an assertion Collection as your view of an Assertion.

comments inline as well.

> -----Original Message-----
> From: Phillip Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Monday, May 28, 2001 7:33 AM
> To: security-services@lists.oasis-open.org
> Subject: RE: Top down or bottom up
> 
> 
> comments inline
> 
> 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, May 22, 2001 11:34 AM
> > To: security-services@lists.oasis-open.org
> > Subject: RE: Top down or bottom up
> > 
> > 
> > I've tried to summarize what I think the issues are:
> > 1) Are we defining a framework for assertions?
> 
> I would rephrase the question:
> A) If there was an assertion framework established would we attempt to
> conform to it?
> B) If such a framework is established after the fact is it 
> likely that a
> group of users would want to conform to it, thus forking the 
> specification?
> 
> I don't think that we should take a decision to restrict the 
> specification
> to an arbirtrary model should be taken lightly.
> 

You have stated that before.  But you are avoiding the fact that you are
proposing a new type of schema language, a framework for assertions.  The
use of claims to determine kinds of assertions is a new mechanism.  Further,
there are many restrictions in your proposal.  

> > 2) Where do we reduce freedom in order to standardize
> 
> You have stated that your aim is to force users to 
> standardize on your use
> cases model. If so I believe that we must open up the use cases for
> rediscussion since there is a world of difference between a 
> set of use cases
> proposed as EXAMPLES of the type of applications that SAML is 
> to SUPPORT and
> use cases specified as an ENUMERATION of the ONLY use cases 
> that SAML will
> PERMIT.

They are not MY use cases model.  They are OUR use cases model.  You agreed
to them as well.  

> 
> I do not believe that the use cases document is specified 
> with anything like
> the degree of precision that would be necessary if it was for 
> the latter
> purpose. Nor do I see a legitimate role for a standards body 
> to dictate how
> users organize their authorization infrastructure.
> 

Instead of continually deriding the use cases, why don't you help make them
better?  I have asked you to suggest use cases that are better met by
bottomish versus toppish, but I still don't see anything.  It's very
difficult to debate issues, then resolve them, without buy-in on our
process.

> In short we should only reduce functionality where there is a 
> demonstrated
> need that it is essential to do so to permit interoperability.
> 
> It has been established that the bottom-up approach does not 
> introduce any
> interoperability issue. It is a purely syntactic issue and it 
> is actually
> easier to enforce cardinality constraints in the bottom up 
> case than in the
> top down.

I disagree with these claims.  I assert that bottom up introduces
interoperability and complexity problems, and hinders developers ability to
deliver implementations.  Top down makes it easier to enforce cardinality.
Further, it is much more natural to xml authors and more easily supported by
xml schema authors.  

> 
> The only distinguishing feature of bottom up versus top down 
> is that if we
> chose top down the data structures we arrive at are less 
> felxible and will
> be less suited to adaptation to further applications. Hence 
> if we chose top
> down the chances are that SAML 2.0 will not interoperate with 
> SAML 1.0. The
> advantage of the bottom up approach is that it retains the 
> flexibility.

Another unfounded assertion.  I have proposed a technique where SAML 2.0
will interoperate with SAML 1.0 as well as being simpler and more intuitive
than bottomish.

> 
> > 3) Should we define cardinalities of relationships (this must 
> > have 1 of
> > these and 2 of those) as part of #2?
> 
> If not the argument for the top down model fails entirely.
> 
> However it is as a matter of the XML schema language much 
> easier to enforce
> constraints at the bottom of the structure where they belong 
> than at the top
> and the bottom of the structure.
> 
> In order to apply the top down model it is necessary to 
> either place no
> restrictions on the cardinalities of the inner elements or to 
> introduce
> additional element names whose sole purpose is to carry 
> constraints from the
> top of the XML data structure to the bottom, viz:
> 
> <AttributeAssertion>
>    <AssertionID>
>    <AttributeClaims>
>       <Subject>
>       <Attribute>
> 
> <AuthorizationAssertion>
>    <AssertionID>
>    <AuthorizationClaims>
>       <Subject>
>       <Resource>
> 
> The only reason for introducing <AuthorizationClaims> is so that the
> cardinality constraints implied at the toplevel element can 
> be enforced on
> the innermost element.

Umm, then don't use Claims.

<AttributeAssertion AssertionID="">
	<Subject>
	<Attribute>

<AuthorizationAssertion AssertionID="">
	<Subject>
	<Resource>


> > > -----Original Message-----
> > > From: Phillip Hallam-Baker [mailto:pbaker@verisign.com]
> > > Sent: Tuesday, May 15, 2001 10:44 AM
> > > To: Orchard, David; security-services@lists.oasis-open.org
> > > Subject: RE: Top down or bottom up
> > > 
> > > 
> > > > Well, I'll bite at the bait.  Unfortunately, due to 
> > > > circumstances beyond my
> > > > control, I don't have as much time to write a response as 
> > I'd like.
> > > > 
> > > > Which use cases do you believe bottomish makes easier than 
> > > > toppish?  
> > > 
> > > I believe that both mechanisms can meet the use cases specified.
> > > 
> > > However the use cases specified may be unrealistic in being more
> > > abstract and simplified than practical implementations 
> > would require.
> > > 
> > > The bottomish approach would provide more flexibility should 
> > > practical experience prove that the original use case analysis
> > > was wrong.
> > > 
> > 
> > I'd like to see the use cases and requirements why toppish 
> > shouldn't be
> > done.  I don't think I'm amenable to doing something the 
> > opposite of what I
> > propose without some justification.  
> 
> It is an issue of syntax and is thus an architectural issue. 
> To ask for a
> use case or a requirement to constrain syntax is somewhat odd.
> 
> As stated above, it is a matter of extensibility. 
> 

Right.  I understand that you don't want to talk about requirements.  But
WHERE should SAML be extensible?  That has to be guided by requirements.

> 
> > Does the rest of the TC believe that we are defining or 
> > should be defining a
> > framework for assertions?  I'm interested in the will of the 
> > group on this
> > very important design goal that seems to have been overlooked 
> > yet slipped
> > in.   This seems issue #1 in this discussion.
> 
> I don't think the group ever decided to NOT adopt a modular 
> approach which
> anticipates that the work that this group does MAY be used by 
> other groups.
> 
> In particular I believe that if we do SAML in a modular 
> fashion then XACML
> should be a slam dunk.

I think that toppish combined with XML Query syntax makes XACML a
kidney-grabbing, reverse-360, no-look, monster slam.  

> 
> > > At a recent workshop Dave Clarke ripped into certain wireless
> > > technology on the basis that the entire range of uses had been 
> > > designed in, the technology was designed to insist that it only 
> > > be used as intended.
> > 
> > That doesn't really help in the analysis.   
> 
> Since he is on the National academy board looking at 
> Authentication schemes
> it might be politic to take his opinions into account.

Quoting scripture is not a useful exercise, as I can quote them too.  Tim
Berners-Lee says the semantic web is the future, so should we use RDF for
everything?  Tim Bray and James Clark have said at various times that XML
Schema is too complicated.  Should we not use XML Schema?  Bill Joy says
Java is great, so should we skip XML Schema and define everything as Java
Interfaces?  

Let's deal with the facts at hand rather than quoting authority figures who
have not said anything about our detailed decision making process.

> 
> > > >I assert that successful standardization
> > > > requires reduced flexibility and locking into a particular 
> > > > model.  SOAP is a
> > > > good example of locking users into a particular model for 
> > > > headers, body,
> > > > requests, responses, parameters, etc.  Java is another 
> example.  
> > > 
> > > That is quite different. The design does not reduce functionality,
> > > it reduces the number of means of achieving a given functionality,
> > > a very different issue.
> > 
> > I think that I'm catching the drift, that you argue keeping 
> > assertions as
> > effectively mixed content where anything can be thrown in is 
> > a good thing.  
> 
> Put in the constraints at the leafs of the tree so that SAML 
> assertions can
> share as much application support as possible with other 
> assertion based
> applications - e.g. XACML.
> 
> > I've never had the luxury of working with languages outside 
> > the mainstream
> > of developers, so I typically base my examples on C, C++, 
> > Java.  I think I
> > might share Wirth's failing.  OTOH, I've never created a 
> > language that we
> > can all talk about.  I don't understand why you view C++ as a 
> > weakly typed
> > language, but that's probably another thread.  I had hoped to 
> > gain some
> > insight, but I'm now more confused.  
> 
> C++ in common with most computing languages confuses 
> representation "a is an
> integer" with type "a is of type length in meters"
> 
> The distinction is important since if a and b are both of 
> type 'length' then
> it is possible to give meaning to the equations a+b and a*b, 
> while if c is
> of type apples the expression a+b is meaningless.
> 
> The C++ 'type' system is actually about representations, it 
> is not possible
> to perform the strong type checking that was intended for ADA 
> (which also
> has problems but we needn't go into here).
> 
> In languages such as Z a specification is developed using 
> strongly typed
> sets.

Ah, this is the notion of Units.  I understand.  However, I feel completely
comfortable talking about strong types meaning representation.  I think 100%
of the developers in my organization use strong type to refer to
representation.  It seems that the language of "strong-types" has evolved.

> 
> > > > One way I'd summarize the toppish versus bottomish as specify 
> > > > cardinalities
> > > > or not.  
> > > 
> > > Confusion of type systems and syntax has long been considered an
> > > error in language design.
> > > 
> > 
> > You didn't say whether specifying cardinalities was an 
> > adequate summary of
> > the difference in the proposal.  I'm still curious as to the 
> > answer.  I
> > think this is issue #3 out of this.  
> 
> It is quite easy to specify cardinalities in the bottom-up 
> approach. You
> simply state that a claim object may contain a Role or a 
> Resource but not
> both.

And how do I state that a claim can do that?  In what "language"?  My point
is I'd like to use XML Schema to do that for me.  It does have these
constructs, like <choice>, that seem appropriate.

Cheers,
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.