W3C home > Mailing lists > Public > www-forms@w3.org > June 2007

Re: XForms and XML Signatures : How to get the presentation layer?

From: David Landwehr <david.landwehr@picoforms.com>
Date: Wed, 20 Jun 2007 12:03:06 +0200
Message-ID: <4678FB5A.2090509@picoforms.com>
To: duryodhan <duryodhan125@gmail.com>
CC: www-forms@w3.org

As we went a little of the www-forms list I post the discussion with 
duryodhan with all posts so far.

Best regards,

 From duryodhan:

Yeah, well , it is my school(under grad college)  , so I don't think
it should be that much of a problem.

But it IS true that non-repudiation is finally not something that you
can achieve. All you achieve is evidence , its value and weight has to
be decided by humans. The more stuff you add (like signing
presentation layer as well as data) , the more weight the evidence has
... thats all.

For a very interesting read (one that opened my eyes regarding the
term non-repudiation) , see "Repudiating Non-repudiation" at

> Now when I look more closely there are lots
> and lots of problems with canvas...

Yeah, but it sure was an interesting idea. :) Infact I will probably
look into it a lot more...

> PS You didn't send this to www-forms?

I sent 1 msg (the first one I sent), I am waiting for you to reply to
that over there (at the www-forms list)... so that I can continue the
thread. Otherwise it will look weird to others.

By the way, sorry about it all .... www-forms sends me the msg a
little differently than other lists. Even the reply-to is you (the
sender) , but should be www-forms (which is the accepted behaviour in
most of the lists I use). Thats why on clicking reply the msg went to
you and not the list. I have to remember that next time onwards ....

Anyways , please reply to my message at www-forms so we can continue
the thread ....
or rather just post the whole thread we just had over there ... I
didn't do this as I am not sure what  would be acceptable at the list
as I am a newbie there (on the list)....


P.S : Sorry about it ... but after the previous mails, I am trying to
specify all the "there"s that I use :)

 From David:
I'm not the right person to ask about the form technology to use. The 
company I work for could implement a  XForms solution for you with 
signing but we don't have shelf product for doing something like it 
right now.

I do believe in XML Signatures, but the thing is that when you are doing 
B2B everything is all good and if you don't have a legal requirement for 
the signature to be valid then a user can also just sign off the data. 
But for arguments it is not enough just to sign the data. I wouldn't say 
you should not use XML Signtures in your solution, e.g. I would sign the 
bitmap and the data using an XML Signature.

Okay I see the problem with canvas, it has not always worked like that, 
e.g. that it had to be an image object or that it had to be in chrome. 
They don't make it easy  :o( Now when I look more closely there are lots 
and lots of problems with canvas...

Best regards,

PS You didn't send this to www-forms?

 From duryodhan:

Now I don't know whether you are the right person to ask this ... but
right now , what is the method used to enable non-repudiation (upto
technically feasible) in forms? For a simple HTML Form, I can collect
all the inputs and their solutions (i.e Name: <input name> , last
name:<input here> etc. etc. ) in a text block and sign, but then I am
only signing data you could say . (well the field names are also
present but not that really good ...). In XForms , there have soo many
lectures about XML Signatures, but you don't seem to believe much in
them ... :) .

Crux is, if you want to implement client side signatures in forms
today , what technology would you use? Just asking for your opinion.

Now, about the canvas idea. The idea is very interesting , but a quick
google search gives me this. ...
"Mozilla's canvas is extended with the drawWindow method. This method
draws a snapshot of the contents of a DOM window into the canvas."

I assume this is what you were talking about ....
All is good till now , but it also says

" This feature is only available for code running with Chrome
privileges. It is not allowed in normal HTML pages."

see http://developer.mozilla.org/en/docs/Drawing_Graphics_with_Canvas

If you were talking about something else, please let me know ...
also , are there JS methods that allow you to change the base64 back to 

Cos the idea is good. Off the top of my head (for an HTML form I am
afraid as I am certainly not going to tell how to write XForms to a WG
member :) ) , the form will consist of a button , which makes all
elements read only and then takes snap and saves it in a hidden field.
And only then allows to press submit...(done through JS and DOM)


 From David:
I did not reply to the list because you did not in your reply to me ;-)

I'm sorry if I'm starting to iterate or write about something you 
already is aware of or other did write to you about, however here it 
comes: It is clear what is to be signed has to be displayed to the user 
to make sure he knows what he is signing. Depending on legal stuff in 
the country and what the application needs there might be strict 
requirements to the signature and the content. E.g. some countries 
requires that the signature is composed of the bitmap for what is 
signed, this is e.g. what adobe reader is doing and I would guess Dr. 
Boyer's implementation as well. Only by having the bitmap you will be 
certain what was presented to the user (corner cases could here be that 
the TFT screen had a bunch of fallouts and therefore the user did not 
see some part of the screen, but legaly that would not hold). When 
signing xhtml+xforms you will soon discover that presenting this to the 
user to be sure what he is signing is difficult, e.g. CSS styling might 
hide fields depending on states and so (or styling could obscure some 
part of the screen e.g. with overflow or fixed boxes). Also with firefox 
you might have a shadow DOM and other pieces of information wich is in 
or not in the DOM. So considering this it seems to be quite problematic 
to solve the signing problem in an elegant way in XForms simply because 
signing is actual about presentation and not so much about the data 
being signed. A note here is that it is not enough simply to sign the 
bitmap without signing the data along with it, as the system also have 
to be sure what the user signed (e.g. if the user can sign a bitmap and 
not the data he might be able to signed a bitmap and submit it to the 
server with some other kind of data which the server cannot likely 
validate since it will not be able to read the bitmap, but I guess I 
would not have needed to explain this)...

Now I was writing this I came up with an idea for what would be a good 
solution in Firefox. Firefox implements the canvas element which is 
actually able to catch part of the screen as bitmap and display it to 
the user. It is also able to convert the bitmap to base64. So you could 
implement the bitmap approach in Firefox... Let me know if you want to 
explore this option and I will eloborate.

Best regards,

 From duryodhan:

Ok! But then if I sign text, then one of the major reasons for me
trying out XForms no longer exist(i.e the output is all XML). If I
wanted text, then I would just use HTML Forms and JS which would parse
the form and write it to text one by one and then save it as a text
var, which the user is next asked to sign.

Now I know , you will all say that there are a 1000 other reasons to
use XForms and that is true. But that isn't what I am talking

What does the XForms spec say? What should be signed? Aren't the
concerns you are raising valid over there too?

Also, does the XForms spec say that XHTML + XML should be signed?

Still a noob, so am probably talking out of my hat.

> I'm sorry I cannot be more helpful than this.

Well I am sorry too! :D


David Landwehr skrev:
> The problem is that the user must be aware of what is being signed and 
> as such it might not even be enough to sign both the xhtml+instance 
> since the form might not display all the information the user is 
> signing (e..g calculated fields or other elements which is not 
> displayed to the user). If I was you I would make an additional step 
> to the signing, e.g. to transform the instance into a text piece of 
> information where all the information are present and then ask the 
> user to sign that. This is an often used see method, when an applet is 
> doing the signing.
> If you are doing an implementation with firefox then the applet 
> solution might be of use to you. Additional you can make the 
> transformation from instance to clear text using an XSLT (see e.g. 
> http://landwehr.dk/blog/ for how to use XSLT with XForms in Firefox to 
> do sorting).
> I'm sorry I cannot be more helpful than this.
> Best regards,
> David
> On Jun 20, 2007, at 7:20 AM, duryodhan wrote:
>> Hey,
>> ok! No offense, but I am aware WHY you need to sign the presentation
>> layer too .. (from your own blog posts I am afraid), but the point I
>> was asking was... to sign the whole presentation layer + Instance when
>> the XHTML is the presentation layer, what should I sign? The whole
>> XHTML document (with the model replaced by the actual instance). Or is
>> there something more specific only that I should sign? I am afraid
>> that most of the stuff online about this is mostly about XFDL (again
>> by you :) ).
>> Also, I wanted to know ... HOW should I get the whole presentation
>> layer from the client side to the server side ?
>> I am a little of a noob , so please bear with me , if I am waaay off
>> course and clear me up.
>> The *first* question is what I am most dense about. ... could you
>> please give an example of _what_ should be signed, when the XForms use
>> XHTML as presentation layer, assuming a simple XML Signature tool that
>> I have which converts an XML Doc to one containing an enveloped
>> signature?
>> Regards,
>> duryodhan

David Landwehr
Senior Product Architect
web:    http://www.picoforms.com
e-mail: david.landwehr@picoforms.com
phone:  +45 24 27 55 18
Received on Wednesday, 20 June 2007 10:03:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:20 UTC