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

Re: [widgets] Jar signing vs. XML signatures

From: Marcos Caceres <marcosc@opera.com>
Date: Fri, 17 Apr 2009 13:54:49 +0200
Message-ID: <49E86E09.4060308@opera.com>
To: Henri Sivonen <hsivonen@iki.fi>
CC: Robin Berjon <robin@berjon.com>, Frederick Hirsch <frederick.hirsch@nokia.com>, ext Jonas Sicking <jonas@sicking.cc>, Thomas Roessler <tlr@w3.org>, public-webapps <public-webapps@w3.org>

Hi Henri,
On 4/17/09 1:19 PM, Henri Sivonen wrote:
> 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.

I don't think this is a realistic solution at this point, but we are 
totally open to fixing what we currently have.

> 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).

Agreed.

> 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.

Agreed.

> 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.

Probably agree (need to read it, but makes sense... of course, you are 
assuming that HTML5's definition is finished and without bugs - can you 
guarantee this somehow? I.e., test cases that prove a 1 to 1 between 
browser implementations and what is in HTML5?).

> 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?)

Yeah, Robin! :)

Kind regards,
Marcos
Received on Friday, 17 April 2009 11:55:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT