Re: Additional use cases

Karen,

As far as I know that's the only way to achieve what you want to do 
without imagining some other script injection mechanisms which could be 
far more frightening (and dangerous). As I mentioned that's not an 
absolute user friendly way but to install the button you just have to 
drag and drop it from originX in the toolbar, I don't think the user can 
realize what is doing the button when he clicks on it.

Of course originX should be trusted and origin1 should cooperate, the 
button must not work for other origins, all this only depends on the 
user action, and usually the user is not willing to attack himself.

Any other mechanism would require origin1 to know about originX.

Regards

Aymeric

Le 11/05/2013 00:26, Lu HongQian Karen a écrit :
>
> 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>

-- 
jCore
Email :  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
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com