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

On Thu, May 16, 2013 at 1:49 PM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
> Arun,
>
> In the use case document, for cross-origin use cases, maybe we should describe the limits (or assumptions) of the webcrypto API in dealing with such use cases and the privacy considerations?
>
> The approach of webcrypto API + postMessage :
>
> http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0084.html
> http://lists.w3.org/Archives/Public/public-webcrypto/2013May/0085.html
>
> can solve some of the cross-origin use cases, but not all of them. It works when Origin A generates the key and persists it on the user computer that the UA runs. Then Origin B can ask Origin A to do operations using the key. (How does Origin B specify which key to use?)

Up to however Origin A and Origin B want to communicate. There's no
reason to specify or recommend anything. Origin B could provide
criteria (that Origin A knows how to interpret), Origin A could
provide Origin B stable identifiers (eg: based on IndexedDB keys), or
any other number of possible solutions. That's just an implementation
issue - nothing for the spec or use cases doc, arguably.

>
> This approach does not work when Origin A provisions the key in a smart card without persists anything on the user computer, and Origin B wants to use the key without invoking Origin A. These are typical eID, eHealth, and other smart card use cases.

Two parts:
- We've repeatedly established smart card use cases as out of scope.
That said, in a hypothetical world (which we have not agreed to as a
WG to take on) in which we're talking smart card keys, this exact
model works just the same. It makes no difference *how* the key was
provisioned for Origin A.

- Your real meat of concern is "when Origin B wants to use the key
without invoking Origin A", but I would suggest you're not fully
realizing how this is exactly the same model that eID, eHealth, and
other smart card use cases are *already* dealing with smart cards. The
vast majority of cards have either a smart card minidriver OR smart
card middleware, to be used for their use case. Consider document
signing. Most document signing solutions are some combination of
vendor-supplied software (eg: Adobe Acrobat), some middleware (that
might handle XAdEs), some smart card driver (either from the OS vendor
or from the card vendor), and the smart card.

You need to think of "Origin A" as being equivalent to
[vendor-supplied software, middleware, smart card driver] - whichever
helps you conceptualize it easiest. It's part of the "software
solution" stack.

Again, as re-iterated earlier, postMessage does not involve actually
sending data over the wire. You're exchanging messages between two
"programs" - those "programs" just happen to be distinct origins. This
is the same thing you do when, for example, you ask Windows CNG to
"sign" a message: you provide the message to the CSP/KSP, which then
sends it to another process for that ('trusted') process to [hash the
message, xmit to the card, receive from card].

So I would argue it definitely solves all of the use cases provided so far.

>
> Thanks,
> Karen
>
>
> -----Original Message-----
> From: Arun Ranganathan [mailto:arun@mozilla.com]
> Sent: Wednesday, May 15, 2013 1:17 PM
> To: Mountie Lee
> Cc: Richard L. Barnes; Nick Van den Bleeken; Aymeric Vitte; public-webcrypto@w3.org Group
> Subject: Re: Follow-up. Re: Use case: Authenticate using eID
>
> Mountie,
>
> Another subtle aspect of this model might be found in the way Origin A, which performs cryptographic operations on behalf of Origin B, interacts with the user:
>
> On May 15, 2013, at 6:27 AM, Mountie Lee wrote:
>
>> 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.
>>
>
>
> On the web today, OAuth is fairly prevalent, and is used to authenticate users on some sites with well-established identities on other sites.  To take a practical example, the Facebook, Twitter, and LinkedIn identities (authentication credentials like usernames and passwords) often are used to authenticate users on different sites.  I like this model; users understand it.  We can migrate this model over to our world that uses postMessage within the UA (in lieu of the complicated protocol steps of OAuth).
>
> In our world, OriginA might be considered an iDP (identity provider).  OriginB might be considered a relying party.  Sure, OriginB might use an invocation of OriginA through an iframe, but OriginA might solicit user credentials and thus spawn a UI flow.  Origin A can be explicit about what it grants.
>
> "User consent" that follows the model of OAuth (for inspiration about a UI consent model, of course) on the web today is both feasible and desirable.  Accessiblity can thus be subject to all the usual considerations -- business as usual :-)
>
> Also, I agree with your point made in earlier correspondence about differences about "who owns the key" as being philosophical.  It is philosophical, depending on how you think about the origins.  We're essentially building a web of origins, no different than the web that exists right now.
>
> If you have further questions about this, I'm happy to answer them off-list.  Hopefully when the use case is documented it will also answer your questions.
>
> -- A*
>

Received on Thursday, 16 May 2013 21:07:40 UTC