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

Hi.
visibility has no meaning for blindness.

iframes can be invisible when it run silently.

but
with the view of key ownership,
we can image some interactions between user and script.
- showing content for signing.
- entering passphrase for private key access which is associated with
certificate
- getting user consent for many purposes.

the reason I mentioned disabilities are
in this year, Korea start new act named "Disability Discrimination Act".
even US already have similar "Americans with disabilities Act".

regards
mountie.




On Wed, May 15, 2013 at 7:07 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:

>  Hey Mountie,
>
> I don't think there's an accessibility concern here.  The accessibility
> issues arises when frames are used to display content.  In this example,
> they're just being used to load some JS logic (invisibly).
>
> --Richard
>
>  On Wednesday, May 15, 2013 at 9:58 AM, Mountie Lee wrote:
>
> 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
>
>
>


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