- From: Thomas Roessler <tlr@w3.org>
- Date: Sun, 15 Jun 2008 12:41:38 +0200
- To: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
- Cc: johnath@mozilla.com, pbaker@verisign.com, public-wsc-wg@w3.org, steele@adobe.com, stephen.farrell@cs.tcd.ie, yngve@opera.com
On 2008-06-12 18:22:09 -0400, Mary Ellen Zurko wrote: > You had names on both the to: and cc:. Can you name names so we can all be > clear about who you mean? Sure. Johnath and Yngve since they've most recently looked into conformance; Joe for the extension related part; Stephen and PHB because of the augmented assurance angle. > Can it move to the security considerations section? Here's a stab at how > that would look: I'd rather not. The list of features given here still reads like it's the real definition of conformance for plugins, and therefore creates quite a bit of a confusion risk. I've tentatiely dropped this text. > Plugins wishing to claim conformance will need to understand the > implications of all of the clauses of the conformance level they wish to > claim. For example, plugins which call TLS or present TLS secured content > will need to conform to requirements in 5 Applying TLS to the Web, or > ensure they defer handling of those requirements to some other portion of > the user agent. Plugins will need to neither obscure nor degrade the > rendering of user interface components described in 6.1 Identity and Trust > Anchor Signalling, 6.2 Additional Security Context Information, and 6.4 > Error handling and signalling. In addition, a plugin will need to conform > to 6.4 Error handling and signalling for all security related errors it > handles. Plugins will need to conform to the 7 Robustness recommendations, > with particular attention to 7.1.2 Keep Security Chrome Visible, 7.4.4 > Pop-up Window APIs, and 7.4 APIs Exposed To Web Content. > -- Thomas Roessler, W3C <tlr@w3.org>
Received on Sunday, 15 June 2008 12:28:28 UTC