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
<[email protected]> 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.
True.
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).
Agreed.
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
presented.
Kind regards,
Marcos
[1]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0018.html
[2]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0466.html
