RE: [XML Signature] Issues on Core 19 & Others

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

I agree with the questions about the meaning/function of multiple 
assertions.  If we can't motivate them with native-SAML use cases, we may 
want to look seriously at pulling back a bit.

If I'm understanding correctly, Phill has been promoting this structure in 
order to allow for interesting applications built on top of SAML, which is 
a legitimate data point.  I wonder if there isn't a more useful solution:

Make the native SAML assertion be "singular" in nature (containing a single 
statement), and then allow applications to extend the assertion datatype by 
adding additional statements on the end.  In extremely informal DTDish 
notation, the native assertion type would do this:

   assertion ->
   (meta-stuff, (stmt|subjstmt|authnstmt|authzstmt|attstmt))

And the extensions you could create might look like this:

   my-extended-assertion ->
   (everything-above, (stmt|subjstmt|authnstmt|authzstmt|attstmt)*)

(Sorry, I'm multitasking at the moment and don't trust myself to get an XML 
Schema version right.  I will try to follow up with more specific code.)

This would ensure that SAML's semantics for singular assertions are clear, 
and that while extensions might pick up on native *statement* semantics, 
they're on their own as regards any "multiples" semantics.

         Eve

At 12:12 PM 10/5/01 -0400, Hal Lockhart wrote:
> >               The Signature will be an Enveloped Signature as
> > per the XML Signature
> > specification. There is an issue of support for multiple
> > signatures, which I
> > plan to research thru. Would appreciate feedback.
>
>What would the semantics of multiple signatures be? We should decide what we
>need to do first and then how to do it.
>
> >       2.      Is there a rationale for *separate* single and
> > multiple assertions ?
> > Isn't SingleAssertion a MultipleAssertion with one assertion ? Can we
> > collapse the SingleAssertion and MultipleAssertion elements
> > to one type with
> > minOccurs=1. There is no meaning having an assertion without
> > an assertion
> > type !
>
>I agree with the (implied) suggestion.
>
> >       3.      Signing Multiple Assertions:
> >               Do we have a structure to envelope multiple
> > separate assertions ?
>
>I think it is going to be a lot more convenient for relying parties to sign
>each assertion individually. I know there is an performance cost issue, but
>it can be helped by reusing assertions. Separate signatures actually help
>this, as one assertion can be reused, even if another has to be generated
>and signed on demand. For example a static AuthN Assrt and dynamic Attr
>Assrt
>
> >       4.      Associating Payload:
> >               Is there a way for a payload assertion ? i.e.
> > make an assertion saying
> > that PO is mine. May be this is an attribute assertion the
> > attribute being
> > the hash of the payload. This almost the same as a detached signature.
>
>Start by assuming that the payload must be signed by the subject. I guess
>this could be debated, but if not then either anybody can forge the payload,
>or the function of being an Asserting Party and being a generator of
>transactions gets folded into a single trust point.
>
>I think the result of discussions at the face to face and Bob B's powerpoint
>published imediately after was that tying a payload to an assertion can be
>done by putting the subject's public key in the Subject Confirmation.
>
>The point is that whether the Issing party blesses every individual payload
>generated by the subject or blesses the subject's key, all it is really
>vouching for is that the payload came from the subject, not anything about
>the contents of the payload.
>
>Once this is recognized, it becomes clear that there is no real advantage
>for the issuer to bind the assertion to every payload. The disadvantage is
>that a new assertion is required for every transaction.
>
> >               There are a few issues here as well:
> >
> >               a)      ebXML and RosettaNet has a document
> > model and so the object of signing
> > would be a MIME part
> >               b)      SOAP Payload is an XML fragment and so
> > the object could be an XPath or
> > an XPointer (?)
> >
> >               Is Payload signature a binding issue or a "core" issue ?
>
>Signing the payload itself by the subject is not a SAML requirement at all.
>
> >
> >       5.      Of course, the "core" has the SAMLRequest and
> > SAMLResponse. Does it make
> > sense to add the
> >                               <element ref="ds:Signature"
> > minOccurs="0" maxOccurs="1"/>
> >               to Request (Line 800.1) and Response (Line 973.1) ?
>
>I remember we discussed that Requests should be authenticatable, especially
>in environments, e.g. Shib, where assertion contents depend on who is
>asking. I don't recall any argument for signing responses, but there seems
>little harm in including the possibility in the schema. I would hope that
>the mandatory to implement profiles would not use this signature.
>
>Hal
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>

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