W3C

- DRAFT -

Web Cryptography Working Group Teleconference

27 May 2013

See also: IRC log

Attendees

Present
markw, Virginie, Michael, nvdbleek, +82.22.14.0.aaaa, mountie, hhalpin
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Virginie

Contents


<trackbot> Date: 27 May 2013

https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html

<scribe> scribe : Virginie

<hhalpin> +1

<hhalpin> scribenick: Virginie

<hhalpin> scribenick: virginie

Mark: presenting the web crypto key discovery api https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html
... 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 technical proposal
... 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 question)
... 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 the pre-provisionners
... 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 user interaction
... 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 key origin
... 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

q

<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


.;. and discuss with the belgian eID association, in ordre to get their feedback

<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
... 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)

<hhalpin> np

scribe: and discussion have not happened, as such it will not be part of that spec

Michael: in case you ask all the keys
... 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 key
... 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.

<nvdbleek> issue-25?

<trackbot> ISSUE-25 -- How do we provision Global Unique ID for pre-provisionned symetric keys -- closed

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/25

<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 (?)

Mark: yes

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 spec
... 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

Summary of Action Items

[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/05/27 21:06:51 $

Scribe.perl diagnostic output

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/\me//
Found Scribe: Virginie
Found ScribeNick: Virginie
Found ScribeNick: virginie

WARNING: No "Topic:" lines found.

Default Present: markw, Virginie, Michael, nvdbleek, +82.22.14.0.aaaa, mountie, hhalpin
Present: markw Virginie Michael nvdbleek +82.22.14.0.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]