Re: BBC input

On 21 Jul 2011, at 12:01, Anders Rundgren wrote:

> Here you lost me.  The point with a CA is that you trust it.
> In this case I don't see what you are trusting since anybody can create a key-pair.

Correct. You don't _trust_ anybody on the basis of identification alone. This is exactly the model used in the real world, and indeed the model used by the _vast_ majority of web properties in existence today.

Real-world assurance doesn't work on the basis that “who I am” is inherently trustable, it works on the basis of me providing documentation that links who I am with credentials conferred upon me by trusted organisations (universities, banks, governments, etc.). The ID badge attached to the lanyard around my neck isn't really an identification document — rather, it's an assurance document which links assertions (“I work for the BBC”) with my identity (by way of a photograph and my name). As a large corporation, the BBC has various “employee deals” which means that there are a whole range of not-necessarily-obvious scenarios beyond basic building access where it's useful to present this “assurance document”, including — for example — when I'm buying Sushi in the Westfield shopping centre in London W12.

The vast majority of websites don't require any assurance information whatsoever. Those which do will require specific pieces of (often time-boxed) information whose release should be carefully controlled by the user.

Now, you -can- achieve a reasonable parallel to the real-world approach by having lots of separate sets of credentials each from various issuers (some self-selected, some conferred), and allowing submission of multiple credentials at a time, but this is just a crutch for tying together identification and assurance in a manner which isn't especially granular. If you think of it as a spectrum, with “no assurance needed” at one end, and “lots of assurance needed” at the other, with all of the combinations of presentation of assurance documents along the way, it starts to look an awful lot like a database table in need of some normalisation.

The point here is not merely to solve “access to government services on the Web” or “access to banking on the Web”, but to get rid of classical authentication *entirely*, and to do that requires a foundation flexible enough to run the gamut of identity requirements as they exist now, from just identification, all the way up to heavyweight assurance.

> I did never see anything particularly wrong with CardSpace and U-Prove.
> It was really the lack of a matching PKI and token solution that killed
> these efforts.  Well, they will come back some day, be assured of that :-)

Partly, and to an extent it (CardSpace in particular) was ahead of its time.

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 Thursday, 21 July 2011 11:19:07 UTC