W3C

- DRAFT -

Web Cryptography Working Group Teleconference

10 Mar 2014

See also: IRC log

Attendees

Present
+1.617.253.aaaa, jyates, markw, virginie, hhalpin, sangrae, drew, vgb, [Microsoft], +1.503.712.aabb, terri, nvdbleek, [Google]
Regrets
Chair
Virginie
Scribe
hhalpin

Contents


<trackbot> Date: 10 March 2014

Note that the call is in one hour, 20:00 UTC

<virginie> helo joanne, the call will start in 5 minues

<jyates> Virginie--thanks

<jyates> I don't hear anything now

Minutes from last telco: http://www.w3.org/2014/03/03-crypto-minutes.html

<scribe> scribe: hhalpin

Any objections to approve minutes from last call?

APPROVED: http://www.w3.org/2014/03/03-crypto-minutes.html

virginie: this meeting will make a decision on the Last Call
... we will now start being a bit more formal with minutes, formally approving them

(given the formal decisions we will be making, we need to make sure they occur)

(and are recorded accurately)

welcome

Last Call for WebCrypto API

virginie: status update on WebCrypto API?

markw: We were pretty close on closing all the bugs that were identified the bugs
... ruled on favor of meaningful error codes as proposed by Microsoft
... bugs are still open because lack of confirm from rsleevi, but as far as I'm concerned its complete
... still some open bugs, but none in the category of needing to complete before entering last call.
... I think we're in good shape to go forward

virginie: any questions that would challenge the idea of going to Last Call?

markw: rsleevi isn't here, but rsleevi thinks that we may need to use JWK for Javascript Objects
... right now we support actual JWK objects
... should we go for them as actual JSON objects
... we discussed and rejected in past, no reason not to revisit
... not an alternative IMHO, could be a new potential feature

virginie: any question to editor of the current spec?
... seems like there is no open questions

<virginie> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html

<virginie> from the 7th of march

israelh: Should we put a comment about the JWK in the spec so folks know that is done by design

markw: seems import/export is consistent as you always get serialized data
... now the idea to expose this in an object format
... as for as I know, it's a new feature

israelh: If we already identified that was something we don't want to cover now
... I think we should go into Last Call without making any more design last calls, going forward with this as a potential

isarelh: it seems like we should just go ahead and get a resolution
... we could say its v2.0 feature

virginie: I think this is not a feature that would not take so much time to agree on.
... we could wait for the next version of spec
... we said we would address JWK only in last call?

markw: One time we discussed we should in context of wrap/unwrap object
... but we were looking at is as either-or
... we could postpone to v2.0

hhalpin: I am noting that rsleevi, who is an editor and represents Google is not on the call
... we could use this time to fix the JWK issue

markw: would want to go to Last Call, feels like we do this later

virginie: Apparently rsleevi wants to have the Last Call decision over email

israelh: I think the last open issue was the error types
... he can express over email
... his concerns, or do we just go to Last Call now?

virginie: We can go to the telecon
... and make a telecon

We make an initial decision here, but open it up to the mailing list

and then we discuss with everyone in the WG that are open

to confirming or formally objecting to the Last Call

and then go to Last Call if everyone on mailing lists agrees in 2 weeks.

If they don't, we either open new issues or go to Last Call.

at the next telecon

israelh: I'm OK with that, but we need to figure out if things are in scope or not

vgb: I think we've been stable for a very long time, so we should go to last call

rsleevi: I'm going through the minutes, I don't entirely agree with Mark on the JWK regarding import/export
... I think we should explore other path, would it be appropriate to get feedback besides developers
... I have gotten feedback that it is better
... we're still identifying blocking points because we're still getting
... another WD with a short last call or a Last Call with a longer feedback cycle

we can either go for last call now if this is a developer issue, or if it's a Google issue then we could delay till last call.

rsleevi: both, even in Google we think its unusable or we can wait for developers to tell us that

markw: what we have is a JSON object, the proposal is that we also expose a Javascript object of JWK. But we could even do that to ASN.1
... so I don't think its unusable, that's an easy function for someone to do
... this idea has been clear for months and months
... we can deal with this at Last Call

rsleevi: I want to re-iterate ASN.1 that this can be done as easily is false, most of DOM4 can be implemented as functions in JQuery, that may not be good for developers
... at the primary example, we just changed RSA and HMAC in breaking manner, and the mapping to JWK - those mapping tables show there are gaps within the scope and impedance mismatch between JWK and this spec
... we are revisiting, but it's clear that are several issues on usability

<rsleevi> @hhalpin: They're issues on our end (our spec)

<rsleevi> @hhalpin: Again, if we go to last call, I think we need to have a suitable last call period to allow feedback from everyone - that is, 3 weeks is not desirable

Its not a big deal if a member wants 2 more weeks to review, it would be worrisome if the process never ended.

So as long as we commit to addressing the issue, then I think that's fine.

israelh: Is there a list of other issues that you have defined, or is this the last one?
... anything else major?

rsleevi: we made a lot of changes in last month, some have overlapped, we are still not confident there's been review within the WG
... if we go to Last Call for not only Working Group members to review the spec, as well as the general public
... there's no confidence that the spec has been widely reviewed
... we are very concerned, especially with the compressed period

virginie: this is normal to go forward
... I would suggest we go for Last Call and add a note to address the JWK issue during Last Call

PROPOSAL: Go to Last Call and add a note with 8 weeks of review.

<virginie> Resolution : go for last call with a note calling for JWK javascript object with 8 weeks of review

rsleevi: As aggressively we'd like to get Last Call, and I think 8 weeks is an appropriate time as once we ship we want to get changes

<rsleevi> I can send it today.

israelh: How do we feel as a group if we can get a proposal for solving the JWK issue within 2 weeks?
... we just give a resolution to solve this, and then if this is an issue we need to solve from an implementer perspective, then we can move forward

virginie: New WD that solves this JWK issue, and then go Last Call
... just filling in the blanks

markw: I think it would be better to go to Last Call now, if the proposal was to import/export Javascript Object

<rsleevi> @markw: That's no the proposal

markw: that's simple

<rsleevi> @markw: It doesn't break wrap/unwrap

markw: if the proposal is to replace existing JWK import/export that would break wrap/unwrap

terri: Given we just spent another hour, then maybe we just publish new working draft

israelh: I'm wondering if what Mark suggested is a reasonable approach and then a way to JSON
... ize the objects that doesn't break wrap/unwrap

rsleevi: My concern is do we make JWK an JSON Web Key object, I'm not sure if question of breaking wrap/unwrap - but what is suitble default, ArrayBuffer or object?

virginie: We give ourselves 2 weeks way to solve JWK object question out, and then we go to Last Call. If there is no technical solution, then we replay the WD.
... we can't go to LC without this feature?

rsleevi: If we go to LC then we have to forward with this as a continuing questions, we may make breaking changes

Why not 2 weeks and then Last Call?

markw: 2 weeks deliverable doesn't seem to object
... we get message to developers sooner rather than later

can we sort that in 2 weeks?

<vgb> how about get a proposal this week and discuss it next week so we can have a meaningful last call conversation in 2 weeks?

and then we go to Last Call next meeting?

virginie: action to ryan and mark to have a technical proposal for this feature
... 2 weeks we go to Last Call?

<vgb> yes, i want to make sure we don't come to the next call saying we haven't had time to review the proposal

Is this a workable plan?

markw: I was arguing we go to Last Call now

virginie: but I hear terri and rsleevi wanting to address this before we go to Last Call now

<rsleevi> I would like to clarify that

<rsleevi> I don't think my position is being represented

israelh: Let's give ourselves a time limit of 2 weeks, and then we come up of a soltuion, then we go for standard last call
... seems reasonable

<markw> I can go with what Isreal says

<rsleevi> To re-iterate: If we decide *not* to block LC, then we need an extended LC and will likely revisit this.

<terri> I agree with israelh, just that we not make the decision in 1 minute since it's clear we don't really agree enough for last call today.

PROPOSAL: Revisit Last Call in 2 weeks with action to solve this JWK
... issue

rsleevi: proposal should be 8 weeks, regardless 2 week + 6 week last call

<vgb> i can write up a proposal fairly quickly for the JWK thing, and we cna discuss it on the list starting tomorrow. ok?

<rsleevi> @vgb: I can have it up today within a few hours

terri: I would be OK with that

<vgb> @rsleevi even better :)

<rsleevi> The question for the WG is what should the *default* be for "JWK", which is where I think the only 'contention' is

<rsleevi> PROPOSAL: Take the current ED to LC for 8 weeks, with an "open issue" of JWK

<virginie> resolution : Last call with 8 weeks of comments with a note and an action to adress the JWK aspect

<markw> +1

<nvdbleek> +1

<sangrae> +1

<virginie> +1 (as gemalto)

<terri> -1, this feels rushed to me.

<terri> but it's fine if I'm outvoted.

<mete> +1

<rsleevi> +0 . It works. It's up to the WG what it wants to signal

<terri> -1 but I can live with the group consensus

terri: I don't think it's a good idea but I can live with it

RESOLUTION: Going to Last Call and we ask for 8 weeks of review for Last Call.

virginie: next call 24th of march
... thanks everyone, let's close call.

trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-03-10 21:08:06 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/vgb/israelh/
Succeeded: s/we also expose a Javascript version/the proposal is that we also expose a Javascript object/
Found Scribe: hhalpin
Inferring ScribeNick: hhalpin
Default Present: +1.617.253.aaaa, jyates, markw, virginie, hhalpin, sangrae, drew, vgb, [Microsoft], +1.503.712.aabb, terri, nvdbleek, [Google]
Present: +1.617.253.aaaa jyates markw virginie hhalpin sangrae drew vgb [Microsoft] +1.503.712.aabb terri nvdbleek [Google]
Found Date: 10 Mar 2014
Guessing minutes URL: http://www.w3.org/2014/03/10-crypto-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]