Privileged contexts charter text

Dear WebAppSec,

This is the thread where we discuss the question of scoping the "Privileged
Contexts" deliverable.  Without further ado, here's our proposed charter
text:

-----BEGIN-----
Privileged Contexts (FPWD) - A  recommendation defining a notion of
privileged contexts, which can be used by other features to define security
boundaries, e.g., to protect  access to sensitive personal information.
The recommendation will  describe factors that factors to be considered in
deciding when the  use of a privileged context should be required.  This
work will be a  joint deliverable with the W3C Technical Architecture Group.
-----END-----

The major differences here are (1) it focuses on the definitional aspect of
the document, and (2) instead of "non-normative advice", it calls for
"factors to be considered".

Now, why do we think this is better?  In brief, because it gets work done
-- it focuses on the areas where there is very widespread consensus, and
punts on questions that will slow this work down.

Let me start by saying that we are totally on board with the idea of
privileged contexts and the idea that more of the web needs to live there
-- ideally the whole web.  The question is how best to move toward that
state.  There's a need here to balance between building momentum behind
privileged contexts by providing good tools, while not creating negative
energy that will slow it down.  There is very widespread agreement that a
consistent definition of privileged contexts would be a useful tool for
building the web, and even the considerations that one has to balance when
deciding when to use them.

There is considerably less consensus about how exactly those trade-offs
should be weighed.  WebCrypto, WebRTC, ServiceWorkers, and EME have all had
detailed discussions about where to apply requirements for privileged
contexts.  Looking at these examples, it's not at all clear that there's a
common theme that one could frame as a recommendation.  Worse, it's not
hard to imagine that once the rest of the community gets wind that criteria
are being defined for what should be restricted (as sections 3 and 4 do),
folks will show up to make sure that their favorite API isn't covered.
That will generate a lot of strife and delay for not that much benefit.

How would this change the current document?  First, the overall focus of
the document would be more on what's currently Section 5, defining what a
secure context is.  I would also like to see more discussion of what the
use of a privileged context means for an API; what guarantees it gets.
Likewise, it would be helpful to expand the threat models in section
Section 3.1, again explaining the implications of these models for
evaluating API risks.  Section 3 and Section 4 are where the real problem
lies.  They are very prescriptive, and since they provide no justification
of how they arrive at their prescriptions, not very helpful to API
designers.

So in sum, we think that the WG should focus on specifying the part of this
space around which there is strong consensus, namely the definition of
privileged contexts and the considerations regarding their use.  We should
definitely be discussing the question of how we get more of the web to use
privileged contexts, but we shouldn't gate the specification of privileged
contexts on that question.

Given that this is a fairly small change to the charter text, I would hope
that getting to consensus around it would not cause too much delay.  Thanks
to the chairs for managing this process.

--Richard