W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2013

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

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 17 May 2013 10:35:06 -0700
Message-ID: <CACvaWvZoW3vhMpRgevnnnBG0qcvA7hSOFNgp6MHQ+3zxHhohVg@mail.gmail.com>
To: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
Cc: Lu HongQian Karen <karen.lu@gemalto.com>, Arun Ranganathan <arun@mozilla.com>, Mountie Lee <mountie@paygate.net>, "Richard L. Barnes" <rbarnes@bbn.com>, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, Aymeric Vitte <vitteaymeric@gmail.com>, "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
Root X = Origin C

In at least one possible implementation, Origin B discovers Origin A
through communicating with Origin C.

This is the introducer model you can see through Persona.

There are likely other ways to do this as well (e.g: the past
discussions of Intents or other forms of service discovery).

Mapping back to the identity space, this is the general 'problem' of
discovering which identity providers a user supports. And there are a
variety of ways to do so.

On Fri, May 17, 2013 at 10:31 AM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com> wrote:
> Just to keep taking the PKI example, what I have in mind is this use case
>
> Origin B trusts a certain root  Root X.
>
> Root X lets Origin A to be an intermediate CA.
>
> Origin A issues a certificate to user.
>
> Origin B does not know that Origin A is a CA under Root X.
>
> --Seetharama
>
> On 5/17/13 11:23 AM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
> But Origin B will only accept certificates from a known set of trusted
> roots.
>
> In this case, Origin A is the Trusted Root.
>
> That's not to say that Origin A cannot delegate/establish
> functionality - where through delegation of responsibility or via PKI
> - just trying to explain that the conceptual mapping is the same. That
> is, you trust Origin A.
>
> To further the parallel, and thinking that Origin B may trust multiple
> trust anchors, you can still have Origin B supporting multiple
> different groups (beyond Origin A).
>
> You can accomplish this via a trusted introducer/mediator - in the PKI
> model, this is your "Trusted Root Program" from your vendor or
> government - or you can do other forms of service discovery.
>
> That's not to say the set of problems posed by PKI are not
> interesting, and that there may still be some use cases unaddressed
> with the multi-origin model, but if we're looking at where the gaps
> are, and whether we're "10% there" or "90% there", I think you'd find
> we're far closer to the 90% than the 10%.
>
> To find out what's *missing* is the challenge, and so far the use
> cases haven't been reduced enough to find that out - that is, the
> things people think are missing are already seemingly addressed. Hence
> these e-mails trying to dig through the use cases :)
>
> On Fri, May 17, 2013 at 8:18 AM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
>
> One other point I wanted to add to the 'set of other origins' - if you look
> at it, PKI solved this problem with roots of trust. And implementations
> generally understand that. So, for example, Origin B could accept any key
> issued by an authority that is anywhere in the chain.
>
> On 5/17/13 9: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.
>
> 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.
>
> 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:35:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:17 UTC