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

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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*