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 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
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