W3C home > Mailing lists > Public > public-credentials@w3.org > June 2016

Re: Non-correlation / pseudo-anonymity (was Re: VOTE: Verifiable Claims Terminology)

From: Steven Rowat <steven_rowat@sunshine.net>
Date: Sat, 11 Jun 2016 16:31:54 -0700
To: Manu Sporny <msporny@digitalbazaar.com>, public-credentials@w3.org
Message-ID: <524688eb-aa54-262f-f961-cd8c90cbecf5@sunshine.net>
On 6/11/16 9:46 AM, Manu Sporny wrote:
> On 06/11/2016 07:27 AM, David Chadwick wrote:
>> By using a common ID for two different identity profiles we produce
>> a correlation handle for the relying parties.
> Yes, correlation handles are REQUIRED for a number of use cases.
> Pseudo-anonymity is REQUIRED for others. We need both.
> I'm not arguing against non-correlation. It's an important requirement.
> Correlatability is an important requirement as well.
> I'm strongly asserting that anyone claiming that they have a solution
> that actually provides non-correlatability in non-trivial use cases has
> either not thought deeply about the problem or is selling snake oil.

Granted it's a difficult problem...

I've thought of a way to break part of it down, that might help 
towards a step-by-step solution, which is that pseudo-anonymity and 
pseudonymity are distinctly different things, and are required at 
different levels of the problem, at different steps in the credentials 
flow, and also subject to different regulatory needs.

Manu, you may may know all this, but since you've renamed this thread 
to include pseudo-anonymity, but not pseudonymity, I'm not sure of 
that. And besides, laying out the reasoning will help me understand, 
even if no-one else needs it.  ;-)

So: from the common usages of the words, a Pseudonym is an alias -- 
John wants to be called Alfred. Whereas: Pseudo-anonymity is a 
function that can be carried out without observers of the function 
knowing who initiated it: somebody came in and bought something and 
didn't tell you who they were (they might have been Alfred, or John, 
or somebody else. It's an anonymous interaction.)

And I believe this breaks down to two different places in the 
credential flow as follows:

A. Pseudonymity (Alias) occurs at the issuer stage.
B. Pseudo-anonymity occurs at the Acceptor/Relaying Party/Checkpoint 

For example, if we apply this to the Pseudo-anonymity use case in the 
Editor's Draft June 11 VC use cases,

section 4.4.3, Pseudo-anonymity, and take the last example, of Paula:

"...Paula has been certified as an aid worker, and wishes that 
information to be marked on her posts. She shares her certificate with 
the forum, but limits it to only verifying that she is the holder of 
the certificate, that she is the subject of it, and that she is an aid 
worker. In this way she maintains her anonymity..."

This is scenario B, where at the Relaying Party stage of the 
credential, Paula's name and other important data is withheld so as 
not to identity her.

Now, suppose Paula decides to write a book about her experiences, and 
she is in danger of being killed if she tells the truth. She decides 
to write the book anyway, call herself Norman, and publish it and have 
"Norman" be paid for any sales.

This is scenario A, Pseudonymity (Alias), and occurs at the issuer 
stage of the credential.

In Alias, scenario A, a government wanting to figure out if Norman and 
Paula are the same person could do so, via the issuer. They will not 
care particularly about scenario B.

Thus Pseudonymity (Alias) and Pseudo-anonymity are substantially 
different situations, and will require different levels of security 
and different interfaces with the holder, the government, and the 
credentials issuers and Relaying Parties.

Does this make sense?

If so, then it seems that only scenario B is covered in the VC use cases.

If this is so, I suggest that scenario A, Alias (Pseudonymity), is 
just as important in a social and even financial sense, and should be 
pursued in parallel with Pseudo-anonymity.

Only, if that happens, to simplify things a little, maybe we could 
just call it 'Alias'.  :-)

Received on Saturday, 11 June 2016 23:32:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:53 UTC