Re: [saag] Liking Linkability

Melvin Carvalho <melvincarvalho@gmail.com> Wed, 24 October 2012 15:09 UTC

Return-Path: <melvincarvalho@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2866721F86A0 for <saag@ietfa.amsl.com>; Wed, 24 Oct 2012 08:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.316
X-Spam-Level:
X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xT+azxTcURR for <saag@ietfa.amsl.com>; Wed, 24 Oct 2012 08:09:18 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75B9421F8683 for <saag@ietf.org>; Wed, 24 Oct 2012 08:09:18 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so956933iec.31 for <saag@ietf.org>; Wed, 24 Oct 2012 08:09:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1BOEWZjalMqhcVDcXvhJrlFwm1E+GIyfBRqTE7fdzx8=; b=ObB627BBEFBjjIMOc2dYho4p0Nx+QwptP+LhiY/9/qnk6CXfCqKKAEo8Fe9n+1PNo7 Eax5IzRU1nemL4HKxri4wJ9PmtKUQiU7kSlHugEPgV+4NcajftsKlWvasL1lxxwAIQTD oJ1HdxnlAuPA8wiEr1kudunrCdP3p+C9XyIWy+jFwG6n4OzQMkjRaquoPxi+Mkb+K1kX +CHejNmgw4EEFAKRWeOsyqaOnNmg7tiFmxDMsrRfMf7E+HemcZif3S5x4BlZonJuHsVY y4nRmkbB/ocMo/sWPz1Ncspi3jbs5AlF5cU3CIBtq2Yf7kr2HrvtmWN2piMdD46qhUur c4QQ==
MIME-Version: 1.0
Received: by 10.50.242.74 with SMTP id wo10mr2755191igc.51.1351091357956; Wed, 24 Oct 2012 08:09:17 -0700 (PDT)
Received: by 10.42.247.129 with HTTP; Wed, 24 Oct 2012 08:09:17 -0700 (PDT)
In-Reply-To: <43EEDAE2-6E5F-4D2E-BC1E-516408DCD3CC@bblfish.net>
References: <CCA5E789.2083A%Josh.Howlett@ja.net> <CABrd9SQghpi6_rVQKxYXZDtM5HwvE7Kq7SUw5zi41ZRd3y2h9A@mail.gmail.com> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <CABrd9SQU1uYVaVPedokHxeYkT=759rkPFfimWK1Z8ATzo3yNFA@mail.gmail.com> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <CABrd9SRNVLbWxifQAQ6iuX4qMeFmZVD6rO_q=L348G1UZzr9tg@mail.gmail.com> <50852726.9030102@openlinksw.com> <CABrd9SQ3KTqHq1hOfbLAU5hfgNyqCPK4u+ToEda+VtQ5S0utwA@mail.gmail.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> <CABrd9SQxy3GjKekrrCPikqRBt4z2PdzbOhzZUsDC6asZNSiu0A@mail.gmail.com> <E8AC244A-1D90-49F2-BD8A-2CF13E11D4B7@isoc.org> <5087D92D.8000207@webr3.org> <5087F51D.3040503@openlinksw.com> <CAKaEYhKhkeNLe6LC5fgtjcZZ-L4FbpXDujRzn3zpwNOgNY=HBg@mail.gmail.com> <43EEDAE2-6E5F-4D2E-BC1E-516408DCD3CC@bblfish.net>
Date: Wed, 24 Oct 2012 17:09:17 +0200
Message-ID: <CAKaEYhJR31GQTCYuT32cCXj3bPUk1iHOgT8rPD+k=paT=hGVZw@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Henry Story <henry.story@bblfish.net>
Content-Type: multipart/alternative; boundary=f46d044787d3733cae04cccf783a
X-Mailman-Approved-At: Thu, 25 Oct 2012 08:21:39 -0700
Cc: Robin Wilton <wilton@isoc.org>, public-identity@w3.org, "saag@ietf.org" <saag@ietf.org>, "public-privacy@w3.org list" <public-privacy@w3.org>, public-webid@w3.org
Subject: Re: [saag] Liking Linkability
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2012 15:09:20 -0000

On 24 October 2012 17:00, Henry Story <henry.story@bblfish.net> wrote:

>
> On 24 Oct 2012, at 16:24, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
> On 24 October 2012 16:03, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> On 10/24/12 8:03 AM, Nathan wrote:
>>
>>> Robin Wilton wrote:
>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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.
>>>
>>
> +1 Nathan.
>
> ( btw. It is always good to point people to the spec too
> http://webid.info/spec is the short url for it. )
>
>
>>>
>>>
>>>
>> 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.
>
>
> The spec has a definition that seems pretty reasonable, ( though I think
> we should remove the reference to "intentions" )
>
> http://www.w3.org/2005/Incubator/webid/spec/#terminology
>
> WebIDA URI that refers to an Agent - Person, Robot, Group or other thing
> that can have Intentions. The WebID should be a URI which when dereferenced
> returns a representation whose description uniquely identifies the Agent
> who is the controller of a public key. In our example the WebID refers to
> Bob<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#dfn-bob>ob>.
> A WebID is usually a URL with a #tag, as the meaning of such a URL is
> defined in the document refered to by the WebID URL without the #tag .
>
>
>
> 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.
>
>
> I would not say just implementation details. From the philosophical theory
> of reference
> ( eg: Gareth Evans's book: The variety of Reference ) they may be, but in
> everyday usage
> how these things are implemented is quite important, and so are the
> distinctions.
>
> According to the WebID spec definition:
>  - OpenID is close [1] though they have a URL for a web page rather than
> an agent (not a big deal), but more importantly they don't make use of the
> URL to get the attributes, which is what WebID does. They certainly don't
> publish the public key in the OpenId profile.
>  - webfinger does indeed give a method to dereference a mailto: uri,
> which could be used for a WebID protocol.
>

the current draft of webfinger allows dereferencing a mailto: URI ... in
fact it is anyURI


>  - I don't think OAuth is working with URIs at all
>  - Mozilla Persona could use WebIDs [2] and it would improve their
> protocol so dramatically, it is evident that they will at some point.
>
>   Henry
>
> [1] https://blogs.oracle.com/bblfish/entry/what_does_foaf_ssl_give
> [2]
> http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
>
>
>
>>
>>
>> --
>>
>> 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>
>>
>>
>>
>>
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>