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

Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 13 Apr 2009 13:28:42 +0200
Message-ID: <49E321EA.90703@opera.com>
To: Arthur Barstow <Art.Barstow@nokia.com>
CC: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>, Web Applications Working Group WG <public-webapps@w3.org>
Hi Art,

On 4/13/09 1:03 PM, Arthur Barstow wrote:
> On Apr 9, 2009, at 1:44 PM, ext Marcos Caceres wrote:
>> On 4/9/09 3:56 PM, Arthur Barstow wrote:
>>> On Apr 9, 2009, at 9:52 AM, ext Marcos Caceres wrote:
>>>> On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group
>>>> <Mark.Priestley@vodafone.com> wrote:
>>>>> Hi Art, All,
>>>>> If there is no use case for accessing this information (I was after
>>>>> why
>>>>> you would want to access this information because I think just
>>>>> saying it
>>>>> might be interesting to do so isn't justification enough), then I
>>>>> think
>>>>> my original proposal holds - make the signature files unavailable
>>>>> to the
>>>>> widget at runtime.
>>>>> For clarification I was not suggesting that an API should be added to
>>>>> the DigSig spec but rather that some of the information could be
>>>>> exposed
>>>>> via an API defined in the APIs and Events spec. But I don't think this
>>>>> is necessary or worth the additional specification effort.
>>>> FWIW, I agree with Mark.
>>> Please propose text that will address your concerns.
>> In the P&C spec, I would add something like:
>> "A user agent MUST make the digital signature available only to
>> implementations of the [Widgets-DigSig] specification.
> I don't understand why we would want to create this type for a P&C UA.

Ok, I see the confusion here. It should really have said,

"If a user agent implements [Widgets-Digsig], then it MUST ..."

Implementing [Widgets-DigSig] is always optional. We have similar weak 
dependencies for <preference> and A&E, as well as another weak 
dependency on [Widgets-DigSig] in Step 4... So, I guess they are not 
really "dependencies", more like specified conditions in the presence of 
an implementation of particular specifications.

>> A user agent MUST
>> NOT allow read access to any digital signature in the widget package at
>> runtime.
> I think this conflates requirements for a P&C UA with the requirements
> for Widget [Runtime] UA.


> As such, I disagree with what you are trying to
> prescribe here and think the specs should remain silent on this (or
> perhaps defer this to a definition of a Widgets UA runtime model).


> I still cannot understand why you want to preclude a widget from being
> able to access *all* of its resources. Perhaps it would be helpful if
> you would elaborate on the risk(s) you are trying to mitigate.

Please see Mark's emails[1][2]. He outlined the problem pretty clearly 
and use cases for the author accessing the signature have not been 

Kind regards,

Received on Monday, 13 April 2009 11:29:37 UTC

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