in the mid-90s the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the resulting protocol was x9.59 which we claimed was privacy agnostic
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

a transaction had account number and was digitally signed ... and provided for end-to-end authentication and integrity. to the extent there might be a binding between an account number and an identity ... was outside the x9.59 protocol.

part of this was the realization by numerous institutions in the mid-90s that the x.509 "identity" certificates represented enormous privacy and liability exposures. this led to some of the abortions that attempted to preserve the x.509 infrastructures but eliminating most identity features ... at the time, periodically referred to as relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

and we were repeatedly able to show that such relying-party-only certificates were redundant and superfluous.

the theme about end-to-end authentication and integrity was also somewhat the theme of the naked transaction threads here:
https://financialcryptography.com/mt/archives/000744.html
https://financialcryptography.com/mt/archives/000745.html
https://financialcryptography.com/mt/archives/000747.html
https://financialcryptography.com/mt/archives/000749.html

a lot of SSL use has been hiding transactions during internet transit ... not so much for privacy purposes but for integrity purposes and fraud prevention. however, that left the transactions exposed at thousands of other points. this is somewhat my old post about security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

for instance, lots of the data breaches in the news involves attackers being able to use the exposed information for fraudulent transactions. Neither SSL or x9.59 addresses such data breaches. however, x9.59 eliminates the possibility that the attackers can use the acquired information for generating fraudulent transactions

from the perspective of the x9a10 working group effort ... a lot of the other activities from the period had extremely poorly defined threat models and even less linkage between their possible efforts and exactly how such efforts represented specific countermeasures for specific threats.

recent posting in another fora related to some SSL use:
http://www.garlic.com/~lynn/aadsm25.htm#17 Hamiltonian path as protection against DOS
http://www.garlic.com/~lynn/aadsm25.htm#19 Hamiltonian path as protection against DOS

for other drift ... we had been called in to help word smith the cal. state electronic signature legislation (and later federal electronic signature legislation)
http://www.garlic.com/~lynn/subpubkey.html#signature

one of the participating industry organizations was also involved in various privacy regulation and legislation efforts. they had done a survey regarding the primary driving factors behind privacy regulations and legislation and found
them to be

1) identity theft
2) denial-of-service (by institutions to individuals)

more recently there has been efforts by various organizations to further clarify identity theft ... into

* account fraud (using stolen information to perform fraudulent transactions against existing accounts

* Identity fraud (using stolen information to open new accounts in the name of the victim)

a large portion of the data breaches involve the "account fraud" flavor of identity theft.

as mention in the previous comment
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question

x9.59 doesn't have countermeasure for data breaches ... again the old posting about security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

however x9.59 does have countermeasure against account fraud ... i.e. being able to use the information from data breaches (or other mechanisms) as part of performing fraudulent transactions against existing accounts.

and for other privacy drift ... i was co-author for the financial industry x9.99 PIA privacy standard ... and as part of that did work on a merged privacy taxonomy and glossary
http://www.garlic.com/~lynn/index.html#glosnote

which includes sources from EUDPD, FTC, GLBA, HIPAA, OECD and OMB.

Ironically, a few of the blogs discussing anonymity do not permit anonymous or even plausibly efficient psuedonymous commentary. So much for that.

One comment-shy blog, "Ruminations on Identity" mentioned "Eric Norlin" on another comment-shy blog saying:

http://bderidder.wordpress.com/2006/08/15/do-you-really-think-you-are-anonymous/
http://blogs.zdnet.com/digitalID/?p=61

"All of that nasty, real-world talk aside — the question now becomes: Should the online world reflect the real-world, or not?"

Of course not, and here's why: anonymity is not a principle, it is a design, based on the physics and economics of the environment. Anonymity strictly means you can write something on a piece of paper and not leave any identifying marks. That is, consider pamphlets distributed on some political issue. We can relatively easily create "anonymity" by distributing pamphlets with no author's name on them, thus ensuring that there is obscured relationship between the pamphlet and the person who expressed the opinion.

Trying to do that on the net is hard -- very hard. Better to align ones designs with the capabilities of the net. In further contrasting example, when David Chaum was trying to create digital cash, what he did was to try and duplicate the untraceability of coins as they moved from hand to hand. The result was elegant, one of the most interesting designs of modern cryptography, but mostly impractical, because it fought against the net's natural topography.

The same goes with anonymity. Far better to think in terms of psuedonymity, which is not anonymity as it allows linking between different actions.

Hello Ian,

CardSpace allows for the exact same "pseudonymity" as AADS and Ricardo: nothing more than a smoke-and-mirrors version of genuine pseudonymity. In fact, the approach is the stereotypical "trivial" approach that scientists use to explain why getting genuine strong pseudonymity is a hard problem:-). With the smoke-and-mirrors approach, the link between issuance and presentation of "tokens" is not broken; as a result, issuers can track and link all of a user's actions by simply comparing notes with relying parties (unless issuers do not know the users themselves to whom they issue "pseuudonyms", but then there is no or at best very little security benefit in having issuers - unless one solves the problem of having genuine strong pseudonymity!). As such, the "trivial" attempts provide no more "pseudonymity" than third-party cookies do - in fact, they are worse because the identifiers (crypto keys) that can be used to trace and link all "pseudonymous" actions are universally unique. Saying that the approach provides pseudonymity is the same as saying that having a central party assign a random alias to the author of a book suffices to make the author pseudonymous - that only holds if the assigner is in essence an agent of the book author that is fully trusted by the book author (in essence, the case of self-assignment).

Chaum's original proposals, in contrast, and improved proposals in the spirit of his breakthrough work (such as Credentica's Digital Credentials and IBM's IDEMIX), DO provide for genuine strong pseudonymity. A pseudonymous transaction is accomplished by simply reusing the same untraceable token. Anonymity occurs when pseudonymity is avoided by showing the same token no more than once (or, in IDEMIX, proving knowledge of ALL of its cryptographic data constituents using a "zero-knowledge" proof of knowledge).

- Stefan

Stefan, Thanks for the comment. I'll have to read it carefully to find something to disagree with ;-)

But, yes, I do agree that CardSpace allows for the basic form(s) of psuedonymity. In a sense I'm hoping that if we can keep poking Microsoft on this point, they'll leave that opportunity open, leaving some room for further developments and to save their own bacon when their preferred path collapses.

What then is "genuine" strong psuedonymity? Psuedonymity always outsources the problem of tracking, which is another way of saying it is definately possible. (Psuedonymity is a half measure if your goal is privacy and nothing else, but a full measure if your goal is robustness.)

Can something do better than that?