Re: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

I am not raising another issue for 'query keys belonging to a type of storage' at this point – as there is no key query mechanism at this point. I think I heard Ryan saying that at some point in future we will have to get key query supported in the spec. At that point, we can add type of storage as another query parameter.
Please let me know if my understanding is not correct.

Thanks,
Seetharama

On 8/27/12 2:49 PM, "GALINDO Virginie" <Virginie.GALINDO@gemalto.com<mailto:Virginie.GALINDO@gemalto.com>> wrote:

Karen, Asad, and all,
As per your request of todays call, I have created an issue about the location of the key. Feel free to amend/comment its description and agree with the editors to make sure it is correctly expressed in the version of our draft API going to the FPWD.
Regards,
Virginie
Gemalto
Chair of the Web Crypto WG

-----Original Message-----
From: Web Cryptography Working Group Issue Tracker [mailto:sysbot+tracker@w3.org]
Sent: lundi 27 août 2012 22:46
To: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

http://www.w3.org/2012/webcrypto/track/issues/30

Raised by: Karen Lu
On product: Web Cryptography API

During our discussion on the 27th of august, the problem related to usage of keys stored in secure element has been discussed. While a previous issue (#11] has been already closed about the definition of a specific attribute for indicating if the key was stored in a specific secure element (or crypto providers), the problem about making sure the application is aware of the key location is still pending. The means for solving this specific problem do not need to rely on a specific attribute.

Received on Monday, 27 August 2012 22:58:01 UTC