RE: 3 different assertions diagrams

["Eve L. Maler" <eve.maler@east.sun.com>]

At 08:55 AM 6/11/01 -0700, Phillip Hallam-Baker wrote:
>I am quite happy to go for Eve's diagram with the following modifications:

Note that I'm not particularly attached to the design in my diagram; it 
really was a strawman.  If we can get enough agreement that it's a good 
starting point for recording future design decisions on core assertions, 
then I'm happy to maintain it as a record.  I think we should also have a 
class-style diagram a la Dave's most recent document, for people who prefer 
that.

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

>Consider the case in which the issuer issues an assertion that contains an
>authorization for Alice and a couple of attributes. In a financial services
>application it is very likely that the issuer would want to have some
>mechanism for tying insurance of the assertion claims as a collection to a
>single payment. One of the uses of the Conditions element is to allow that
>type of application to be supported in future releases.
>
>The reason for the current positioning appears to be to prevent adding
>conditions to a decision element. However a decision element is more likely
>to require an Audience restriction not less and the same can be said for the
>other types of condition that might be applied such as online verification.

Actually, the reasoning is simply that I did a cut/paste from the diagram I 
had already done for Dave's proposal...  No real thought went into it, and 
I forgot to check it against the discussion we had last Tuesday. :-)

>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.  The 
notation I've used isn't complete for implementing a schema, but given our 
discovery of mismatched concepts in last Tuesday's meeting, I don't think 
we're ready for a real schema yet.  We have to ensure that our rough design 
incorporates all the "things" it needs and that we have agreed on common 
names for the different "things."  Then we can agree on a configuration for 
them, and only then can we start writing a schema that won't have to be 
rewritten a bunch of times...  I anticipate that we might be able to get to 
the "configuration" point by the end of the F2F, which would be a huge 
accomplishment.

>I would like the toplevel element to remain <Assertion> regardless of the
>type of assertion claim made. This is from experience we had with using OCSP
>responses with PKIX applications. Many PKIX supporting applications (PKCS#7,
>S/MIME, IPSEC) provide a 'slot' for Certificates and CRLs, there is no such
>slot for OCSP tokens and trying to make one was a tedious task which would
>not have been necessary had we had the foresight to declare a toplevel
>'PKIX' container element which we could then subdivide as necessary in our
>own working group.

Do you mean you want the strawman <Compound> element to be called 
<Assertion>?  In our last meeting, we agreed that this was misleading, and 
were calling it AssertionPackage for a while before settling on Compound as 
a temporary measure.  We could perhaps call it SAML or SAMLMessage or 
something...  This container is where, presumably, an ever-growing set of 
different kinds of Molecules might be allowed.

         Eve
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com