Re: Use case: Authenticate using eID

On Thu, Apr 25, 2013 at 11:51 AM, Ryan Sleevi <sleevi@google.com> wrote:

> On Wed, Apr 24, 2013 at 9:44 AM, Nick Van den Bleeken
> <Nick.Van.den.Bleeken@inventivegroup.com> wrote:
> > Get access to government applications that require authentication based
> on your real identity using your eID card (e.g.: to fill in taxes, retrieve
> birth certificate, ...). Including the option to sign out.
> >
> > Requirements:
> > * Identify an appropriate key (issued by the government) -> query
> facility
> > * Export the certificate, including its certificate chain (the website
> has to validate that the public key was issued by the government)
> > * Use the private key to perform basic cryptographic operations
> >
> > Kind regards,
> >
> > Nick Van den Bleeken
> > R&D Manager
> >
> > Phone: +32 3 425 41 02
> > Office fax: +32 3 821 01 71
> > nick.van.den.bleeken@inventivegroup.com
> > www.inventivedesigners.com
> >
> > ________________________________
> >
> > Inventive Designers' Email Disclaimer:
> > http://www.inventivedesigners.com/email-disclaimer
> >
>
> As a clarification/qualification of your use case, as discussed as the
> F2F but ideally to be recorded on the list
>
> Your use case requires this functionality be available to any
> arbitrary web application, correct? That is, there's no specific list
> of origins that should have access (as new services may be started
> up), nor is there any other element that limits this access (eg: only
> allowing access to keys/certificates issued by CA Foo if the server's
> certificate was ALSO issued by CA Foo)
>

I see three issues which have to be solved to enable this use-case.

The first is a privacy issue. The same key is going to be used by multiple
origins (assuming the user approves). So this is effectively a supercookie
which could be used for tracking across origins.

The second is that it is a long way between the API offered by the UA and
the standards for the eID card of a given country. We need to decide how to
bridge this gap and who is going to write which parts of the necessary
specifications. For example, suppose, for this use-case, we introduced
named multi-origin pre-provisioned keys and we equipped them with a
"certificatechain" attribute. To make this work, someone needs to specify
what the name should be for a given kind of eID card. Because the names are
not scoped by origin (as they are for the origin-specific keys), we'd need
a global namespace of some kind. They need to specify exactly how the key
or keys on the card are mapped to the WebCrypto Key object and exactly how
the certificate chain is mapped to the attribute. And on the WebCrypto
side, we'd need to be sure that the generic capability we provide is
suitable for all applications of this kind.

The third issue is whether this really gives you what you want ? As a
service receiving a document signed with one of these keys, what do I know
? I know that some JS was running on a machine with access to the card and
that this JS was approved by the user to make use of the key. Unless I have
certain knowledge of what JS is running, I can't know what the user saw
when they hit the approve key. Did they actually see the document that was
to be signed, or did they see a different one ? Possibly you need more than
just a signature over arbitrary bytes, but you also want the UA to provided
the name of the origin doing the signing and the certificate chain used to
validate this, all signed with this key as well (ekr suggested something
like this at our last meeting - a "signWithOrigin()" method).

...Mark