Lists Home |
Date Index |
Elliotte Harold wrote:
> Sean McGrath wrote:
>> The use case here is transmitting XML-based messages from one service
>> to another service on a Service Oriented Architecture and doing it in
>> such a way that (a) it is possible to be sure that a message routed
>> "straight through" has not been tampered with and yet (b) the XML is
>> fully visibile - not a lump of attatchment goo - for the purposes of
>> intelligent routing.
> This sounds like exactly what XML digital signatures is supposed to do.
Yes - specifically the canonicalisation bit.
> If that doesn't work, then treat the document as read-only data, and
> wrap it in a MIME envelope (a.k.a XOP) along with a digital signature
> over the binary form of the data.
That is precisely what I'm trying to avoid. I think it is silly that we
end up using binary attachments in order to work around the fact that we
cannot sanely process XML losslessly.
>> Equally important is the fact that an intermediating service can
>> add/modify/delete content from the XML instance without doing damage
>> to the untouched parts of the instance.
> I'm not sure I see how this is compatible with the need to route
> straight through without tampering.
Both "straight thru" and "intervened" are use cases in the SOA
architecture I'm advocating. An introductory paper is available at:
http://sdec.reach.ie/papers if you are interested. Comments welcome.
> But again, this is a use case XML digital signatures attempts to
> address. Why is that not working for you?
If you look at the RIG 2 document you will see that the requirements of
RCF compliance are expressed in terms of constrains over and above W3C
XML canonicalisation. In particular, I want to avoid the complexities
that result from combining XML 1.0 canonicalisation with namespaces
(e.g. Exclusive XML canonicalization :-)
Any document that is RCF compliant is also XML canonicalisation
compliant but not the other way around.