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. 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. You suggest referencing RFC 3280. I'd suggest we reference RFC 5280 instead. ;-) 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. 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? 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. That's all for the moment; I look forward to tomorrow's call. -- Thomas Roessler, W3C <[EMAIL PROTECTED]> On 2008-08-01 12:41:02 +0100, David Rogers wrote: > From: David Rogers <[EMAIL PROTECTED]> > To: [email protected], [EMAIL PROTECTED], [EMAIL PROTECTED] > Cc: Nick Allott <[EMAIL PROTECTED]> > 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/[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED] > 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... > > >
