Re: Follow-up. Re: Use case: Authenticate using eID

Mountie,

A user 'visiting' a web page from origin-A or origin-B doesn't mean that the the page can't load resources from another origin (using iframes for example).

So when origin-A is responsible for managing the keys, the user does't has to open a web page on origin-A before he can use keys managed by origin-A.

For example:
1) User opens web page at origin-B
2) Web page of origin-B loads a web page from origin-A in a 2 pixel iframe
3) A script that is loaded by the original web page at origin-B sends a request to the iframe using postMessage() requesting to sign a message
4) If origin-A trusts origin-B it will sign the message and use postMessage() to send the result back to origin-B

*Note*: When origin-A receives the sign message message and doesn't has a key yet it can create the key (if he needs to register the public key to a server, it can also do this)

*Note*: If you completely trust origin-B and want to give it full control origin-A can send back the key to origin-B using postMessage(). But this is probably not desirable.

Kind regards,

Nick Van den Bleeken


On 15 May 2013, at 09:51, Mountie Lee <mountie@paygate.net<mailto:mountie@paygate.net>>
 wrote:

Hi.
let me rewrite my understanding for postMessage.

let's assume
Key-A has origin-A and no Key is associated with origin-B.

if an user visit origin-A
user is able to generate signature with Key-A
and send it to origin-B via postMessage.

if an user visit origin-B
user is unable to generate signature with Key-A
and has nothing to send via postMessage.

normally original text for signature will be prepared by origin-B.

I'm not trying to be negative attitude.
just I'm trying to find acceptable solution for my use case.

still I need help.

regards
mountie.


On Wed, May 15, 2013 at 5:00 AM, Arun Ranganathan <arun@mozilla.com<mailto:arun@mozilla.com>> wrote:
On May 13, 2013, at 4:38 PM, Aymeric Vitte wrote:

In another email, you wrote "2. The key can be shared with origin 2 via cross-origin messaging." (http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0036.html), I don't see how CORS could apply here, withCredentials or not, CORS is only about sending/receiving things to/from other origins and sharing some stringyfiable things or cookies uses, you can not share keys, the best you can do is to send some information to allow another origin to find the keys.

Maybe I am missing something but what is the idea here?


(I was responding to your point about IndexedDB being a "mega-Cookie" and unwisely elected to discuss differences in how Cookies can be used vs. client-side stores.  I'm sorry if this was confusing.  These technologies are unrelated to our discussion of Crypto and cross-origin messaging.)




--
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net<mailto:mountie@paygate.net>


=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World





________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer