15:18:06 <RRSAgent> RRSAgent has joined #crypto
15:18:06 <RRSAgent> logging to http://www.w3.org/2014/10/30-crypto-irc
15:19:08 <virginie> rrsagent, this meeting spans midnight
15:19:53 <virginie> meeting : webcrypto
15:20:29 <virginie> Meeting:webcrypto
15:26:08 <virginie> Chair: virginie
15:26:21 <virginie> agenda+ introduction
15:26:25 <virginie> agenda?
15:28:15 <virginie> zakim, please clear agenda
15:28:15 <Zakim> agenda cleared
15:28:18 <virginie> agenda?
15:28:26 <virginie> agenda+ introduction
15:28:47 <virginie> agenda+ webcrypto API
15:29:02 <virginie> agenda+ Test tools/repository/working method
15:29:16 <virginie> agenda+ Implementation status
15:29:38 <jyates> jyates has joined #crypto
15:29:50 <Charles_Engelke_> Charles_Engelke_ has joined #crypto
15:29:50 <virginie> agenda+ Web Crypto Next Workshop
15:30:05 <steph> steph has joined #crypto
15:30:25 <virginie> agenda+ Re-chartering
15:31:03 <virginie> agenda+ Roadmap & group life
15:31:14 <virginie> agenda+ wrap up
15:31:19 <virginie> agenda?
15:31:32 <sboyera> sboyera has joined #crypto
15:31:32 <nvdbleek> nvdbleek has joined #crypto
15:32:25 <colin> colin has joined #crypto
15:33:13 <Allison> Allison has joined #crypto
15:34:37 <mountie> mountie has joined #crypto
15:35:11 <virginie> Note : slideware to introduce the meeting is available here [pdf] https://www.w3.org/2012/webcrypto/wiki/images/2/2b/Web_Crypto_WG_F2F_Meeting_TPAC_2014_v1.pdf
15:39:21 <steph> steph has joined #crypto
15:39:22 <Karen> Karen has joined #crypto
15:40:13 <markw> markw has joined #crypto
15:40:37 <keiji> keiji has joined #crypto
15:43:34 <tantek> tantek has joined #crypto
15:44:02 <rbarnes> rbarnes has joined #crypto
15:44:24 <sangrae> sangrae has joined #crypto
15:45:05 <jin> jin has joined #crypto
15:46:13 <kodonog> kodonog has joined #crypto
15:46:34 <jy> jy has joined #crypto
15:46:37 <joesteele> joesteele has joined #crypto
15:47:16 <kodonog> scribe: kodonog
15:47:42 <rsleevi> rsleevi has joined #crypto
15:48:06 <kodonog> Virginie: introductions around the room
15:48:15 <kodonog> ... agenda plan
15:48:19 <JeffH> JeffH has joined #crypto
15:48:22 <melinda> melinda has joined #crypto
15:49:05 <harry> harry has joined #crypto
15:49:35 <kodonog> https://www.w3.org/2012/webcrypto/wiki/F2F_santa_clara_Oct2014
15:50:03 <kodonog> Virginie: Objectives for this F2F
15:50:10 <kodonog> ... finalize webcrypto API
15:50:28 <kodonog> ... trigger next phase
15:50:38 <kodonog> ... general discussion (no decision) on next charter
15:52:12 <kodonog> ... News from W3C blog, Jeff Jaffe says security is top priority
15:53:40 <kodonog> .... W3C security activities on a http://www.w3.org/Security/wiki/Main_Page
15:54:20 <kodonog> ... intro slides https://www.w3.org/2012/webcrypto/wiki/images/2/2b/Web_Crypto_WG_F2F_Meeting_TPAC_2014_v1.pdf
15:55:37 <kodonog> ... Web Crypto Discovery API has been unchanged for months, what do we want to do with it (technical note, recommendation, next charter)
15:55:46 <virginie> q?
15:55:53 <kodonog> markw: I was expecting it to go to Last Call soon
15:56:33 <vgb> vgb has joined #crypto
15:56:38 <kodonog> ... it doesn't have the same implementation status as laptop browers, but applicable for some devices
15:56:52 <rsleevi> s/laptop/desktop/
15:57:09 <kodonog> Virginie: that finishes my intro, now moving onto the webcrypto api
15:57:46 <markw> s/laptop browsers/the main api as it's not applicable to laptop & desktop browsers/
15:58:22 <kodonog> rsleevi: missing 25973 (secure origin)
15:58:30 <rsleevi> 25972
15:58:49 <harry> lets kill some bugs that we may otherwise forget
15:59:00 <kodonog> markw: the proposed list are the ones that I thought we could make good progress on
15:59:11 <rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972
15:59:44 <kodonog> s/25973/25972
16:00:34 <rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25198
16:00:39 <JonathanJ1> JonathanJ1 has joined #crypto
16:01:49 <mdwood> mdwood has joined #crypto
16:01:57 <rsleevi> q+
16:02:12 <kodonog> markw: minor implications either way
16:03:06 <kodonog> rsleevi: historical context, originally working around a promise webidl type of bug, the language has been fixed in the webIDL spec
16:03:16 <israelh> israelh has joined #crypto
16:03:22 <israelh> Preasent+ Israel_Hilerio
16:03:39 <kodonog> ... the main argument for doing it as an enum is making it more consistent with webidl
16:03:52 <kodonog> ... if we take it on we are going to be taking on more spec maintenance
16:04:46 <kodonog> ... would anyone be concerned with changing to enum
16:05:08 <kodonog> Israelh: so you are talking about using enums as strings
16:05:10 <vkata> vkata has joined #crypto
16:05:19 <kodonog> markw: no change as far as the user of the api is concerned
16:05:41 <kodonog> ... may have a minor impact on errors
16:06:25 <kodonog> Virginie: there are no objections so we will change to ENUM, what is the timeframe for this change
16:06:55 <kodonog> markw: minor implications either way
16:07:51 <virginie> PROPOSAL: Resolve 25198 by changing the things we changed to DOMString back to enums (KeyFormat, KeyType, KeyUsage)
16:07:58 <rsleevi> +1
16:08:00 <rbarnes> +1
16:08:04 <tantek> tantek has joined #crypto
16:08:06 <wseltzer_> wseltzer_ has joined #crypto
16:08:08 <kodonog> +1
16:08:30 <rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26322
16:08:34 <kodonog> Virginie... 25198 is resolved
16:11:04 <kodonog> rsleevi: explanation: this is messy internal details, issue from tag review, how we expose java script objects without impacting internal processing
16:12:14 <kodonog> ... two solutions under discussion
16:12:17 <virginie> q?
16:12:25 <tantek_> tantek_ has joined #crypto
16:12:33 <kodonog> ... goal is to not have it be visible
16:12:45 <israelh> q
16:12:53 <juanlang> juanlang has joined #crypto
16:13:10 <israelh> q+
16:13:33 <rsleevi> q+
16:14:01 <kodonog> markw: explained third option
16:14:07 <rbarnes> FWIW, in the current Firefox webidl, we have: [Cached, Constant, Frozen] readonly attribute sequence<KeyUsage> usages;
16:14:34 <JonathanJ1> JonathanJ1 has joined #crypto
16:14:48 <nvdbleek> Can you see the internal internal slots in the debugger?
16:15:02 <rsleevi> You can neither see internal slots nor 'internal' internal slots
16:15:16 <kodonog> markw: what we store in the internal slot be what we expose in the ECMA script
16:15:54 <virginie> q?
16:16:02 <nvdbleek> hmm, it is going to be really confusing if you can’t access the ‘real’ internal values
16:16:04 <markw> Options 1) Store a frozen JS object in the existing internal slot
16:16:27 <markw> Option 2) Store a non-frozen JS object in a new internal slot, this is the one returned to script
16:16:41 <markw> Option 3) Store a frozen JS object in a new internal slot
16:16:46 <mountie> mountie has joined #crypto
16:16:58 <virginie> thanks mark for option reminder/clarifying
16:17:23 <mountie> mountie has joined #crypto
16:17:44 <markw> IIUC, Mozilla [Cached, Constant, Frozen] annotation is equivalent to option 3
16:18:09 <kodonog> israelh: this doesn't seem unique to us,
16:18:51 <kodonog> rsleevi: two dimensions to discussion, codify the internal slot in the spec and javascript can't mess with that,
16:19:32 <kodonog> ... other dimension is that read only is a lie, frozen more aligns with what you expect from read only
16:20:16 <kodonog> israelh: we are adding more complexity, read only is a bigger problem,
16:21:01 <kodonog> markw: ideally webIDL would have solved this for us and we would use that solution
16:21:06 <virginie> note : the chair would like to poll : please type your favorite option in the irc in the form of 'I prefer option X' based on markw description
16:21:57 <kodonog> rsleevi: in the presence of this webIDL bug, we need to address it in some way
16:22:22 <kodonog> rsleevi: we should just solve it in the spec,
16:22:36 <kodonog> harry: probably better to do the right thing then to continue a lie
16:22:41 <virginie> q?
16:23:22 <kodonog> israelh: to the extent that implementators aren't going to change their behavior, how much value is there to put this into the spec
16:23:36 <kodonog> rsleevi: TAG would prefer some discussion in the spec
16:23:51 <kodonog> markw: text problem at the moment is that the text isn't clear
16:24:36 <kodonog> markw: we could modify the existing text, we could also add a note that we are expecting webIDL to codify it in the future
16:25:07 <kodonog> israelh: everybody is modifying the objects
16:25:52 <kodonog> rsleevi: this is not what normal programmers expect but it is what web programmers expect
16:26:26 <kodonog> rsleevi: draft proposal: don't freeze the attributes, ensure that the same ECMAscript object is returned
16:26:28 <JMR> JMR has joined #crypto
16:27:12 <virginie> PROPOSAL: 1) Don't freeze the attributes 2) Return the same ECMAscript object each time (aka [Cached])
16:27:31 <rsleevi> Correct, [Cached] but not [Frozen]
16:28:12 <kodonog> Virginie: seeing no objection, we will close the bug
16:29:32 <rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26741
16:29:32 <kodonog> rsleevi: we should check with the original submitters
16:30:14 <kodonog> markw: summarizing  https://www.w3.org/Bugs/Public/show_bug.cgi?id=26741
16:30:34 <rbarnes> 1+
16:30:37 <rbarnes> q+
16:30:52 <rbarnes> q-
16:30:53 <kodonog> ... this type of operation should be delevated to cryptographic libraries, do the libraries validate on import?
16:31:19 <mountie> mountie has joined #crypto
16:31:22 <kodonog> ... given that libraries do, we should validate the public keys on import
16:31:24 <rsleevi> rsleevi: NSS didn't, but it does now
16:31:26 <joesteele> a/delevated/delegated/
16:31:37 <rsleevi> rsleevi: OpenSSL/BoringSSL do, CNG does. Unclear on Apple
16:31:53 <rsleevi> PROPOSAL: Validate EC keys are valid points on the curve during import, and return DataError if not
16:31:58 <mountie> mountie has joined #crypto
16:32:27 <kodonog> Virginie: no object, bug will be closed, clarification in the spec
16:32:37 <rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26903
16:32:48 <kodonog> markw: summarizing https://www.w3.org/Bugs/Public/show_bug.cgi?id=26903
16:33:26 <kodonog> ... we don't know what granularity of errors you will get back from various cryptographic libraries, we are trying to normalize the errors
16:33:50 <kodonog> ... distinction between errors where the raw data is wrong, or the web crypto parameters are incorrect values
16:34:05 <kodonog> ... our definition of syntax errors includes out of range
16:34:35 <virginie> q?
16:34:48 <mdwood_> mdwood_ has joined #crypto
16:34:55 <JonathanJ1> JonathanJ1 has joined #crypto
16:34:55 <kodonog> ... question is should we switch to ??? for all these range type of errors
16:35:21 <israelh> q+
16:35:41 <kodonog> rsleevi: this is really a debugging aide,
16:35:50 <kodonog> rbarnes: one exception is not supported error
16:36:09 <kodonog> israelh: we struggle with this alot, we don't believe that web developers look at the error types
16:36:10 <rsleevi> q+
16:36:45 <kodonog> israelh: you can get better analysis of how things are failing, we could spend alot of time doing this for very little value
16:36:53 <markw> q+
16:37:10 <mountielee> mountielee has joined #crypto
16:37:31 <mountielee> mountielee has left #crypto
16:37:46 <kodonog> rsleevi: there is one thing that web developers do that reports general errors back to the server
16:37:50 <mountielee> mountielee has joined #crypto
16:37:57 <israelh> q+
16:38:19 <kodonog> ... changes to the spec in this area don't affect site compatibility
16:38:44 <kodonog> israelh: this isn't necessarily the case, we are doing things that are borderline
16:39:11 <kodonog> rsleevi: you lie about who else you are, but you are also honest about who you are
16:39:41 <kodonog> markw: our previous decision on enum will have an effect of moving a number of these to type errors
16:40:00 <rsleevi> PROPOSAL: Take a sweep through and find any other issues that should be converted to TypeError
16:40:07 <JeffH> bug # ?
16:40:24 <virginie> to jeffH https://www.w3.org/Bugs/Public/show_bug.cgi?id=26903
16:40:28 <rsleevi> PROPOSAL: Take a sweep through and look for out of range issues that were previously SyntaxError and convert to TypeError
16:40:51 <kodonog> Virginie: no objection, resolved by proposal
16:41:04 <rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25619
16:41:19 <kodonog> markw: summarizing https://www.w3.org/Bugs/Public/show_bug.cgi?id=25619
16:41:47 <kodonog> ... we don't have text on this, we could won't fix this
16:42:09 <markw> https://github.com/w3ctag/spec-reviews/issues/3#issuecomment-41521737, second bullet
16:42:36 <kodonog> vijay: why do we have to go around fixing
16:42:57 <kodonog> rsleevi: for implementors and users this is not an essential definition,
16:43:28 <rbarnes> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#scope-operations
16:43:28 <markw> "Although the API does not expose the notion of cryptographic providers or modules, each key is internally bound to a cryptographic provider or module, so web applications can rest assured that the right cryptographic provider or module will be used to perform cryptographic operations involving that key."
16:43:29 <rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#scope-operations
16:43:32 <kodonog> vijay:maybe we should just remove instances of cryptographic provider,
16:43:58 <kodonog> rsleevi: we added this paragraph on the TAGs request
16:44:09 <virginie> q?
16:45:29 <kodonog> rsleevi: I'll take the action to delete text
16:45:37 <rsleevi> PROPOSAL: rsleevi to reword the section to remove much of the text
16:46:30 <kodonog> Virginie: 25619 closed with Ryan's text
16:46:35 <rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972
16:47:13 <kodonog> Harry: can someone summarize the discussion
16:47:27 <colin> colin has joined #crypto
16:47:54 <kodonog> Virginie: Mark Nottingham could be on a case by case basis
16:48:05 <kodonog> ... no general strategy from W3C
16:48:53 <kodonog> BradHill: in WebAppSec WG we had moved further towards requiring secure origin in more places
16:49:12 <virginie> q?
16:49:16 <kodonog> BradHill: no consensus yet at the W3C level
16:49:18 <rbarnes> rbarnes has joined #crypto
16:49:19 <rsleevi> q+
16:49:41 <kodonog> rsleevi: I will explain our position and rationale
16:50:02 <kodonog> ... from the Chrome side we have restricted this to secure origin, there are at least 2 degrees of restrictions
16:50:30 <kodonog> ... one restrict at the origin of the document or the top level of the origin of the document
16:50:49 <JMR> JMR has left #crypto
16:51:33 <JMR> JMR has joined #crypto
16:51:47 <virginie> q?
16:52:04 <kodonog> ... Chrome has implemented the first scenario, we believe that any web crypto delivered of http won't provide any security guarantees
16:52:10 <kodonog> s/of/over
16:54:07 <virginie> q?
16:54:13 <markw> q+
16:55:15 <nvdbleek> rsleevi: What about localhost and protocols different from http(s) (more specfic on mobile where you can have hybrid applications)
16:55:48 <kodonog> virginie: google has an implementation and it would be hard to sum up
16:55:54 <virginie> q?
16:56:00 <rsleevi> nvdbleek: See http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features for our current context
16:56:40 <kodonog> markw: there are 2 distinct topics: 1) when is it appropriate to require a secure origin as a part of a new feature
16:57:06 <rbarnes_> rbarnes_ has joined #crypto
16:57:21 <kodonog> ... 2) does it make any sense to use webcrypto over http or are any security benefits that you think you might have just an illusion
16:57:32 <harry> q+
16:57:42 <nvdbleek> rsleevi: thank you this totally answers my questions and I personally see any problems with the secure origins proposal
16:58:07 <kodonog> ... we (netflix) have derived some security benefits from this
16:58:09 <nvdbleek> s/see any problems /don’t see any problems /
16:58:20 <mountielee> q+
16:58:36 <harry> q-
16:58:51 <rsleevi> q+
16:59:07 <kodonog> ... test on secure origins, and test on insecure origins (either all pass or all fail)
16:59:20 <harry> q+
17:00:14 <rbarnes_> q+
17:00:14 <kodonog> virginie: mark would be willing to have an option in the spec based on the google approach of the restriction is on the document and not the top level document
17:01:56 <kodonog> mountie: for many years i have request exceptions for some options, ihow do we accept exceptions for secure origin
17:02:26 <kodonog> virginie: is this question out of scope
17:02:59 <markw> s/have an option in the spec/make it allowed for UAs to restrict to secure origins/
17:03:02 <rsleevi> rsleevi: Same Origins Policy changes are out of scope
17:03:23 <harry> That's whats in the charter
17:03:24 <rsleevi> but the (Chrome) proposal recognizes https, wss - but also localhost, 127.0.0.0/8, ::1/128, file, extensions, etc
17:03:36 <virginie> q?
17:03:39 <kodonog> virginie: this is for future discussion
17:04:26 <kodonog> rsleevi: does the current spec allow you to restrict origins today, google's view is "yes"
17:05:53 <virginie> q+ israelh
17:07:12 <kodonog> ... another dimension, if we require https for algorithms ...
17:08:15 <joesteele> q+
17:08:15 <vgb> q+
17:08:15 <kodonog> ... we could do this on an algorithm by algorithm basis and normatively require secure origin for some algorithms and not others
17:08:50 <kodonog> harry: we are moving towards a strawman consensus
17:09:30 <kodonog> ... do not require normatively but strongly encourage and list some use cases where it might be ok
17:10:09 <rsleevi> q+
17:10:16 <harry> ack harry
17:10:47 <kodonog> rbarnes: our implementation does not enforce any secure origins for webcrypto
17:11:05 <kodonog> ... our rationale was that there are some use cases where this makes sense
17:11:11 <kodonog> ... obvious case is digest
17:11:39 <rsleevi> rbarnes: If your view is that passive attackers are the concern, webcrypto over HTTP is just fine
17:11:42 <kodonog> ... this helps for the passive attcker case but obvious not MITM
17:11:52 <rsleevi> scribenick: rsleevi
17:11:58 <tantek> tantek has joined #crypto
17:12:10 <virginie> thanks rsleevi
17:12:24 <kodonog> yes thanks rsleevi
17:12:30 <rsleevi> ... it seems that unless you restrict on top level documents, people will work around any restrictions
17:12:53 <rsleevi> ... someone could stand up https://webcrypto.io and offer a pass-through that would avoid things like same origin restriction
17:12:54 <virginie> q?
17:13:05 <rsleevi> ... seems like restricting to origin without restricting top level will end up in a worse world
17:13:41 <wseltzer> rrsagent, pointer?
17:13:41 <RRSAgent> See http://www.w3.org/2014/10/30-crypto-irc#T17-13-41
17:13:58 <joesteele> -q
17:13:58 <rsleevi> israelh: for us, one of the big concerns of starting to restrict some things in general is enterprises / intranets
17:14:17 <rsleevi> ... we do see some people who want to use different capabilities inside of their firewall/organizations, and we want to provide them some flexibility
17:14:21 <harry> In my personal opinion, restriction to secure origin makes sense for the 99%.
17:14:45 <rsleevi> ... while we see value in this, we think it's up to corporations to set their policies and what sort of environments they want to support
17:14:46 <rbarnes> q+
17:14:55 <harry> That being said, making it normative in the spec - I'm not sure how that will change things if at least one or two vendors have real use-cases they will use this API that they won't change.
17:15:06 <rsleevi> ... and we see this for some of the adhoc development in enterprises where someone is given a project and told to go implement, it's difficult for them to stand up an HTTPS server
17:15:20 <harry> In general, the text should be aimed at Web developers to make sure they do *not* use non-secure origins
17:15:24 <rsleevi> ... from our perspective, it's OK to leave it up to the people who use this stuff to understand their policies
17:15:35 <harry> Enterprise and the Netflix case is a bit odd.
17:15:39 <harry> but they do exist
17:15:46 <rsleevi> virginie: Clarification on which you'd prefer
17:15:49 <rsleevi> israelh: informative text
17:15:49 <rsleevi> q?
17:16:46 <rsleevi> vgb: I'm not sure what we would require in a spec to get this
17:17:00 <rsleevi> ... we have windows features where only certain hosts can be accessed over IPSec w/ source authentication
17:17:19 <rsleevi> ... by the time we're done listening the matrix of what should be done, we're adding lots of complexity
17:18:05 <rsleevi> vgb: I'm suggesting there's so much nuance here that we shouldn't try to express the nuance
17:18:07 <virginie> q?
17:18:21 <rsleevi> rbarnes: I think you can put some things in the security considerations
17:19:33 <wseltzer> rsleevi: to address israel and vijay, that file origins and chrome extensions are treated as secure origins
17:19:47 <wseltzer> ... you've also made choices, e.g. Internet zone
17:19:52 <virginie> thanks wseltzer
17:20:13 <wseltzer> ... and other zoning; these policies already differ from global web-wide
17:20:53 <wseltzer> ... regarding concern for developers, that it's hard for a single dev to stand up an HTTPS server, what consititutes a secure origin is left to the browser
17:21:36 <wseltzer> ... Browsers already have policies, e.g. webgl limits
17:21:48 <virginie> q?
17:21:55 <wseltzer> ... So browser can have policy "treat this http page as secure origin"
17:22:24 <wseltzer> israelh: We tried hard not to continue path we took before, not to separate internet/intranet
17:22:37 <wseltzer> ... even to the detriment of intranet sites running on IE7
17:22:38 <JeffH_> JeffH_ has joined #crypto
17:22:51 <wseltzer> ... we despise the notion of fragmenting the Web Platform at the API level
17:23:05 <wseltzer> ... I agree we should enable policies that people and corporations can manage
17:23:19 <wseltzer> ... caveat, that doesn't make normative changes to the spec
17:23:38 <rsleevi> q+
17:23:38 <vgb> q+
17:23:39 <wseltzer> ... maybe a note, that agent should enable global policies to be set
17:23:50 <wseltzer> ack rbarnes
17:23:51 <harry> q?
17:24:03 <rsleevi> rbarnes: I'm gonna catch on the other half
17:24:13 <rsleevi> ... where we can say secure origin and wave our hands
17:24:19 <rsleevi> ... seems sort of developer hostile
17:24:31 <nvdbleek> nvdbleek has joined #crypto
17:24:38 <rsleevi> rbarnes: it may have loose fringy edges but it needs some solid core for developers
17:24:53 <rsleevi> ... I think we're largely thinking in an HTTP/1.1 world
17:25:07 <rsleevi> ... where you can deliver HTTP schemed origins over HTTPS connections
17:25:32 <rsleevi> ... it seems like you might be able to get more security for origins than you think
17:25:50 <rsleevi> virginie: Options: mandate secure origins
17:25:58 <rsleevi> ... include in the spec in a normative way as an option
17:26:16 <rsleevi> ... option 3: have informative text
17:26:19 <rsleevi> ... option 4: do nothing
17:26:42 <virginie> q?
17:26:47 <rsleevi> virginie: Please express preferences in IRC about which options you prefer
17:26:48 <vgb> 3
17:26:50 <rsleevi> rsleevi: Option 1
17:26:51 <markw> 3 or 4
17:26:51 <rbarnes> 3
17:26:54 <israelh> 3
17:27:48 <wseltzer> virginie: Who would object to mandating secure origin?
17:27:51 <rsleevi> virginie: Show of hand objection, who would object to Option 1
17:28:09 <lurker> lurker has joined #crypto
17:29:07 <vgb> +1 for the reason that it would be hard to precisely define
17:29:13 <markw> +1
17:29:14 <JeffH_> q?
17:29:31 <israelh> Same as vgb
17:29:31 <mountielee> can not choose
17:29:46 <markw> for the reason that webCrypto is still useful on insecure origins
17:29:48 <harry> q+
17:30:09 <wseltzer> rsleevi: We'd have issues; it does no one any favors
17:30:29 <wseltzer> ... doesn't give developers a clear expectation
17:30:37 <wseltzer> ... a security consideration that shoudl be obvious to the web
17:31:00 <wseltzer> ... For implementors, the "MAY" doesn't address any interop concerns
17:31:36 <wseltzer> ... vijay raised the concern that it's difficult to express secure origins
17:31:51 <wseltzer> ... that convo is happeniing in several groups, eg. svc workers, which has clear security concerns
17:32:05 <wseltzer> ... Q: If there was a suitable def of secure origin, woudl you go with option 1?
17:32:17 <joesteele> s/woudl/would/
17:32:31 <keiji> keiji has joined #crypto
17:32:32 <virginie> q?
17:32:37 <wseltzer> @@
17:32:37 <mdwood_> q+
17:32:58 <wseltzer> rsleevi: for chrome, svc workers, you don't get it over http unless you open dev tools
17:33:17 <wseltzer> ... for developers, expectation you won't be able to throw it on an http site and use it
17:33:25 <wseltzer> ... but enterprise policy lets you set an exception
17:34:21 <wseltzer> vijay: I see how leaving it to implementers is a cop-out, but don't see how it's worse than policy-based bypass proposal
17:34:39 <wseltzer> ... since all the telemetry I've seen, when you give users a prompt, they say "yes, get work done"
17:34:47 <virginie> q?
17:34:51 <wseltzer> israelh: you never see a prompt
17:35:17 <harry> q- harry
17:35:25 <wseltzer> [10 minute break]
17:46:34 <nvdbleek> nvdbleek has joined #crypto
17:47:21 <mdwood> mdwood has joined #crypto
17:48:31 <markw> markw has joined #crypto
17:48:33 <rsleevi> virginie: Based on the discussion, I don't think there's any consensus to go forward with secure origin
17:48:35 <rbarnes> rbarnes has joined #crypto
17:48:50 <rsleevi> ... I see in other working groups there will be more urgent requests for a definition for secure origin (e.g. service worker)
17:48:59 <rsleevi> ... putting a dependency on secure origins may be nonproductive
17:49:14 <rsleevi> ... based on that, I'd go with informative text on secure origin
17:49:45 <virginie> q.
17:49:49 <virginie> q?
17:49:52 <paulj> paulj has joined #crypto
17:50:02 <melinda> melinda has joined #crypto
17:50:21 <Allison> Allison has joined #crypto
17:50:21 <wseltzer> rsleevi: I think it's important for this group to have the technical discussion
17:50:33 <mountie> mountie has joined #crypto
17:50:37 <wseltzer> ... is the objection to option 1 that we don't have a good enough def of secure origin?
17:50:40 <wseltzer> ... or aer there other concernce?
17:51:00 <wseltzer> ... I'd prefer not to make the decision today without that discussion
17:51:08 <wseltzer> s/aer/are/
17:51:18 <rsleevi> virginie: My issue is we're trying to finalize the spec, and we're trying to deliver something
17:51:32 <rsleevi> ... I feel like there's no consensus on this new feature, and it would take ages (months) to address the issues
17:51:58 <rsleevi> ... and there's only one company requesting for secure origin
17:52:06 <jin> jin has joined #crypto
17:52:15 <rsleevi> ... which is why I'm cutting the debate. I'm more interested in shipping something
17:52:33 <rsleevi> israelh: one thing I'm not even sure if it's in our charter to figure out what this secure origin is
17:52:42 <rsleevi> ... I think it's a great thing to do, but I don't think it's necessarily our focus
17:53:00 <rsleevi> ... at some point you need to make the best decision based on the knowledge you have
17:53:20 <rsleevi> rbarnes: One of the points raised in the pervassive monitoring was that it'd be useful to have a broader perspective on what it means
17:54:00 <wseltzer> rsleevi: it will take years to change course, once we ship
17:54:11 <slightlyoff> q+
17:54:16 <wseltzer> ... look at geolocation, EME
17:54:37 <wseltzer> virginie: are you saying we need to stop the web now?
17:54:53 <wseltzer> ... or can come to conclusion quickly?
17:55:03 <wseltzer> ... 2 weeks vs months?
17:55:11 <mdwood> q-
17:55:20 <wseltzer> markw: Broader project to migrate all of web to https, that will take years
17:55:32 <rsleevi> slightlyoff: You will continue to get static from the TAG if you make this discussion
17:55:45 <wseltzer> s/discussion/decision/
17:56:02 <vgb> vgb has joined #crypto
17:56:02 <rsleevi> virginie: I discussed with another member from the TAG regarding secure origins and it did not seem like this was consistent with the TAG
17:56:11 <rsleevi> ... what would you recommend for the specification?
17:56:45 <wseltzer> rsleevi: normative text on secure origin, configurable through policy
17:57:00 <wseltzer> ... 2 qs, what to users expect, what do devs expect?
17:57:32 <wseltzer> ... if you set a minimum expectation, then that this policy may be extended, enhanced
17:57:45 <wseltzer> ... goal, be clear for devs, what user should experience when visiting their site
17:58:02 <wseltzer> ... interop concern on algos, if it's not clear to devs what users will have
17:58:25 <wseltzer> ... baseline expectation: if a user, frshly installed browser, comes to the site, what should they see
17:58:28 <virginie> q?
17:58:39 <markw> q+
17:58:49 <wseltzer> ... then we can allow for carve-outse, e.g. local sites, developer options
17:58:52 <virginie> zakim, close queue
17:58:52 <Zakim> ok, virginie, the speaker queue is closed
17:59:02 <wseltzer> s/outse/outs/
17:59:24 <rsleevi> virginie: If you can come back in the afternoon as to what the changes to the specification would be
17:59:36 <rsleevi> israelh: I think it's clear / we have enough information to know what's proposed
17:59:45 <harry> harry has joined #crypto
17:59:47 <virginie> q?
17:59:52 <hhalpin> hhalpin has joined #crypto
18:00:10 <wseltzer> q- mdwood
18:00:10 <slightlyoff> q-
18:00:29 <hhalpin> q?
18:00:41 <rsleevi> markw: We've heard that this is supposed to be a case by case basis
18:00:48 <rsleevi> ... and the rationale here is different than say geolocation
18:01:11 <rsleevi> ... and that argument does not apply to webcrypto, since we see there are generally useful things that we can do
18:01:20 <rsleevi> ... so this is being used as a stick to push people to HTTPS
18:01:49 <slightlyoff> Spec text is necessary but not sufficient
18:02:10 <wseltzer> rsleevi: I was trying to understand, is this an opposition on definition, or on reasoning?
18:02:23 <wseltzer> ... if it's a definitional issue, I can work on the definition
18:02:25 <mountielee> mountielee has joined #crypto
18:02:27 <slightlyoff> And without necessary improvements, you don't get the outcomes you want
18:02:33 <wseltzer> ... if it's a purpose issue, then that's a longer conversation
18:02:47 <virginie> q?
18:02:47 <wseltzer> vijay: it seems to be a purpose issue
18:03:03 <markw> last part of my comment was that moving the web to HTTPS is a larger project in which spec mandates of this kind are not helpful
18:03:05 <JeffH_> JeffH_ has joined #crypto
18:03:38 <rsleevi> vgb: it seems like a statement of philosopical purpose in a normative portion of the spec is not an appropriate thing
18:04:07 <virginie> Resolution : https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972 to be closed with option 3 or 4 (as decribed earlier)
18:04:22 <rbarnes> +1
18:04:30 <markw> +1
18:04:30 <vgb> +1
18:04:33 <rsleevi> 0
18:04:36 <mountielee> +1
18:04:37 <israelh> +1
18:04:44 <sangrae> +1
18:04:57 <jin> +1
18:05:07 <mdwood> 0
18:05:20 <selfissued> selfissued has joined #crypto
18:05:27 <wseltzer> virginie: can we get proposed informative text?
18:05:37 <wseltzer> ... for discussion this afternoon
18:06:32 <wseltzer> rsleevi: @@ the may restrict is unnecessary
18:06:52 <wseltzer> ... unclear what option 3 proposes
18:06:59 <wseltzer> virginie: Discuss this afternoon
18:07:05 <rsleevi> virginie: We will come back and revisit what Option 3 is proposing in the afternoon
18:08:12 <rsleevi> rsleevi: (minuting my remarks earlier) saying a UA MAY restrict to a secure origin in the spec is unnecessary, as that's true for all specs. It's unclear whether what is being proposed is that the spec recommends that UAs SHOULD restrict to secure origin, or if it's something else. The spec already lists in security considerations for authors that they
18:08:12 <rsleevi> SHOULD _use_ secure origins
18:08:36 <hhalpin> It's likely SHOULD for 99% uses
18:08:50 <tantek> tantek has joined #crypto
18:19:40 <mountie> mountie has joined #crypto
18:22:06 <lurker> lurker has joined #crypto
18:24:21 <virginie> virginie has joined #crypto
18:25:34 <virginie> zakim, generate minutes
18:25:34 <Zakim> I don't understand 'generate minutes', virginie
18:26:26 <virginie> rrsagent, generate minutes
18:26:26 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-crypto-minutes.html virginie
18:27:06 <virginie> rrsagent, make logs world-visible
18:35:15 <steph> steph has joined #crypto
18:39:32 <mountie> mountie has joined #crypto
18:47:19 <Karen> Karen has joined #crypto
19:13:33 <nvdbleek> nvdbleek has joined #crypto
19:24:10 <mountie> mountie has joined #crypto
20:09:13 <rbarnes> rbarnes has joined #crypto
20:21:49 <selfissued> selfissued has joined #crypto
20:32:01 <nvdbleek> nvdbleek has joined #crypto
20:32:10 <JMR> JMR has joined #crypto
20:32:38 <JMR> JMR has left #crypto
20:34:01 <rbarnes> rbarnes has joined #crypto
20:36:15 <hhalpin> hhalpin has joined #crypto
20:37:10 <jyates> jyates has joined #crypto
20:42:23 <JonathanJ1> JonathanJ1 has joined #crypto
20:50:41 <JMR> JMR has joined #crypto
20:54:34 <rbarnes> rbarnes has joined #crypto
20:57:02 <steph> steph has joined #crypto
20:57:23 <nvdbleek> nvdbleek has joined #crypto
21:02:43 <nvdbleek3> nvdbleek3 has joined #crypto
21:10:29 <schuki> schuki has joined #crypto
21:13:33 <rbarnes_> rbarnes_ has joined #crypto
21:16:14 <Karen> Karen has joined #crypto
21:21:25 <steph> steph has joined #crypto
21:21:54 <tantek> tantek has joined #crypto
21:25:05 <Karen> Karen has joined #crypto
21:45:42 <npdoty> npdoty has joined #crypto
21:49:25 <melinda> melinda has joined #crypto
21:53:11 <rsleevi> rsleevi has joined #crypto
21:54:32 <rbarnes> rbarnes has joined #crypto
21:59:38 <jin> jin has joined #crypto
22:00:42 <nvdbleek3> nvdbleek3 has joined #crypto
22:01:50 <virginie> virginie has joined #crypto
22:02:02 <mountie> mountie has joined #crypto
22:03:40 <mountie> mountie has joined #crypto
22:03:43 <allison> allison has joined #crypto
22:03:51 <kodonog> kodonog has joined #crypto
22:04:11 <mdwood> mdwood has joined #crypto
22:04:15 <npdoty> scribenick: npdoty
22:04:25 <juanlang> juanlang has joined #crypto
22:04:38 <harry> harry has joined #crypto
22:04:42 <npdoty> Topic: Web Crypto bugs
22:04:49 <virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972
22:04:50 <harry> hi everyone!
22:04:56 <vgb> vgb has joined #crypto
22:05:08 <npdoty> virginie: scenario regarding secure origin
22:05:15 <npdoty> ... clarify behavior or recommend usage of a secure origin
22:05:18 <npdoty> ... 2 options:
22:05:25 <npdoty> ... 1) write some text or 2) do nothing
22:05:35 <israelh> israelh has joined #Crypto
22:05:44 <npdoty> ... already written a requirement for using HTTPS
22:06:24 <npdoty> rsleevi: currently, text is a recommendation to use https in the security considerations
22:06:28 <harry> Security consideration text: "
22:06:28 <harry> While this API provides important functionality for the development of secure applications, it does not attempt to provide a mitigation for existing threats to the web security model, such as script injection or hostile intermediaries. As such, application developers must take care to ensure applications are secured against common and traditional attacks, such as script injection, by making use of appropriate existing functionality such as Content Security Poli
22:06:29 <harry> cy and the use of TLS. "
22:06:32 <npdoty> ... the question is whether to add a requirement for UAs to the specification
22:06:41 <virginie> as a reminder our morning minutes are : http://www.w3.org/2014/10/30-crypto-minutes.html
22:06:50 <npdoty> thoughts?
22:07:16 <npdoty> harry: what would the text look like?
22:07:28 <npdoty> rsleevi: point to existing specifications, like Service Worker, that normatively require TLS
22:07:51 <npdoty> ... but a recognition that policy always exist in the Web platform, and specs don't address it, because policy is policy
22:07:59 <harry> From Service workers: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#security-considerations
22:08:05 <npdoty> ... say, effectively, that UAs will expose this feature on HTTPS but not on HTTP
22:08:25 <harry> Key sentence is "Service workers should be implemented to be HTTPS-only. "
22:08:27 <npdoty> ... already have a number of specifications that don't mention policy
22:08:32 <harry> Then there's some discussion:
22:08:41 <harry> "The reasons for SSL-only support include:
22:08:44 <harry>     Better to protect end users from man-in-the-middle attacks
22:08:44 <harry>     Do good by encouraging HTTPS adoption
22:08:44 <harry>     Existing "playground" services (e.g. github.io) now work with HTTPS
22:08:44 <harry>     HTTPS is coming across much more of the web quickly
22:08:44 <harry>     Devtools can loosen the restriction for development (file://, localhost, etc.)
22:08:45 <harry> "
22:08:48 <JeffH> JeffH has joined #crypto
22:08:49 <npdoty> ... and of course policy overrides specifications, because policy is about configuring to do something other than originally expected
22:08:55 <harry> q+
22:09:12 <npdoty> Zakim, open the queue
22:09:12 <Zakim> ok, npdoty, the speaker queue is open
22:09:15 <npdoty> q+ harry
22:09:22 <npdoty> @@: already discussed. what about option 3?
22:09:29 <markw> markw has joined #crypto
22:09:34 <rsleevi> s/@@/israelh/
22:09:37 <npdoty> ... like a non-binding note to user agents
22:09:55 <npdoty> virginie: could take the example from service worker, but informative rather than normative
22:09:59 <npdoty> q+
22:10:09 <npdoty> ack harry
22:10:09 <virginie> q?
22:10:28 <npdoty> harry: seems like Web Crypto should be implemented to be HTTPS-only in user agents
22:10:43 <npdoty> ... might be different for Web Crypto rather than other api's
22:10:53 <npdoty> ... could have a SHOULD instead of a MUST
22:10:59 <npdoty> ... would be clearer as a note to developers
22:11:35 <npdoty> ... so that the standard web case should be over TLS, but could have some alternative environments
22:11:44 <Charles_Engelke_> Charles_Engelke_ has joined #crypto
22:11:58 <rsleevi> npdoty: I don't have a particular view on the view of normativity
22:12:14 <rsleevi> ... it seems like we need to have a better definition, perhaps authenticated origins
22:12:24 <rsleevi> ... a term from the Mixed Content Specification
22:12:28 <mountie> +1
22:12:48 <virginie> q?
22:13:03 <harry> Rather easy to reference that spec
22:13:05 <colin> colin has joined #crypto
22:13:13 <npdoty> rsleevi: yes, have a definition in normative language and an algorithm to evaluate it, addresses edge cases
22:13:54 <rsleevi> Mixed Content specification: https://w3c.github.io/webappsec/specs/mixedcontent/
22:14:21 <npdoty> rsleevi: willing to write up the proposal, although I would prefer MUST to SHOULD
22:14:25 <npdoty> virginie: follow up in email
22:14:32 <rsleevi> including https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-powerful-features
22:15:06 <npdoty> virginie: 16 minutes left before test session
22:15:10 <npdoty> ... list of bugs to address
22:15:36 <npdoty> virginie: more to do on errata extension?
22:15:44 <npdoty> markw: done.
22:16:03 <npdoty> virginie: security recommendations, expecting something from IETF CRFG
22:16:08 <virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607
22:16:18 <npdoty> harry: received a response, with expectation of decision by early December
22:16:29 <npdoty> ... don't think that actually influences us right now
22:16:33 <virginie> q?
22:16:38 <npdoty> ... we have a clear errata process if we need to change it later
22:16:53 <jgraham> jgraham has joined #crypto
22:16:59 <selfissued> selfissued has joined #crypto
22:17:00 <virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=2561
22:17:16 <markw> @rsleevi, regarding https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-powerful-features, I don't think we have agreed that WebCrypto is a "powerful feature" - at least we have not really discussed that
22:17:19 <nvdbleek> nvdbleek has joined #crypto
22:17:26 <rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25619
22:17:39 <Bert> Bert has joined #crypto
22:17:44 <npdoty> rsleevi: addressed this morning.
22:18:31 <npdoty> 26322 already addressed
22:18:43 <npdoty> 27137 just editorial, has been fixed
22:19:09 <npdoty> 24944 pubrules
22:19:21 <npdoty> markw: need to be consistent about reference to normative/informative references
22:20:09 <npdoty> markw: isn't there a bug about interoperability?
22:20:22 <npdoty> rsleevi: we've floated different proposals, but not closed
22:20:26 <virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985
22:20:37 <npdoty> harry: we have a game plan
22:20:50 <npdoty> rbarnes: game plan is to see what's implemented and perhaps have a common core
22:21:09 <npdoty> virginie: milestones
22:21:23 <npdoty> ... before the new W3C Process was endorsed, following 2005 Process
22:21:40 <npdoty> ... Candidate Recommendation, Proposed Recommendation and then Recommendation
22:21:55 <npdoty> harry: could have small changes based on a decision we could make after CR
22:22:07 <npdoty> virginie: try to put some dates to these Rec track steps
22:22:32 <npdoty> ... determine when are we going to re-charter?
22:22:40 <npdoty> harry: CR will depend on the test suite situation
22:22:57 <npdoty> ... could be fairly quickly, in a few months
22:23:14 <npdoty> ... PR and Rec are more of a phase about patent commitments more than anything else, little for the WG to do
22:23:35 <npdoty> ... workload for the WG will lighten after CR
22:23:37 <nvdbleek3> nvdbleek3 has joined #crypto
22:24:23 <npdoty> harry: want to finish the test suite, and then re-charter
22:24:41 <npdoty> ... likely to be over the winter, but could be variable so don't need to settle those dates in a new charter right now
22:24:57 <npdoty> virginie: harry to prepare the transition request
22:25:16 <npdoty> ... need the editors to have a very clean response to all bugs. when will bugzilla be empty?
22:25:41 <npdoty> markw: could be early next week
22:26:07 <virginie> q?
22:26:08 <rsleevi> q?
22:26:09 <npdoty> harry: can start pubrules once you send me an email
22:26:16 <harry> once all the text is completed.
22:26:28 <harry> in terms of substantial comments.
22:26:59 <shadow> shadow has joined #crypto
22:27:08 <npdoty> Topic: Tests and Tools
22:27:31 <npdoty> harry: for a spec for which you have a few different implementations, can you explain the testing and toolset?
22:27:48 <npdoty> jgraham: basically, there's a certain existing infrastructure for testing
22:27:56 <npdoty> ... a harness for writing tests: testharness.js
22:28:01 <npdoty> ... documented on testthewebforward.org
22:28:15 <npdoty> ... server-side component
22:28:26 <npdoty> ... a repository of web platform tests
22:28:40 <npdoty> ... pull down the server as well as all the tests, a complete locally available test environment
22:29:09 <npdoty> ... a couple of tools for running the tests: in-browser runner, one page after another
22:29:25 <npdoty> ... reports of different implementations, produces JSON output and tables
22:29:46 <npdoty> ... wbtrunner: run the tests externally and run them in various different browsers
22:29:52 <npdoty> ... state of the infrastructure
22:30:14 <npdoty> virginie: don't have any tests yet, but do have implementations, don't have anyone in charge of tests
22:30:25 <npdoty> ... what's your advice for making the testing phase efficient?
22:30:57 <npdoty> jgraham: not sure historically we've been that successful about getting all the tests, but we're getting better
22:31:12 <npdoty> ... some WGs have appointed a czar as responsible for the tests
22:31:27 <npdoty> ... make sure people are actually submitting tests, getting others to review, etc.
22:31:36 <npdoty> ... giving someone responsibility may be quite helpful
22:31:45 <npdoty> berjon: it's work
22:31:50 <rsleevi> q+
22:31:52 <harry> q+
22:32:04 <npdoty> berjon: some groups have had test-oriented meetings
22:32:12 <markw> There are some Jasmine tests in the web folder here: https://github.com/Netflix/NfWebCrypto/tree/master/
22:32:20 <npdoty> ... a f2f meeting where people code, maybe just 5 people all-day for two or three days
22:32:32 <npdoty> ... good for momentum
22:33:00 <npdoty> rsleevi: question on licensing expectations for tests
22:33:35 <npdoty> jgraham: typically dual licensed, W3C Test Suite License, but for all other purposes are BSD licensed
22:34:04 <npdoty> rsleevi: there are a ton of tests in Chromium, which is already BSD licensed
22:34:04 <npdoty> ... just might be a matter of importing them
22:34:14 <npdoty> ... WebKit also has tests, but not sure about translating them or the license
22:34:30 <npdoty> rbarnes: Mozilla has tests that could be moved over as well
22:34:52 <npdoty> jgraham: problem isn't about license, typically, but about time to convert
22:35:04 <npdoty> markw: also have tests we could contribute, and don't have time to convert
22:35:06 <rbarnes> the moz tests: http://dxr.mozilla.org/mozilla-central/search?tree=mozilla-central&q=path%3Adom%2Fcrypto%2Ftest&redirect=true
22:35:34 <npdoty> israelh: without a test team/restructuring recently
22:35:35 <npdoty> ack harry
22:35:36 <jy> jy has joined #crypto
22:35:54 <npdoty> harry: just wanted to check about MSFT. anyone else with tests?
22:36:12 <virginie> q?
22:36:17 <rsleevi> https://code.google.com/p/chromium/codesearch#chromium/src/content/test/data/webcrypto/ as test data with https://code.google.com/p/chromium/codesearch#chromium/src/content/child/webcrypto/test/
22:36:20 <npdoty> ... just finding someone to do the conversion of Chrome, Mozilla, Netflix tests
22:36:38 <selfissued> selfissued has joined #crypto
22:37:04 <npdoty> berjon: coordinating test-writing, could have been more efficient to just use the open source testing in Web Platform
22:37:22 <npdoty> rsleevi: but unit tests are easier/closer to run for a particular product during development
22:37:31 <npdoty> virginie: how do we know when we're happy about test coverage?
22:38:11 <npdoty> berjon: we've tried to build heuristics in the past. parse the spec, detect a conformant statement, and then expect a certain number of tests
22:38:41 <npdoty> ... without doing the human work of comparing the spec and the tests
22:38:59 <virginie> q?
22:39:18 <npdoty> ... job of the test czar
22:39:40 <npdoty> ... never get to Rec without a good test suite
22:40:15 <npdoty> jgraham: looking at the tests posted in IRC. Mozilla tests are something you can start from -- written in JavaScript in the Web browser, not about a specific implementation
22:40:35 <npdoty> markw: Netflix tests also include tests that run in the browser
22:40:45 <npdoty> virginie: who wrote the nice tests?
22:40:50 <rsleevi> Apple's is http://trac.webkit.org/browser/trunk/LayoutTests/crypto
22:41:03 <rsleevi> which are all JS as well
22:41:10 <virginie> q?
22:42:30 <npdoty> jgraham: would like to avoid different test formats, which requires maintaining an ever greater number of test formats/harnesses
22:42:41 <shadow> shadow has joined #crypto
22:43:12 <rbarnes> rbarnes has joined #crypto
22:43:21 <harry> q+
22:43:26 <npdoty> virginie: anyway interested in investing in the tests, in order to advance to Recommendation
22:43:27 <npdoty> ack harry
22:43:57 <npdoty> harry: I'll take an action about trying to make a more compelling reason for Test Czar or TTWF event
22:43:59 <npdoty> ... maybe there's funding available for events
22:44:02 <npdoty> ... make it more enticing
22:45:32 <npdoty> berjon: #testing is a friendly channel for getting advice
22:45:38 <npdoty> thanks from and to the testing folks
22:45:46 <npdoty> q?
22:46:01 <npdoty> Topic: Implementations
22:46:07 <npdoty> harry: good with promises?
22:46:09 <npdoty> israelh: yeah
22:46:11 <virginie> q?
22:46:15 <rbarnes> detailed firefox status: https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing
22:46:25 <rsleevi> q+
22:46:55 <npdoty> virginie: microsoft, google, mozilla, apple, netflix plugin
22:46:56 <npdoty> ack rsleevi
22:47:04 <rbarnes> q+
22:47:12 <npdoty> rsleevi: netflix tests passed in Chrome
22:47:19 <npdoty> ... similar status on algorithms to Firefox
22:47:28 <npdoty> ... not adding new algorithms to NSS-based implementations
22:47:51 <npdoty> ... moving all of our platforms to BoringSSL
22:48:19 <npdoty> ... will have algorithms that appear differently in different versions as we move to BoringSSL
22:48:51 <npdoty> ... a penalty of a decreasing number of cryptographic libraries
22:49:34 <npdoty> ... not planning to implement AES-CMAC or CONCAT
22:49:40 <npdoty> ... if people have use cases, let us know
22:50:07 <npdoty> ... ECC is also going into BoringSSL soon
22:50:19 <npdoty> ... depending on platform
22:50:23 <npdoty> ack rbarnes
22:50:23 <virginie> q+
22:50:37 <npdoty> rbarnes: spreadsheet https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing#gid=1
22:50:48 <npdoty> ... as of Firefox 35 in early January, all algorithms will be there
22:50:56 <npdoty> ... turning on WebCrypto by default in November-ish
22:51:12 <npdoty> ... ECDSA and ECDH, likely to come in January
22:51:27 <npdoty> ... not seeing demand for CFB
22:51:43 <virginie> q?
22:51:46 <npdoty> ... not planning on CONCAT or HKDF
22:52:17 <rsun> rsun has joined #crypto
22:52:17 <npdoty> rsleevi: differences in the specification of CONCAT?
22:52:21 <npdoty> vijay: CONCAT is fine
22:52:29 <npdoty> ack virginie
22:52:59 <npdoty> virginie: for the group, how are we going to document? interoperability bugs will require us to describe the implementations and interoperability tests
22:53:16 <npdoty> ... should we keep track of different implementations?
22:53:24 <npdoty> ... level of implementation should be documented
22:53:29 <npdoty> harry: with the test suite
22:53:50 <nvdbleek> nvdbleek has joined #crypto
22:53:57 <npdoty> rsleevi: focus on the test suite, and answers not just whether the vendor announces support but empirically whether it does
22:53:57 <npdoty> q+
22:54:19 <rsleevi> npdoty: Do we have any site that will tell us the implementation status for different browsers
22:54:35 <npdoty> q-
22:54:46 <rsleevi> hhalpin: That's generally covered by tests (Test the web forward)
22:54:51 <npdoty> harry: haven't seen that automated, though maybe it was interest
22:55:00 <npdoty> israelh: behind a flag?
22:55:15 <npdoty> won't be behind a flag or isn't behind a flag
22:55:31 <harry> To be clear, there was interest and I think it would be a good idea but doesn't exist yet
22:56:36 <npdoty> Topic: Web Crypto Next Workshop
22:56:37 <rbarnes> in safari, it appears to be window.crypto.webkitSubtle
22:57:08 <harry> heh webkitSubtle :)
22:57:09 <npdoty> virginie: 70 people, 44 papers, actors from several industries
22:57:15 <harry> it's a subtle fad
22:57:33 <npdoty> ... new friends -- lots of w3c non-members
22:57:57 <npdoty> ... discussion of new features: algorithms, key storage/secure storage, etc.
22:58:11 <npdoty> ... authentication and access to services in secure token
22:58:17 <mountie> please post the link of report
22:58:29 <npdoty> ... secure elements, TPM, trusted execution environment
22:58:43 <npdoty> ... scheme for authentication, similar to FIDO alliance or PKI-based challenge-response
22:58:51 <npdoty> ... discussion of government authentication
22:59:10 <npdoty> ... report available
22:59:37 <harry> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html
22:59:42 <npdoty> ... followed-up on Web Security IG mailing list, a public discussion (not to interrupt Last Call)
22:59:56 <npdoty> ... next step is to find a place for new features to land
23:00:11 <npdoty> ... charter or re-charter as necessary. could be in Web App Sec, or Web Crypto
23:00:18 <npdoty> ... both potentially re-chartering now
23:01:15 <npdoty> ... captured a list of use cases or new features
23:02:13 <npdoty>     Authentication API: medium support
23:02:13 <npdoty>     Algorithm Discovery: medium support
23:02:14 <npdoty>     Key Discovery: high support
23:02:17 <npdoty>     Device Discovery: high support
23:02:17 <npdoty>     Hardware tokens in scope (including Platform-held keys): unanimous support
23:02:19 <npdoty>     Attestation of provenance: high support
23:02:20 <npdoty>     Discovery with access control: medium support
23:02:22 <npdoty>     Multi-origin support: medium support
23:02:23 <npdoty>     User-owned keys: medium support
23:02:24 <npdoty>     Origin and attested signatures: medium support
23:02:25 <npdoty>     Local authentication binding with key usage: high support
23:03:32 <npdoty> virginie: harry organized a show of hands for rough count
23:04:03 <npdoty> ... high numbers for hardware tokens (lots of those vendors in the room, but interest from others too)
23:04:07 <virginie> q?
23:04:15 <harry> q+
23:04:19 <npdoty> ... any questions?
23:04:22 <npdoty> ack harry
23:04:52 <npdoty> harry: to clarify, W3C doesn't do workshops just 'cause, but rather because of interest of Members
23:05:32 <npdoty> ... maybe sooner than necessary. heterogeneous group
23:05:42 <npdoty> ... but try to get consensus at least from the members who would be in the WG
23:05:56 <rbarnes> q+
23:06:00 <rsleevi> q+
23:06:13 <npdoty> ... do people show up? do they agree at all?
23:06:21 <virginie> note : raw notes of the workshop https://www.w3.org/Security/wiki/IG/webcryptonext_workshop
23:06:25 <npdoty> ... capabilities for accessing hardware-bound tokens would be useful
23:06:35 <npdoty> ... not necessarily agreement for a single technical approach
23:06:59 <harry> q+
23:07:04 <npdoty> virginie: if I stay as a chair, don't want work in the charter that people won't contribute to
23:07:06 <selfissued> q+
23:07:20 <npdoty> ... pushing hardware vendors to join if they want to see that work done
23:07:51 <npdoty> rbarnes: very valuable for me in seeing all the hardware work out there
23:08:07 <npdoty> ... problem of supporting secure hardware, but not a crypto problem
23:08:24 <npdoty> ... might be better in a different WG, rather than just a Crypto approach
23:08:36 <npdoty> ack rbarnes
23:08:43 <npdoty> ... open to discussing other topics
23:08:57 <Karen> Karen has joined #crypto
23:09:09 <npdoty> rsleevi: have a similar position
23:09:29 <npdoty> ... w/r/t rechartering, likely not interested beyond potential algorithmic changes
23:09:38 <virginie> q?
23:09:51 <npdoty> ... Google interested in hardware token, part of FIDO, not a crypto problem
23:10:08 <vgb> q+
23:10:11 <npdoty> ... not very interested in a general API for hardware tokens
23:10:28 <npdoty> ... unless we see a set of proposals that already look valuable
23:10:45 <npdoty> ... for proposals that want to explore/propose something valuable, could use a Business Group or Interest Group
23:11:15 <npdoty> ... model that FIDO has used is a good example. got a set of use cases and requirements and then an API, and now have a completed set for discussion
23:11:33 <npdoty> ... includes platform-bound keys, which can be privacy-invasive, so will require a lot of discussion
23:12:07 <npdoty> harry: uncomfortable chartering new work unless we have a clear input submission or submissions with agreement
23:12:28 <npdoty> ... having a blank slate in the WG (as we kind of did with this one) makes for more work
23:12:41 <npdoty> ... FIDO work and key discovery would be the non-blank-slate one
23:13:00 <npdoty> ... if people want to look at those sets of drafts here, if we have the time
23:13:22 <npdoty> ... quicker to recharter than to start a new WG, but totally possible to charter new WG if we have committed
23:13:57 <npdoty> ... could try to convince webappsec
23:14:02 <npdoty> virginie: webappsec has a poll for potential features for rechartering
23:14:16 <npdoty> nickv: they already went through their list of ten
23:15:49 <npdoty> selfissued: to take a contrary position on scope of rechartering
23:16:08 <npdoty> ... two of the work items we're considering are about extending/using webcrypto capabilities
23:16:22 <npdoty> ... using webcrypto operations with platform-held keys rather than browser-held keys
23:16:28 <npdoty> ... not a big extension
23:16:36 <npdoty> ... colleagues will present a concrete suggestion on how that could happen
23:16:46 <npdoty> ... very in scope of this group to enable the use of more keys
23:17:01 <npdoty> ... if we decide to take on the BigNum work, it's a clear extension of the WebCrypto work
23:17:08 <rsleevi> We have zero interest in the current BigNum proposal.
23:17:13 <virginie> q?
23:17:20 <npdoty> ... it's not generic BigNum, but for field mathematics for cryptographic applications
23:17:35 <npdoty> vgb: broadly, +1 to rsleevi rbarnes
23:17:36 <rbarnes> i also don't have a strong feeling one way or another on bignum
23:17:44 <npdoty> ... shouldn't start with a blank slate, but a clear idea of what to do
23:17:54 <npdoty> ... access to hardware is not primarily a crypto problem
23:18:14 <npdoty> ... if we can break off the crypto part of that problem, if we can do that concretely, that would be good
23:18:22 <npdoty> ... but don't want mission creep, away from our core competency
23:18:36 <npdoty> virginie: if the function is implemented in a hardware token
23:18:50 <npdoty> vgb: what should the interface be at a crypto level, rather than the device driver aspect
23:19:30 <vgb_> vgb_ has joined #crypto
23:19:34 <npdoty> virginie: send to the WG members a poll, as webappsec has done, maybe in a few months
23:19:42 <npdoty> q?
23:19:45 <israelh_> israelh_ has joined #Crypto
23:19:51 <juanlang_> juanlang_ has joined #crypto
23:19:51 <npdoty> ack rsleevi
23:20:13 <npdoty> rsleevi: that said, we have been exploring APIs through extensions
23:20:23 <npdoty> ... especially around security concerns regarding the hardware tokens
23:20:38 <npdoty> ... before we would be willing to do that for the Web
23:20:53 <npdoty> ... but have an extensions API, as encouragement for vendors to explore
23:21:12 <npdoty> ... for platforms with extensions, a way to balance the functionality with security concerns
23:21:32 <npdoty> ... in the near term, based on current discussions, not optimistic about a proposal. if there is a really good proposal, we'd support re-chartering
23:21:48 <npdoty> ... work with the same set of people in the room, that might eventually make it into an API proposal
23:21:58 <jin_> jin_ has joined #crypto
23:22:13 <npdoty> Topic: Certificate & Key Management
23:22:35 <npdoty> israelh: what's the minimum core set of capabilities that extend crypto
23:22:44 <npdoty> ... users to be able to manage their certificates and keys independent of transactions
23:23:11 <npdoty> ... not always associated with the domain of origin
23:23:17 <npdoty> ... hardware-bound certificates or keys
23:23:21 <npdoty> ... user-selection of certs and keys
23:23:37 <npdoty> ... be able to generate new certs and keys as part of their workflow
23:24:04 <npdoty> ... out of scope: dealing with writing certs/keys back to external devices
23:24:31 <npdoty> ... existing capabilities
23:24:49 <npdoty> ... ... provisioning certificates, processing operations, storage
23:24:55 <npdoty> ... ... polyfills already provided
23:25:07 <npdoty> rrsagent, please draft the minutes
23:25:07 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-crypto-minutes.html npdoty
23:25:24 <npdoty> ... ... server-side, updating and revoking certificates
23:25:52 <npdoty> ... capabilities not already covered:
23:25:55 <tantek> tantek has joined #crypto
23:25:56 <npdoty> ... ... generating keys
23:26:06 <npdoty> ... ... get a key and sign with that key
23:26:35 <npdoty> ... ... create an API so that a developer can get a key, but from anywhere
23:26:54 <npdoty> ... what are the boundaries where we need to provide an API?
23:27:10 <rsleevi> Chrome extension documentation - https://developer.chrome.com/extensions/enterprise_platformKeys
23:27:18 <npdoty> ... using Pre-Provisioned Keys from External Devices
23:27:59 <allison> allison has joined #crypto
23:28:25 <npdoty> ... can select a prompt that leads to an OS-provided interface for choosing a key and entering a PIN
23:28:35 <npdoty> ... and only then return the key to the web api
23:28:45 <npdoty> ... acquiring a new key from the Web
23:28:50 <jy> jy has joined #crypto
23:29:15 <npdoty> ... going to a Visa site, creating a certificate, and then immediately return to the other page with that key/cert
23:29:31 <npdoty> ... iframe collaboration / postMessage
23:29:41 <tantek_> tantek_ has joined #crypto
23:29:46 <rbarnes> oh look, OAuth!
23:30:03 <npdoty> ... proposes two new methods on the SubtleCrypto interface
23:30:11 <npdoty> ... signExt and generatekey
23:30:49 <npdoty> vgb_: origin-bound keys is almost everything, but want to bring in keys that exist but aren't origin-bound, like Smart Cards
23:30:59 <npdoty> ... use user consent as the vehicle
23:31:06 <npdoty> ... newly-generated keys will be origin-bound
23:31:34 <npdoty> ... how do you know that the thing you signed is what the user thought they were signing?
23:31:43 <npdoty> ... show this to the user and bind it together with the hash/signature
23:32:08 <npdoty> ... primitive for a hash that is signed combined with what the user was shown to be signed
23:32:20 <npdoty> ... useful and not a huge addition
23:32:25 <markw> markw has joined #crypto
23:32:37 <npdoty> israelh_: key metadata for querying a key at a later time
23:32:39 <colin> colin has joined #crypto
23:32:46 <Charles_Engelke_> Charles_Engelke_ has joined #crypto
23:33:04 <npdoty> ... "issuer" and "subject" for querying certificates later
23:33:58 <npdoty> ... have an aggregated list of keys for the developer, rather than particular URIs
23:33:58 <npdoty> ... always only get one key, the key that the user selected
23:34:02 <rbarnes> rbarnes has joined #crypto
23:34:05 <npdoty> ... if the key is domain-bound, don't have to ask the user, already in the circle of trust
23:35:02 <npdoty> vgb_: having a relatively heavy-weight selection process. sites can clone the key, but users can clear with their browsing history
23:35:15 <npdoty> ... preserves at least some of the user expectation of privacy
23:35:58 <npdoty> israelh_: [generate key example]
23:36:04 <bhill2> bhill2 has joined #crypto
23:36:12 <npdoty> ... [getKey example]
23:36:47 <npdoty> ... rely on the user agent to bring up the UI, to look very different, full-screen system UI
23:36:56 <npdoty> ... make it more difficult to be spoofed
23:37:18 <npdoty> questions?
23:37:32 <npdoty> vgb_: an early strawman, not a finished API draft
23:37:49 <npdoty> ... detail of what we think a minimal, concrete proposal would look like
23:37:50 <mountie> q+
23:37:58 <rsleevi> q+
23:38:17 <virginie> virginie has joined #crypto
23:38:21 <nvdbleek> nvdbleek has joined #crypto
23:38:34 <npdoty> mountie: this covers the multiple topics discussed at the workshop, key discovery, multiple origin support, user provided keys
23:38:41 <npdoty> ... +100
23:38:46 <virginie> q?
23:38:57 <rbarnes> q+
23:39:13 <npdoty> rsleevi: this is very similar in many ways to the Chrome extension API that we've explored
23:39:23 <npdoty> ... doesn't address all the use cases that people want for smart cards
23:39:36 <npdoty> ... especially for Internet at large
23:39:59 <npdoty> ... biggest concern, security concern
23:40:31 <npdoty> ... exposing hardware tokens of any sort, is that these can be trivially postMessaged off to another origin
23:40:53 <npdoty> ... hard or unlikely to make it not-postMessage-able
23:40:59 <npdoty> ... need a stronger component for authorization
23:41:15 <npdoty> ... FIDO binds in the origin, unspoofable because it comes from the UA
23:41:41 <npdoty> ... scary if possible to get permanent access to a hardware token from an evil site
23:41:49 <virginie> q?
23:42:35 <npdoty> vgb_: isn't existing also vulnerable to postMessage off the origin?
23:42:44 <npdoty> rsleevi: particularly for hardware tokens
23:43:05 <npdoty> vgb_: mitigated if the sign-with UI is sufficiently good
23:43:06 <nvdbleek> nvdbleek has joined #crypto
23:43:23 <npdoty> ... if the signature is only valid for the thing you thought you were signing, then you're okay
23:43:23 <nvdbleek> q+
23:43:37 <npdoty> ... bad guy gets a signature, but it's not good for anything
23:43:50 <virginie> to rbarnes, lets finish that exchange, if this is ok with you ...
23:44:03 <npdoty> rsleevi: an early proposal was similar to mozilla window.crypto.sign box
23:44:09 <npdoty> ... down that road lies madness
23:44:33 <npdoty> ... XML DSig or PDF -- the space is messy
23:44:55 <npdoty> ... one suggestion was sign all the resouces on the page (to ensure not XSS)
23:45:05 <npdoty> ack rbarnes
23:45:20 <npdoty> rbarnes: Firefox has had a similar API to this for a while, generate new keypair, enroll a certificate
23:45:34 <npdoty> ... API is disappearing shortly, for security concerns and lack of use
23:45:35 <kodonog> kodonog has joined #crypto
23:45:49 <npdoty> ... would want a more general approach
23:46:03 <mountie> ㅂ+
23:46:03 <mountie> q+
23:46:15 <npdoty> ... general way of talking to applications on secure hardware, where crypto is just one application
23:46:24 <JeffH> JeffH has joined #crypto
23:46:29 <npdoty> ... access-control story, including these sharing issues
23:46:53 <npdoty> ack nvdbleek
23:47:00 <npdoty> nvdbleek: for our use cases, the proposal looks very promising
23:47:05 <JeffH> q+
23:47:18 <npdoty> ... regarding keys moving to different origins. for lots of hardware tokens, have to add an extra PIN for every operation
23:47:35 <npdoty> ... so the key is unlikely to be stolen, because it requires that PIN every time
23:47:46 <npdoty> rsleevi: the experience is that PINs don't at all mitigate that concern
23:47:56 <npdoty> ... FIDO has a user interactivity requirement, but even that is insufficient
23:48:14 <npdoty> ... a PIN prompt when you have 20 tabs open ....
23:48:24 <npdoty> vgb_: should have a richer conversation offline
23:48:39 <npdoty> ack mountie
23:49:01 <rbarnes> q+
23:49:02 <npdoty> mountie: for TLS, a certificate is the baseline of security on the Internet,
23:49:06 <rbarnes> q-
23:49:16 <npdoty> ... we already need the certificate at the application-layer
23:49:40 <npdoty> ... many things we need to touch at the application-layer, like key discovery
23:49:50 <npdoty> ack JeffH
23:50:02 <npdoty> JeffH: some looks very similar to what we've done in FIDO
23:50:15 <rsleevi> Notes regarding hardware access APIs my previous presentation from the Lyon F2F - http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/att-0022/Web_Crypto_Introduction.pdf
23:50:16 <npdoty> ... addressed issues that rsleevi is raising
23:50:45 <npdoty> ... token-binding which is presumed that wasn't discussed
23:51:25 <npdoty> ... a layered approach: discussing the Crypto API by itself, may create problems when trying to address the cohesive whole
23:51:45 <npdoty> ... the app id and facet stuff, aluded to, is aimed at preventing misuse of the signing operation by other entities
23:51:49 <bhill2> q+
23:51:51 <npdoty> ... doesn't necessarily fit in web crypto
23:52:02 <npdoty> ... token-binding stuff already in IETF
23:52:22 <npdoty> vgb_: a single more holistic discussion?
23:52:47 <rsleevi> q+
23:52:52 <npdoty> JeffH: scary, sharp security problems might be more present when looking at a piece in isolation
23:53:06 <npdoty> bhill2: Brad Hill, Facebook, Web App Sec
23:53:18 <npdoty> ... paper co-authored with JeffH and some FIDO folks
23:53:31 <npdoty> ... key-usage and origin-binding
23:53:37 <npdoty> ... people want to use them from mobile applications as well
23:54:02 <npdoty> ... how do we build keys that can be used, generally, in the browser but also Android, iOS, Windows Phone
23:54:24 <npdoty> ... keep that as a high-level use case to keep in mind
23:54:35 <bhill2> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_44.pdf
23:54:38 <npdoty> vgb_: Web Crypto has always been about web interfaces to platform capabilities
23:54:54 <npdoty> ... what would be the platform capability to which this would correspond?
23:54:56 <JeffH> the position paper hillbrad was referring to: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_44.pdf
23:55:50 <npdoty> bhill2: existing Smart Card systems or PKI systems aren't already built around origin concepts
23:56:03 <npdoty> rsleevi: tension between Extensible Web Manifesto and low-level primitives
23:56:15 <npdoty> ... and this holistic view
23:56:25 <npdoty> ... platform-keys have historically had bad security properties
23:56:46 <npdoty> ... emergent properties vs. high-level, FIDO-like API
23:57:00 <npdoty> ... desire and pressure to move existing systems to the Web
23:57:17 <npdoty> ... Web has changed in the past two years
23:57:54 <npdoty> ... have an extension / USB API
23:58:13 <npdoty> ... low-level prmiitive, scoped to signed applications, add low-level interfaces to experiment with
23:58:59 <npdoty> ... bringing platform keys into web crypto can't deal with the holistic security issues, because Smart Cards alone can't do so
23:59:11 <npdoty> ... slides from Lyon still relevant
23:59:59 <npdoty> israelh: not a secure model, in that the extension can be across origins and doesn't have the guarantees that we're worried about
00:00:13 <npdoty> rsleevi: not inherently more secure, but allows for experimentation
00:00:46 <npdoty> ... that's a good way to iterate and implement in order to get a more firm proposal
00:00:50 <jyates_> jyates_ has joined #crypto
00:01:04 <virginie> q?
00:01:21 <rsleevi> scribenick: rsleevi
00:01:51 <rsleevi> virginie: so this story of new features and rechartering will happen in a few months
00:02:06 <rsleevi> ... few things about the WG life
00:02:21 <rsleevi> ... our current operation method is we don't have calls anymore, we treat stuff over the mailing list
00:02:35 <rsleevi> ... we do ad-hoc calls if necessary, and then any resolutions on the calls have two weeks on the mailing list
00:02:50 <sangrae> sangrae has joined #crypto
00:02:58 <rsleevi> ... we meet once a year on average
00:03:09 <rbarnes> more meetings in Lyon!
00:03:22 <rsleevi> virginie: Wanted to confirm that this WG method is still workable
00:03:26 <virginie> q?
00:03:35 <rbarnes> ping
00:03:36 <virginie> q?
00:04:10 <rsleevi> virginie: Next steps: We will be working over the mailing list to clean the Web Crypto API
00:04:22 <rsleevi> ... specifically editors / chair / staff contacts to deal with progressing on the rec track
00:04:37 <rsleevi> ... question raised by @@ on whether we want to have a day for testing
00:04:58 <rsleevi> virginie: Would the WG be willing to spend a day or two F2F to integrate testing
00:05:26 <rsleevi> ... is there AOB to address before we close?
00:05:46 <rsleevi> @@: The Web Payments IG has started this week
00:06:23 <rsleevi> ... the web payments is only an IG at the moment. Our plan is to start collecting use cases, authentication, access to a secure element
00:06:31 <rsleevi> ... in time we'll look for a WG that can handle this work
00:07:16 <rsleevi> virginie: I think we can now close the meeting. Thanks to everyone for the very hard work
00:07:32 <rsleevi> ... thanks to everyone for coming and have a great end of the week
00:07:39 <RRSAgent> I'm logging. I don't understand 'prepare the minutes', rsleevi.  Try /msg RRSAgent help
00:08:01 <rsleevi> RRSAgent, please draft the minutes
00:08:01 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-crypto-minutes.html rsleevi
00:08:08 <bhill2> bhill2 has joined #crypto
00:16:53 <rbarnes> rbarnes has joined #crypto
00:26:34 <nvdbleek> nvdbleek has joined #crypto
00:31:41 <mountie> mountie has joined #crypto
00:44:54 <steph> steph has joined #crypto
01:58:00 <harry> harry has joined #crypto
02:29:08 <bhill2> bhill2 has joined #crypto
03:02:20 <bhill2> bhill2 has joined #crypto
04:53:51 <bhill2> rrsagent, make minutes
04:53:51 <RRSAgent> I have made the request to generate http://www.w3.org/2014/10/30-crypto-minutes.html bhill2
04:53:55 <bhill2> rrsagent, set logs public-visible
04:54:00 <bhill2> bhill2 has left #crypto
04:57:17 <nvdbleek> nvdbleek has joined #crypto
06:01:16 <rbarnes> rbarnes has joined #crypto
06:08:55 <Bert> Bert has left #crypto
06:36:28 <tantek> tantek has joined #crypto
07:28:11 <mountie> mountie has joined #crypto
08:32:24 <mountie> mountie has joined #crypto