Core Gadget - Security Policy
This is a DRAFT.... currently, the Security Policy Feature section is buried inside the element definitions for ModulePrefs... this is silly. This rewrite pulls it out into it's own section and removes the definition of the el_escaping permission which should be defined elsewhere when dealing with the Expression Language stuff..
<section title="Security Policy Feature" anchor='SecurityPolicy'>
<t>Gadget's often require the ability to perform potentially
dangerous or sensitive operations or work with sensitive information.
Such gadget's SHOULD only be allowed to perform those operations
if explicitly granted permission to do so by the container or the
user.</t>
<t>The Security Policy feature is used by a gadget to request
permissions under which to run. Specific permissions are requested
with <Param> elements, with the "name" attribute on the
Param element identifying the feature and the text content of
the element providing any additional required feature-specific information.
The Security Policy feature is specified within the <ModulePrefs>
with the feature name "security-policy" using either the <Optional>
or <Require> element. A container MAY support the
Security Policy feature.</t>
<t>Containers MAY override any gadget-request permission with its
own security policy.</t>
<figure><preamble>A gadget requesting optional permissions from the
container:</preamble><artwork xml:space="preserve">
<ModulePrefs >
<Optional feature="security-policy" >
<Param name="foo">bar</Param>
</Optional >
</ModulePrefs >
</artwork></figure>
<t>If an application requests a security policy that is not supported,
the container MUST log an error to the gadgets.log. A container MAY
render that gadget using a supported security policy, or display an
appropriate error message. TODO: Clarify this</t>
<t>Containers are free to define their own permissions for any purpose.
TODO: should we have a registry of common permissions???</t>
<t>TODO: Move the definition of the el_escaping permission to the
appropriate different location in the spec</t>
</section>