W3C home > Mailing lists > Public > public-credentials@w3.org > November 2015

Re: Solutions to the NASCAR problem?

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Sun, 22 Nov 2015 17:03:02 -0500
To: David Chadwick <d.w.chadwick@kent.ac.uk>, Anders Rundgren <anders.rundgren.net@gmail.com>, public-credentials@w3.org
Message-ID: <56523B96.10902@digitalbazaar.com>
On 11/22/2015 12:53 PM, David Chadwick wrote:
> On 22/11/2015 16:33, Anders Rundgren wrote:
>> On 2015-11-22 17:10, David Chadwick wrote:
>>> Hi Anders
>> Hi David,
>> <snip>
>>>>> The user sends the consumer SOP public key to the issuer and 
>>>>> the issuer assigns the attribute to that.
>>>> I think you lost me here, at least with respect to the NASCAR 
>>>> problem.
>>> This is because the user does not go to any third party to 
>>> authenticate to a site. A new key pair is generated for the
>>> site, and this authenticates the user each time he calls. Note
>>> however that FIDO does not provide any identity or authz
>>> information, just an authn key, which is why we need to add this
>>> functionality using issuers.
>> It is this sending of the consumer public key to issuer by the
>> user which I don't quite understand :(
> The user can prove possession of all the public keys his device has 
> issued. This is how he authenticates. The consumer only knows it is 
> the user at the other end of the connection because a challenge from 
> the consumer was signed by the private key corresponding to the 
> user's consumer public key.
> Now if the consumer receives an attribute signed by an issuer, it 
> proves that the issuer issued it, but not who it belongs it. By
> using the consumer public key as the ID of the user, the consumer now
> knows that the user it has authenticated is the righful owner of the
>  attributes.

This makes perfect sense to me, though I'm not sure if there are any
restrictions in the current/prospective APIs or FIDO designs for sharing
one origin's key with another origin.

I mainly worry about the fact that you're sharing how you identify with
every consumer out there with the issuer (and that issuers need to
provide highly-available services to ensure you can give them this
information in exchange for a credential).

I understand that additional tracking information is required for an
issuer to link the opaque identifier they are given to the consumer, but
I'm uneasy about increasing the attack surface area in this way *for
every credential exchange*. As I said in another mail, I'd rather see
this option layered on top of a less intrusive core sharing protocol.

I do think there are some very valuable ideas here that we could
integrate and layer on top of the work we've been doing in the
Credentials CG and I'm happy you're sharing this information with us!

Dave Longley
Digital Bazaar, Inc.
Received on Sunday, 22 November 2015 22:03:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:26 UTC