Re: Privacy in Web Payments [Was: Re: Nigeria launches national electronic ID cards]

On 9/10/14 10:57 AM, Timothy Holborn wrote:
> +1
>
> Yet, I'm not sure how payments could work, without identity which
> is part of credentials isn't it?
>
> So, from what I gathered, the issues then relates to receipts?
>
> What else?

Given the ability of big data to crunch patterns and remember -- and 
of cookies to provide extra data points -- I think it relates to 
almost any data. Even if there is anonymity, or pseudo-anonymity 
(which, as an aside, I think has been well justified in the recent 
telecon as being the most basic level of real anonymity we're going to 
get, given the needs of law to track), -- even then, with 
pseudo-anonymity, it's still possible for skilled examiners to figure 
out who is who, merely by the patterns of locations, times, purchases, 
and interests -- if that data is available to be passed on (or 
monitored surreptitiously).

So, while I agree that privacy will central to the credentials work, I 
think it's closer to being evenly split between payments and credentials.

IMO this was made clear by the example demonstration in the Istanbul 
IG workshop video, in that it showed that credentials standards and 
payments standards will be used intertwined and all in one quick 
interaction, within seconds and sometimes milliseconds of each other. 
So I don't think it's going to be easy to say -- or at least, predict 
at this point -- which privacy issues relate to the credentials and 
which to the payments.

Steven



>
> Sent from my iPad
>
>> On 11 Sep 2014, at 3:19 am, Steven Rowat
>> <steven_rowat@sunshine.net> wrote:
>>
>> [The original thread was moved by Manu to Credentials, but I
>> think this aspect is more germane to Web Payments, hence the new
>> thread.]
>>
>> [I previously wrote:]
>>>> and that certain sockets are built into the payments code
>>>> that won't permit the system to function unless they are
>>>> fulfilled.
>>
>>> On 9/9/14 6:42 PM, Manu Sporny wrote: Sure, for some value of
>>> "certain sockets", "won't permit", and "fulfilled". If you have
>>> an idea of what these values are, that would be helpful. Keep
>>> in mind that it's hard to define those values w/o also making
>>> value judgments.
>>
>> True, there will be value judgments made about which ones to
>> concentrate on -- but aren't we all agreed that 'some' level of
>> privacy is important? If so, that's also a value judgment.
>>
>> I think the main point I was attempting to make, and perhaps
>> didn't express well, was that since money is fundamental to the
>> operation of the world society, then there must be some level of
>> privacy that is fundamental to the web payments standard -- as a
>> design criteria. Not all the protection of privacy should lie in
>> the 'credentials' arm, since the two things are separable.
>>
>> Or to put it another way, the most important privacy, as far as
>> governments, criminals, and corporations are concerned, is in the
>> movement of money. Therefore they will concentrate on hacking and
>> controlling that. Therefore a high degree of technological
>> security -- as high as possible -- needs to be put into assuring
>> that some fundamental privacy is respected in the movement of
>> money (as well as in other things), unless a) there's legislation
>> or a legislated court order otherwise; or b) there's opt-in by
>> the owner of the data, agreeing that they can be 'harvested'.
>>
>> Perhaps I'm mistaken about how the handshaking between the two
>> arms (payments and credentials) will work, but it seems possible
>> to me that unless the above is put in the web-payments protocol
>> itself, credentials-only safeguards will be insufficient to
>> prevent a worldwide monitoring of the payments system.
>>
>>
>>> I agree that we should make it as hard as possible to run w/o
>>> basic privacy considerations. In fact, I don't think it's
>>> difficult to meet the "basic privacy considerations" bar.
>>
>> Would these include 'who paid who how much when for what'? I'd be
>> satisfied with that. ;-)
>>
>>
>>> The design approach we've used for much of the Web Payments
>>> specs to date is assuming that we're wrong and the system will
>>> be broken, and once it's broken, it should be easy to replace
>>> the broken bits with working bits w/o much effort. For example,
>>> the graph normalization and digital signature algorithm we use
>>> is designed to be replaced overnight if there is a security
>>> compromise, and we specifically did that because we made the
>>> assumption that people with more resources than we have will
>>> find a way to break it.
>>
>> +1
>>
>>
>> Steven Rowat
>>
>

Received on Thursday, 11 September 2014 04:18:50 UTC