Re: Last call for public comments on Web Crypto charter

> Harry,
> I'm sorry these comments are coming rather late.
> We share some of the concerns that have been expressed about the scope of
> the charter focussing on solutions rather than on the problem. The
> specific technology solutions should be driven by use-cases and
> identifying these should be the first task of the group (unless we want to
> do that now, and have scope be "support these use-cases").

I agree that use-cases should be the first task of the group, and I'm
happy to add an explicit non-normative use-case deliverable.

> I think that in essence what we are trying to achieve is to enable Web
> Application Developers to create secure application protocols. I took a
> stab at re-casting the first three paragraphs of the scope in this way. I
> think that the intention of the existing text is maintained, but at this
> different level. I also think we should be explicit about the need for
> use-cases and give the group a mandate to exclude use-cases based on
> schedule risk (the reason for trying in advance to exclude one technology
> area or another was only to have a task that could be finished on time.
> But commonly there is churn in the mapping of features to releases based
> on actually meeting the schedule, so why not just be explicit about
> that).

The reason why we try to have explicit scoping in the charter is because

1) IP for W3C RFF is scoped to the charter originally.

2) To prevent the group from going down long, winding paths - so the chairs
can rely on the charter to say "out of scope".

So for that reason, I'll try to merge your text as regarding use-cases
(and adding an explicit use-case deliverable) with the text currently in
the charter.

> Regarding the features currently mentioned, I think we should explicitly
> add a mention of pre-provisioned keys, as we have discussed at the
> meeting. I'm also not sure what it meant by excluding "multi-key
> collections" - as soon as you want to generate temporary session keys from
> long-lived keying material you have more than one key for an origin.
> So I propose replacing paragraphs 2-4 of the scope with:
> "The Web Cryptography API will provide Web Application developers with the
> primitives needed to implement secure application protocols, including
> message confidentiality and authentication services, based on secure
> storage of private keying material below the JS API. Features to be
> supported shall be derived from concrete use-cases - the definition of
> which shall form the initial part of the group's work - but shall include
> at least support of public key and symmetric cryptography, key generation,
> key agreement and use of pre-provisioned keys.
> Capabilities related to identity, meaning ways to securely associate
> secret keying material with users or services, shall be out of scope.
> In identifying use-cases, the group shall consider the primary objective
> of meeting the schedule outlined below and may therefore exclude use-cases
> requiring capabilities expected to cause excessive schedule risk. As
> guidance it is expected that access control beyond the same-origin policy,
> management and validation of certificates and device-specific access to
> keying material."
> I am not sure what the "device-specific access to keying material" means,
> though ?

I think this is a reference to Virginie's concerns re whether or not a
particular key is from hardware (smartcard) or software.

> We will happily provide a detailed use-case involving securing
> communication between Javascript application and server in a way that is
> bound to a pre-provisioned key.


I'll try to merge your changes into the charter tomorrow and send an
update to the mailing list, and then we'll get the charter out of the wiki
and into proper HTML so it's ready for AC Review.

> ...Mark
> On Nov 17, 2011, at 7:17 AM, Harry Halpin wrote:
> Everyone,
> On next Tuesday, as said earlier, I plan to take the Web Cryptography
> charter [1] from the wiki and put it into HTML as an "official draft
> charter" then ask for preliminary feedback from the AC, before going to
> real AC review in December (thus launching Working Group in January).
> So, if you have any comments, *now* is the time to send to the mailing
> list. Suggested text replacement is most welcome.
>      cheers,
>         harry
> [1]

Received on Sunday, 20 November 2011 15:47:21 UTC