This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:Web Applications Working Group
Other specs in this tool
Quick access to LC-2400
There are 3 comments (sorted by their types, and the section they are about).
I have updated the "Digital Signatures for Widgets" editors draft
(note title change agreed earlier) .
The changes made were noted in http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0028.html
and agreed to on today's teleconference .
Also updated the XML Security references, passed link checker and
This should complete ACTION-519 (For tracker)
Please review section 1.4, example Reference URI="#prop"; section 7.1
item 3c; section 7.2 paragraph 2 and following note; section 7.3
fourth paragraph; and References for [XMLDSIG11], [XMLSecAlgs],
I have fund a number of issues with the dig sig spec:
1. Â The conformance model is all screwy: it mixes conformance criteria
for too many products (including ones on which were it makes no sense,
like signature documents). The conformance criteria makes the spec
really hard to write test for. Only two classes of products should be
allowed to conform: signers and validators.
2. The spec requires zip-relative-paths to be URL encoded during
signing. I think this is an oversight, specially because during
signature validation it does not say that the paths be decoded. URL
Encoded of paths should be removed from the spec, IMO. Zip-relative
paths are supposed to be URI safe, hence should not require URL
Encoding (and when they violate URI's path rule, they should be
treated as invalid widgets anyway as per the P&C spec).
3. The document is full of editorial redundancies (about 100+). It is
also badly structured, with behavioral conformance criteria mixed in
with definitions and support requirements (making the spec really hard
In the interest of saving time, I have created a new version of the
spec that addresses all the issues above:
To compare my draft with latest WG endorsed editorial draft:
In addition, the new draft has the advantage of being fully testable
and written using the method defined in  (meaning we can plug in
WebApps test suite creation infrastructure, which assures that all
conformance requirements in the spec will get tested!).
I encourage the working group to adopt my modified version once it has
been reviewed. Aside from the URL Encoding thing, the modified version
does not change the behavior existing implementations: it just makes
it much more clear what each kind of product needs to do to conform.
On Thu, Apr 29, 2010 at 2:21 PM, Arthur Barstow <email@example.com> wrote:
> Reminder: May 6 is the deadline for comments re the April 15 LCWD of the Digital Signatures for Widgets spec:
> Â http://www.w3.org/TR/2010/WD-widgets-digsig-20100415/
> Please send comments to firstname.lastname@example.org.
> Begin forwarded message:
>> From: "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>
>> Date: April 16, 2010 5:25:27 PM EDT
>> To: public-webapps <email@example.com>, "firstname.lastname@example.org" <email@example.com>
>> Subject: Request for Comments: LCWD of Digital Signatures for Widgets; deadline 6 May 2010
>> Archived-At: <http://www.w3.org/mid/8679D7D8-A881-4FD2-B1A3-693507FB66FF@nokia.com>
>> On April 15 the WebApps WG published a new LCWD of the Digital
>> Signatures for Widgets spec (formerly titled Widgets 1.0: Digital
>> Â http://www.w3.org/TR/2010/WD-widgets-digsig-20100415/
>> This spec was last published as a CR [CR]. The new LC includes a fix
>> to a bug [Bug] that was identified during the implementation of the
>> spec's June 2009 Candidate.
>> The deadline for this LC's comments is 6 May 2010.
>> We will explicitly ask the XML Security WG to review this LC and
>> comments from others are welcome.
>> -Art Barstow
>> [Bug] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/
>> [CR] http://www.w3.org/TR/2009/CR-widgets-digsig-20090625/
just a minor comment found by build a test case :
Section7.1. Common Constraints for Signature Generation and Validation
3. For each ds:Reference element:
1. The URI attribute MUST be a zip relative path from the root of the widget package to the file entry being referenced.
This condition should not be applied to same-document references. It only makes sense to 'external' references.
Andreas KÃ¼hne phone: +49 177 293 24 97 mailto: firstname.lastname@example.org
Trustable Ltd. Niederlassung Deutschland StrÃ¶verstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868
Directors Andreas KÃ¼hne Heiko Veit
Company UK Company No: 5218868 Registered in England and Wales
Add a comment.