See also: IRC log
<trackbot> Date: 15 April 2013
<karen> aacc is Karen
<hhalpin> scribe: ddahl
<hhalpin> PROPOSAL: http://www.w3.org/2013/04/01-crypto-minutes.html are the correct minutes
<hhalpin> RESOLVED: http://www.w3.org/2013/04/01-crypto-minutes.html are the correct minutes
<trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open
<trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open
hhalpin: mainly dealing in
... issue 7 is first
<rsleevi> PROPOSAL: Close ISSUE-7
<hhalpin> RESOLVED: http://www.w3.org/2012/webcrypto/track/issues/7 is CLOSED due to ddahl's document, but the document may not end up being Rec-track
<trackbot> ISSUE-17 -- Define the scope and API for custom key attributes -- open
hhalpin: issue 17 was non-contreversial as well
<hhalpin> PROPOSAL: http://www.w3.org/2012/webcrypto/track/issues/17 is closed and the answer is "there iwll not be aan API for custom key attributes
<hhalpin> RESOLVED: http://www.w3.org/2012/webcrypto/track/issues/17is closed and the answer is there will not be an API for custom key attributes
hhalpin: next is issue 22
hhalpin: cloneable discussion
<hhalpin> I do not aymeric
<trackbot> ISSUE-22 -- Should CryptoOperations be clonable -- open
<hhalpin> does anyone else want clonability?
hhalpin: amyeric is the only one who wanted clonaeability
rsleevi: not stong feelings either way, aymeric's use cases and explanations were not ideal, not going to cry if it goes away, even though there may actualy be solid usecases
hhalpin: we could keep it open and if no uses cases come up, we close it
rsleevi: there are use cases, but, do we need thins in v. 1.0?
<arunranga> Can we list the strong use cases for .clone that are better than Aymeric's scary ones?
<hhalpin> PROPOSAL: Close ISSUE-22 until we have a more tighter use-case and then add a new issue for that use-case
<hhalpin> RESOLVED: Closed ISSUE-22 until we have a more tighter use-case and then add a new issue for that use-case
<hhalpin> that's in SysApps now
hhalpin: issue 32, secure
element, moved to sysaps WG
... anyone here in sysaps? establishing a connection with them might make some sense
<hhalpin> anyone else from sysapps here?
hhalpin: sysaps WG should be notified that we are not doing anything with secure element
rsleevi: gemalto has proposed the
secure element API
... not aware of any formal agreements on implementing it
hhalpin: this is a scoping issue
and we are agreeing to not handle smartcard/seciure element
... proposes that we close issue 32
<hhalpin> So we want to interoperate with any future work (likely via Key Discovery work) in terms of SmartCard and SecureElements, but we are not writing our own APIs for these areas
karen: question: assume the sec element api made its way into sysapps...
if we want to convert or map the sysapp key to the web crypto API?
<nvdbleek> sounds good to me, but keeping a door open for smart card access through a discovery API might be an option in my opinion
scribe: how is that done
<hhalpin> PROPOSAL: ISSUE-32 closed insofar as Secure Elements is now in SysApps, and interoperability with any future API will be done via interoperability with Key Discovery Draft.
karen: sooner or later we will need to deal with interoperability
rsleevi: not going to deal with
apis not in scope or theoretical implenations
... we recognize that this is not a problem for this WG to take on at this time
karen: we don not want to solve the problem right now, but do WG generally work together with overlapping interests?
hhalpin: sometimes you have atask force between 2 WGs for related work
<sangrae> IPcaller is sangrae. Sangrae Cho from ETRI
hhalpin: we might want to clarify
that we will handle keys from secure elements via key discovery
api at alater time
... within a use case doc we can specify the interop here
rsleevi: the proposal in sysaps
by gemalto is not the same as our own use case
... there is very clear charter sep. between the issues, but there are 2 different problems here between the WGs
<nvdbleek> you might also have a look at the wiki page I started about certificate discovery https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/API
<hhalpin> PROPSOAL: ISSUE-32 closed insofar as Secure Elements is now in SysApps, and interoperability with any future API will be done via interoperability with Key Discovery Draft.
<rsleevi> -1, due to the committment on interoperability for as of yet unspecified APIs
i agree with rsleevi here
<rsleevi> Would prefer the second clause dropped
<hhalpin> PROPOSAL: ISSUE-32 closed insofar as Secure Elements is now in SysApps
hhalpin: we could say possible future interop
<hhalpin> any objections to simpler terminology?
<hhalpin> RESOLVED: ISSUE-32 closed insofar as Secure Elements is now in SysApps
<rsleevi> @hhalpin - there are lots of other interop issues beyond key discovery (eg: handling of APDUs and crypto operations via smart cards, hence my objection
hhalpin: no objections, discussion next
<hhalpin> section: unwrap and wrapping
hhalpin: unwarp/ wrap and separation of alg and operation params again
markw: I am suggesting we just
rename tsome things and move things around as there has been
some confusion in reading the key gen / operation params
... we should separate and clarify the dictionaries used in algs and operations
rsleevi: naming is hard
... we should simplify things, however, not sure if there is no overlpa at all
... you don't want to be able to generate a key that you cannot use
<hhalpin> thus, the relationship to operation and algorithm parameters
markw: agree with the comments
that this is hard to nail down here
... not sure how the operation params need to be re-specified once the key is already generated
<hhalpin> ack rsleevi?
rsleevi: i am in agreement in the
idea of if we move paramters to the key we should not have to
specify in operation, but there are edge cases here
... when we start writing example code the spec vastly changes
... some hesitation here yest
hhalpin: makes sense to walk
through this very carefully in the face to face
... or not as time may be limited?
rsleevi: i am planning on working through the issues before our f2f
rsleevi: [the devil is in the details]
<hhalpin> lunch -> 4:30 PM
<hhalpin> 2 hours and 30 minutes
hhalpin: lets look at the schedule to see where we can spend time on this
hhalpin: perhaps we can discuss
this on Tuesday
... during the f2f
markw: we still need to discuss the wrap / unwrap
<hhalpin> Wednesday 24th of April
<hhalpin> 9-10 AM BigNum
<hhalpin> ACTION: hhalpin to make sure Microsoft can make Wednesday morning [recorded in http://www.w3.org/2013/04/15-crypto-minutes.html#action01]
<trackbot> Created ACTION-77 - Make sure Microsoft can make Wednesday morning [on Harry Halpin - due 2013-04-22].
hhalpin: we might discuss high-level during f2f
rsleevi: we should postpone
highlevel discussions until we nail down the first
... we can mobve ny discussion like this till later in the day
<hhalpin> How about moving testing earlier in the day
<hhalpin> use-cases after lunch (would include, high-level and BigNum proposals as well as certificates)
markw: proposal is on the wiki, a
few minor changes based on discussions, fairly fleshed out
... want to understand the process to move forward
... looking to use jwa jwk to soecify this api
... understand the JOSE specs are a moving target
rsleevi: wish we could have
discussed this better by now
... JSON serialization vs Object representation
... discussion within JOSE right now about how to deal woth key wrapping
... algorithm names and key attrs are still being figured out here in both groups
... not convinced we will have an implementable spec yet
... we can move it into the spec with many caveats
markw: would like to move it into
the spec with cveats understood
... implementable? i know a few people who have done this
<rsleevi> Note: I wasn't suggesting canonical JSON - just the issue of DOMString vs UTF-8 ArrayBuffer
markw: is this a style issue over serialization vs. object?
<rsleevi> whereas using a JSON dictionary matching the JWK (eg: the result of a hypothetical JSON.parse) was the more realistic result
<hhalpin> "Feature at risk"
<markw> @rsleevi: do you just mean the pain of converting between the two ?
hhalpin: we can have features "at risk" up until the test stage
<rsleevi> @markw: Both pain and idiomatic API usage. JOSE being a wire-format, whereas we're trying to focus on an API
hhalpin: any more agenda items?
<hhalpin> Meeting adjourned.
<hhalpin> See everyone at the face to face!
<markw> @rsleevi: ok, fair enough
<hhalpin> trackbot end meeting
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/PROPOSOAL/PROPOSAL/ Found Scribe: ddahl Inferring ScribeNick: ddahl Default Present: +1.857.928.aaaa, +1.650.214.aabb, +1.512.257.aacc, ddahl, rsleevi, [IPcaller], Karen, jyates, wseltzer, nvdbleek, hhalpin, +1.415.294.aadd, arunranga, +1.408.540.aaee, markw, skelly, +126.96.36.199.aaff, +1.512.257.aagg, mountie Present: +1.857.928.aaaa +1.650.214.aabb +1.512.257.aacc ddahl rsleevi [IPcaller] Karen jyates wseltzer nvdbleek hhalpin +1.415.294.aadd arunranga +1.408.540.aaee markw skelly +188.8.131.52.aaff +1.512.257.aagg mountie Regrets: Virginie Found Date: 15 Apr 2013 Guessing minutes URL: http://www.w3.org/2013/04/15-crypto-minutes.html People with action items: hhalpin[End of scribe.perl diagnostic output]