RE: 3 different assertions diagrams

[Phillip Hallam-Baker <pbaker@verisign.com>]

All,

> >1) Move conditions up to the 'Assertion Molecule' level, for 
> the reasons
> >given in my other post and because moving it to the upper 
> level allows
> >support for 'single use' assertions with multiple claims 
> that depend upon a
> >single verification while attaching the conditions to each 
> claim does not.
> 
> Is there a case for keeping them at the Atom level too, or do 
> you think they should simply be removed from there?

I would say not the arguments being as follows:

For conditions at the atom level:
    *  Allows fine grained conditions that attach to specific claims

Against conditions at the atom level:
    *  Requires implementations to support mechanism to manage 
       conditions on specific claims
    *  Fine grained conditions can be supported through multiple
       assertions.
    *  The notion that an element that can have a status attached
       be a first class object (have an AssertionID) seems reasonable.

       Managing status of individual claims would increase the complexity
       of XTASS type meta-assertions greatly since the Assertion ID is
       unique and unambiguous while XPointer games would require the
       ability to navigate the XML structure long into the future.

> >2) It is not clear from the diagram (which is one reason I don't find
> >diagrams useful) how the syntax is implemented.
> 
> Sorry, but I find diagrams immensely useful for ensuring that 
> we all are 
> talking in the same language, and they're particularly useful 
> in a group 
> where most of the expertise is on the security side, not the 
> XML side.  

My prejudice aginst them probably stems from spending a year doing
comparative studies of OMT, Booch, Rumbaugh, et. al. at the end
of which all the boxes with little arrows start to look alike.

My point was that I think that we are largely in agreement about 
what the structure should look like, reification in XML is the
issue for me.

> Do you mean you want the strawman <Compound> element to be called 
> <Assertion>?  

I don't care about the name, but I think it is less confusing to 
see a single name there.

I note the use of abstract types and the extension mechanism. I
would like to use those at the lower level.
 
So the structure would look like:

<AssertionPackage [Basic Info]>
   <Claims>
       [List of elements of ClaimType]
   <Conditions>
       [List of elements of ConditionType]
   <Advice>
       [List of elements of AdviceType]

This would allow extension schemas to then declare that 'this new element
can only be used in the X slot'.

I am currently reading up on XML schema to try to understand the significant
variations in schema design from the insignificant.

We could use SAML or SAMLPackage as the toplevel element. That would have
the considerable advantage of being able to instantly recognise what spec
the data comes from when reading data dumps, or for that matter trying to
argue a case in court. 

I know that the xmlns= attribute has the same data, but if we have an
element SAMLAssertion it is pretty easy for counsel to then put a SAML
expert on the stand to explain what it means. If the element is something
obscure then the opportunities for FUD are somewhat greater.

		Phill

Phillip Hallam-Baker (E-mail).vcf