W3C home > Mailing lists > Public > public-credentials@w3.org > September 2014

Re: Nigeria launches national electronic ID cards

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 09 Sep 2014 21:42:16 -0400
Message-ID: <540FAC78.9050807@digitalbazaar.com>
To: Steven Rowat <steven_rowat@sunshine.net>, Credentials Community Group <public-credentials@w3.org>
Moving discussion to Credentials CG, bcc: Web Payments. Start of thread
is here:


On 09/02/2014 05:23 PM, Steven Rowat wrote:
>> I wish, but it really isn't going to be that straight forward.
>> What the W3C MUST do is devise open standards that do not
>> compromise the privacy of Web users. Anything less defeats its
>> mission.
> +1 to Kingsley.
> Manu, what you appear to be saying is that it's possible to make a 
> financial standard that's fully separate from privacy issues, and
> each government will choose how private the users can be in their
> country.

That's not quite what I'm trying to say, and I apologize for the
confusion. What I'm saying is that even if we do an excellent job at
building a privacy-protecting standard, legislation can corrupt that
standard quite easily. Privacy isn't as simple as building a technology.

For example, many touted Bitcoin for its anonymity in the beginning only
to find out that it's not anonymous at all. Many believe that Tor allows
you to be anonymous online, but there are a number of attacks that
enable your privacy to be violated in a number of terrible ways that
don't require large resources.

Security and privacy are not easy to solve, there are always trade-offs.
We are trying to build something that is very secure and privacy-aware,
but it's also important to understand the sorts of things that we can't
protect against such as legislative actions, massive government
resources thrown at an individual, etc.

> Like Kingsley, I believe history (long past and recent past) teaches
> that privacy needs to be baked at a technologically advanced level
> into any ubiquitous system. This will force the governments (and
> corporations, and criminals) to jump through hoops to get at the data
> -- valid ones, involving courts, or non-valid ones, involving
> difficult cyberhacking. Doing the reverse will probably precipitate a
> free-for-all. Trusting governments (or anyone) to avoid 'the easy
> way' of getting the data doesn't seem rational.

+1, completely agree.

My point is that even if we do all that, we shouldn't pretend as if the
system is impenetrable. There are many ways to get around technological
measures, such as the rubber hose attack.

> It might seem that this issue is more central to the new Identity
> web group, but IMO it crosses over in interesting ways. Perhaps it's
> true that the web payments group isn't the place now for a secure
> privacy technology to be developed -- but it seems to me a  necessary
> condition of the web payments code development that such a technology
> is required to be developed *somewhere*


> and that certain sockets are built into the payments code that won't
> permit the system to function unless they are fulfilled.

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.

> In other words, if the web payments group facilitates a new
> efficient world financial system that can easily be manipulated to
> run without basic privacy considerations -- by one large government
> or a coalition of governments -- this might very well be an
> invitation to making "the Web our nightmare" as Kingsley put it.

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. My concern is with reaching and
maintaining the higher bar of "strong privacy protection".

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.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
Received on Wednesday, 10 September 2014 01:42:48 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:38 UTC