W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] Signed XHTML

From: Martin Bo▀let <martin.bosslet@googlemail.com>
Date: Thu, 20 Oct 2011 20:57:42 +0200
Message-ID: <CAFfYYxJv-MEucMA05RaZrtdt1JNZX5JqOpQtS14POpS2UHt-6A@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:37 UTC