<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: http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html]

<arunranga> 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 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: 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: 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 http://www.w3.org/2012/12/17-crypto-minutes.html#action02]

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

<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> [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 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

<wseltzer> trackbot, end teleconf