Re: [W3C Web Crypto WG] Rechartering discussion

Just to clarify as I've had a few off list emails expressing confusion
on what it means to 'recharter' from folks new to the W3C:

We can recharter WebCrypto with *no* new deliverables. This means we can
simply extend the charter to deal with the current relatively small
delay we have off of our current charter.

That being said, if there is work that people want in scope, either of
the WebCrypto WG or WebAppSec or a new WG, it would be great to have
member submissions before the WebCrypto charter expired, ideally before
the end of February. W3C wants work to go in the best and most
appropriate forum for the particular deliverable.

Although the decision would always rest with the WG for new deliverables
to a charter and with the AC for the creation of a new WG, I would
personally skeptical of adding new deliverables unless there are clear
member submissions and some emerging consensus that we should add a new
deliverable.

Nonetheless, we at W3C are firmly interested in seeing authentication on
the Web become more secure, and are actively interested in ways to
operationalize this in a way that is acceptable to both users, vendors,
and implementers. It's a tough job, but someone's got to do it :)

   cheers,
       harry


On 01/08/2015 01:31 AM, Richard Barnes wrote:
> On Wed, Jan 7, 2015 at 7:43 PM, Ryan Sleevi <sleevi@google.com> wrote:
> 
>> As noted during the F2F during the 2014 TPAC, it's unlikely we would
>> be able to support such a rechartering.
>>
>> In the goals, only the first goal is something that aligns with our
>> interest.
>> In the scope, we are explicitly not interested in "user managed"
>> storage and "web certificate management". Further, we don't believe
>> this group is the appropriate venue for the discussion of Web
>> Authentication - that would be better for WebApps or WebAppSec.
>> WebAppSec already has proposals for dealing with credentials -
>> http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0141.html
>>
>> Put differently, for a rechartering, the only effort we'd likely
>> support support is the maintenance and exploration of algorithms.
>>
>> Any other chartering discussions should follow the highly productive
>> workmodes of WebApps and WebAppSecs - that is, concrete, defined
>> proposals being brought forth and holding rechartering discussions in
>> specific and narrow scopes if such proposals have consensus (in
>> particular, from user agents).
>>
> 
> Reserving the right to disagree with Ryan on the particular scoping above,
> I strongly agree with the above paragraph.  None of the proposed work items
> to date has been defined in enough scope to make it clear what a WG would
> do.
> 
> --Richard
> 
> 
> 
>>
>>
>> On Wed, Jan 7, 2015 at 1:48 AM, GALINDO Virginie
>> <Virginie.Galindo@gemalto.com> wrote:
>>> Dear all,
>>>
>>>
>>>
>>> Web Crypto WG charter [1] will end by the end of March. We need to
>> prepare
>>> the next charter of Web Crypto.
>>>
>>>
>>>
>>> As a reminder, the conversation has started on this page :
>>> https://www.w3.org/Security/wiki/IG/webcryptonext_draft_charter
>>>
>>> Feel free to add you ideas and suggestions on the wiki and/or expose your
>>> opinion and question on the public-webcrypto@w3.org or
>>> public-webcrypto-comment@w3.org (for non W3C Web Crypto WG members).
>>>
>>>
>>>
>>> Regards,
>>>
>>> Virginie
>>>
>>>
>>>
>>> [1] http://www.w3.org/2011/11/webcryptography-charter.html
>>>
>>>
>>>
>>> ________________________________
>>> 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 Thursday, 15 January 2015 13:50:48 UTC