Re: Solutions to the NASCAR problem?

On 11/22/2015 11:20 AM, David Chadwick wrote:
> 
> 
> 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.

It can be automated, but it still requires extra infrastructure and
implementation complexity for issuers. It raises the bar for entry into
the ecosystem as an issuer; there are obviously some issuers that will
already need to have highly-available systems for a variety of other
reasons or because of the type of credential they offer, however,
issuers that don't already have this need will now have to provide for
it (one way or another).

The Credentials CG position is that, if, once a credential holder has a
credential in their "wallet", they can present that credential to any
RP, that is ideal from an implementation and infrastructure perspective.
Using this as a starting point and then adding further guarantees of
unlinkability on top of this, where necessary, allows for a wider
spectrum of issuers in the ecosystem.

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

It's certainly true that we hope that there are sufficient regulations
in place to help protect our privacy where the technology can not. But
where we can, we should work to make the technology reduce the need for
legal enforcement.

Of course, I'm sure you agree, and it's about trade offs. But I'd rather
layer the technologies such that the most basic protocol for sharing a
credential with a consumer does not involve the issuer in that
relationship (in any way that could potentially link the user with the
consumer or increase the attack surface area). Other options that trade
off this privacy to some extent in return for, for example, binding a
bearer credential to a particular consumer, should be layered on top. I
don't think the implementation complexity rises so much to be a
deterrent with this approach.

If we wanted a more "perfect" solution, we'd invent a new form of
cryptography that allows issuers to digitally-sign credentials in a way
that can be altered (within some reasonable parameters) by the
credential holder without affecting verifiability prior to their
submission to the consumer. This would allow us to reuse credentials at
different consumers (RPs) without linkability and without communicating
with issuers when the sharing is taking place. Of course, we don't have
that yet :), but this could be easily layered on top of the Credentials
CG work should someone invent it.

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

Thank you, I'll have to check this out.

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

Understood. But one could layer the same approach you've taken top of
the Credentials CG work. The anonymizer service could receive your
previously-signed credential and the SOP key for the consumer (RP) and
strip the old identifier and resign it using only the key information.
That way the system can work in both ways, depending on the use case.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Sunday, 22 November 2015 21:34:38 UTC