Re: Solutions to the NASCAR problem?

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

This can be automated by an intelligent agent running on the users
device that receives the consumers authz policy, matches it to the
issuers the user has registered with, then asks the user which of his
matching credentials he wants to use. The analogy is going shopping,
seeing the shops policy in its window (stickers of which credit cards it
accepts) then the user choosing which one to pay with.


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.

I have not considered tracking cookies, but an issuer and consumer could
collude by matching SOP keys. I think this should be illegal under
current data protection legislation, unless the user says he is happy
for consumers to do this.


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


This sounds like a system I devised back in 2008/9, which I called
FileSpace and presented at NIST. Here a user simply browsers his local
directory and uploads files to the consumer. Each file is a digitally
signed credential attached to a pseudonym the user invents.

“FileSpace - An Alternative to CardSpace that supports Multiple Token
Authorisation and Portability Between Devices”. Proc. 8th Symposium on
Identity and Trust on the Internet, NIST, Gaithersberg, April 2009.
pp94-102. Available from
http://middleware.internet2.edu/idtrust/2009/papers/08-chadwick-filespace.pdf


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

But in my model they are not bearer credentials since you can prove
ownership via your FIDO key

regards

David
>

Received on Sunday, 22 November 2015 16:20:56 UTC