- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 24 Oct 2012 10:03:09 -0400
- To: nathan@webr3.org
- CC: Robin Wilton <wilton@isoc.org>, Ben Laurie <benl@google.com>, Ben Laurie <ben@links.org>, Halpin Harry <H.halplin@ed.ac.uk>, public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" <public-privacy@w3.org>, public-webid@w3.org
- Message-ID: <5087F51D.3040503@openlinksw.com>
On 10/24/12 8:03 AM, Nathan wrote: > Robin Wilton wrote: >> >> >> >> >> >> Robin Wilton >> Technical Outreach Director - Identity and Privacy >> Internet Society >> >> email: wilton@isoc.org >> Phone: +44 705 005 2931 >> Twitter: @futureidentity >> >> >> >> >> On 24 Oct 2012, at 10:30, Ben Laurie wrote: >> >>> On 23 October 2012 10:58, Robin Wilton <wilton@isoc.org> wrote: >>>> >>>> On 23 Oct 2012, at 09:44, Ben Laurie wrote: >>>> >>>> <snip> >>>> >>>> >>>> Not disagreeing with any of the above, but observing that: >>>> >>>> a) There's no particular reason you could not have an email per site >>>> as well as a key per site. >>>> >>>> b) Linkability it not, as you say, inherently bad. The problem occurs >>>> when you have (effectively) no choice about linkability. >>>> >>>> >>>> >>>> But it's very hard to use either of those mechanisms (separation >>>> through >>>> emails or keys) without giving some third party the ability to >>>> achieve total >>>> linkability. (In other words, both options remove effective choice). >>> I agree that emails are a problem, but not at all sure why keys are? >>> In the case of appropriate selective disclosure mechanisms, even if >>> there were a third party involved, they would not be able to link uses >>> of the keys. Also, if you insist on using linkable keys, then per-site >>> keys do not involve third parties. >>> >> >> It may just be that I'm not getting a clear mental picture of your >> architecture. But here was my thinking: >> - If you use symmetric keys, you get a system which can't scale >> unless you opt for Schneier's idea of a key server… but then the key >> server becomes a point of potential panopticality. >> >> - If you use PKI, *and* you want your communicating parties to be >> able to validate the certs they're relying on, then you have to >> design a CRL- or OCSP-like mechanism into the architecture, and again >> you end up with a component which is potentially panoptical. (Plus, >> you have to address the 20-year-old problem of how to make PKI usable >> by human beings, when recent history suggests that PKI only takes off >> where human beings are kept well away from it). > > CRL is pretty much built in to WebID, if you remove a public key from > the document pointed to by your uri-identifier, then it's no longer > valid for use in WebID - auth can't happen, rendering the cert useless > for WebID. > > > For sake of clarity, Nathan is speaking about the WebID authentication protocol. A WebID on its own refers to an resolvable (de-referencable) identifier. The WebID protocol verifies the aforementioned identifier (entity denotation mechanism) via a combination of cryptography and entity relationship semantics oriented logic. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 24 October 2012 14:03:43 UTC