W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widgets] Jar signing vs. XML signatures

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 17 Apr 2009 14:19:27 +0300
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, ext Jonas Sicking <jonas@sicking.cc>, "marcosc@opera.com" <marcosc@opera.com>, Thomas Roessler <tlr@w3.org>, public-webapps <public-webapps@w3.org>
Message-Id: <5CE02CEA-64BB-4D30-AD82-E44E5AE6990F@iki.fi>
To: Robin Berjon <robin@berjon.com>
On Apr 17, 2009, at 13:24, Robin Berjon wrote:

> Trying to separate the discussion from the change request: would you  
> be satisfied if requirements to perform C14N were removed and  
> reliance on XSD data types for definition purposes were replaced  
> with something less scary (though in this case this is a bit of a  
> FUD argument Henri, the referenced types aren't overwhelming)?

My preferred change would be adopting jar signing. However, if that's  
not feasible, my next preferred option would indeed be removing the  
requirement to perform canonicalization (i.e. sign XML as binary with  
a detached traditional binary signature block).

As for the data types, I'd be satisfied if the datatypes were defined  
in such a way that attribute value parsing algorithms and conversion  
methods that a browser engine has to contain anyway were reusable.  
This should include well-defined behavior in the case of non- 
conforming input.

For example, for dates (which is a datatype that widgets add--not  
something that comes from XML signatures), it makes more sense to  
reuse an appropriate microsyntax definition from HTML5 than to  
delegate to XSD. XSD not only makes leading and trailing whitespace  
conforming and fails to define behavior in the case of non-conforming  
dates, XSD which even allows leap seconds! (Is it a FUD argument that  
XSD dates deviate from the value space that is typically used in Posix  
date conversions between multi-unit tuples and epoch seconds?)

Henri Sivonen
Received on Friday, 17 April 2009 11:20:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC