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

Re: Solutions to the NASCAR problem?

From: David Chadwick <d.w.chadwick@kent.ac.uk>
Date: Mon, 23 Nov 2015 19:40:02 +0000
To: Dave Longley <dlongley@digitalbazaar.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, public-credentials@w3.org
Message-ID: <56536B92.7020603@kent.ac.uk>

On 22/11/2015 22:03, Dave Longley wrote:
> 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.

There are restrictions on the private key, but not distribution of the
public key AFAIK. See for example

Jeff Hodges. “FIDO and Federation in << 10 Minutes”. Available from

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

The issuer has no idea who the consumers are. It is not told. There is
no audience restriction in the credential. Issuers have two choices:
long lived or short lived credentials, with the pros and cons of each
one. I will leave it up to others to decide which they prefer.

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

You have to consider user abuse as well. In this case the consumer needs
to tell the issuer (indirectly) who the user was. So using a public key
for this is no different to the SAML persistent id.

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

Happy to, because I would like to find out all the weaknesses before the
proof of concept implementation is completed (which it should be by
March 2016).


Received on Monday, 23 November 2015 19:40:06 UTC

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