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

[Hal Lockhart <hal.lockhart@entegrity.com>]

> 		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