RE: Additional use cases

You have an interesting approach. Indeed the origin 1 does not know what happens to its key. This, however, is cumbersome to users. You cannot pre-store all the bookmarklets and click each one of them when at the origin 1. Furthermore, many people would not want to save bookmarlets once they know what they are and what they can do.

Thanks,
Karen

From: Aymeric Vitte [mailto:vitteaymeric@gmail.com]
Sent: Friday, May 10, 2013 5:46 AM
To: Lu HongQian Karen
Cc: Arun Ranganathan; public-webcrypto@w3.org Working Group
Subject: Re: Additional use cases

What you could be doing for the privacy concern is again exactly what we are doing in [1], but this might become a bit confusing and tricky for the user :

- you go on origin1 which generates the keys
- origin2 has provided you a script that you can store like a bookmark (a button in the bookmark's bar that you can install being on origin2 as showed in [1])
- while being on origin1, you click on the bookmark
- this inserts a script in origin1 which loads an iframe to origin2 and sends a postMessage to this iframe with the keys
- origin2 iframe stores the keys in indexedDB
- therefore during all this process, origin1 is not aware of origin2
- you go on origin2 and can use the keys, and, again, origin1 has no clue of the keys being used by origin2,3 or 4

Regards,

[1] http://extractwidget.com/#demo
Le 09/05/2013 23:43, Lu HongQian Karen a écrit :
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<mailto: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*



--

jCore

Email :  avitte@jcore.fr<mailto:avitte@jcore.fr>

iAnonym : http://www.ianonym.com

node-Tor : https://www.github.com/Ayms/node-Tor

GitHub : https://www.github.com/Ayms

Web :    www.jcore.fr<http://www.jcore.fr>

Webble : www.webble.it<http://www.webble.it>

Extract Widget Mobile : www.extractwidget.com<http://www.extractwidget.com>

BlimpMe! : www.blimpme.com<http://www.blimpme.com>