[minutes] Dec 17 Teleconf

Thanks to all, editors especially, for the good work getting three
documents approved for publication for our next heartbeat.

Minutes at http://www.w3.org/2012/12/17-crypto-minutes.html and below.

--Wendy

17 Dec 2012

   [2]Agenda

      [2]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Dec/0044.html

   See also: [3]IRC log

      [3] http://www.w3.org/2012/12/17-crypto-irc

Attendees

   Present
          Wendy, +1.707.799.aaaa, emily, Virginie_Galindo, JimD,
          ddahl, John_Simmons, +1.408.540.aabb, arunranga,
          rsleevi, wtc, +1.512.257.aacc, karen, markw,
          [Microsoft], mitchz, Tony_Nadalin, Mike_Jones

   Regrets
   Chair
          Virginie

   Scribe
          rsleevi

Contents

     * [4]Topics
         1. [5]approval for WebCrypto Use Cases for FPWD
         2. [6]Use Cases
         3. [7]Key Discovery
         4. [8]approval for KeyDiscovery API for FPWD
         5. [9]Planning for January
         6. [10]next call/F2F
     * [11]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 17 December 2012

   <wseltzer> markw: The decision on WebCryptoAPI and
   KeyDiscoveryAPI should be a single decision

   <wseltzer> virginie: do I understand correctly, if KeyDiscovery
   is not approved, next step will be to make clear in
   WebCrytpoAPI that this is under development.

   <wseltzer> markw: but in that case, we wouldn't be able to
   approve that today

   <wseltzer> scribenick: rsleevi

   <scribe> scribenick: rsleevi

approval for WebCrypto Use Cases for FPWD

Use Cases

   <wseltzer> [Use cases:
   [12]http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overv
   iew.html]

     [12]
http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html

   <arunranga>
   [13]http://lists.w3.org/Archives/Public/public-webcrypto/2012De
   c/0046.html

     [13]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Dec/0046.html

   arunranga: Goal of use cases has always been to primarily
   document "What will we do first"
   ... taken feedback from markw, rsleevi and wrote use cases
   document to cover both APIs
   ... if a feature comes from key discovery API, clearly marked
   as such
   ... more feedback (particularly on OTR) needed, example code
   still needs work

   virginie: Hopefully use cases document will clarify what we're
   trying to reach with the API

   arunranga: Use Cases document is probably not Rec Track, but as
   a companion document

   PROPOSAL: Agreement to publish Use Cases document as FPWD

   <JimD> +1

   +1

   <emily> +1

   <ddahl> +1

   <virginie> +1

   <wseltzer> +1

   <arunranga> +1

   <Karen_> +1

   <wtc> +1

   <johnsim> +1

   <mitchz> +1

   RESOLUTION: Use Cases document to be published as FPWD

   <scribe> ACTION: arun to update Use Cases to conform to Pub
   Rules [recorded in
   [14]http://www.w3.org/2012/12/17-crypto-minutes.html#action01]

   <trackbot> Created ACTION-71 - Update Use Cases to conform to
   Pub Rules [on Arun Ranganathan - due 2012-12-24].

Key Discovery

approval for KeyDiscovery API for FPWD

   <wseltzer> [Key Discovery:
   [15]http://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/k
   eydiscovery.html ]

     [15]
http://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/keydiscovery.html

   markw: Scope of key discovery draft has been limited to
   origin-specific named provisioned keys
   ... Changes since last week: Updated async pattern to match
   core Web Crypto API pattern
   ... returning no keys is considered an 'error' case, although
   it may represent a normal case (no keys, user not authorized)

   <wseltzer> [Mark's update email:
   [16]http://www.w3.org/mid/8B8A45F5-1877-485E-914E-BC2908304FF1@
   netflix.com ]

     [16]
http://www.w3.org/mid/8B8A45F5-1877-485E-914E-BC2908304FF1@netflix.com

   markw: means onsuccess always has 1 or more keys
   ... introduces NamedKey subclass of Key, exposes new
   attributes. Object is immutable on creation (id and name CANNOT
   change)
   ... has a case where underlying key material may disappear
   while a Key object exists
   ... moves use case from core spec that used discovery into this
   spec
   ... added to workerglobalscope

   <Karen_> +q

   <arunranga> markw, a "once-over" of the use case would be
   helpful.

   karen: Why is cryptokey on window instead of window.crypto

   <johnsim> microsoft.a is tony nadalin

   markw: The idea was to try to make a clear separation between
   the optional functionality and the core spec
   ... Having two high level objects is a clear way to signal that

   karen: Isn't putting .cryptokey under .crypto the same?

   markw: Really don't have a strong opinion

   <wseltzer> rlseevi: don't have strong opinion, suggest we take
   the discussion to the list

   <wseltzer> ... how does it interface with core spec, with
   workers

   <wseltzer> ... mostly a question for implementors

   virginie: This spec is just a first draft, showing we're
   progressing and well-structuring the specification

   <arunranga> +1 rsleevi, and FWIW I think that we don't need to
   bring provisioned keys and {generated} keys under the same host
   object.

   wtc: The way you specify the name attribute implies you want to
   allow multiple keys with the same name
   ... Wondering if you have a use case for keys with the same
   name, or is this an oversight?

   <arunranga> - arunranga

   markw: I don't think we have a use case for multiple keys in
   the same device with the same name
   ... The way key discovery was specified is that you get all the
   keys that match the criteria
   ... currently the only criteria is name, which is an exact
   match
   ... discussing internally about alternate matching (eg:
   wildcards) which can return multiple keys
   ... believes it was decided against, so that the outcome was
   only zero or one keys

   virginie: wtc, do you see use cases for multiple keys matching
   the same name

   <selfissued> Mike Jones online

   wtc: This was just a question when comparing what Mark
   specified and what was specified in the FPWD. What was the
   equivalent attribute in the FPWD implied that it is unique
   within the origin, but the current draft in Mark's spec has no
   such requirement

   markw: The intention was that the name was unique within the
   origin. We can change that

   wseltzer: Just to put a voice to what Arun mentioned on IRC.
   The votes are just to the publication of the documents.
   ... Agreement means you agree the document accurately captures
   the state of discussion, not necessarily that you agree with
   whats in the document or that you support all of the features
   ... thanks to everyone for getting to this point

   PROPOSAL: Publish Key Discovery API as FPWD

   +1

   <markw> +1

   <ddahl> +1

   <JimD> +1

   <Karen_> +1

   <virginie> +1

   <emily> +1

   <wseltzer> +1

   <mitchz> +1

   <selfissued> +1

   RESOLUTION: Consensus to publish key discovery API

   virginie: Thanks to Mark for taking up editing this document.
   It will be submitted for WD with the main API

   <scribe> ACTION: markw to update Key Discovery API to Pub Rules
   [recorded in
   [17]http://www.w3.org/2012/12/17-crypto-minutes.html#action02]

   <trackbot> Sorry, couldn't find markw. You can review and
   register nicknames at
   <[18]http://www.w3.org/2012/webcrypto/track/users>.

     [18] http://www.w3.org/2012/webcrypto/track/users%3E.

   <wseltzer> rsleevi: There have been no changes since we called
   for publication last week

   <wseltzer> ... still some pubrules and typo changes to fix, but
   no substantive changes

   PROPOSAL: Publish Web Crypto API ED as the next WD

   +1

   <virginie> +1

   <ddahl> +1

   <emily> +1

   <JimD> +1

   <wtc> +1

   <Karen_> +1

   <mitchz> +1

   <wseltzer> +1

   <markw> +1

   RESOLUTION: Consensus to publish as next WD

   <wseltzer>
   [19]http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Over
   view.html]

     [19]
http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html

   <scribe> ACTION: rsleevi to update ED to Pub Rules for next WD
   [recorded in
   [20]http://www.w3.org/2012/12/17-crypto-minutes.html#action03]

   <trackbot> Created ACTION-72 - Update ED to Pub Rules for next
   WD [on Ryan Sleevi - due 2012-12-24].

Planning for January

next call/F2F

   virginie: Planning for how to get feedback from community about
   this next WD and getting feedback from the wider community
   ... Key Discovery API is very new, make sure that we're
   covering the necessary features

   <johnsim> +1 on publishing web crypto API ED

   virginie: regular call will be one call every two weeks.
   ... call will focus on specific issues to make sure we're
   helping the editors improve the specification
   ... To decide in January which week we will meet for a F2F
   ... two weeks in March where wseltzer will be free. Need to
   decide on location
   ... possibilities are Boston and Korea so far

   <JimD> Excellent work. Thanks to the editors!

   virginie: Agreed. Very good that we have a structured set of
   documents and that we're progressing
   ... next challenge will be high-level API, being worked on by
   ddahl, rbarnes, and selfissued
   ... Thanks to everyone for making this call. Next call will be
   second week of January
   ... January 7 at 20:00 UTC

-- 
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Policy Counsel, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

Received on Monday, 17 December 2012 20:51:10 UTC