- From: Martin Boßlet <martin.bosslet@googlemail.com>
- Date: Thu, 20 Oct 2011 20:57:42 +0200
Dear all, since HTML5 is not finalized yet, I would like to ask if the following would have any chance to be considered for the specification. With TLS we have a great tool for secure communication, we can do privacy and mutual authentication etc. with it. But I have worked on a couple of projects where clients were asking for the possibility to somehow store a receipt of some transaction that took place in their browser. Although we can secure the communication channel, establish identity and authentication with TLS, all the data that is sent back and forth stays "ephemeral", with no actual proof of its authenticity and integrity. Those guarantees are only given on the transport channel, but the data itself remains in its original, non-secured form. What those customers wanted was a reliable "receipt" that could serve as proof of a transaction really having taken place at a certain point in time (both client and server would be potentially interested in such a receipt). At the time, we thought of using XML signatures[1] ?to sign the XHTML on the server, but signatures could also be applied on the client side - clients could sign the data they submit. Currently we realize such things using smart cards and Java applets on the client side, but this would simplify a lot if we had "native" Javascript support for smart card access. Clients could download the XHTML signed by the server in order to have some form of transaction receipt. Servers on the other hand would be able to archive the signed data submitted by users and could archive it reliably (by applying timestamps and embedding revocation information), effectively establishing an artifact of the client's commitment to a particular transaction, with the signature guaranteeing a form of "non-repuditation". The problem with such a solution currently is that adding a <dsig:Signature> element unfortunately results in invalid XHTML. In my opinion this could be mitigated simply by importing the XML signature XSD in the XHTML XSD and declaring <dsig:Signature> as a valid element of XHTML. Of course this feature would be exclusive to XHTML and not applicable to "normal" HTML. If part of the specification, browsers then could decide to react on the presence of <dsig:Signature> elements, e.g. by visualizing the presence of a digital signature on the current page, or by offering to download the XHTML in order to store it locally etc. Are there plans in this direction? Would functionality like this have a chance to be considered for the standard? Best regards, Martin Bo?let [1] http://www.w3.org/TR/xmldsig-core1/
Received on Thursday, 20 October 2011 11:57:42 UTC