See also: IRC log
<trackbot> Date: 27 May 2013
<scribe> scribe : Virginie
<hhalpin> scribenick: Virginie
<hhalpin> scribenick: virginie
Mark: presenting the web crypto
key discovery api
... reminding the use case
... related to the identity and properties of the device
... making the key origin specific avoiding to have problem with the web security model
... the notion of key name is also described
... the first draft aims to be as simple as possible
... Reagrding change : return in key by name should be a simple key object
... has to be updated
Michael: what about with a fixed name, we could return all the possible keys ?
Mark: it is required to get more
... the level of abstraction in the APi has maybe to be discussed
Harry: writing an eID
specification may also be out of scope
... but some of the capabilities could be used by the system to build a solution
... and it would value the API for such usage
... we could maybe first issue a spec and then have the eID use case to see how to get the most of it
<hhalpin> I don't know what other capabilities are needed.
Mark: we need to define exactly
what is missing (e.g. certificate discovery, ...)
... in order to implement this use case
... but it may happen that it will not be in the scope of the WG charter
<hhalpin> I think the WG would have to be convinced that certs would be needed rather than just keys
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)
... if you have the ability to get all the same origin policy (from any source)
that would be already interesting
Mark: If we talk only about the key discovery, that is ok, without specifying the exact key we are looking at (properties)
Mountie: (can not really get the
... about the way keys are pre-provisionned
Harry: the major vendors will impelment that spec, but we have not seen any movement from them
Mark: actually it will be more on TV market that first implementations will happen
Harry: GUID was hardly discussed in the past, where is it in the spec ?
Mark: I am ok to use the id as mentionne din spec, so we may close the issue-25
Michael: what is the intent to have an id ?
Mark: the id is different from the name
names of key are the way application are using keys
scribe: while id are identifying keys among a specific fleet of devices
Michael: How van it be knowable ?
Mark: If you dont know the id, you can not use it.
<nvdbleek> you may have another way to identify the device
<nvdbleek> and then you don't need an ID on the keys to uniquely identify them, if you have uniqualy named keys
Mark: the id is usually shared by
... to the service providers
... it is a matter of deployment to make sure the uniqueness of the keys
<hhalpin> My only suggestion was that we then propose to the WG to close ISSUE-25 unless there are any objections
<hhalpin> at our next meeting
Mountie: when reading the spec,
it seems that the specification is not suitable if there is not
... based on the worlwide experience
... the spec is trying to use the pre-shared keys between device makers and service providers
<MichaelH> @Virginie Michael : How can it be nullable?
the usecase can not be applicable to a usecase where small manufacturers
scribe: are installing some keys
Mark: the specification does not
mandate the scheme of key deployment
... any scheme for provisioning the keys are acceptable
... one key per application pre-provisionned
... or one master key to be derived per application
... but it is out of scope of the spec
Mountie: answers are ok, but concern stays
<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
<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
<MichaelH> You can still use Key Object sharing if both origins agree (postMessage)
<hhalpin> I am still not sure why the Korean banking use-case can't use postMessage
Harry: to Mountie, the banking
usecase wont be solved with the current set of spec
... but the keys being pre-provisionned by the device
... can it be used anyway ?
<hhalpin> I think origin-free keys would likely be a "no go"
Mountie: the main problem is the
... and to initiate a key operation, key consumers are the triggers of the usage
... while post message is under the 'power' of the application issue
<hhalpin> Key consumers need to "get" the key, not simply have a "key" postmessage, right mountie?
<hhalpin> I thought iframe would work here :(
Mountie: in addition this may not be compatible with regulation in korea
<hhalpin> You said "iframe" wouldn't work due to "accessibility" regulation?
<hhalpin> And you want "user-interaction"
Mountie: 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
<hhalpin> thinks that maybe that be done via interaction triggered by the iframe?
Nick: we are trying to set up a proposal related to eID
<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
Michael: the user controlling the
key, this may be managed by the application
... it would be somtehing to treat in the next generation of specification
... on another topic key discovery with or without name
... why cant we ask for all origin keys ?
Mark: on getting all the
... keys can be dynamically changed
and the other reaosn is that if we get a bunch of keys, it wil be hard to identify which one is which one
scribe: and it would make sense
to get a use case describing the exact story
... on the user interaction : if it is to protect the user
... this is the task of the browser to have appropriate control
... and thus out of that spec
... if te service wants to know if the user clicked on the actual operation confirmation, this is a different topic
<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)
scribe: and discussion have not happened, as such it will not be part of that spec
Michael: in case you ask all the
... you will have the properties (?) of all keys
[discussion on who is assigning the name and who knows the name]
<nvdbleek> you might recognize the prefix of the name
Michael: typically when
provisioning keys, names are allocated based on name of signing
... the application will determine from that name what to do
Mark: get a key, with 3 keys with diffreent names, how would that work ?
Michael: the application will make a decision, not the user
Mark: why dont you know the name ?
Michael: you may not know it completely, depending on when and how the key has been generated
Mark: I need to know if this would work across browsers
with the same user experience
Michael: this is why we need to
have a standard spec including that
... (analogy with post message)
<nvdbleek> The alias (when using Java) for a beID are for example 'John Doe (Authentication)' and 'John Doe (Signature)'
Harry: procedural point on issue-25
<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.
<trackbot> ISSUE-25 -- How do we provision Global Unique ID for pre-provisionned symetric keys -- closed
<markw> Ah, yes, the issue is closed. I just need to update the specification to remove the reference to the definition
Harry: Other point : will the doc be ready for next PWD and ping the Privacy interest group (?)
Harry: we need to check that postmessage does not address the concerns of Korean banking case and belgium eID
<nvdbleek> Harry, that is exactly what we will try to talk about
Harry: would that be possible to
make sure that local/national bodies look that current
... so that we can get if this is suitable or not, and how to improve it
<hhalpin> ACTION: hhalpin to ping Privacy Interest Group to put Key Discovery in radar before we go to next publication [recorded in http://www.w3.org/2013/05/27-crypto-minutes.html#action01]
<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].
Nick: this is what we are targeting
Mountie: we will have that kind of exchange this week
<markw> @harry: when is the next PWD heartbeat ?
<MichaelH> Did I get an ACTION?
<hhalpin> ACTION: MichaelH to outline his use-case for not needing a "name" and send to mailing list [recorded in http://www.w3.org/2013/05/27-crypto-minutes.html#action02]
<trackbot> Error finding 'MichaelH'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
<hhalpin> We are techically behind schedule with heartbeats, ideally we'd have one in May, but we can slip to June
<hhalpin> trackbot, meeting adjourned
<trackbot> Sorry, hhalpin, I don't understand 'trackbot, meeting adjourned'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<hhalpin> trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/\me// Found Scribe: Virginie Found ScribeNick: Virginie Found ScribeNick: virginie WARNING: No "Topic:" lines found. Default Present: markw, Virginie, Michael, nvdbleek, +220.127.116.11.aaaa, mountie, hhalpin Present: markw Virginie Michael nvdbleek +18.104.22.168.aaaa mountie hhalpin WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 27 May 2013 Guessing minutes URL: http://www.w3.org/2013/05/27-crypto-minutes.html People with action items: hhalpin michaelh WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]