RE: Additional use cases

Hi Arun,

Please see my comments below marked with KL>.

Thanks,
Karen

From: Arun Ranganathan [mailto:arun@mozilla.com]
Sent: Tuesday, May 07, 2013 1:10 PM
To: Lu HongQian Karen
Cc: public-webcrypto@w3.org Working Group
Subject: Re: Additional use cases

Hi Karen :)

On May 6, 2013, at 12:38 PM, Lu HongQian Karen wrote:


Hi Arun,

Here are the two use cases that I have talked about at the recent F2F meeting.

Cross-origin use cases:


I'm strongly in favor of capturing a cross-origin use case that leverages the existing web technology stack and the Web Crypto API.  The way I envision this is having a credible multi-origin use case make use of cross-origin messaging (postMessage) and the fact of Structured Clonability to perform a cryptographic operation in one origin under the aegis of the origin that has generated the keys.

[KL> I understand. ]



1.  Asymmetric key use case: A healthcare association (origin 1) issued Dr. Smith an X.509 certificate and the corresponding private key. Dr. Smith accesses an e-prescription service (origin 2) and uses her private key to sign e-prescriptions.


This would be a good use case for my claim above, modulo a few things:

1. The X.509 certificate you mention can be stored in IndexedDB within origin 1, and can be represented in JSON.
2. The key can be shared with origin 2 via cross-origin messaging.

Do you envision things like this?

[KL> Yes. We discussed the postMessage at the F2F meeting. IndexedDB is one possible storage for the key object. One downside of using the cross-origin messaging is the privacy concern because the key issuer (origin 1) will know which service provider (origin 2) that the user accessed for the first time. For some situations, such as the Dr. Smith case, this may not be a problem. For other situations, such as eID, this may be a problem. The citizen may not want the issuer (origin 1) to know where he is using the key. ]



2.  Secret key use case: Danny signed up at a cloud storage (origin 1) that created him a secret access key and persisted it through Danny's UA. Danny stores his 3D model data in the cloud storage. He then uses an online 3D printing service (origin 2) to print his model. To access Danny's model in Origin 1, Origin 2 needs to use Danny's secret key. Danny tells Origin 2 certain attribute(s) of his key. The Origin 2 finds the key object through the UA and uses the key to sign API requests for getting the model from cloud storage.


This use case is also credible, but I'm not sure why it's necessary for Danny to "tell Origin 2 certain attribute(s) of his key."  Do you mean, the key here is exportable?  Do you think that cross-origin messaging alone is insufficient here?

[KL> No, I do not mean that the key is exportable. Danny may have more than one keys. He need to somehow tell Origin 2 which key to use, for example, a name or id or something else. Yes, the cross-origin messaging could work here too. Again, privacy may be an issue.]



Although these two use cases are out of the current WG scope. It'll be good to collect them for future work.


Interestingly enough, I think we should put these use cases in scope of this WG, *unless* you think cross-origin messaging is insufficient to carry them out :)

[KL> May be we can add these use cases, write out the flows, and then discuss the security and privacy considerations.]


-- A*