- From: Ryan Sleevi <sleevi@google.com>
- Date: Thu, 25 Apr 2013 10:09:50 -0700
- To: Mark Watson <watsonm@netflix.com>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Thu, Apr 25, 2013 at 10:06 AM, Mark Watson <watsonm@netflix.com> wrote: > All, > > At the meeting yesterday there were two questions regarding named key > discovery for the Key Discovery draft. > > First, how are public/private key pairs handled. Second can more than one > key have the same name. > > I checked the main draft and AFAICT there is no way to distinguish a public > key from a private key by looking at the Key object. You have to know a > priori. In the named key discovery context, this means such keys would need > to have different names. > > Regarding multiple keys with the same name, the API supports this now and > the implication would be that you would then examine the Key objects to > determine which was which. If two indistinguishable keys are returned the > app has no way to decide - or even to ask the user - which to use. This > implies that keys with the same name must differ in some other detectable > way. That seems a rather awkward and error-prone restriction. Especially > since one of the most obvious cases for grouping keys under the same name - > the public private key case - wouldn't be supported because this difference > is not detectable. > > Given the above, I'm inclined to propose that we make the API as simple as > possible whilst still supporting the use-cases. With the present use-cases, > that would mean requiring that every key have a distinct name and modifying > the API to return NamedKey? instead of NamedKey[]. +1 > > Does anyone have use-cases for named keys that would not be supported if we > make this change ? Can you provide details ? > > Thanks, > > Mark
Received on Thursday, 25 April 2013 17:10:21 UTC