OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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