[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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? What current SAML requirement is met by bottomish that isn't by toppish? You mention end-users, but all of our end-users are web users who shouldn't be seeing SAML assertions. Is there a set of use cases you'd like to propose, such as "Developer adds new assertion type to SAML and all software works without modification" or somesuch? My guess is that you are evaluating the two styles of typing against a set of requirements and use-cases that at least I'm not familiar with. One of the ideas that these discussions and proposals seems to have brought is a scope discussions about whether we are defining a framework for assertions or assertions themselves? I think one of your objections to toppish typing is that it locks implementations into a particular model. But isn't that what we want? 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. The arguments that you are making, particularly to Pascal and to reduced flexibility, leads me to believe that you are of the weakly-typed camp, ala Smalltalk. Whereas I've been a strongly-typed proponent, ala Java and C++ Would strong versus weak types be an accurate analysys of the toppish versus bottomish typing? I don't fully understand what you are proposing as "bottomish" and where the types are defined versus not defined. There isn't a complete schema proposal for bottomish types in the spec or your examples, so I can't see how they relate to each other. I see fragments of schema, but not the relationship between things. I think you are saying that there should a single assertion type that has many different optional components. I argue that top typing gives developers more flexibility because it allows them to push type-checking into the xml parser. An example from you is: I expect an assertion that has Role and Authorization elements, and only 1 Authorization element. I can either create an XML schema that describes this, or I have to do the logic in the programs on both sides of the protocol. I think according to the bottomish proposal the cardinalities and optionalities of these relationships is negotiated out-of-band, and both parties somehow know what they should be. In summary, it seems like the bottomish approach avoids specifying cardinalities of all the leaf nodes, such as roles and authorizations. I can't see how this leads to interoperability. Say I run Netegrity SAML SiteMinder on one side and Securant ClearTrust on the other. How do they know to understand the different pieces? How do they change them? This seems problematic to me. One way I'd summarize the toppish versus bottomish as specify cardinalities or not. Cheers, Dave > -----Original Message----- > From: Phillip Hallam-Baker [mailto:pbaker@verisign.com] > Sent: Friday, May 11, 2001 2:07 PM > To: security-services@lists.oasis-open.org > Subject: Top down or bottom up > > > One of the outstanding issues on the conference call was > whether the typing > of assertions should be 'toppish' or 'bottomish'. > > For example: Toppish > > <Response> > <YadaYadaYada> > <AuthorizationAssertion> > <Version> > <AssertionID> > <Claims> > <Binding> > <Subject> > <CommonName>Soup Dragon > <Object> > <Resource> > > Or alternatively > > <Response> > <YadaYadaYada> > <Assertion> > <Version> > <AssertionID> > <Claims> > <Binding> > <Subject> > <CommonName>Soup Dragon > <Object> > <Resource> > > Where the difference is felt is in the complexity of the > schema and in the > limitations imposed on end users. > > Say we have 4 types of assertion. Using the top model we have > to coordinate > a range of values at the top of the XML tree and at the bottom. An > <AttributeAssertion> can only specify <Attribute> elements as > objects. I > think this is a hard problem in any schema language. > > The other limitation is on the end users. With top typing we > are essentially > telling the world 'use our model or else'. We deliberately > prohibit someone > creating an assertion that binds a subject to both an > attribute and a role. > I think this is very common 'Alice is a plummer and can > access the watergate > files'. > > It is possible to kludge arround the limitation for example > by hypothecating > multiple assertions. However the following is clean, neat and easilly > implemented. I challenge anyone to give an example of using multiple > assertions that has any of those properties. > > <Response> > <YadaYadaYada> > <Assertion> > <Version> > <AssertionID> > <Claims> > <Binding> > <Subject> > <CommonName>Soup Dragon > <Object> > <Attribute>urn:date-time:1968-02-02:makes_spaghetti > <Role>urn:date-time:1968-02-02:soup_maker > <Authorization> > <Permision>Read > <Resource>http://www.sun.com/finance/secrets.asp > > > So in summary, the bottom up typing is elegant and efficient > and is equally > rigorous in terms of strong typing as the top down model. It > avoids the > design error in the type system of over constraining the user > that crippled > the Pascal language relegating it to obscure academic use and > divergent > standards. > > The only thing the bottom up typing does not do is to lock in > the end users > into a particular model. > > Phill > > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC