virginie: i see that it was started by Zakim

<rbarnes> i'm on the phone

virginie: ddahl is on the phone

<rbarnes> don't think that worked

<selfissued> selfissued is Mike Jones

<scribe> scribe: ddahl

<hhalpin> PROPOSAL: http://www.w3.org/2012/08/13-crypto-minutes.html is the correct minutes

hhalpin: is that the right command?

<hhalpin> ACCEPT: http://www.w3.org/2012/08/13-crypto-minutes.html is the correct minutes

virginie: Begin with presentation of the draft API

rsleevi: A lot of the changes were in wordsmithing, still a lot of boilerplate to fill in

<virginie> http://www.w3.org/2012/webcrypto/WebCryptoAPI/

Presentation of new Web Crypto API update from editors

<hhalpin> scribenick: ddahl

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0140.html

rsleevi: tried to describe how this api would work in a PKCS#1 mode
... wanted to point out the importance of the keyStorage interface
... types of keys and what origins authorize them
... the key interface is mainly describing the metadata around the keys themselves not how it is initialized etc
... spec'd diffie hellmen, but not ECC
... if implementors have a preferred format for additional key types, feedback is very welcome based on the template provided in the spec
... key import was also tackled here, thanks to vgb for his notes in the mailing list

<rsleevi> for (i = 0; i < window.crypto.keys.length; ++i) { window.crypto.keys[i]; }

rbarnes: key storage stuff looks good, is there a richer way to label the keys? metadata- > name, etc?

rsleevi: perhaps raise an issue on this - numeric getters and symbolic names are used in localStorage, perhaps we do the same?

<rsleevi> window.crypto.key['foo']

rbarnes: meta question: can I refer to a key in a persistent way? not clear if these indexes are persistent?

rsleevi: key object has a keyID and this is fully persistent
... symbolic name vs numeric index? does this matter?

<rsleevi> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#key-interface-members

virginie: did you specify the persistence of each key?

rsleevi: still need to do that - add language to clarify

<rsleevi> ACTION: sleevi to add explicit language to clarify that Key object attributes are persistent to keys. the key.id is consistent between browsing contexts [recorded in http://www.w3.org/2012/08/20-crypto-minutes.html#action01]

<trackbot> Created ACTION-34 - Add explicit language to clarify that Key object attributes are persistent to keys. the key.id is consistent between browsing contexts [on Ryan Sleevi - due 2012-08-27].

asad: followup: can we indicate a source once we have the key ID?
... certain operations would be tied to a specific provider
... is the binding of the key ID to the corresponding source known to the web app?

rsleevi: if an implementation is going to expose providers, it is an implementation detail

<hhalpin> i.e. "custom attribute"

asad: if a user selects a key, it is up to the browser to make sure the operations are executed within the specific source?

rsleevi: yes, but there will be additional discussions on this - [reference to a recently closed issue]
... this provider issue is in the secondary use cases

markw: where would we put the global Id for a pre-provisioned sym key?

rsleevi: there should be some kind of foreknowledge of the key's meta data that might be stored in localStorage, etc
... need to raise an issue here

markw: do we need a couple of key IDs to help locate symmetric keys?
... one global and one in the origin

rsleevi: pre-provisioned attrs should help here

<rsleevi> ddahl: The (closed) query issue was ACTION-16

markw: most of the attributes are user attributes seem to carry less weight than needed for unique IDs for symmetric keys

(ddahl note: that last bit was hard to scribe)

__markw: was that accurate?

rsleevi: there have been a few actions that did not have a wide consensus before closing them

markw: the GUID for sym keys issue needs more discussion

<hhalpin> either way of dealing with it is actually fine!

<hhalpin> perhaps its more of an open ISSUE

<hhalpin> than an action.

virginie: action 16 was closed, but probably needs postponement instead

<markw> just to be clear, a globally unique identifier for pre-provisioned symmetric keys needs more discussion (it's been suggested that the id field on the key - which is a local identifier - might actually be a GUID)

rsleevi: need to build better consensus on mailing list

selfissued: Need to touch on the relationship between JOSE and W3 web crypto - and how we will use JOSE

<rsleevi> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#use-cases

selfissued: need to have new paragraph on this topic in the spec

virginie: there is something in the draft
... to that effect

hhalpin: if someone has taken an action and cannot fullfil it - we need to open an issue to help keep track of it

<rsleevi> https://www.w3.org/2012/webcrypto/track/issues/17 / ISSUE-17 is tracking the discussion on attributes

hhalpin: or if consuensus cannot be reached
... JOSE was only being referenced in key import/export
... we are working on a lower-level API that may not support JOSE directly, however, later a high-level design may better support JOSE directly

selfissued: are you looking to get these new JOSE formats created?

<rsleevi> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-KeyFormat

hhalpin: does the working group feel that it is something to discuss now
... ?

selfissued: we need to understand the use cases to make sure it makes sense to support JOSE, some use cases seem to exists just to support JOSE

virginie: if we ask JOSE for new formats - private keys, etc, how long will it take to spec?

selfissued: we could have a draft in weeks, making it part of the spec may not happen until IETF ATL in 3 months

<arunranga> I don't think we need a "spec benediction" to start using it.

<hhalpin> I think the use-case is "key import/export" in the secondary features of the charter, http://www.w3.org/2011/11/webcryptography-charter.html.

<hhalpin> We have about a year to reach total stability on our spec, so timing should be relatively easy here

<rsleevi> virginie: There's an ISSUE ;)

markw: unique ID thing is functional and may need a separate issue

virginie: let it be so!

rsleevi: importing og JWK public keys seems like a very useful thing
... exporting private keys may require some custom operations with polyfills etc in mind
... exposing this kind of thing for RSA with OEAP will be tricky
... is there a WEBIDL or JWK format that will allow this
... ?
... we could create a WebIDL for this operation

selfissued: we should see if we can get IETF to also spec this format

<Zakim> rsleevi, you wanted to respond about JOSE

rsleevi: the overhead of ASN.1 parser is part of this ongoing issue

markw: want to understand how the DH will work?

<rsleevi> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dh

markw: 2 operations, KeyGen and KD - do you use the KD to derive the key?

rsleevi: yes, 3 phases, 1. key gen, export key so we can get either side of key, then KD operation. Phase 2: derive shared secret
... can an application polyfill? maybe, or we should specify this

markw: we might have a generic key exchange API that makes the algorithm an argument

rsleevi: strong case to keep this operations spearate
... fairly common to separate these ops in most crypto APIs

markw: would like to have less specific key exchange API
... less specific to alg

rsleevi: where do we draw the boundry between low and high level apis
... looking for input for the preferred form here

<hhalpin> +1 re slipperly slope, we do have time limits!

virginie: markw: can you provide an example here?

markw: yes

virginie: we have some issues in the draft that do not appear in our issue tracker, should we add them?

rsleevi: yes, the intent was to get more input from WG members
... we will convert them all over to real issues

virginie: there is still some heavy debate on the mailing list on various issues

vgb: the import export has made it into the draft, still need more feedback

<virginie> http://www.w3.org/2012/webcrypto/track/actions/open

virginie: we should cover the open actions

<hhalpin> ACTION-13 WTC and Arun to add missing use-cases [CONTINUES]

<hhalpin> ACTION-17 Review key generation and propose a way for user agents to expose unique IDs as first class [CONTINUES]

rsleevi: need to clarify action ?? to help with the understanding of issue 34

virginie: getRandomValues issue needs clarification

<hhalpin> ACTION-23: wseltzer return with report on XMLSec PAG [CONTINUES]

<trackbot> ACTION-23 Find out status of getrandom in HTML5 notes added

wtc: discussed this with ifette, just copied this from the whatwg site

hhalpin: unclear to me about each implementation

wtc: implemented in Chrome and Firefox

hhalpin: will the IE team be interested in implementing it

NOTE: the Firefox implementation is not landed in Firefox nightly yet, waiting on some DOM hackers to look at it. it is implemented in patches:)

vgb: IE team COULD easily implement this, however I do not speak for them:)

hhalpin: changes to the verbiage to make it more clear how this ended up in the spec

wtc: i can clarify this

<rsleevi> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#Crypto-method-getRandomValues - current text

virginie: need commentary on the current draft from WG members

<hhalpin> ACTION: hhalpin to talk to adrian bateman re IE implementation of getRandomValues [recorded in http://www.w3.org/2012/08/20-crypto-minutes.html#action02]

<trackbot> Created ACTION-35 - Talk to adrian bateman re IE implementation of getRandomValues [on Harry Halpin - due 2012-08-27].

<rsleevi> +1 to proposals, and not just issues ;)

virginie: comments plus proposal are needed

<asad> +1

+1

<emily> +1

<virginie> +1

<hhalpin> +2

<arunranga> +1

<rbarnes> +1

<cjkula> +1

<vgb> +1

<wtc> +1

<sdurbha> +1

<JimD> +1 but we may need to comment on comments as well

virginie: need to go find the participants we may not have heard from to get feedback from them

<arunranga> Notes that the synchronous question is an important one which we didn't really discuss.

<hhalpin> thus the editors get a well-deserved vacation!

arunranga: i think the synch version should follow other existing DOM apis that do this

<hhalpin> as people get a week for comments

virginie: try to get as much feedback in by this Friday

rsleevi: some specs are barebones, some are fully spec'd with implementations, we have a number of open issues and actions yet, how far do we wnat to go before we feel like we have a publishable spec?

virginie: we can have many open issue before we publish FPWD

hhalpin: some APIs just document what browsers already do, the nature of this API does want each issue to be well-documented
... current draft is in good shape

markw: before FPWD we need each functional piece documented in the spec or in an open issue
... the identity piece is not well defined

virginie: propose comments until next monday instead

rsleevi: comments may just be "here is an issue..."

<hhalpin> please send *exact* text if possible to the editors on the mailing list!

rsleevi: please propose text and raise issues, but at least raise issues

<zooko> bye!

virginie: meeting over amd thanks ryan!

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/zakim: i am aabb//
Succeeded: s/+1.512.257.aaaa is asad//
Succeeded: s/I believe they are public//
Succeeded: s/they become public as soon as meeting is over//
Succeeded: s/see web-page for records of previous meetings//
Succeeded: s/not really, but it won't take into account any minor errors we tend to make and fix with s. If you really want to watch the minutes live, go for it.//
Found Scribe: ddahl
Inferring ScribeNick: ddahl
Found ScribeNick: ddahl
Default Present: +1.512.257.aaaa, +1.410.290.aabb, saerd, ddahl, emily, virginie, Google, [Microsoft], JimD, markw, rbarnes, hhalpin, arunranga, zooko
Present: +1.512.257.aaaa +1.410.290.aabb saerd ddahl emily virginie Google [Microsoft] JimD markw rbarnes hhalpin arunranga zooko

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 20 Aug 2012
Guessing minutes URL: http://www.w3.org/2012/08/20-crypto-minutes.html
People with action items: hhalpin sleevi