RE: [widgets] OMTP input to W3C Widget Requirements (2 of 2)

Hi Thomas,

Many thanks for your feedback. Please find my comments inline below, marked [MP]. Obviously we can go into more detail on the call later where needed.

Thanks,

Mark 

-----Original Message-----
From: David Rogers [mailto:david.rogers@omtp.org] 
Sent: 07 August 2008 10:09
To: Thomas Roessler
Cc: public-webapps@w3.org; marcosscaceres@gmail.com; art.barstow@nokia.com; Nick Allott; Priestley, Mark, VF-Group
Subject: RE: [widgets] OMTP input to W3C Widget Requirements (2 of 2)

Hi Thomas,

Mark Priestley of Vodafone will respond to you on OMTP's behalf in relation to the comments below. Speak to you all on the call later on today.

Thanks,


David.

-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org]
Sent: 07 August 2008 01:30
To: David Rogers
Cc: public-webapps@w3.org; marcosscaceres@gmail.com; art.barstow@nokia.com; Nick Allott
Subject: Re: [widgets] OMTP input to W3C Widget Requirements (2 of 2)

David,

thanks a lot for your comments.  Some quick reactions to the changes that you propose...

>A conforming specification SHALL specify the expected behaviour when 
>multiple signatures and certificate chains are provided. A conforming 
>specification SHALL specify that if none of the signatures and 
>certificate chains can be verified, e.g. because of missing root 
>certificates or where any certificates in the chain have expired or are 
>not yet valid, then the widget resource SHALL be treated as unsigned. A 
>conforming specification SHALL specify that the widget environment 
>SHALL not install or load a widget resource when it can determine that 
>any certificate in the chain has been revoked.

Note that PKIX CRLs are only required to cover *un*expired certificates.  Therefore, a client may not be able to distinguish an expired and a revoked certificate.

[MP] This requirement is meant to define what happens when a client can tell that a certificate has expired or has been revoked. Is your comment that clients can't always tell the difference?

I'm therefore wary of the proposal to require at least one valid signature chain unless there is at least one revoked chain -- it seems a bit inconsistent.  I'd rather that we say very clearly that either all certificate chains must validate and lead up to a trusted root, or that this must be true for at least one.

[MP] This was not how the requirement was supposed to read. What we were trying to say was that if no certificate chains can be verified then the widget should be treated as unsigned but if the certificate chain can be verified but the client can tell that one of the certificates has been revoked, then the widget will not be treated as unsigned and will be treated as revoked. Does this make more sense?

You suggest referencing RFC 3280.  I'd suggest we reference RFC 5280 instead. ;-)

[MP] Our mistake, agree with your suggestion :-)

In the "Signing Procedure Agnostic" requirement, you write:

> A conforming specification SHALL specify a mechanism for signing a 
> widget resource that does not explicitly or implicitly impose any 
> restrictions on the procedure for generating the signature.

That makes a lot of sense, although there is a question whether a certain set of algorithms should be fixed for interoperability.
(SHA-256 and RSA, for example).  You get to that point in a proposed later requirement; I actually wonder whether it's still worth calling out SHA-1 as a requirement there.

[MP] This was not quite what was meant but I think you make a valid point anyway ;-) What we were trying to say in a round about way was that any procedure for signing a widget (i.e. the end to end process, not just the algorithm used) should not restrict how you are able to use that process. For example, the process shouldn't assume that the signing entity is the same as the widget author. 

Back to the "Signing Procedure Agnostic" requirement:

> More specifically, a conforming specification SHALL allow the use of 
> end entity keys stored in a secure module in a hosted environment. A 
> conforming specification SHALL specify that implementations SHOULD be 
> able to use end entity keys via a
> PKCS#11 interface. 

I'm not sure how this fits together with the rest of the requirements, and with the specification overall.  Could you clarify?

[MP] See above comment for explanation. Also, it is worth mentioning that we were not sure whether such a requirement fell under the scope of this specification but included them so that they could at least be considered. Most signing tools that use secure hardware, such as the tools used to sign many mobile applications today, use the PKCS#11 interface. Our feeling is that to gain widespread support for the mechanism defined in W3C it would be beneficial if tools implementing the specification could just be plugged into existing systems. In light of that desire, we wanted to ensure that whatever mechanism is defined by this specification makes use of PKCS#11 possible. This is highly likely to be the case but we haven't looked at PKCS#11 in detail to be able to make this requirement more specific. Happy to discuss further.    


The "Key Usage Extension" requirement is a good catch.


I'd like to understand the motivation for the "inclusion of revocation information" requirement better.  I think that it's a good idea to mandate widget engines to consult CRLs. However, I wonder if packaging these into the widget itself won't cause a significant likelihood of stale information, at least in Web-based deployments.

[MP] In a lot of cases stale information could be avoided by implementing the necessary server side logic and processing, however, you are right, including revocation information in the package will lead to cases where the information is stale and the widget client will need to fetch new information. The motivation behind this requirement is top be able to reduce load on revocation information servers based on experience with mobile applications. 

That's all for the moment; I look forward to tomorrow's call.
--
Thomas Roessler, W3C  <tlr@w3.org>






On 2008-08-01 12:41:02 +0100, David Rogers wrote:
> From: David Rogers <david.rogers@omtp.org>
> To: public-webapps@w3.org, marcosscaceres@gmail.com, art.barstow@nokia.com
> Cc: Nick Allott <nick.allott@omtp.org>
> Date: Fri, 1 Aug 2008 12:41:02 +0100
> Subject: [widgets] OMTP input to W3C Widget Requirements (2 of 2)
> List-Id: <public-webapps.w3.org>
> X-Spam-Level: 
> Archived-At: <http://www.w3.org/mid/4C83800CE03F754ABA6BA928A6D94A06014DBC16@exch-be14..exchange.local>
> X-Bogosity: Unsure, tests=bogofilter, spamicity=0.500000, version=1.1.6
> 
> Dear Art, Marcos and all,
> 
>  
> 
> Please find attached the second set of OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call as outlined in my last email. The relevant text from the document is extracted below:
> 
>  
> 
> Expressing Widget Dependency Information in Widget Packaging
> 
>  
> 
> Introduction
> 
> OMTP is a forum backed by many of the largest mobile operators and has members from many hardware and software vendors across the value chain.
> 
> It was set up with the aim of gathering and driving mobile terminal requirements to ensure consistent and secure implementations, thereby reducing fragmentation and simplifying the customer experience of mobile data services. OMTP recommendations benefit carriers, content providers, middleware vendors and handset manufacturers to develop open and compatible mobile devices.  OMTP have created their BONDI initiative to specifically address the problem of fragmentation in the evolution of the mobile web and to ensure the protection of the user from malicious web based services. The BONDI initiative will be delivering documentation throughout 2008 with the aim of driving activities in other appropriate standardisation and industry bodies such as W3C.
> 
> Devices supporting some of the features of BONDI will become available in 2009.
> 
>  
> 
> This proposal is intended as input to the W3C Web Applications work group and represents a snapshot of current discussions on including Widget Dependency Information for both heterogeneous (e.g. Mobile) and homogeneous (e.g. PC) environments in the Widget Configuration Document as defined in the W3C Widget Packaging and Configuration specification (Section 6: Configuration Document).
> 
>  
> 
>  
> 
> 
> Terminology
> 
> 
>  
> 
> The following terms are used in this document:
> 
>  
> 
> Widget Package - A collection of resources required by a widget (including a Widget Configuration Document) that is packaged for distributive purposes (from W3C).
> 
>  
> 
> Widget Configuration Document - an XML document that has <widget> as its root. Used to describe the configuration of a Widget Package (from W3C).
> 
>  
> 
> Widget Dependency Information - a combination of Resource Information and Device Capability Information that may be included in a Widget's Configuration Document. Widget Dependency Information is a super-component of Resource Information and Device Capability Information.
> 
>  
> 
> Resource Information - a collection of references and/or inferences to External Widget Resources (e.g., Widget Packages, APIs, Javascript, CSS, XSLT files and packages) that are not included in a Widget's Packaging. Resource Information can be mandatory or optional (see definitions in proposal below). Resource Information is a sub-component of Widget Dependency Information.
> 
>  
> 
> Device Capability Information - a collection of references and/or inferences to Device Capabilities either mandatory or optional (see definitions in proposal below) to provide the functionality of a widget. Device Capability can be hardware-based (e.g., Operating System, Provision of device features such as Camera, etc) and/or software-based (e.g., Specific Browser is available, Specific codec is available, etc). Resource Information can be included either as required (mandatory) or optional in order to provide the functionality of a widget. Device Capability Information is a sub-component of Widget Dependency Information.
> 
>  
> 
>  
> 
> 
> Requirements
> 
> 
>  
> 
> Widget Dependency Groupings
> 
>  
> 
> The Widget Dependency Information required in Widget Packaging falls in to two categories:
> 
>  
> 
> 1.	Resource Information. External Widget Packages, Device APIs (Address Book API, Location API, etc) / Non-Device APIs (e.g. Javascript Toolkits such as Dojo, Yahoo UI, etc) and other web-based resources (e.g., CSS, XSLT, Folders) required to provide the functionality of a widget.
> 2.	Device Capability Information. Minimum environment configuration required to provide the functionality of a widget (e.g., a camera, a particular sub-class of device, etc).
> 
>  
> 
> In addition, each component of Widget Dependency Information should either be:
> 
>  
> 
> 1.	Mandatory - a Resource must be present to install (if required), load and run the core features of the widget. In the case that a mandatory dependency cannot be provisioned a fatal error may occur.
> 2.	Optional - a Resource may be present but could be provisioned later and/or at runtime or not at all to run peripheral / non-core functionality of the widget. In the case that a optional dependency cannot be provisioned a non-fatal error may occur.
> 
>  
> 
> The W3C Widget Packaging specification may wish to define how the widget handling environment will treat dependencies marked as Mandatory and Optional.
> 
>  
> 
> Resource Information and Device Capability Information requirements are discussed below.
> 
>  
> 
> Widget Dependency Information
> 
>  
> 
> A widget developer should include all Widget Dependency Information in their widget configuration document.
> 
>  
> 
> By including this information it is foreseen that the widget developer will be improving the overall experience for their consumers by allowing the intended device to check if the required dependencies are provisioned and/or available to be provisioned prior to the provisioning of the full widget. 
> 
>  
> 
> By specifying the Widget Dependency Information in the Configuration Document it may be possible for a consuming device to query the Configuration Document either prior to download of the entire widget package OR prior to installation/execution of a widget once it has been downloaded to a device. This may be particularly useful in environments that exhibit limited bandwidth and/or where cost is incurred in the download of data (e.g., mobile environments). It may also be used to manage user expectations that the widget will work on their intended device. A user may have the ability to check if the intended widget is likely to run on the intended device prior to incurring the cost and inconvenience of downloading, installing and/or executing the full widget package.
> 
>  
> 
> The Widget Dependency Information may be used by the consuming device to make decisions on which resources the widget is allowed to use. For example, access to resources declared in the Widget Dependency Information may be allowed or denied according to the security policy defined on the device. A consuming device may also allow access to resources that are requested programmatically but not declared in the Widget Dependency Information. 
> 
>  
> 
> It is recommended that developers include all Widget Dependency Information in their Widget Configuration Document to aid the widget provisioning process. The security impact of omitting resources the Widget Dependency Information is currently under discussion within BONDI. For example, failure to declare a widget dependency may result in the device denying widget access to the omitted dependency.
> 
> The intention is that Widget Dependency Information in a Widget's Configuration Document shall not infer any specific means of enforcing security.
> 
>  
> 
> Resource Information
> 
>  
> 
> It should be possible to reference multiple external Widget Resources in a Widget's Configuration Document. External Widget Resources may include Widget Packages, Javascript files, Javascript/Non-Javascript APIs, CSS files, XSLT files and Folders. The reference to any of these Widget Resources must be possible by either:
> 
>  
> 
> §  direct reference to the actual location of that resource (e.g. the URL where the resource resides); OR by,
> 
> §  indirect inference to the resource type, class or unique identifier (e.g. to allow a third-party mechanism to infer the required resource from a selection of similar resources intended for different platforms and environments).
> 
>  
> 
> It shall be possible to specify the version / revision number of a resource. The version or revision number can be either a single value (e.g. v1.5.3) or bounding values (e.g. v1.5.3 to v1.7) that are compatible with the intended widget.
> 
>  
> 
> It shall be possible to specify a friendly (display) name for each Resource Dependency required.
> 
>  
> 
> It shall be possible to state whether a Resource Dependency is Mandatory or Optional for installation and/or execution of the intended widget. The intention is to enable developers to programmatically provide fail-safe functionality (i.e., Exception Handling) when Optional Resource Dependencies are not present on the device. For example, if the Location API is not installed on the intended device, a Widget will can still execute and is able to display maps in the widget but cannot pinpoint the user's location as part of its function.
> 
>  
> 
> It may be possible to indicate where a Resource Dependency should be placed in relation to the Widget Package once it has been provisioned on a device (e.g., Referred Javascript files may be required at a certain point in the relative widget directory path).
> 
>  
> 
> It may be possible to include a hash checksum of the external dependency for each External Resource included in the Configuration Document. This may be used by a device to check the integrity of an external dependency prior to provisioning of the external resource.
> 
>  
> 
> Device Capability Information
> 
>  
> 
> It should be possible to reference multiple Device Capabilities (e.g., Device Type, Operating System, Peripheral Device Support, etc) in a Widget's Configuration Document. This may be based on the specifications provided by the W3C Ubiquitous Web Applications Working Group on Delivery Context Ontology, Interfaces and Functions or some equivalent device capability profiling initiative. 
> 
>  
> 
> It shall be possible to specify an exact match requirement on Device Capability required by a Widget. By this we mean that it should be possible to specify whether a Device should match exactly the information provided in the Device Capability Information to ensure proper function.
> 
>  
> 
> In the case where an exact match is required on an abstract Device Capability node, a Boolean matching expression may be used to indicate if the required Device Capability is available (e.g., an intended device must have a browser = true, rather than a requirement on a specific browser being available).
> 
>  
> 
> It shall be possible to specify a bounding requirement on Device Capabilities required. It should be possible to specify whether the Device should match based on being greater than, less than or equal to a range of responses available (e.g., OS version is less than or equal to v8 and greater than v6).
> 
> --------  END OF DOCUMENT  --------
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Thanks,
> 
>  
> 
>  
> 
> David.
> 
>  
> 
> David Rogers
> OMTP Director of External Relations 
> m: +44 (0) 7771 838197  david.rogers@omtp.org
> skype: dg.rogers
> 
> linkedIn: http://www.linkedin.com/in/davidrogersuk
> 
> 
> OMTP Ltd. 
> Marble Arch Tower
> 55 Bryanston Street
> London
> W1H 7AJ
> 
> www.omtp.org
> 
> P Please consider the environment - don't print this mail unless you really need to...
> 
>  
>

Received on Thursday, 7 August 2008 13:43:55 UTC