> 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