Providing my thoughts on this. On 8/28/12 7:10 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote: Just a quick note - I think the discussion related to key querying (that is, previously authorized or pre-provisioned) and key discovery (discovery of keys not explicitly granted) is too complex and the needs not well understood enough to support adding this to the draft. I've made note to highlight ISSUE-30, but I have concern adding this API for FPWD. I agree that key query needs to fleshed out a little further before it goes into FPWD. I think having ISSUE-30 highlighted in the FPWD should appease anyone looking for the functionality. In order to better understand what you're proposing here: 1) Can you please provide a sample of what you imagine "KeyLocation" containing. In my mind, the coarse-grained classification of 'internal' vs 'external' could be used. Essentially, it means whether the key is stored within browser's own storage (including ones it has direct access to – like KeyChain used by Chrome), or externally (primarily accessed through PKCS#11 providers). [BTW, key stores other than browser's own – like KeyChain – could be a third category, but I do not want to complicate things right away.] 2) Can you please provide a use case for how an application would use "KeyLocation" Given the classification above, the application can query for 'external' keys (satisfying some other criteria that we will get to when we discuss this topic in detail) 3) Can you please provide an example of how "KeyLocation" may be implemented by all conforming user agents, in a manner that is agnostic to the method of key storage they use? If the classification I mentioned above is used, then I guess the semantics of internal vs external are simple and can be uniformly implemented across browsers.
Received on Wednesday, 29 August 2012 15:46:36 UTC