RE: Require security review before FPWD

Chaals, David, Jeff,

Direct answer to the Web Security IG involvement in delivering security guidelines...
- The Web Security IG has been re-born one year ago, the dynamic of the Web Security IG is still low (10 people maximum, all overbooked)
- Developing those guidelines were part of my goal as co-chair (see
- I believe that if the W3C were to decide to develop the guidelines, based on Mike's straw man proposal, that would be great.
- The Web Security IG could be a mean to gather the appropriate people, organize the work and make sure something is delivered (provided that we can get on board some contributors)
- and finally, changing my hat, wearing my gemalto hat, we would be delighted to participate...

Co-chair web security IG

-----Original Message-----
From: []
Sent: vendredi 7 novembre 2014 13:57
To: David Singer
Cc: Jeff Jaffe; GALINDO Virginie; Karl Dubost; Anne van Kesteren; Philippe Le Hegaret; public-w3process
Subject: Re: Require security review before FPWD

07.11.2014, 13:08, "David Singer" <>:
> On Nov 7, 2014, at 12:02 , wrote:
>>  04.11.2014, 15:25, "Jeff Jaffe" <>:
>>>  On 11/4/2014 3:40 AM, GALINDO Virginie wrote:
>>>>  +1 for the guidelines,
>>>  Would the Security IG be the right place to develop those guidelines?
>>  They would be the obvious group to have them as a deliverable. But
>> in the nature of things, they probably should look around for
>> expertise in other groups to help make the guidelines as good as we
>> can get them…
>>  cheers
> I think the community as a whole should develop the guidelines, and if we don’t get input from the security IG then I am not sure we’d have a good set of guidelines.


> But the model that ‘the XXX IG is responsible for developing the guidelines’ or, worse, ‘the primary responsibility for an XXX review lies with the YYY IG’, is flawed.

These are very different. Asking "the whole community" to publish and maintain the document falls into the "4 people" trap (everybody, somebody, anybody nobody) and makes it difficult to work out how to resolve issues (including that the document was maintained by nobody).

>  This is, in effect, signing up IGs for open-ended amounts of work.
> The primary responsibility for ensuring that XXX has had consideration
> in a document, lies with the group that wants to publish that
> document,


> and in this case, the primary responsibility for developing requirements and guidelines in the process for XXX reviews lies with the group that is working on the process — the process G and the AB, with the AC and staff.

That seems to be signing up the process CG to produce the deliverable. Which is a priori a reasonable alternative proposal - but I think not the right choice.

There is a requirement to discuss the technical aspects of privacy/accessibility/security/etc in order to make the guidelines as useful as we can. Very little of the required expertise is in the Process CG, and it isn't in the scope of the Process CG.

> Yes, we want the security IG’s (and privacy IG’s, and…) help.  No, it is not their deliverable.

I think that the relevant IGs are in fact the best home for the various guidelines, and I think making them deliverables of the respective IGs is in fact the right thing to do - while recognising that the responsibility for getting the reviews rests not with the IGs but the producers of whatever spec needs review.

(And that's what you get for 2 kopecks these days)


> David Singer
> Manager, Software Standards, Apple Inc.

Charles McCathie Nevile - web standards - CTO Office, Yandex - - - Find more at

 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Received on Monday, 10 November 2014 10:51:31 UTC