20:03:55 <RRSAgent> RRSAgent has joined #crypto
20:03:55 <RRSAgent> logging to http://www.w3.org/2013/05/27-crypto-irc
20:03:57 <trackbot> RRSAgent, make logs public
20:03:59 <trackbot> Zakim, this will be SEC_WebCryp
20:03:59 <Zakim> ok, trackbot, I see SEC_WebCryp()4:00PM already started
20:04:00 <trackbot> Meeting: Web Cryptography Working Group Teleconference
20:04:00 <trackbot> Date: 27 May 2013
20:04:00 <mountie> zakim, aaaa is mountie
20:04:00 <Zakim> +mountie; got it
20:05:08 <Zakim> +[IPcaller]
20:05:18 <hhalpin> Zakim, IPcaller is hhalpin
20:05:18 <Zakim> +hhalpin; got it
20:05:50 <virginie> https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html
20:06:09 <virginie> scribe : Virginie
20:06:10 <hhalpin> +1
20:06:23 <hhalpin> scribenick: Virginie
20:06:30 <hhalpin> scribenick: virginie
20:07:05 <virginie> Mark : presenting the web crypto key discovery api https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html
20:07:16 <virginie> ... reminding the use case
20:07:28 <virginie> ... related to the identity and properties of the device
20:07:48 <virginie> ... making the key origin specific avoiding to have problem with the web security model
20:08:10 <virginie> ... the notion of key name is also described
20:08:24 <virginie> ... the first draft aims to be as simple as possible
20:08:52 <virginie> ... Reagrding change : return in key by name should be a simple key object
20:09:03 <virginie> ... has to be updated
20:09:34 <virginie> Michael : what about with a fixed name, we could return all the possible keys ?
20:09:49 <virginie> Mark : it is required to get more technical proposal
20:09:58 <MichaelH> q+
20:10:21 <virginie> ... the level of abstraction in the APi has maybe to be discussed
20:10:28 <hhalpin> q+
20:11:39 <virginie> Harry : writing an eID specification may also be out of scope
20:11:57 <virginie> ... but some of the capabilities could be used by the system to build a solution
20:12:09 <virginie> ... and it would value the API for such usage
20:12:57 <virginie> ... we could maybe first issue a spec and then have the eID use case to see how to get the most of it
20:13:11 <hhalpin> q- hhalpin
20:13:21 <hhalpin> I don't know what other capabilities are needed.
20:13:27 <virginie> Mark : we need to define exactly what is missing (e.g. certificate discovery, ...)
20:13:41 <virginie> ... in order to implement this use case
20:13:59 <virginie> ... but it may happen that it will not be in the scope of the WG charter
20:14:21 <hhalpin> I think the WG would have to be convinced that certs would be needed rather than just keys
20:15:07 <virginie> Michael : a proposal can be drafted (story from michael, an application ask the key and get all the keys issued by that domain, pre-provisionned)
20:15:18 <markw> q+
20:15:42 <virginie> ... if you have the ability to get all the same origin policy (from any source)
20:15:49 <mountie> q+
20:15:51 <virginie> that would be already interesting
20:15:56 <MichaelH> q-
20:17:27 <virginie> Mark : If we talk only about the key discovery, that is ok, without specifying the exact key we are looking at (properties)
20:17:50 <virginie> q?
20:18:21 <markw> q-
20:19:00 <virginie> Mountie : (can not really get the question)
20:20:35 <hhalpin> q+
20:20:36 <virginie> ... about the way keys are pre-provisionned
20:20:39 <MichaelH> q+
20:21:16 <virginie> Harry : the major vendors will impelment that spec, but we have not seen any movement from them
20:21:37 <virginie> Mark : actually it will be more on TV market that first implementations will happen
20:22:08 <virginie> Harry : GUID was hardly discussed in the past, where is it in the spec ?
20:22:20 <Zakim> -hhalpin
20:22:30 <virginie> Mark : I am ok to use the id as mentionne din  spec, so we may close the issue-25
20:22:40 <virginie> Michael : what is the intent to have an id ?
20:22:52 <virginie> Mark : the id is different from the name
20:23:11 <virginie> names of key are the way application are using keys
20:23:35 <virginie> ... while id are identifying keys among a specific fleet of devices
20:24:11 <virginie> Michael : How van it be knowable ?
20:24:21 <virginie> Mark : If you dont know the id, you can not use it.
20:25:42 <nvdbleek> you may have another way to identify the device
20:26:47 <nvdbleek> and then you don't need an ID on the keys to uniquely identify them, if you have uniqualy named keys
20:26:51 <virginie> Mark : the id is usually shared by the pre-provisionners
20:27:00 <virginie> ... to the service providers
20:27:44 <mountie> q+
20:27:44 <virginie> mark : it is a matter of deployment to make sure the uniqueness of the keys
20:27:51 <hhalpin> hhalpin has joined #crypto
20:28:12 <hhalpin> Zakim, what's the code?
20:28:12 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin
20:28:26 <hhalpin> My only suggestion was that we then propose to the WG to close ISSUE-25 unless there are any objections
20:28:32 <hhalpin> at our next meeting
20:28:51 <virginie> Mountie : when reading the spec, it seems that the specification is not suitable if there is not user interaction
20:29:05 <virginie> ... based on the worlwide experience
20:29:41 <virginie> Mountie : the spec is trying to use the pre-shared keys between device makers and service providers
20:30:19 <MichaelH> @Virginie Michael : How can it be nullable?
20:30:21 <virginie> the usecase can not be applicable to a usecase where small manufacturers
20:30:57 <hhalpin> Zakim, what's the code?
20:30:57 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin
20:31:23 <virginie> ... are installing some keys
20:31:48 <virginie> Mark : the specification does not mandate the scheme of key deployment
20:32:14 <Zakim> +[IPcaller]
20:32:57 <virginie> Mark : any scheme for provisioning the keys are acceptable
20:33:04 <hhalpin> Zakim, IPcaller is hhalpin
20:33:04 <Zakim> +hhalpin; got it
20:33:07 <virginie> ... one key per application pre-provisionned
20:33:18 <virginie> ... or one master key to be derived per application
20:33:25 <virginie> ... but it is out of scope of the spec
20:33:30 <hhalpin> q?
20:33:31 <virginie> q?
20:33:57 <virginie> Mountie : answers are ok, but concern stays
20:34:14 <markw> So, manufacturers could explicitly pre-provision keys for particular origins, or provide a generic capability that derives an origin-specific key for any origin that asks
20:35:11 <markw> if they choose the former approach, this does indeed make it difficult for a small service provider to get access to keys, but this is by the decision of the manufacturer not because of the specification
20:36:08 <virginie> q?
20:36:29 <MichaelH> You can still use Key Object sharing if both origins agree (postMessage)
20:37:17 <hhalpin> I am still not sure why the Korean banking use-case can't use postMessage
20:37:49 <virginie> Harry : to Mountie, the banking usecase wont be solved with the current set of spec
20:38:03 <mountie> q+
20:38:27 <virginie> ... but the keys being pre-provisionned by the device
20:38:46 <nvdbleek> q+
20:38:53 <virginie> ... can it be used anyway ?
20:39:10 <hhalpin> I think origin-free keys would likely be a "no go"
20:39:10 <virginie> Mountie : the main problem is the key origin
20:39:49 <virginie> ... and to initiate a key operation, key consumers are the triggers of the usage
20:40:06 <virginie> ... while post message is under the 'power' of the application issue
20:40:16 <hhalpin> Key consumers need to "get" the key, not simply have a "key" postmessage, right mountie?
20:40:24 <hhalpin> I thought iframe would work here :(
20:40:43 <virginie> ... in addition this may not be compatible with regulation in korea
20:40:49 <hhalpin> You said "iframe" wouldn't work due to "accessibility" regulation?
20:41:02 <hhalpin> And you want "user-interaction"
20:41:25 <virginie> ... silent encryption is possible by the specification, but in the banking use case in korea, the ownership has to be in the hand of the user
20:41:39 <virginie> q
20:41:41 <virginie> q?
20:41:56 <mountie> q-
20:42:01 <hhalpin> thinks that maybe that be done via interaction triggered by the iframe?
20:42:04 <hhalpin> q- hhalpin
20:42:24 <hhalpin> q+ procedural points
20:42:31 <hhalpin> q- procedural
20:42:39 <hhalpin> q- points
20:42:41 <hhalpin> q+
20:43:23 <Zakim> -Michael
20:43:59 <virginie> Nick : we are trying to set up a proposal related to eID
20:44:26 <Zakim> +Michael
20:44:35 <MichaelH> q+
20:44:40 <virginie> .;. and discuss with the belgian eID association, in ordre to get their feedback
20:45:10 <hhalpin> I think what we need is one sensible flow that fulfills the eID and/or Korean banking use-case using CORS/postMessage and the application prompting
20:45:14 <virginie> Michael : the user controlling the key, this may be managed by the application
20:45:31 <markw> q+
20:45:43 <virginie> ... it would be somtehing to treat in the next generation of specification
20:46:03 <virginie> ... on another topic key discovery with or without name
20:46:13 <virginie> ... why cant we ask for all origin keys ?
20:46:24 <MichaelH> q-
20:46:44 <virginie> Mark : on getting all the keys
20:47:00 <virginie> ... keys can be dynamically changed
20:47:25 <virginie> and the other reaosn is that if we get a bunch of keys, it wil be hard to identify which one is which one
20:47:41 <virginie> ... and it would make sense to get a use case describing the exact story
20:47:57 <virginie> ... on the user interaction : if it is to protect the user
20:48:13 <virginie> ... this is the task of the browser to have appropriate control
20:48:32 <virginie> ... and thus out of that spec
20:48:58 <virginie> ... if te service wants to know if the user clicked on the actual operation confirmation, this is a different topic
20:49:05 <nvdbleek> I think it just depends how much of uniqueness you put in the name versus the ID if you will need a getKeys with wildcards or not (with a return all keys as a wide wildcard)
20:49:20 <hhalpin> np
20:49:38 <virginie> ... and discussion have not happened, as such it will not be part of that spec
20:49:59 <virginie> Michael : in case you ask all the keys
20:50:17 <virginie> ... you will have the properties (?) of all keys
20:50:39 <virginie> [discussion on who is assigning the name and who knows the name]
20:50:48 <nvdbleek> you might recognize the prefix of the name
20:52:32 <virginie> Michael : typically when provisioning keys, names are allocated based on name of signing key
20:52:56 <virginie> ... the application will determine from that name what to do
20:53:19 <virginie> Mark : get a key, with 3 keys with diffreent names, how would that work ?
20:53:32 <virginie> Michael : the application will make a decision, not the user
20:54:16 <virginie> Mark : why dont you know the name ?
20:54:45 <virginie> Michael : you may not know it completely, depending on when and how the key has been generated
20:55:14 <virginie> Mark : I need to know if this would work across browsers
20:55:35 <virginie> with the same user experience
20:55:56 <virginie> Michael : this is why we need to have a standard spec including that
20:57:05 <virginie> ... (analogy with post message)
20:57:25 <MichaelH> q-
20:58:03 <nvdbleek> The alias (when using Java) for a beID are for example 'John Doe (Authentication)' and 'John Doe (Signature)'
20:58:23 <nvdbleek> q-
20:59:33 <virginie> Harry : procedural point on issue-25
20:59:38 <markw> When we have previously talked about window.postMessage it has just been about posting Key objects. I'm confused about the reference to additional specifications for this.
20:59:47 <nvdbleek> issue-25?
20:59:47 <trackbot> ISSUE-25 -- How do we provision Global Unique ID for pre-provisionned symetric keys -- closed
20:59:47 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/25
21:01:31 <markw> Ah, yes, the issue is closed. I just need to update the specification to remove the reference to the definition
21:01:32 <virginie> ... Other point : will the doc be ready for next PWD and ping the Privacy interest group (?)
21:01:45 <virginie> Mark : yes
21:02:28 <virginie> Harry : we need to check that postmessage does not address the concerns of Korean banking case and belgium eID
21:02:30 <nvdbleek> Harry, that is exactly what we will try to talk about
21:02:50 <virginie> ... would that be possible to make sure that local/national bodies look that current spec
21:03:07 <virginie> ... so that we can get if this is suitable or not, and how to improve it
21:03:17 <hhalpin> ACTION: hhalpin to ping Privacy Interest Group to put Key Discovery in radar before we go to next publication
21:03:17 <trackbot> Created ACTION-103 - Ping Privacy Interest Group to put Key Discovery in radar before we go to next publication [on Harry Halpin - due 2013-06-03].
21:03:20 <virginie> Nick : this is what we are targeting
21:03:33 <virginie> Mountie : we will have that kind of exchange this week
21:03:54 <markw> @harry: when is the next PWD heartbeat ?
21:04:09 <MichaelH> Did I get an ACTION?
21:05:02 <hhalpin> ACTION: MichaelH to outline his use-case for not needing a "name" and send to mailing list
21:05:02 <trackbot> Error finding 'MichaelH'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
21:05:29 <virginie> q?
21:05:35 <hhalpin> \me We are techically behind schedule with heartbeats, ideally we'd have one in May, but we can slip to June
21:05:40 <markw> q-
21:05:45 <hhalpin> s/\me//
21:06:08 <markw> markw has joined #crypto
21:06:22 <Zakim> -nvdbleek
21:06:23 <Zakim> -markw
21:06:23 <Zakim> -mountie
21:06:25 <Zakim> -hhalpin
21:06:28 <hhalpin> trackbot, meeting adjourned
21:06:28 <trackbot> Sorry, hhalpin, I don't understand 'trackbot, meeting adjourned'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
21:06:29 <Zakim> -Virginie
21:06:37 <hhalpin> trackbot, end meeting
21:06:37 <trackbot> Zakim, list attendees
21:06:37 <Zakim> As of this point the attendees have been markw, Virginie, Michael, nvdbleek, +82.22.14.0.aaaa, mountie, hhalpin
21:06:45 <trackbot> RRSAgent, please draft minutes
21:06:45 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/27-crypto-minutes.html trackbot
21:06:46 <trackbot> RRSAgent, bye
21:06:46 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2013/05/27-crypto-actions.rdf :
21:06:46 <RRSAgent> ACTION: hhalpin to ping Privacy Interest Group to put Key Discovery in radar before we go to next publication [1]
21:06:46 <RRSAgent>   recorded in http://www.w3.org/2013/05/27-crypto-irc#T21-03-17
21:06:46 <RRSAgent> ACTION: MichaelH to outline his use-case for not needing a "name" and send to mailing list [2]
21:06:46 <RRSAgent>   recorded in http://www.w3.org/2013/05/27-crypto-irc#T21-05-02