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 11:00:24 -0500
To: public-credentials@w3.org
Message-ID: <5651E698.5050709@digitalbazaar.com>
On 11/22/2015 08:58 AM, David Chadwick wrote:
> 
> 
> On 22/11/2015 05:19, Anders Rundgren wrote:
>> On 2015-11-21 22:57, David Chadwick wrote:
>>> On 21/11/2015 21:32, Manu Sporny wrote:
>> 
>> <snip>
>> 
>>>>> No discovery of IdPs or AAs is needed, as AAs are recorded
>>>>> in the FIDO metadata.
>>>> 
>>>> I'd be interested to understand how this works with multiple 
>>>> FIDO devices. What happens when you lose a FIDO device? What 
>>>> does the AA set as the subject of the attribute assertion (how 
>>>> does it identify the user that the attribute belongs to)?
>>> 
>>> The user is identified by the SOP key associated with the Issuer
>> 
>> This is the core part from the NASCAR perspective. As far as I 
>> understand this information is currently not available to SPs.
>> 
> 
> Sorry my answer was ambiguous/unclear. The user is identified to the
>  Issuer by the SOP key associated with the issuer. The user is 
> identified to the consumer by the SOP key associated with the 
> consumer. The user sends the consumer SOP public key to the issuer 
> and the issuer assigns the attribute to that. The issuer has no idea 
> who the consumer is since this key is unique to the user. But the 
> consumer knows the user possesses the attribute since the assertion 
> is signed by the issuer, and the attribute is attached to its SOP 
> key.

In this system, the user doesn't have to manage their own identifiers,
but unfortunately, this has the side effect of requiring users to get a
new credential for every consumer. I haven't put much thought into other
considerations like how a tracking cookie could be used to reduce the
privacy protections or what it means for the issuer to know the SOP key
to another site.

We took a different trade off in the Credentials CG work. Users can
create as many identifiers as they want to and then choose which one
to authenticate with at an issuer. The issuer will then associate new
credentials with that identifier. Each identifier can refer to a
different identity/aspect of the user. It is then up to the user to
decide how to aggregate credentials by deciding which ones to attach to
different identifiers. This is more work for the user, but it seems to
have a fairly natural mapping to how we use identity in the world today.

We do have designs in the system to increase unlinkability that would be
very similar to the system you describe. Essentially, you can trade a
credential previously issued to one of your identifiers for a very
short-lived bearer credential from the issuer or from a trusted
"anonymizer service". This can be done without revealing any information
about the consumer.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Sunday, 22 November 2015 16:00:49 UTC

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