- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Wed, 24 Oct 2012 16:24:26 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: nathan@webr3.org, 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: <CAKaEYhKhkeNLe6LC5fgtjcZZ-L4FbpXDujRzn3zpwNOgNY=HBg@mail.gmail.com>
On 24 October 2012 16:03, Kingsley Idehen <kidehen@openlinksw.com> wrote: > 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. Kingsley, thanks for pointing this out. I think some of the confusion arises from the fact that a webid is sometimes not that clearly defined, and people focus on the protocol. In particular a WebID is a URI that references an Agent (human or machine) Similarly, email will become WebIDs using the webfinger spec (when that's complete) It can be argued that OAuth/OpenID identifiers are also WebID but with a different auth protocol. Mozilla persona, although certainly useful, would possibly not fit into the same category, as they use a proprietary identification system. The whole idea is that WebID brings things together at an architectural level. "The WebID Protocol", certs, X.509 are implementation details really. > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen> > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about> > LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen> > > > > > >
Received on Wednesday, 24 October 2012 14:24:55 UTC