Re: Privacy (was: "")

Hi Francisco,

On 23 Jul 2011, at 19:58, Francisco Corella wrote:

> This has a privacy drawback.  When the user presents one of the
> "shorter-lifetime certificates" to a relying party, the user also
> sends the "self-asserted CA cert" with the "issuer pubkey".  So the
> relying party learns "the real identity of the user".

Yup, you're entirely right — although I will contend that there are applications where a persistent cross-RP identity is desirable. I need to read up fully on Idemix to understand how it can fit into the picture. I don't think it's an binary choice thing, though.

I believe there are three sets of problems which are in effect separate, but are of course related:

1. An improvement on the username/password (or typically, e-mail address and password) combination

2. Avoiding privacy leakage where desirable (such as in the medical insurance case you've described)

3. Authentication schemes strong enough for, e.g., banks

The status quo is clearly unacceptable on all counts; replayable credentials are trivially phished on a daily basis, and organisations which really do need strong crypto-based identification prefer to roll out their own stacks than use what exists in the browser today.

My focus *right now* is therefore on sketching out a framework upon which at least some progress can be made — improving the usability and workflow around self-signed certs for identification helps to eliminate usernames and passwords in a decentralised way, and wouldn't — I hope — preclude the use of non-/less-leaky credentials in some applications.

My view is that these usability issues are a serious stumbling-block with relatively little attention being paid to them by many smart people; it's great that privacy issues around generic PKI-based credentials are being researched and (hopefully) resolved, but it doesn't advance the state of play very much if nobody's gets as far as using them…

On the third point, this has proved to be pretty territory-specific. Banks in the UK, for example, don't bother with any of it and instead mandate 2FA with a completely standalone smartcard reader doing challenge/response (which, of course, avoids issues in PKI-land with the continual pull in opposite directions between private key storage policies and the need for flexibility).

M.

-- 
Mo McRoberts - Data Analyst - Digital Public Space,
Zone 1.08, BBC Scotland, 40 Pacific Drive, Glasgow G51 1DA,
Room 7066, BBC Television Centre, London W12 7RJ,
0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Friday, 29 July 2011 16:05:46 UTC