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

Seetharama,

> Note that the reason we are down this path is so that the application 
> can limit the keys it wants the user to select.

I'd go so far as to say that an application that requires a user to select a key has failed its customers. As you note, users are not capable of making good choices here, nor should they have to. With that context, it feels like this is adding a feature that is exclusively intended for use by broken applications.

If an application knows what keys are acceptable to it, then it should just select the best such key. If the application does not know what keys it wants, then arguably the user is in no position to know either.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Wednesday, August 29, 2012 11:18 AM
To: Seetharama Rao Durbha
Cc: Lu HongQian Karen; Ali Asad; GALINDO Virginie; public-webcrypto@w3.org
Subject: Re: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

On Wed, Aug 29, 2012 at 11:03 AM, Seetharama Rao Durbha <S.Durbha@cablelabs.com> wrote:
>
>
> On 8/29/12 11:35 AM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
> On Wed, Aug 29, 2012 at 10:02 AM, Lu HongQian Karen 
> <karen.lu@gemalto.com> wrote:
>
> Hi Ryan,
>
> I agree with you that Issue-30 needs more elaboration.
>
> Regarding to keylocation, I was thinking
>
> Enum keyLocation {
>    None, // unspecified
>    Browser, // browser's storage
>    Local, // local storage other than browser's
>    CryptoProvider // complexity: a user agent may have more than one 
> cryptoProviders };
>
>
> The distinction between "Local" and "CryptoProvider" is fundamentally 
> flawed in assuming an implementation detail - since an implementation 
> may access "Local" (which I assume to mean 'OS storage', but in fact 
> can mean much more) storage via CryptoProviders.
>
> In fact, all Browser storage is could simply be another CryptoProvider.
>
> Note that the reason we are down this path is so that the application 
> can limit the keys it wants the user to select.

<snip>
And that's where the breakdown in communication is happening.

The premise of a user selecting something is related to querying/discovery, not provisioning. Further, this isn't the only reason we're down this path - it has been expressly commented and described by Karen that this distinction is for web applications to make trust decisions - http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0274.html

As discussed elsewhere, the notion of "provisioning", as has been used in the discussion of "pre-provisioned keys", is meaning that all the information is already provided, and there is nothing for the user TO select.

The moment you talk about "the user selecting" something, this goes into
1) Key discovery
2) User interface experience to support key discovery

We're not there yet. We're a rather long way away from that, in fact, because of the security/usability concerns, let alone the implementation details.

Received on Tuesday, 4 September 2012 09:07:01 UTC