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 10:25:15 -0500
To: David Chadwick <d.w.chadwick@kent.ac.uk>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
Message-ID: <5651DE5B.4060306@digitalbazaar.com>
On 11/22/2015 08:41 AM, David Chadwick wrote:
> Hi Dave
> On 22/11/2015 01:28, Dave Longley wrote:
>> On 11/21/2015 03:12 PM, David Chadwick wrote:
>>> Hi Dave
>>> 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
>>> The technical details are in a paper I presented at the ARES 
>>> conference in 2013 (if anyone is interested). The system was 
>>> based on SAML assertions which were aggregated from multiple 
>>> authorities. The protocol however is not that important as 
>>> subsequently I designed an alternative based on UMA. It is the 
>>> concepts and models that are more important.
>>> 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).
>>> Credentials are digitally signed by their issuers (AAs) so the 
>>> trust model is the same as yours.
>>> No discovery of IdPs or AAs is needed, as AAs are recorded in the
>>> FIDO metadata.
>> Thank you for the slides. The system you describe is very similar 
>> to the Credentials CG work. One minor point of confusion is around 
>> what IdPs represent in the Credentials CG work. They are not like 
>> IdPs in SAML, where they essentially double as what we refer to as 
>> issuers. IdPs do not make assertions nor do they necessarily do
>> any direct communication with consumers (SPs) or issuers (AA).
>> Issuers make the assertions and IdPs simply aggregate them. They 
>> are more like "Identity Agents". Another key difference from the 
>> SAML or OpenID Connect architecture is that this new architecture 
>> does not require users that share credentials to reveal the 
>> identity of the consumer to their IdP (agent) or to issuers.
> Thanks for the clarification. And I agree that the non-reveal 
> property is an important feature.
>> As you stated in another mail, we should be more clear about 
>> definitions in the Verifiable Claims proposal as well.
>> You can think of Credential CG IdPs as playing the same role that
>> a FIDO device plays in your system, but they are expected to be 
>> implemented as services. I see no reason why they can't also be 
>> implemented as a device (or a service on a device), however, there 
>> are problems with that approach, the most glaring one being that 
>> people lose their devices.
>>> DIDs are now the users keys with SOP.
>>> The user stores his credentials on his FIDO device and so has 
>>> full control of them.
>>> I suspect this system is simpler than the one you describe below
>> The two systems sound very similar in architecture, probably more 
>> than you could have known prior to the IdP clarification.
>> Again, the main difference is that we recommend that an IdP be 
>> implemented as a Web service, though, it could be on a device. 
>> Implemented as a Web service, however, to which the user can 
>> authenticate with a FIDO device, is a better option, in my view. It
>> helps users cope with the fact that many of them, will at some 
>> point or another, lose their device. Having to revisit all of the 
>> issuers (AAs) you received credentials from because you lost your 
>> device is painful and may even be extremely difficult in some 
>> cases.
> But if I can only authenticate to my IdP from my FIDO device, and I 
> lose my FIDO device, then I am in a similar situation as in my model.
> Admittedly I only need to prove who I am to one entity (the IDP)
> rather than multiple ones (the issuers), but in the real world this
> is handled today by companies, TTPs, who will contact all your credit
> card and other issuers for you, and get you a new set of credentials.
> So this TTP could be an additional optional web service in my model
> which would then make the two models equal in terms of loss of FIDO
> device.

It would be better to only have to get access to your IdP vs. having to
go out and retrieve all of your credentials again. You could also use a
mechanism to add more than one FIDO device to authenticate with your IdP
or use additional alternative authentication mechanisms. Adding an
additional/backup FIDO device wouldn't require visiting all of your
issuers to get your credentials tied to the new device; you'd only have
to undergo a linking process to tie it to the same identity at your IdP.

We have another layer (the WebDHT) that lets you specify public keys
that give you access to one of your identities. In the design, we also
want to add the ability for users to specify other keys or identities
that can vouch for you. Provided that you can obtain M of N signatures
from those other parties, you can add a new key to get access to your
identity again if you had lost it. We're trying to make it as painless
as possible, yet still secure, for people to use these systems.

IdPs can use this layer to authenticate users in the same way users use
it to authenticate with issuers and consumers.

Dave Longley
Digital Bazaar, Inc.
Received on Sunday, 22 November 2015 15:25:42 UTC

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