RE: Top down or bottom up

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

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.

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

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.

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.

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.

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


> I also include comments.
> 
> > -----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. 


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

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

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

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

In fact as I showed above, it is quite a bit easier to do this with the
bottom up approach.

Whether one should do it is a different matter. I think not.

DNS works quite well with the concept of additional resource records being
appended to responses. Or rather it does so now that the implementations
subject additional resource records to the same authentication checking as
primary resource records. I am not aware of additional resource records
leading to interoperability issues.

		Phill

Phillip Hallam-Baker (E-mail).vcf