- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Wed, 26 Mar 2003 09:17:39 -0800
- To: "Marc Hadley" <Marc.Hadley@Sun.COM>
- Cc: <xml-dist-app@w3.org>
> > -----Original Message----- > From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] > Sent: 26 March 2003 08:19 > To: Martin Gudgin > Cc: xml-dist-app@w3.org > > I'm generally in favor of this approach but I think there are > a couple of problems it doesn't adequately address: > > (i) Attachments are an optimization to avoid having to base64 > encode binary data. Section 8 of the proposal requires that > 'signatures over elements with xbinc:Include children MUST be > signatures over the base64 data'. If you buy the premise that > security in the form of DSIGs etc is going to be widely used > then this requirement basically nullifies the advantage of > using attachments since you'll have to run the base64 > encoding to compute and verify signatures. > > I think a better approach would be a xbinc:Include aware XML > DSIG C14N algorithm that just streams the binary data in the > case of attachments (hence preserving the optimization) and > does base64 decoding in the case of embedded data. Don and I were discussing this approach last night, definitely worth investigating I think. > > (ii) the current formulation misses an important facet of included > attachments: their identity - i'll try to illustrate with a > (contrived) example. <SNIP>example</SNIP> > > I suspect that a constrained use of the swa:Representation > element might help with this problem - that is if there is > only 1 representation of a given resource in the MIME package > the swa:Representation/@href can be used. Alternatively an > application specific attachment reference mechanism could be > used but that kind of defeats the purpose. Certainly I was thinking that where identity was important swa:Representation would be used. Gudge
Received on Wednesday, 26 March 2003 12:17:32 UTC