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

On Fri, May 17, 2013 at 8:01 AM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com> wrote:
> Looks like there is an assumption being made that Origin B knows exactly the
> other origin (Origin A) whose keys it wants to use.

If this is about discovering the set of possible origins that may be
involved (eg: Origin A, B, and C may all issue keys under a given
'healthcare' protocol/scheme), then you've just reduced it back to the
"Introducer" pattern, and patterns used by other schemes (such as
Persona) equally apply here - that is, there exist a variety of
options.

>
> It looks to me that that may not be the case. Origin B may allow one from a
> set of other Origins. In fact, tying a key to an origin (specific domain to
> satisfy SOP) may introduce inflexibility for Origin A in how they
> issue/manage their keys. I know that such expectations are met today through
> exposure of OpenID, OAuth URLs and other web services URLs. But just
> wondering that this is something that Origin A needs to be explicitly aware.

Are you thinking of the situation where "foo-provider.example" gets
acquired and rebrands themselves as "bar-incorporated.example"?

The postMessage + structured clone allows for key portability there.

This is not unique to WebCrypto though - they would want to move
anything they had persisted on the users' device (eg: IndexedDB).

>
> I could be totally off on my understanding of what is being discussed here
> too :) Apologies if so.
>
> On 5/16/13 5:32 PM, "Lu HongQian Karen" <karen.lu@gemalto.com> wrote:
>
> Please see my comments in [KL>].
>
> Thanks,
> Karen
>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Thursday, May 16, 2013 4:07 PM
> To: Lu HongQian Karen
> Cc: Arun Ranganathan; Mountie Lee; Richard L. Barnes; Nick Van den Bleeken;
> Aymeric Vitte; public-webcrypto@w3.org Group
> Subject: 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.
>
> [KL> There are software stack providers, key issuer (Origin A), and key
> consumer (Origin B). Most of the time, the software providers are not key
> issuers and, hence, cannot be the Origin A. Let's take your example above -
> these vendors provide the software solution stack to make the signing
> possible. The key (or certificate and key pair) issuer (Origin A) web
> application, e.g. a health organization, issues the key using the software
> solution stack to an end user. A relying party (Origin B) web application,
> e.g. e-prescription, has the document signed using the key and using the
> same software solution stack. If the software stack is the Origin A, then we
> need to redefine the same origin policy.]
>
> 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 Friday, 17 May 2013 17:19:53 UTC