This document briefly describes a description of identity and trust model for widgets with some suggested requirements for a security model consisting of a widget's declaration of intent with an accompanying security policy document. The position is based on Opera's prior implementation experience with widgets.
In the discussion of identity models here, the definition of identity does not correspond with any similarily named concept in the set of widget specifications. It is not the identity of a single widget, but rather the identity of the authoring or issuing party of a widget or client-side web application.
By and large, there are two categories of assigning identity to a widget; origin-based identity, where the identity is a property of the medium the widget is delivered from, and signature-based identity, where the transfer method or medium is irrelevant, instead relying on a verifiable signature embedded within the widget, used to assign identity.
Origin-based identity may be formed whenever the widget is delivered from any source, and the strength of the identity is based on a number of implicit criteria:
In the majority of the cases, we can assume that the origin will be a widget delivered over http or https, using the domain the widget is served from forming the base of the identity.
The strength of this model is that it's extremely simple for authors, as there are no further concerns for the author beyond deploying the widget.
The weakness of the model lies in it's simplicity:
The other form of identity is based on signing the widget package, widget signatures, preferably in accordance the Widget Digital Signatures 1.0. The strength of this identity model are numerous:
The downside to a signature-based model is that it places a small, extra toll on the developer who will have to sign the widget.
It should be noted that the established identity of the widget itself does not imply any trust is pre-delegated to the widget, or widgets from a certain origin, or by a certain widget signer.
Determining trust for a widget with verified identity may vary from vendor to vendor, and criteria such as vendor business concerns, partnerships, QA processes, community trust and user decisions come into play. It is thus believed that a one-size-fits-all model for assigning trust may be difficult to achieve.
Based on identity and trust, any of the interested parties may provide a security policy that should apply to the widget. This model is required to mitigate a number of factors:
A security policy needs to be based on the following components.
A common syntax for expressing a declaration of intent must be developed. This language must be contained within the widget package itself, either as part of config.xml. This declaration syntax must provide authors the ability to:
It is highly preferable that the syntax for declaration is kept simple, as history shows that authors are still often hand-editing code, or using copy-and-paste to author markup.
Upon installation of a widget, a User Agent should examine the identity of the widget, and provide a mapping between this identity and a policy document that describes the privileges this widget may have. Installation of the widget should be determined based on the result of comparing the declaration of intent and the policy. Should the widget require something the policy can't allow, installation should preferably fail.
As with the intent language, it is desirable to have a common policy language, mostly from a perspective of reuse and integration with other toolchains. The main requirement for such a policy language is that it is able to provide a one-to-one mapping with a language for declaration of intent.