I wonder what the interaction between this and a manifest approach for
URI dereferencing would be. I could argue the case both ways, but
would be interested in your thoughts.
--
Thomas Roessler, W3C t...@w3.org
On Mar 18, 2009, at 20:53, Frederick Hirsch
frederick.hir...@nokia.com wrote:
Marcos
Regarding the requirement for validity checking zip relative paths
in widget signature [1] references, does the following change make
sense to you?:
Change last paragraph in section 5.1, Use of XML Signature in
Widgets to (only last sentence is changed, to two new sentences):
Every ds:Reference used within a widget signature MUST have a URI
attribute. Every ds:Reference to an item within the widget signature
MUST use an IDREF value for the ds:Reference URI attribute,
referring to a unique ID within the widget signature [XML-Schema-
Datatypes]. Every ds:Reference to a widget file MUST use a URI
expressing the zip relative path to the widget file, properly URL
encoded [URI]. The zip relative path MUST conform to the
requirements expressed in [Widgets Packaging].
Please let me know any comment or suggestion. Thanks for noting this
concern.
regards, Frederick
Frederick Hirsch
Nokia
[1] http://dev.w3.org/2006/waf/widgets-digsig/
On Mar 17, 2009, at 8:15 AM, ext Marcos Caceres wrote:
Hi Frederick,
On 3/17/09 1:01 PM, Frederick Hirsch wrote:
The latest draft includes the revised text from Thomas.
Marcos, are you suggesting we add something more? It sounds like
what
you are saying here, is that it should be a valid widget file. Isn't
that part of PC checking? I'm not sure what it means to check
that the
paths are as secure as possible.
You might want to check the following section of the PC [1] and
see if
it is usable in dig sigs. Given that the paths in the reference
elements MUST be zip-relative-paths, the rules for checking the
validity
of those paths may apply to the Widgets Dig Sig spec.
[1] http://dev.w3.org/2006/waf/widgets/#zip-relative-paths
