Re: Use case: Authenticate using eID

Hi.
I found the differences between origin-specific key and key for cross
origin use.

it is quite philosophical.

the people who have experience to use certificate, key pair is belong to
people's not belong to service provider.
the owner is able to decide "my key" can be used on any sites.

but if the key is binded into specific origin, means originA has the
ownership of "the key provided by origin A".

the approach is very different.

I agree that just public-private key pair can be belong to specific origin
and the origin will have control for the key.
but
with certificate-private key combination, users normally will think "my
Key".

this is the Gap.

regards
mountie.

On Thu, Apr 25, 2013 at 1:49 PM, Mark Watson <watsonm@netflix.com> wrote:

>
>
> 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
>



-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World