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

Hi.

thanks all for examples.
I now completely understand usage.

in the view of web accessibility for disabilities.
frame or iframe are not recommended (http://webaim.org/techniques/frames/)

CSS? ... hmm.

are we sure
iframe and postMessage combination is best practice for all tech consumers
in the world?

regards
mountie.







On Wed, May 15, 2013 at 5:25 PM, Nick Van den Bleeken <
Nick.Van.den.Bleeken@inventivegroup.com> wrote:

>  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>
>  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>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
>
>  =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>
>
>
>
>
> ------------------------------
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>



-- 
Mountie Lee

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

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