Hi Mark,
First of all thank you for making Key Discovery API promises based just like the Web Crypto API!
For the other change, I'm not that convinced anymore that there should be only one key with a certain name (I know we discussed this at the FtF but…).
With the current spec someone can choose to deploy multiple keys with the same name and use a particular naming schema for the ID to distinguish the keys. (There is currently no query or list functionality so you need to know the name of the key upfront (you can't for example use a particular naming schema on the name to because then you don't know the exact name for the key)).
In a future version of the Key Discovery API we might add other 'attributes' that could be assigned to keys by the provisioner, which make it even more useful to return multiple keys (but currently implementers could choose to experiment with adding their own extension attributes).
A possible use case could be pre-provisioned keys issued by a particular issuer for a particular usage that have an X.509 certificate associated with them. But even without the certificate, when you are in a trusted environment only having the ID, which encodes the 'subject' will benefit by being able to return multiple keys for the same name.
Regards,
Nick
[cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110]
On 09 Jul 2013, at 01:51, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
All,
I updated the Key Discovery editor's draft to use Promises and to support retrieval of a single named key: https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html
(Yes, I know it should be Promise<any> in the IDL, but I don't think respec supports this ...)
There have been some requests for APIs to discover multiple keys, for which I'm waiting on a clear use-case.
...Mark
________________________________
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
