- 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
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. >[snip] > I'm not arguing against non-correlation. It's an important requirement. > Correlatability is an important requirement as well. >[snip] > 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 stage. For example, if we apply this to the Pseudo-anonymity use case in the Editor's Draft June 11 VC use cases, http://w3c.github.io/webpayments-ig/VCTF/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'. :-) Steven
Received on Saturday, 11 June 2016 23:32:20 UTC