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
https://docs.google.com/presentation/d/1_j6EYJZT_iT0LyLe_ErUS-Zxo6W93fmkqq1lhvnNqMM/edit#slide=id.g89af9b99f_0_0


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

regards

David
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