[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Top down or bottom up
> 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. Such as? I do not see why recognizing that 'Assertions' represent an abstraction of all the SAML assertions should be something to be affraid of. > They are not MY use cases model. They are OUR use cases > model. You agreed to them as well. Actually I agreed that SAML MUST satisfy the use cases as a minimum. I never agreed that SAML should be designed to ONLY support those use cases or to REQUIRE the application of the domain model. > Instead of continually deriding the use cases, why don't you > help make them better? False claim, I am derriding the idea that any set of use cases can be complete. If you want to re-open the use case discussion then we should consider the case in which a Web site is receiving authorization assertions from multiple sources and caching parts of the decision. > I disagree with these claims. I assert that bottom up introduces > interoperability and complexity problems, and hinders > developers ability to > deliver implementations. Dave, you repeatedly ask me for more information on the approach I suggest. I have thus far provided the only description that goes down to the bytes on the wire, I have addressed the alledged interoperability issue you claim exists on many occasions, to repeat the argument: The request for an assertion contains all the information required to identify the type of assertion to be returned. >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. Untrue, utterly untrue. The 'bottomish' approach implements cardinality constrains within a sub element of <claims>, your approach implements those constraints at the topmost SAML level, but probably 4 elements deep into the XML Protocol package. There are no XML schema implications that arise. > 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. No, absolutely not since if something is a REQUIREMENT then it has to be met by SAML. IT CANNOT BE MET BY AN EXTENSION! If extensibility is to be driven by requirements analysis we MUST open discussion for a new round of requirements - those that must be expressible in SAML 2.0,... 5.0. > 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? I have worked with Tim long enough not to treat his work as scripture. In particular I see no basis for introducing a new syntax with RDF. However they have spent a lot of time thinking about RDF and it certainly makes sense to look at the work they have done. > 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. Or regressed. You asked why I considered C++ to not be strong typed. I have a background in formal methods and have used genuinely strong typed languages such as ML, Orwell and Z. I doubt that many developers in your organization have spent a substantial amount of time writing programs in ANSI Pascal which is the only programming language standard ever to try to enforce Wirth's type system. I can say that with confidence since writing a program with ANSI standard pascal is probably impossible. > > 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. We can use XML Schema to do that in the bottomish approach. Phill
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