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: Sat, 21 Nov 2015 21:57:57 +0000
To: public-credentials@w3.org
Message-ID: <5650E8E5.7040406@kent.ac.uk>
Hi Manu

On 21/11/2015 21:32, Manu Sporny wrote:
> On 11/21/2015 03:12 PM, David Chadwick wrote:
>> your system has some similarities to one we developed 4 years ago 
>> under the EC TAS3 project. I gave a demo and presentation at the W3C 
>> meeting in Mountain View in 2011. The slides are here
>> http://www.w3.org/2011/identity-ws/slides/Chadwick.pdf
> Hey David, very interesting - lots of similarities between what you
> presented and the design of the Identity Credentials ecosystem (and Dick
> Hardt's work from 2006).
>> The technical details are in a paper I presented at the ARES 
>> conference in 2013 (if anyone is interested).
> Yes, very interested. Got a link to the paper?

Yes you can get the paper and slides from here


>> However, things have moved on significantly since then. My latest 
>> design is based on FIDO, and it does not need IdPs anymore. IdPs 
>> morph into attribute authorities (AAs) as now they only assert user 
>> attributes (credentials) for the user. The user can authenticate 
>> himself to the SP and the AAs with his FIDO keys. Un/pws are no 
>> longer needed (unless you use the U2F model instead of UAF).
> What is an SP? Is it a relying party?

Yes (Service Provider)

> To map your terminology to this community's terminology:
> AAs -> Issuer
> SP  -> Credential Consumer
> FIDO Device -> identity vault?

Yes I guess so

>> Credentials are digitally signed by their issuers (AAs) so the trust
>>  model is the same as yours.
> +1
>> 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
Each issuer is given a unique key by the FIDO device
If you loose your device you have to start again. Like loosing your
physical wallet or credit cards it is a real pain.

>> DIDs are now the users keys with SOP.
> What happens when the user loses their key?

You cant really lose your keys since they are in the device (its like
saying what happens if you loose your chip from your credit card). You
can lose your device as noted above.

 Does their identity
> disappear as well? For example, if you tie a university degree to the
> user's key, if you lose the key, do you lose your university degree?

No you dont lose your degree, just as you dont lose your degree today if
you lose your paper certificate. You have to get a new one issued.
However, FIDO supports key rollover, so you can swap keys periodically.

>> The user stores his credentials on his FIDO device and so has full 
>> control of them.
> What happens if the user has two FIDO devices (since this is best
> practice, I expect everyone will have at least two devices)?

Then you have two authentication machines. But you can still register
both devices with your issuers and use both of them to issue the same
identity attributes. Nothing to stop that. However, the CC will not
recognise you as the same person, as you have different keys, unless it
provides a linking facility. This is a feature of FIDO today, and not
directly related to the authz mechanism.

>> I suspect this system is simpler than the one you describe below
> It is, with one potentially bad side effect - you lose your FIDO device,
> you lose your identity.

Slight correction. You dont lose your identity. You lose your short
lived credentials, and have to rebuild your identity on your new device.

It is possible that FIDO might address this as uptake increases.


> Very interested to hear how you overcame this
> pitfall.
> -- manu
Received on Saturday, 21 November 2015 21:58:04 UTC

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