Re: Solutions to the NASCAR problem?

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

No not for issuers as they never see the consumers policy (think shop
window. Visa never see these). The extra work is in the GUI software,
thats all (aka users brain).

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.

How are your credentials revoked?
If you can use the same credential for multiple consumers, then how can
you have unlinkability?

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

I agree. Technological enforcement is better where ever possible. But
some things are impossible, such as user privacy and the right of the
consumer to notify the issuer about an abusive user.

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

If you cannot link the user with the consumer then you cannot prevent
abusive users.

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

It depends on which you see as being more important. In my case, I am
leveraging the strong authn of FIDO with a similarly strong authz
mechanism. So my target audience is higher value transactions. I see no
point in having weak authn with strong authz or vice versa. I see bearer
credentials as being weak authz.


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

Then you are making the anonymiser a super trusted third party and a
central point of failure. So why not distribute this functionality, and
give a bit of it back to each issuer. Voila, you have my model :-)

David

> 

Received on Monday, 23 November 2015 19:58:17 UTC