Seeking feedback on Widget Signing

For signing, we may want to look at XML Signatures... 
http://www.w3.org
/TR/xmldsig-core/.   Mozilla signed scripts may prove a 
good start for ways to describe capabilities...  
http://www.mozilla.org/projects/security/
components/signed-scripts.html

I think we want to be very clear on what we want the default
trust model 
and validation of that trust model to be for Widgets. 
Because they are 
chromeless, Widgets already require a higher level of trust
as they can 
be used for more sophisticated phishing attacks. 

What is intended software distribution model for widgets? 
Are they 
expected to be managed and installed like desktop
applications, or is 
the hope that they can proliferate and be adopted/changed at
the same 
rate as web pages?  Basically, are we asking the IT
department to trust 
the widget engine or the individual widgets themselves or
both?

I think this is an interesting topic to ask the new Web
Security Context 
Working Group to also provide input. 

Brad

Arthur Barstow wrote:
>
> Hi All,
>
> As you may know, on November 9 the FPWD of the Widgets
1.0 spec was 
> published:
>
>  <http://www.w3.org/T
R/widgets/>
>
> Although this document does not explicitly address
"access control" 
> per se, it identifies two security-related issues and
thus I seek your 
> input on these issues. If you have any
feedback/comments on these 
> issues, please respond directly to WAF's public mail
list:
>
>  <mailto:public-appformatsw3.org>
>
> 1. Section 2.1 contains the following open issue
regarding digital 
> signing of widgets:
>
> [[
> A future revision of this draft will address digital
signing of 
> widgets. Need to figure out how.
> ]]
>
> Yahoo!'s Ed Voas submitted a comment about the above
issue:
>
>  <http://lists.w3.org/Archives/Public/p
ublic-appformats/2006Nov/0043.html> 
>
>
> 2. Section 3.13 contains an open issue about the
<security> element:
>
> [[
>
> Specific details of the <security> element are to
be determined. This 
> element might address things like:
>
>     * Signing (although it's unclear if this element is
the right 
> place for that);
>     * Stating the intent to access various domains
(outside the 
> "default browser security model");
>     * Lifting the restricted access to the file system;
>     * Granting access to system sensitive information.
> ]]
>
> Thanks,
>
> Art Barstow
> ---
>
>
>
>
>
>
>
>