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


Hi Phil,

I've tried very hard to understand your rationale for many parts of your
proposal.  In my attempts at coming up with a proposal, I've learned a lot
about the design you have created.  Believe me, I'd much rather be working
on the sessions stuff.  But I don't think that you are really understanding
my proposals.  And I'm quite troubled that I STILL don't fully understand
what you are proposing, yet I've been poring over it for 3 days solid and
I'm not exactly an XML, Web or systems slouch.  I don't see how we're going
to get widespread adoption of SAML if only a few people on the planet really
understand it.  One of my key requirements for any spec is that it must be
as easy as possible to understand.

IMHO, I think that at some point you may need to decide between 1) being the
assertions editor and doing your best to represent the Working group or 2)
being a strong submitter to the WG.  Your comment about you being the only
submitter of bits on the wire and your intransigence at looking at an
alternative leads me to this observation.

I've embedded comments to ask for more details and out of courtesy, but I
think we're almost at the end of the road on this.  We disagree on whether
the use cases should be sufficient or not, on where extensibility and
non-extensibility should be, and I'd like to see examples of the cardinality
refinement you mention.  We should probably raise some issues to resolve
these, and we also have a concrete toppish and xml query proposal on the
table now.

Thanks for keeping the debate reasoned,
Dave

> -----Original Message-----
> From: Phillip Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Monday, June 04, 2001 5:46 AM
> To: Orchard, David; security-services@lists.oasis-open.org
> 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? 

Like that attributes have to be some structured string, that there's a
proprietary request language, there's no defined mechanism for defining
cardinalities, etc.

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

I understand your position now.

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

The TC has never signed up for the idea that the use cases are illustrative
but not complete.  I think the previous core assertions WG had voted for
that, but it never went to the TC.  I'm personally totally open to making
sure the use cases are sufficient for a working 1.0 implementation.  I
welcome any and all examples that you bring.  I know you've thought about
this a whole lot.  I happen to be a strong believer that we need to be very
clear about what we are doing and what we aren't doing, and we need to be
able to communicate that clearly to the public with no surprises.

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

I now understand much more of your proposal.  I just think it's too flexible
in some areas, and not flexible enough in others.   I guess I've now
provided a description that goes down to bytes on the wire.
<snip/>

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

I argue that a topmost SAML level assertion works very well in a SOAP header
and messages.  Perhaps the protocols subcommittee can show us examples.  

Can I see an example of the claims constraints?  I'd really like to see what
language it is in.

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

I think you are still trying to avoid what I'm getting at.  We need to
define where the extensibility will occur. I propose that extensibility is
at defining new types of assertions, by an open content model for
attributes, by an extensible permissions Type, and by a very flexible query
grammar.  I propose that there is NOT extensibility at the query constructs,
that the top level data model is fixed.  

I am trying to describe and understand exactly where extensibility needs to
occur, and where it doesn't.  I'm trying to meet various use-cases, like
"Add custom attributes", "Add custom permissions", "Create custom queries",
etc.


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

You completely diverted from the issue that I raised about quoting scripture
from authority figures.  I'm surprised that my RDF troll worked, but I do
agree with your sentiment on it.

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

Cool.  Thanks for the education.  I've sometimes thought about trying to go
back to school and learn more formal stuff.  But I think my brain is too old
for the math.  The closest I can handle is "Proof".

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

Please show an example.  
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC