Re: Solutions to the NASCAR problem?

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

If you have two FIDO devices then you might as well register then both
with your issuers, then you have two ways of authenticating to them and
getting credentials.
It would be good if FIDO could add a mechanism for linking devices
(keys) together as part of its specifications, so that two or more keys
can be registered to the same account. I dont know if they have
considered this or not. I can ask.

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

Understood. I think that usability functions like the above will grow as
user demand for them grows.
There is a balance to be struck between making the initial system all
singing and dancing, but too complex for implementors to want to bother
implementing it.

regards

David


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

Received on Sunday, 22 November 2015 16:28:57 UTC