From nobody Tue Apr 3 04:44:40 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B9212E8A1; Tue, 3 Apr 2018 04:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mouz9FoEqlo; Tue, 3 Apr 2018 04:44:37 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EECD1243F6; Tue, 3 Apr 2018 04:44:37 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id x77so15381451ioi.2; Tue, 03 Apr 2018 04:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=r0NLE5gmf/1xnZpeUG8FzuT/A1XTGDJmLcudbSg3cdY=; b=pHj61/+ePmONTt+47JyOWn0r1zbJSqqmKmdBrVRFV/zQKG2wYErmz8IWuB2T9khJlG 5+Bf9B4D40cUfL0LYENRCq3Fw9ZY7Jlwk66/EKUYU2cXhKwmUUGUPZKhYMbGLb2kTeI8 cMeSLoEVSROGS52Za+7L3Q43oPqnYd8nS9nZWkMBD3moS+xdBYS+q2sZ3GmXsdUTMaUr AhfUn4/d3qLLiCZ0QF9DfR2gwnqD0ZH/FpJbxEOcjCNLgorWYyM+4Py1J2Ve6k703XJi GO82+iBvC7zhStXFKVOVcD4IWrIM3rUZTpKtwDSkLPvFJTViFXkDHf7boMIhu7FuOOZ3 8trg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=r0NLE5gmf/1xnZpeUG8FzuT/A1XTGDJmLcudbSg3cdY=; b=snQ8OfarTtEU7iVhC95o3Ss8Y1T+adC8w6nRztrXnx7OBS7NB4ys9VbxJ77U9ZT9kC IEkV6OR7cBJwZWhHoqzX5KkUdsVQwD15YenO0iBl/zZr1Klh3dMSE7YH/LNrPIrxpND1 /YKo3AjhRPG+VRVwCAWwTAjvnB9MXFGVKo8xIxH8RaIQ5GcDFJE6tFOLz7ZlalcQhKwz 506xZ5hhrIyvaRKGZa2uI9fmObZPlGBrnKhJ/bQT0ht8Z6Rhecx0U2q+nOZ6V+oNNLPA I+ICM2s1FUcRxY3Ngkum6kXtR7sSCPOYPz2NTRg5K6Nx6lSD++pq9+qA6fv3StYQVqz9 OJ+w== X-Gm-Message-State: ALQs6tBIqoL87mAzLCTbFFYGmiONovZt0ok057olWZGcrKOAm6nTTvik rtbkLQVaH9GFRPrgO6eLbZSSu9+bNAGcUb1e2RgdwPkw X-Google-Smtp-Source: AIpwx490uw11cx7pe1cnQMjunQAKeH2U9q+0p+G+hGFe6BLDUv/MUE4zGp3sH/M0azltfzn0c3auT8fjE8y29wWlx8Q= X-Received: by 10.107.30.135 with SMTP id e129mr11143280ioe.183.1522755876360; Tue, 03 Apr 2018 04:44:36 -0700 (PDT) MIME-Version: 1.0 Sender: arjuna.sathiaseelan@gmail.com Received: by 10.79.198.5 with HTTP; Tue, 3 Apr 2018 04:44:35 -0700 (PDT) From: Arjuna Sathiaseelan Date: Tue, 3 Apr 2018 12:44:35 +0100 X-Google-Sender-Auth: ksxlYXq-j21o0xP33oxHgk3NNks Message-ID: To: din@irtf.org Cc: gaia Content-Type: multipart/alternative; boundary="001a1140f5d217176d0568f03bc3" Archived-At: Subject: [Din] Hyperledger evaluation on a mesh network X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 11:44:39 -0000 --001a1140f5d217176d0568f03bc3 Content-Type: text/plain; charset="UTF-8" we recently did an evaluation of the hyperledger fabric in a community wireless network within the famous guifi.net.. will be of interest https://arxiv.org/pdf/1804.00561.pdf Regards -- Arjuna Sathiaseelan University of Cambridge | Ammbr Research Labs Personal: http://www.cl.cam.ac.uk/~as2330/ N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d --001a1140f5d217176d0568f03bc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a1140f5d217176d0568f03bc3-- From nobody Tue Apr 3 19:09:24 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EBA124BAC for ; Tue, 3 Apr 2018 19:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6oNbuq0XBJE for ; Tue, 3 Apr 2018 19:09:22 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32790127735 for ; Tue, 3 Apr 2018 19:09:22 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 68AE621665 for ; Tue, 3 Apr 2018 22:09:21 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Tue, 03 Apr 2018 22:09:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=9drERw PXgR8964gjPpIk81A9AWljWa0gp0IXmc8FkRQ=; b=iWr6kCYew0OpMCdIghIGg2 QYSbhoL0igXmK+wPk9LHjeIL6nYTUgoE5G1bXFUmu65aXkCnja0ajOwb2TQ0KrFp +qw2Xsa+weBi7v0XrgLJQJdBeehFjJfScNsx1uYjSSVtU1Fc7lKLWXSqw40ZCCSN ay0Rldjou98y54d2qmCO4brkA14rWCEA6yvtqPb4yyNJ6AcSkMTEov/eIdmcD52Y GLBf/Szz/R7uKsOHqBXeU/nQ+K2BPbQdrn3OGYHYQy8vGYzsRDsOcIHllvv0Br1e 7qja6NvaKNqTVYkHROnTB+H01yMOdXwpwkJ+1vm9aKiMwMgqpHOQ/nSLyvi+FXcA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 435FE9E379; Tue, 3 Apr 2018 22:09:21 -0400 (EDT) Message-Id: <1522807761.2691505.1325710912.72C042EF@webmail.messagingengine.com> From: Jehan Tremback To: din@irtf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152280776126915051" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338 In-Reply-To: Date: Tue, 03 Apr 2018 19:09:21 -0700 References: Archived-At: Subject: Re: [Din] Hyperledger evaluation on a mesh network X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:09:23 -0000 This is a multi-part message in MIME format. --_----------=_152280776126915051 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Why run full nodes on your networking hardware? One could achieve the same security characteristics (or better) by simply using light clients of a public blockchain on the networking hardware. -- Jehan Tremback jehan@altheamesh.com On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote: > we recently did an evaluation of the hyperledger fabric in a community > wireless network within the famous guifi.net..> > will be of interest https://arxiv.org/pdf/1804.00561.pdf > > Regards > > -- > > Arjuna Sathiaseelan > University of Cambridge | Ammbr Research Labs > Personal: http://www.cl.cam.ac.uk/~as2330/ > N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d > _________________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din --_----------=_152280776126915051 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Why run full nodes on your networking hardware? One could achieve the same security characteristics (or better) by simply using light clients of a public blockchain on the networking hardware. 

--
  Jehan Tremback
  jehan@altheamesh.com



On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote:
we recently did an evaluation of the hyperledger fabric in a community wireless network within the famous guifi.net..


Regards

--

Arjuna Sathiaseelan
University of Cambridge | Ammbr Research Labs
_______________________________________________
Din mailing list

--_----------=_152280776126915051-- From nobody Wed Apr 4 01:04:36 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AC4124205 for ; Wed, 4 Apr 2018 01:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gO2nxZCcyt0 for ; Wed, 4 Apr 2018 01:04:33 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84DC120047 for ; Wed, 4 Apr 2018 01:04:32 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id r191so7721361wmg.4 for ; Wed, 04 Apr 2018 01:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zW5OcYP1zGimW8bXtQ5pXJuABe/DJGCqXApB0THNpdI=; b=oGHiFh2Zs6MX1a7MbBcbM+tWWp6ttQ9vt7QGsI9fs9QWSDBsgDfvStirDPzrPo20wz +u3fD0csp4uuTt+B7grRouXLXinK9/wYxP1+ST+6w6gjrUR6QMl+WR0vLlvAwCiKeUKh KOBeWUwxHImEXGdbSgdO1CihiKMyuwX7Z4A+Bs6m5vohpCdEGqXc134TCsofw4RZpZJ2 pCDv5WsX5JClCHq+nTDNOKPFFs6+jtFygXAAX8AJN9ljTq4V7QfQEoxjW4t2Fq4mTqen wrCDDxln+CpmkGKcHulbWnSZkVBizNPvTS3yK+5NKnybaol/bnfPNqw+L/ohmDVWmcoe grXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zW5OcYP1zGimW8bXtQ5pXJuABe/DJGCqXApB0THNpdI=; b=exNRfNJ16AocsctMgk4yaKtMe84ZSGXKJt1onsckK0h+U5p1F4gDKfa5uriLMK77WE qG3Wgxf/kHmnk3ZHHeq26kARbuiMVHVApJQ1Yl975DiQp/cToQfE/gHdF35N/0xkasKY ZwbZ0MBDfuJc7YT0dxj99JPH8BDSlfjwwVs4stHgQc2EgnkGrNAAF5AfxQ9gjrevk3Ok 09V2ZI+Ov3P1OCPGQOivaOhYb+auHdUMFF18/C+NwIJRFgERmtasIltTlBOtIT9UGk8+ NoO3KyQSrjzNS//c6TeVSEAvmKbs95Gdx1uPf8eh/q7UEa/l+6lp9RleD56OacOlT7ec FtSA== X-Gm-Message-State: AElRT7Hy0IaUbvy46dmZ/W5f/JEv5Rf4c4cZjkZ2qUl7/njRHM/zQ9i9 UMcfvuhiEJolvtSX/d4Nh5KLl1Ize8juKxFXI8o= X-Google-Smtp-Source: AIpwx49DeRIegarBEfpdF7HnMrrdWRao8Uou5Fldvy+4BRCDJQoJZZtw+X6xBdnp9H37N8Hs6+7YKMK2TK+W/YwCZMI= X-Received: by 10.28.153.12 with SMTP id b12mr6961812wme.104.1522829071221; Wed, 04 Apr 2018 01:04:31 -0700 (PDT) MIME-Version: 1.0 Sender: crowcroft@gmail.com Received: by 10.28.167.86 with HTTP; Wed, 4 Apr 2018 01:04:30 -0700 (PDT) In-Reply-To: <1522807761.2691505.1325710912.72C042EF@webmail.messagingengine.com> References: <1522807761.2691505.1325710912.72C042EF@webmail.messagingengine.com> From: Jon Crowcroft Date: Wed, 4 Apr 2018 09:04:30 +0100 X-Google-Sender-Auth: 1fDKSLNk1kWCY__LKgjpGvzGcB4 Message-ID: To: Jehan Tremback Cc: din@irtf.org Content-Type: multipart/alternative; boundary="001a114b1ca2d809bd05690145d5" Archived-At: Subject: Re: [Din] Hyperledger evaluation on a mesh network X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 08:04:36 -0000 --001a114b1ca2d809bd05690145d5 Content-Type: text/plain; charset="UTF-8" or a much simpler approach: https://hal.inria.fr/inria-00466747/document On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback wrote: > Why run full nodes on your networking hardware? One could achieve the same > security characteristics (or better) by simply using light clients of a > public blockchain on the networking hardware. > > -- > Jehan Tremback > jehan@altheamesh.com > > > > On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote: > > we recently did an evaluation of the hyperledger fabric in a community > wireless network within the famous guifi.net.. > > will be of interest https://arxiv.org/pdf/1804.00561.pdf > > Regards > > -- > > Arjuna Sathiaseelan > University of Cambridge | Ammbr Research Labs > Personal: http://www.cl.cam.ac.uk/~as2330/ > N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d > *_______________________________________________* > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > > --001a114b1ca2d809bd05690145d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback <jehan@altheamesh.com= > wrote:
Why run full nodes on your networking hardware? One could achieve= the same security characteristics (or better) by simply using light client= s of a public blockchain on the networking hardware.=C2=A0

--
=C2=A0 Jehan Tremback
=C2=A0 jehan@altheamesh.com



On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote:
we recently did an evaluation of the hyperledger fabric in a commun= ity wireless network within the famous guifi.net..

will be of interest=C2=A0https://arxiv.org/pdf/1804.00561.pdf

Regards

--

Arjuna Sathiaseelan
University of Cambridge | Ammbr Research Labs
_______________________________________________
Din mailing list


_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din


--001a114b1ca2d809bd05690145d5-- From nobody Wed Apr 4 08:58:28 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5297512DA49 for ; Wed, 4 Apr 2018 08:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8K22M2LXO5m for ; Wed, 4 Apr 2018 08:58:24 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D7F1201F8 for ; Wed, 4 Apr 2018 08:58:24 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B8D0A212FC; Wed, 4 Apr 2018 11:58:22 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Wed, 04 Apr 2018 11:58:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=roERPQ I/x4pOE0QzXM4uIFZHWa+8eallu0qbNmpS0CU=; b=SOeyiJrDtAd60uGNRJ9/E8 vLLPsn60j8CVZsmYE19h4iej2r2JIDzU6Yakzuh83UIbA9hOclxW+0L6Vu46m7f0 dwlxKXxSCE+5mzy62Lr2iE4FtboHk6qE7HleRIhhluP9vz9No7aECt3d8SdabLol XZ67R0+QWlNbevW5WVnvdWRWZKmuTvwt6sKI8ZLvtFdz8X7dAMPvWVAw1zBFf/hr 3koVfhr35aIWc6dnNFESnQbs1hFCLnpxvnbDcZbr+iG5lnGoX/54/F1VS6INBxpM NZuKyDfirqxa5ouGsAriCfnpAsHn+vtUyUoQUIpY+t8VzsAwuKzU0b2O7rGv0PmQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3DA699E19E; Wed, 4 Apr 2018 11:58:22 -0400 (EDT) Message-Id: <1522857502.1313779.1326451800.352B185C@webmail.messagingengine.com> From: Jehan Tremback To: Jon Crowcroft Cc: din@irtf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152285750213137791" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338 In-Reply-To: Date: Wed, 04 Apr 2018 08:58:22 -0700 References: <1522807761.2691505.1325710912.72C042EF@webmail.messagingengine.com> Archived-At: Subject: Re: [Din] Hyperledger evaluation on a mesh network X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:58:26 -0000 This is a multi-part message in MIME format. --_----------=_152285750213137791 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Even simpler, by adding a monetary price metric to a distance vector protocol (we are currently testing this in production). Skimming your paper, it looks like you are thinking along the same lines. https://altheamesh.com/documents/whitepaper.pdf Back to the Arjuna's post, the use of a blockchain implies that there is some value to having an immutable transaction ordering mechanism. In our protocol we conceptualize these ordered transactions as "payments", while in Arjuna's paper the actual use of this transaction ordering is left unspecified. Running the transaction ordering consensus protocol on the network nodes themselves seems like a bad idea. These nodes have more of an incentive to mess with the ordering than some faraway validators who know nothing about the specific application and are only incentivized to order transactions correctly. Also, the fact that there are always going to be many fewer validators available on a local network means that the consensus pool is smaller and more vulnerable to manipulation. I say, leave the transaction ordering to a global network of validators who specialize in transaction ordering and leave the networking to network hardware equipped with light clients. With Althea, we are able to run everything on commodity routers on OpenWRT. -- Jehan Tremback jehan@altheamesh.com On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote: > or a much simpler approach: > https://hal.inria.fr/inria-00466747/document > > On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback > wrote:>> __ >> Why run full nodes on your networking hardware? One could achieve the >> same security characteristics (or better) by simply using light >> clients of a public blockchain on the networking hardware.>> >> -- >> Jehan Tremback >> jehan@altheamesh.com >> >> >> >> On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote: >>> we recently did an evaluation of the hyperledger fabric in a >>> community wireless network within the famous guifi.net..>>> >>> will be of interest https://arxiv.org/pdf/1804.00561.pdf >>> >>> Regards >>> >>> -- >>> >>> Arjuna Sathiaseelan >>> University of Cambridge | Ammbr Research Labs >>> Personal: http://www.cl.cam.ac.uk/~as2330/ >>> N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d >>> _________________________________________________ >>> Din mailing list >>> Din@irtf.org >>> https://www.irtf.org/mailman/listinfo/din >> >> >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >> --_----------=_152285750213137791 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Even simpler, by adding a monetary price metric to a distance vector protocol (we are currently testing this in production). Skimming your paper, it looks like you are thinking along the same lines.


Back to the Arjuna's post, the use of a blockchain implies that there is some value to having an immutable transaction ordering mechanism. In our protocol we conceptualize these ordered transactions as "payments", while in Arjuna's paper the actual use of this transaction ordering is left unspecified. 

Running the transaction ordering consensus protocol on the network nodes themselves seems like a bad idea. These nodes have more of an incentive to mess with the ordering than some faraway validators who know nothing about the specific application and are only incentivized to order transactions correctly. Also, the fact that there are always going to be many fewer validators available on a local network means that the consensus pool is smaller and more vulnerable to manipulation.

I say, leave the transaction ordering to a global network of validators who specialize in transaction ordering and leave the networking to network hardware equipped with light clients. With Althea, we are able to run everything on commodity routers on OpenWRT.

--
  Jehan Tremback
  jehan@altheamesh.com



On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote:

On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback <jehan@altheamesh.com> wrote:

Why run full nodes on your networking hardware? One could achieve the same security characteristics (or better) by simply using light clients of a public blockchain on the networking hardware. 

--
  Jehan Tremback



On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote:
we recently did an evaluation of the hyperledger fabric in a community wireless network within the famous guifi.net..


Regards

--

Arjuna Sathiaseelan
University of Cambridge | Ammbr Research Labs
_______________________________________________
Din mailing list


_______________________________________________
Din mailing list


--_----------=_152285750213137791-- From nobody Wed Apr 4 13:31:37 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1939812DA68 for ; Wed, 4 Apr 2018 13:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EjM3Qp0qRdD for ; Wed, 4 Apr 2018 13:31:33 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EFA112D864 for ; Wed, 4 Apr 2018 13:31:33 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id e79so27920426ioi.7 for ; Wed, 04 Apr 2018 13:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3BklwErmudoAC2L+mIH2lbfC6SV7AkR/wA2imAQvumY=; b=ELr+PLg9tgsringhUlqL0JyYxIC7NYBeVwqwnpSmrLIowDEpxXbVKVoDh8APjmQe8Q sOP7quPg/LIZD6XOUPqtpwHaS6MoJPH2viSYVDOKANpPASGiBOqfBBd6mV9pGYgVakVY 3J+KYQyLlrAqw9f9lscLrBcBLYNCb4DUPT02r+c+ZqXuXlqyzaMs5RnDJ/st+azrtvID NCE2Ut2gha6wpFGyTzLGrQHy24V6DLZQwa3Kyg6fhxr5FoTVwIh4/uw/uUsekmUsW5Zg Ix0v8LQIW60LZc5y7G9Bj+VUa4z/vL3yYTvOQIyfs5byscnP9u5k+FoWVXVwa31U3uZQ Yevw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3BklwErmudoAC2L+mIH2lbfC6SV7AkR/wA2imAQvumY=; b=F3o9OZHdaVOYjQAcT+QYmLzbaKYHWuMkzJMpNd/gqYgJa+g1dExNmLs5m2Q5wkY84P bZVkZdEUTRh9GF4pBOdG2EMWJvdwaI54oeTO0Nd50NzEf11Go7EgduM2pC6XHc0vqEfL UV09Wik3XeM+Az+eEiZBjH6xGF3NAHfatC/xSDZYhznNMY4TMcT3PzmW/9zwGFu81JeX EFo+AEd8qPtaG8iw6aNboucKEGDaj2RFP2wpQBNxmj1/lplpdZ8W/A/NH9YBQwM5o6Mx PZURgH08HIzYiX7A2IrsSI2hKeKhZpUnmVntqnvwzhf5FGou7CT3zhPKKoSIvUUUaua8 Xu9g== X-Gm-Message-State: AElRT7EygdmuSlLg6I+4MWO1/rHRFxbBMNBoWH9lju3aON+vS0pc2Bm+ tDLfk3cibMaMi5Bw4WPIPcktBun6/8/pw35AmQg= X-Google-Smtp-Source: AIpwx4+qOnYYzEy1Cdwaq2NNocO0b6m+mDyjyCPqgiec4FFqnthqseRPzCDbCe2K0o6ot4GdFqLj9wB+vt4hLcFYCFE= X-Received: by 10.107.37.5 with SMTP id l5mr17225551iol.47.1522873892666; Wed, 04 Apr 2018 13:31:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.198.5 with HTTP; Wed, 4 Apr 2018 13:31:31 -0700 (PDT) In-Reply-To: <1522857502.1313779.1326451800.352B185C@webmail.messagingengine.com> References: <1522807761.2691505.1325710912.72C042EF@webmail.messagingengine.com> <1522857502.1313779.1326451800.352B185C@webmail.messagingengine.com> From: Arjuna Sathiaseelan Date: Wed, 4 Apr 2018 21:31:31 +0100 Message-ID: To: Jehan Tremback Cc: Jon Crowcroft , din@irtf.org Content-Type: multipart/alternative; boundary="001a1140f4186903b505690bb503" Archived-At: Subject: Re: [Din] Hyperledger evaluation on a mesh network X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 20:31:36 -0000 --001a1140f4186903b505690bb503 Content-Type: text/plain; charset="UTF-8" Jehan, Good points. The aim of the paper was to benchmark HL and understand the painpoints and hardware requirements. So this is the way I see things from Ammbr's point of view: 1. We are developing hardware (the Ammbr routers) that would function as part of the blockchain e.g. act as orderers & any node/hardware can still be a light node within the network - they just cant participate in the consensus. 2. Our PoET/PoV consensus + the underlying DAO ensures fairness/decentralisation + does not allow nodes to mess around - any bad behaviour will involve revoking the certificates by the certification authority.. Regards On Wed, 4 Apr 2018, 16:58 Jehan Tremback, wrote: > Even simpler, by adding a monetary price metric to a distance vector > protocol (we are currently testing this in production). Skimming your > paper, it looks like you are thinking along the same lines. > > https://altheamesh.com/documents/whitepaper.pdf > > Back to the Arjuna's post, the use of a blockchain implies that there is > some value to having an immutable transaction ordering mechanism. In our > protocol we conceptualize these ordered transactions as "payments", while > in Arjuna's paper the actual use of this transaction ordering is left > unspecified. > > Running the transaction ordering consensus protocol on the network nodes > themselves seems like a bad idea. These nodes have more of an incentive to > mess with the ordering than some faraway validators who know nothing about > the specific application and are only incentivized to order transactions > correctly. Also, the fact that there are always going to be many fewer > validators available on a local network means that the consensus pool is > smaller and more vulnerable to manipulation. > > I say, leave the transaction ordering to a global network of validators > who specialize in transaction ordering and leave the networking to network > hardware equipped with light clients. With Althea, we are able to run > everything on commodity routers on OpenWRT. > > -- > Jehan Tremback > jehan@altheamesh.com > > > > On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote: > > or a much simpler approach: > https://hal.inria.fr/inria-00466747/document > > On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback > wrote: > > > Why run full nodes on your networking hardware? One could achieve the same > security characteristics (or better) by simply using light clients of a > public blockchain on the networking hardware. > > -- > Jehan Tremback > jehan@altheamesh.com > > > > On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote: > > we recently did an evaluation of the hyperledger fabric in a community > wireless network within the famous guifi.net.. > > will be of interest https://arxiv.org/pdf/1804.00561.pdf > > Regards > > -- > > Arjuna Sathiaseelan > University of Cambridge | Ammbr Research Labs > Personal: http://www.cl.cam.ac.uk/~as2330/ > N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d > *_______________________________________________* > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > --001a1140f4186903b505690bb503 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jehan,

Good points. The aim of the paper was to benchmark HL and under= stand the painpoints and hardware requirements.=C2=A0

So this is the way I see things from Ammbr= 9;s point of view: 1. We are developing hardware (the Ammbr routers) that w= ould function as part of the blockchain e.g. act as orderers & any node= /hardware can still be a light node within the network - they just cant par= ticipate in the consensus. 2. Our PoET/PoV consensus + the underlying DAO e= nsures fairness/decentralisation + does not allow nodes to mess around - an= y bad behaviour will involve revoking the certificates by the certification= authority..

Regards

<= div class=3D"gmail_quote">
On Wed, 4 Apr 2018, 16:58 Jehan = Tremback, <jeh= an@altheamesh.com> wrote:
Even simpler, by adding a monetary price metric to a distance vec= tor protocol (we are currently testing this in production). Skimming your p= aper, it looks like you are thinking along the same lines.


Back to the Arjuna's post, the use of a blockchain implies that th= ere is some value to having an immutable transaction ordering mechanism. In= our protocol we conceptualize these ordered transactions as "payments= ", while in Arjuna's paper the actual use of this transaction orde= ring is left unspecified.=C2=A0

Running the transaction ordering consensus protocol on the network no= des themselves seems like a bad idea. These nodes have more of an incentive= to mess with the ordering than some faraway validators who know nothing ab= out the specific application and are only incentivized to order transaction= s correctly. Also, the fact that there are always going to be many fewer va= lidators available on a local network means that the consensus pool is smal= ler and more vulnerable to manipulation.

I say, leave the transaction ordering to a global network of validator= s who specialize in transaction ordering and leave the networking to networ= k hardware equipped with light clients. With Althea, we are able to run eve= rything on commodity routers on OpenWRT.

--
=C2=A0= Jehan Tremback
=C2=A0= jehan@altheamesh.com



On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote:


Why run full nodes on your networking hardware? One could achieve= the same security characteristics (or better) by simply using light client= s of a public blockchain on the networking hardware.=C2=A0

--
=C2=A0 Jehan Tremback



On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote:
we recently did a= n evaluation of the hyperledger fabric in a community wireless network with= in the famous guifi.net..


Regards

--

Arjuna Sathiaseelan
University of Cambridge | Ammbr Research Labs
_______________________________________________
Din mailing list


_______________________________________________
Din mailing list


_______________________________________________
Din mailing list
Din@ir= tf.org
https://www.irtf.org/mailman/listinfo/din
--001a1140f4186903b505690bb503-- From nobody Wed Apr 4 16:09:20 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10AE126FB3 for ; Wed, 4 Apr 2018 16:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnfG88ZSpZhU for ; Wed, 4 Apr 2018 16:09:14 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6E92812D86C for ; Wed, 4 Apr 2018 16:09:11 -0700 (PDT) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id w34N8xdB025816; Thu, 5 Apr 2018 01:08:59 +0200 Received: from user-32-244.vpn.net.private.cam.ac.uk (global-184-3.nat-1.net.cam.ac.uk [131.111.184.3]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 596187C4; Thu, 5 Apr 2018 01:08:52 +0200 (CEST) From: Leandro Navarro Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_67C851D4-9439-44AB-BE9C-3DADFB98917C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 5 Apr 2018 01:08:49 +0200 In-Reply-To: <1522857502.1313779.1326451800.352B185C@webmail.messagingengine.com> Cc: Jon Crowcroft , din@irtf.org To: Jehan Tremback References: <1522807761.2691505.1325710912.72C042EF@webmail.messagingengine.com> <1522857502.1313779.1326451800.352B185C@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Din] Hyperledger evaluation on a mesh network X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 23:09:18 -0000 --Apple-Mail=_67C851D4-9439-44AB-BE9C-3DADFB98917C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The paper that Arjuna shared looks to the general topic of this WG = =E2=80=9CDecentralized Internet Infrastructure=E2=80=9D, with an = evaluation of the Hyperledger framework when running on a edge scenario = of small Debian servers spread in a mesh network (not in the routers), = instead of a typical data center env. > On 4 Apr 2018, at 17:58, Jehan Tremback wrote: >=20 > Even simpler, by adding a monetary price metric to a distance vector = protocol (we are currently testing this in production). Skimming your = paper, it looks like you are thinking along the same lines. Simpler but not too simple regarding pricing. Jon=E2=80=99s paper looked = in 2010 at pricing related to congestion, fairness, incentives for = cooperation, sending rates in flows and overall stability in a local = mobile ad-hoc net. Still relevant work 8 years later. > Back to the Arjuna's post, the use of a blockchain implies that there = is some value to having an immutable transaction ordering mechanism. In = our protocol we conceptualize these ordered transactions as "payments", = while in Arjuna's paper the actual use of this transaction ordering is = left unspecified.=20 =E2=80=A6 not an objetive of that research paper (evaluation of = Hyperledger) !=3D whitepaper. > Running the transaction ordering consensus protocol on the network = nodes themselves seems like a bad idea. > These nodes have more of an incentive to mess with the ordering than = some faraway validators who know nothing about the specific application = and are only incentivized to order transactions correctly. Also, the = fact that there are always going to be many fewer validators available = on a local network means that the consensus pool is smaller and more = vulnerable to manipulation. Hyperledger has strong limitations when running in small servers, = let=E2=80=99s forget about routers, but just relying on remote servers = for local transactions can have drawbacks too. > I say, leave the transaction ordering to a global network of = validators who specialize in transaction ordering and leave the = networking to network hardware equipped with light clients. With Althea, = we are able to run everything on commodity routers on OpenWRT Thanks for your comments, Leandro. > . >=20 > -- > Jehan Tremback > jehan@altheamesh.com >=20 >=20 >=20 > On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote: >> or a much simpler approach: >> https://hal.inria.fr/inria-00466747/document = >>=20 >> On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback > wrote: >>=20 >> Why run full nodes on your networking hardware? One could achieve the = same security characteristics (or better) by simply using light clients = of a public blockchain on the networking hardware.=20 >>=20 >> -- >> Jehan Tremback >> jehan@altheamesh.com >>=20 >>=20 >>=20 >> On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote: >>> we recently did an evaluation of the hyperledger fabric in a = community wireless network within the famous guifi.net = .. >>>=20 >>> will be of interest https://arxiv.org/pdf/1804.00561.pdf = >>>=20 >>> Regards >>>=20 >>> --=20 >>>=20 >>> Arjuna Sathiaseelan >>> University of Cambridge | Ammbr Research Labs >>> Personal: http://www.cl.cam.ac.uk/~as2330/ = >>> N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d = >>> _______________________________________________ >>> Din mailing list >>> Din@irtf.org >>> https://www.irtf.org/mailman/listinfo/din = >>=20 >>=20 >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din = >>=20 >=20 > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din -- Leandro Navarro http://people.ac.upc.edu/leandro http://dsg.ac.upc.edu --Apple-Mail=_67C851D4-9439-44AB-BE9C-3DADFB98917C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = paper that Arjuna shared looks to the general topic of this WG = =E2=80=9CDecentralized Internet Infrastructure=E2=80=9D, with an = evaluation of the Hyperledger framework when running on a edge scenario = of small Debian servers spread in a mesh network (not in the routers), = instead of a typical data center env.

On 4 Apr 2018, at 17:58, Jehan = Tremback <jehan@altheamesh.com> wrote:

Even simpler, by adding a monetary price metric to a distance = vector protocol (we are currently testing this in production). Skimming = your paper, it looks like you are thinking along the same lines.

Simpler but not too simple regarding = pricing. Jon=E2=80=99s paper looked in 2010 at pricing related to = congestion, fairness, incentives for cooperation, sending rates in flows = and overall stability in a local mobile ad-hoc net. Still relevant work = 8 years later.

Back to = the Arjuna's post, the use of a blockchain implies that there is some = value to having an immutable transaction ordering mechanism. In our = protocol we conceptualize these ordered transactions as "payments", = while in Arjuna's paper the actual use of this transaction ordering is = left unspecified. 

=E2=80=A6 not an objetive of that research paper = (evaluation of Hyperledger) !=3D whitepaper.

Running = the transaction ordering consensus protocol on the network nodes = themselves seems like a bad = idea.
These = nodes have more of an incentive to mess with the ordering than some = faraway validators who know nothing about the specific application and = are only incentivized to order transactions correctly. Also, the fact = that there are always going to be many fewer validators available on a = local network means that the consensus pool is smaller and more = vulnerable to manipulation.

Hyperledger = has strong limitations when running in small servers, let=E2=80=99s = forget about routers, but just relying on remote servers for local = transactions can have drawbacks too.

I say, = leave the transaction ordering to a global network of validators who = specialize in transaction ordering and leave the networking to network = hardware equipped with light clients. With Althea, we are able to run = everything on commodity routers on = OpenWRT

Thanks for = your comments, Leandro.

.
--
 = Jehan Tremback
  jehan@altheamesh.com



On = Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote:
or a much simpler approach:
https://hal.inria.fr/inria-00466747/document

On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback <jehan@altheamesh.com> wrote:

Why run full nodes on = your networking hardware? One could achieve the same security = characteristics (or better) by simply using light clients of a public = blockchain on the networking hardware. 

--
  Jehan Tremback
  jehan@altheamesh.com



On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan = wrote:
we recently did an evaluation of the = hyperledger fabric in a community wireless network within the = famous guifi.net..

will= be of interest https://arxiv.org/pdf/1804.00561.pdf

Regards

-- 

Arjuna Sathiaseelan
University of Cambridge | Ammbr Research Labs
Personal: http://www.cl.cam.ac.uk/~as2330/
N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d
_______________________________________________
Din = mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din


_______________________________________________
Din = mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din

_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din
--
Leandro Navarro
http://people.ac.upc.edu/leandro =  http://dsg.ac.upc.edu

= --Apple-Mail=_67C851D4-9439-44AB-BE9C-3DADFB98917C-- From nobody Wed Apr 4 16:43:49 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA701126C2F for ; Wed, 4 Apr 2018 16:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMvv_sD6_hYx for ; Wed, 4 Apr 2018 16:43:45 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1531200A0 for ; Wed, 4 Apr 2018 16:43:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 62D712106D; Wed, 4 Apr 2018 19:43:43 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Wed, 04 Apr 2018 19:43:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=rMXZuj tPJqQH+4Q+IlX99Ey9Pfaj01z0ATnJdIU72Ho=; b=D4lfdmdJ03etZ2t9eAQmNu 7UCINyejW4q9TR2V4z0f/0D6CDx7l9LO2O+jHOMUdSkCeB4pXaMvo7kQlvcX8VJh xc7bQXjHsw+JuOM3hU409w5OuWSSocayc6+PHV2C6j/KSKiEa1u6V4NcaFf7VTZk 3tvc4s7pTYcIsDKv9DYWoZjhPZXFCzTvzVExh0HIvLzOeY6tWwTK1Na+Mxjp5Tfa qneId2G34CZNuvxvGU3oHKfneCq+hzoTrjlIY7jSnYfJ1N+WUf1Q3jNGUBnDvdYE XbTXG7jFeVeRQ/1rzgrHNUQMFsS8jSUSiJxJoqB+YQqS7DokWsrKKsNT21EVHswQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3BA8A9E19C; Wed, 4 Apr 2018 19:43:43 -0400 (EDT) Message-Id: <1522885423.2450300.1326960016.657AF135@webmail.messagingengine.com> From: Jehan Tremback To: Leandro Navarro Cc: Jon Crowcroft , din@irtf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152288542324503003" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338 References: <1522807761.2691505.1325710912.72C042EF@webmail.messagingengine.com> <1522857502.1313779.1326451800.352B185C@webmail.messagingengine.com> Date: Wed, 04 Apr 2018 16:43:43 -0700 In-Reply-To: Archived-At: Subject: Re: [Din] Hyperledger evaluation on a mesh network X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 23:43:48 -0000 This is a multi-part message in MIME format. --_----------=_152288542324503003 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Thanks Leandro. Our protocol does indeed leave pricing considerations un-analyzed. This is something we will unfortunately not be testing in a simulation like Jon, we'll have to see how things evolve in the real world. Some of the insights gained from that paper may prove to be useful. The paper that Arjuna shared does indeed provide interesting and rigorous experimental results on running a very small consensus network in some specific network conditions. My criticisms were on the "why" of doing that and do not detract from the quality of the paper. Thanks for sharing. -- Jehan Tremback jehan@altheamesh.com On Wed, Apr 4, 2018, at 4:08 PM, Leandro Navarro wrote: > The paper that Arjuna shared looks to the general topic of this WG > =E2=80=9CDecentralized Internet Infrastructure=E2=80=9D, with an evaluati= on of the > Hyperledger framework when running on a edge scenario of small Debian > servers spread in a mesh network (not in the routers), instead of a > typical data center env.>=20 >=20 >> On 4 Apr 2018, at 17:58, Jehan Tremback wrote:>>= =20 >> Even simpler, by adding a monetary price metric to a distance vector >> protocol (we are currently testing this in production). Skimming your >> paper, it looks like you are thinking along the same lines.>=20 > Simpler but not too simple regarding pricing. Jon=E2=80=99s paper looked = in > 2010 at pricing related to congestion, fairness, incentives for > cooperation, sending rates in flows and overall stability in a local > mobile ad-hoc net. Still relevant work 8 years later.>=20 >> Back to the Arjuna's post, the use of a blockchain implies that there >> is some value to having an immutable transaction ordering mechanism. >> In our protocol we conceptualize these ordered transactions as >> "payments", while in Arjuna's paper the actual use of this >> transaction ordering is left unspecified.>=20 > =E2=80=A6 not an objetive of that research paper (evaluation of Hyperledg= er) > !=3D whitepaper.>=20 >> Running the transaction ordering consensus protocol on the network >> nodes themselves seems like a bad idea.>> These nodes have more of an in= centive to mess with the ordering than >> some faraway validators who know nothing about the specific >> application and are only incentivized to order transactions >> correctly. Also, the fact that there are always going to be many >> fewer validators available on a local network means that the >> consensus pool is smaller and more vulnerable to manipulation.>=20 > Hyperledger has strong limitations when running in small servers, > let=E2=80=99s forget about routers, but just relying on remote servers for > local transactions can have drawbacks too.>=20 >> I say, leave the transaction ordering to a global network of >> validators who specialize in transaction ordering and leave the >> networking to network hardware equipped with light clients. With >> Althea, we are able to run everything on commodity routers on OpenWRT>=20 > Thanks for your comments, Leandro. >=20 >> . >>=20 >> -- >> Jehan Tremback >> jehan@altheamesh.com >>=20 >>=20 >>=20 >> On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote: >>> or a much simpler approach: >>> https://hal.inria.fr/inria-00466747/document >>>=20 >>> On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback >>> wrote:>>>> __ >>>> Why run full nodes on your networking hardware? One could achieve >>>> the same security characteristics (or better) by simply using light >>>> clients of a public blockchain on the networking hardware.>>>>=20 >>>> -- >>>> Jehan Tremback >>>> jehan@altheamesh.com >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote: >>>>> we recently did an evaluation of the hyperledger fabric in a >>>>> community wireless network within the famous guifi.net[1]..>>>>>=20 >>>>> will be of interest https://arxiv.org/pdf/1804.00561.pdf >>>>>=20 >>>>> Regards >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Arjuna Sathiaseelan >>>>> University of Cambridge | Ammbr Research Labs >>>>> Personal: http://www.cl.cam.ac.uk/~as2330/ >>>>> N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d >>>>> _________________________________________________ >>>>> Din mailing list >>>>> Din@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/din >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Din mailing list >>>> Din@irtf.org >>>> https://www.irtf.org/mailman/listinfo/din >>>>=20 >>=20 >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >=20 > -- > Leandro Navarro > http://people.ac.upc.edu/leandro http://dsg.ac.upc.edu Links: 1. http://guifi.net/ --_----------=_152288542324503003 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Thanks Leandro. Our protocol does indeed leave pricing considera= tions un-analyzed. This is something we will unfortunately not be testing i= n a simulation like Jon, we'll have to see how things evolve in the real wo= rld. Some of the insights gained from that paper may prove to be useful.&nb= sp;

The paper that Arjuna shared does indeed provide interesting and rigor= ous experimental results on running a very small consensus network in some = specific network conditions. My criticisms were on the "why" of doing that = and do not detract from the quality of the paper. Thanks for sharing.

--
  Jehan Tremback
  jehan@altheamesh.com



On Wed, Apr 4, 2018, at 4:08 PM, Leandro Navarro wrote:
The paper that Arjuna shared looks to t= he general topic of this WG =E2=80=9CDecentralized Internet Infrastructure= =E2=80=9D, with an evaluation of the Hyperledger framework when running on = a edge scenario of small Debian servers spread in a mesh network (not in th= e routers), instead of a typical data center env.


On 4 Apr 2018, at 17:58, Jehan Tre= mback <jehan@altheamesh.com&= gt; wrote:

Even simpler, by adding a monetary pric= e metric to a distance vector protocol (we are currently testing this in pr= oduction). Skimming your paper, it looks like you are thinking along the sa= me lines.

Simpler but not too simple regarding pricing. Jon=E2=80=99s paper look= ed in 2010 at pricing related to congestion, fairness, incentives for coope= ration, sending rates in flows and overall stability in a local mobile ad-h= oc net. Still relevant work 8 years later.

Back to the A= rjuna's post, the use of a blockchain implies that there is some value to h= aving an immutable transaction ordering mechanism. In our protocol we conce= ptualize these ordered transactions as "payments", while in Arjuna's paper = the actual use of this transaction ordering is left unspecified. 
<= /div>

=E2=80=A6 not an objetive of that research paper (evaluation of Hyperl= edger) !=3D whitepaper.

Running the transa= ction ordering consensus protocol on the network nodes themselves seems lik= e a bad idea.
These no= des have more of an incentive to mess with the ordering than some faraway v= alidators who know nothing about the specific application and are only ince= ntivized to order transactions correctly. Also, the fact that there are alw= ays going to be many fewer validators available on a local network means th= at the consensus pool is smaller and more vulnerable to manipulation.

Hyperledger has strong limitations when running in small servers, let= =E2=80=99s forget about routers, but just relying on remote servers for loc= al transactions can have drawbacks too.

I say, leave = the transaction ordering to a global network of validators who specialize i= n transaction ordering and leave the networking to network hardware equippe= d with light clients. With Althea, we are able to run everything on commodi= ty routers on OpenWRT

Thanks for your comments, Leandro.

.

--
  Jehan Tremback



On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcro= ft wrote:
o= r a much simpler approach:

On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback = <jehan@altheam= esh.com> wrote:

Why run full nodes on your networking hardware? One could achieve= the same security characteristics (or better) by simply using light client= s of a public blockchain on the networking hardware. 

--
  Jehan Tremback



On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote:
we recently did a= n evaluation of the hyperledger fabric in a community wireless network with= in the famous guifi.net= ..


Regards

-- 

Arjuna Sathiaseelan
University of Cambridge | Ammbr Research Labs
_______________________________________________
Din mailing list


_______________________________________________
Din mailing list


______________________________________________= _
Din mailing list

--
Leandro Navarro
http://people.ac.upc.edu/= leandro  http://dsg.ac.upc= .edu

--_----------=_152288542324503003-- From nobody Thu Apr 5 00:39:50 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FFA126DC2 for ; Thu, 5 Apr 2018 00:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWtRDm8Lo1QM for ; Thu, 5 Apr 2018 00:39:46 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774AC120725 for ; Thu, 5 Apr 2018 00:39:45 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id m13so26728436wrj.5 for ; Thu, 05 Apr 2018 00:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oqZb4b/li3Rmg6vEb9Txl7CfgchOKVCSICmnMDc9yVU=; b=TCB1k/k3rlpFggR9va9OHVMMBrwR3lYu9fUz/AFpUhUtC3qf/VFThKRWKi5FPbcdFO UUtslhXfUahOiH5SGi7eVeYLcToMiDeJ8NKH/n4jhAl4XX8aQwu4SYN3Gr/16UlniR3U ZXCJZBKp6DE41B+6pYdV9QYvI1qKUA5Cdj88aIaz3daDtVuY03PgwEDOkctjNzQo2GWQ BjjqpT8a2FJZpn7NPyiXpffDkQc0p6taHYXHazHzxC+/2hV2p5vZ/nsk0fHQXr3hjdaq cPcZyAuhaBIIKZYDkpa0bS/Wm05TcXvnMyCwkN4RuNyGfN7fezkO4sHF6LN+l/9c3UvC BB/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=oqZb4b/li3Rmg6vEb9Txl7CfgchOKVCSICmnMDc9yVU=; b=rviBfj9woFi6Z4RYGlYT3R6ZldbJmHWf30TpmLK46Z982RTYJSZyPU3tDD9WnoQu9j OAGPTGIu0eFIGqVnY90OfLBwwHGW4PA4HxUvOlxGnTzG6ADdoP6GSneKmYOg5VT0Vgg8 shOu7R/DZsy5F7A2388xBxpOdckcTm9e1ISTEU7KNfLopaEqeFUuW6cMGMXx38WuNYpU AjxL5KYFIXd0VRrjLzXCLmba7xAqvMaSVa0+Z3IBtEJ1A1tP8HMSAYFKiXFZsMUubRqf kWKclmfQ10eD3tZJjirxtA9z4bK3HfWFirNuqf1V8OwHkswej045mxD5cD0XQroadTlw cyFw== X-Gm-Message-State: AElRT7FJvMqyCvrfn8jy2k64eoWp2PnaOOQZT8e60BJSYtm3BtlRHOTU RZf5lGbLF2yVVdsvvaRxiQ+Xu3jnY6spxqtlVc0= X-Google-Smtp-Source: AIpwx49gUjEAN1LHiERsFFN4SPUmwzTh2mDbOetSU19W5gj3fCOeVXhZ6AAw7rO+fvycCa9vE8fI6UnePLPqPPPGJi8= X-Received: by 10.223.196.74 with SMTP id a10mr13906801wrg.190.1522913983809; Thu, 05 Apr 2018 00:39:43 -0700 (PDT) MIME-Version: 1.0 Sender: crowcroft@gmail.com Received: by 10.28.167.86 with HTTP; Thu, 5 Apr 2018 00:39:43 -0700 (PDT) In-Reply-To: References: <1522807761.2691505.1325710912.72C042EF@webmail.messagingengine.com> <1522857502.1313779.1326451800.352B185C@webmail.messagingengine.com> From: Jon Crowcroft Date: Thu, 5 Apr 2018 08:39:43 +0100 X-Google-Sender-Auth: Qfy1wrxSpqw8sOTcmqnAKfWaYd8 Message-ID: To: Arjuna Sathiaseelan Cc: Jehan Tremback , din@irtf.org Content-Type: multipart/alternative; boundary="089e08281304074e8f0569150b0f" Archived-At: Subject: Re: [Din] Hyperledger evaluation on a mesh network X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 07:39:48 -0000 --089e08281304074e8f0569150b0f Content-Type: text/plain; charset="UTF-8" right - it is worth knowing, for sure, that such a full-on system can work - lighter alternatives are nice, but compute/storage resources in community nets' nodes can be significant for little captial outlay too! On Wed, Apr 4, 2018 at 9:31 PM, Arjuna Sathiaseelan < arjuna.sathiaseelan@gmail.com> wrote: > Jehan, > > Good points. The aim of the paper was to benchmark HL and understand the > painpoints and hardware requirements. > > So this is the way I see things from Ammbr's point of view: 1. We are > developing hardware (the Ammbr routers) that would function as part of the > blockchain e.g. act as orderers & any node/hardware can still be a light > node within the network - they just cant participate in the consensus. 2. > Our PoET/PoV consensus + the underlying DAO ensures > fairness/decentralisation + does not allow nodes to mess around - any bad > behaviour will involve revoking the certificates by the certification > authority.. > > Regards > > On Wed, 4 Apr 2018, 16:58 Jehan Tremback, wrote: > >> Even simpler, by adding a monetary price metric to a distance vector >> protocol (we are currently testing this in production). Skimming your >> paper, it looks like you are thinking along the same lines. >> >> https://altheamesh.com/documents/whitepaper.pdf >> >> Back to the Arjuna's post, the use of a blockchain implies that there is >> some value to having an immutable transaction ordering mechanism. In our >> protocol we conceptualize these ordered transactions as "payments", while >> in Arjuna's paper the actual use of this transaction ordering is left >> unspecified. >> >> Running the transaction ordering consensus protocol on the network nodes >> themselves seems like a bad idea. These nodes have more of an incentive to >> mess with the ordering than some faraway validators who know nothing about >> the specific application and are only incentivized to order transactions >> correctly. Also, the fact that there are always going to be many fewer >> validators available on a local network means that the consensus pool is >> smaller and more vulnerable to manipulation. >> >> I say, leave the transaction ordering to a global network of validators >> who specialize in transaction ordering and leave the networking to network >> hardware equipped with light clients. With Althea, we are able to run >> everything on commodity routers on OpenWRT. >> >> -- >> Jehan Tremback >> jehan@altheamesh.com >> >> >> >> On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote: >> >> or a much simpler approach: >> https://hal.inria.fr/inria-00466747/document >> >> On Wed, Apr 4, 2018 at 3:09 AM, Jehan Tremback >> wrote: >> >> >> Why run full nodes on your networking hardware? One could achieve the >> same security characteristics (or better) by simply using light clients of >> a public blockchain on the networking hardware. >> >> -- >> Jehan Tremback >> jehan@altheamesh.com >> >> >> >> On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote: >> >> we recently did an evaluation of the hyperledger fabric in a community >> wireless network within the famous guifi.net.. >> >> will be of interest https://arxiv.org/pdf/1804.00561.pdf >> >> Regards >> >> -- >> >> Arjuna Sathiaseelan >> University of Cambridge | Ammbr Research Labs >> Personal: http://www.cl.cam.ac.uk/~as2330/ >> N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d >> *_______________________________________________* >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >> >> >> >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >> >> >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >> > --089e08281304074e8f0569150b0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
right=C2=A0 - it is worth knowing, for sure, that such a f= ull-on system can work - lighter alternatives are nice, but compute/storage= resources in community nets' nodes can be significant for little capti= al outlay too!

On Wed, Apr 4, 2018 at 9:31 PM, Arjuna Sathiaseelan &l= t;arjuna= .sathiaseelan@gmail.com> wrote:
Jehan,

<= div dir=3D"auto">Good points. The aim of the paper was to benchmark HL and = understand the painpoints and hardware requirements.=C2=A0

So this is the way I see things from Amm= br's point of view: 1. We are developing hardware (the Ammbr routers) t= hat would function as part of the blockchain e.g. act as orderers & any= node/hardware can still be a light node within the network - they just can= t participate in the consensus. 2. Our PoET/PoV consensus + the underlying = DAO ensures fairness/decentralisation + does not allow nodes to mess around= - any bad behaviour will involve revoking the certificates by the certific= ation authority..

Regards
=

On W= ed, 4 Apr 2018, 16:58 Jehan Tremback, <jehan@altheamesh.com> wrote:
Even simpler, by adding a monetary price metric to a distance vec= tor protocol (we are currently testing this in production). Skimming your p= aper, it looks like you are thinking along the same lines.


Back to the Arjuna's post, the use of a blockchain implies that th= ere is some value to having an immutable transaction ordering mechanism. In= our protocol we conceptualize these ordered transactions as "payments= ", while in Arjuna's paper the actual use of this transaction orde= ring is left unspecified.=C2=A0

Running the transaction ordering consensus protocol on the network no= des themselves seems like a bad idea. These nodes have more of an incentive= to mess with the ordering than some faraway validators who know nothing ab= out the specific application and are only incentivized to order transaction= s correctly. Also, the fact that there are always going to be many fewer va= lidators available on a local network means that the consensus pool is smal= ler and more vulnerable to manipulation.

I say, leave the transaction ordering to a global network of validator= s who specialize in transaction ordering and leave the networking to networ= k hardware equipped with light clients. With Althea, we are able to run eve= rything on commodity routers on OpenWRT.

--
=C2=A0 Jehan Tremback
=C2=A0 jehan@altheamesh.com



On Wed, Apr 4, 2018, at 1:04 AM, Jon Crowcroft wrote:


Why run full nodes on your networking hardware? One could achieve= the same security characteristics (or better) by simply using light client= s of a public blockchain on the networking hardware.=C2=A0

--
=C2=A0 Jehan Tremback



On Tue, Apr 3, 2018, at 4:44 AM, Arjuna Sathiaseelan wrote:
we recently did a= n evaluation of the hyperledger fabric in a community wireless network with= in the famous guifi.net..


Regards

--

Arjuna Sathiaseelan
University of Cambridge | Ammbr Research Labs
_______________________________________________
Din mailing list


_______________________________________________
Din mailing list


_______________________________________________
Din mailing list
Din@ir= tf.org
https://www.irtf.org/mailman/listinfo/din

--089e08281304074e8f0569150b0f-- From nobody Fri Apr 6 09:35:14 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA201200C5 for ; Fri, 6 Apr 2018 09:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcnbM0YH1OGV for ; Fri, 6 Apr 2018 09:35:09 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C2012025C for ; Fri, 6 Apr 2018 09:35:09 -0700 (PDT) X-AuditID: 12074423-38fff70000001bdd-6b-5ac7a1ba93f4 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B8.F2.07133.BB1A7CA5; Fri, 6 Apr 2018 12:35:07 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w36GZ5P0029132 for ; Fri, 6 Apr 2018 12:35:06 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w36GYGBq021514 for ; Fri, 6 Apr 2018 12:35:05 -0400 Received: from OC11EXHUB10.exchange.mit.edu (18.9.3.24) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 6 Apr 2018 12:34:17 -0400 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.111]) by OC11EXHUB10.exchange.mit.edu ([18.9.3.24]) with mapi id 14.03.0352.000; Fri, 6 Apr 2018 12:34:17 -0400 From: Thomas Hardjono To: "din@irtf.org" Thread-Topic: WSJ article on Identity and Blockchains Thread-Index: AQHTzcUHgLU9VkLMR0+I6ZGjg4OG6Q== Date: Fri, 6 Apr 2018 16:34:16 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsUixCmqrbt74fEog91dehZLP+5lcWD0mLzx MFsAYxSXTUpqTmZZapG+XQJXRufiZqaCPcwV6988Zm9gfMfUxcjJISFgIjHp9XnmLkYuDiGB xUwSn29OBksICVxilLh4wwgicZNR4tycm6wQznZGiaU3rjNBOKsYJd6072UDaWET0JBo+9HL DmKLCChKLG2YyghiCwsYSEy+/guomwMobipx9WUJRImeRNPKVrBtLAIqEiev3mIBsXkFgiR6 OzuYQWxGATGJ76fWgNUwC4hL3HoyH+psQYlFs/cwQ9hiEv92PWQDGS8hICux/LwbRLmOxILd n9ggbG2JZQtfM0OMF5Q4OfMJywRG0VlIps5C0jILScssJC0LGFlWMcqm5Fbp5iZm5hSnJusW Jyfm5aUW6Zrp5WaW6KWmlG5iBEUJu4vyDsaXfd6HGAU4GJV4eCU6j0cJsSaWFVfmHmKU5GBS EuU9aA8U4kvKT6nMSCzOiC8qzUktPsQowcGsJMK7+8+xKCHelMTKqtSifJiUNAeLkjjv4v17 o4QE0hNLUrNTUwtSi2CyMhwcShK85xYADRUsSk1PrUjLzClBSDNxcIIM5wEavhGkhre4IDG3 ODMdIn+KUZej4/2UHmYhlrz8vFQpcd46kCIBkKKM0jy4OZDkxiz0ilEc6C1h3kiQKh5gYoSb 9ApoCRPQkgmJR0CWlCQipKQaGB0+lLGVXAwsbFl+4LmBgN6NmS9Sz4Rc57jNfTlmA3fir8UP k3gnlb6v7RKJy8v1ub6tQCwrmNde1T+Q7xNHIE+vQ+WTJTYnSgPWflfUkN237IXvVJa9T0/d MM14+tp9m809WUZnU5stJyZWlt1knnlUpzAuuP3kHtdPE2cfLHFom6fQl+f3RomlOCPRUIu5 qDgRAJsTYDhJAwAA Archived-At: Subject: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:35:11 -0000 Folks, I thought to share this WSJ article with the DIN group. Relevant in the lig= ht of recent interest in using BC for identity. Advance apologies if it offends some people :-) https://blogs.wsj.com/cio/2018/04/03/digital-identity-is-broken-heres-a-way= -to-fix-it/ Below is a link to a PDF version. http://hardjono.mit.edu/sites/default/files/documents/WSJ_Digital_Identity_= is_Broken.pdf Best -- thomas --=20 From nobody Sun Apr 8 03:38:59 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0FD12895E for ; Sun, 8 Apr 2018 03:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWBS5oU_bVvK for ; Sun, 8 Apr 2018 03:38:56 -0700 (PDT) Received: from mta0.cl.cam.ac.uk (mta0.cl.cam.ac.uk [128.232.25.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13DD12426E for ; Sun, 8 Apr 2018 03:38:55 -0700 (PDT) Received: from ely.cl.cam.ac.uk ([128.232.64.213] ident=jac22) by mta0.cl.cam.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1f57in-0004gH-Gx; Sun, 08 Apr 2018 11:38:53 +0100 From: Jon Crowcroft To: Thomas Hardjono cc: "din@irtf.org" , Jon Crowcroft In-reply-to: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> Comments: In-reply-to Thomas Hardjono message dated "Fri, 06 Apr 2018 16:34:16 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36114.1523183933.1@ely.cl.cam.ac.uk> Content-Transfer-Encoding: quoted-printable Date: Sun, 08 Apr 2018 11:38:53 +0100 Message-Id: Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 10:38:58 -0000 very nice article... so you _are_ your social network...in terms of trustworthy identity...sure= ... there's two problems with this though in details... i.e. how we build on this idea technically in the Din context... 1/ its still dependent on technologies, = and there's a seperate issue of why we trust them to proxy our social net = - i certainly would it find it hard to trust any social media app, running o= n a cloud platform, using a smart mobile device, to vouch for all these friends & colleagues -= too many layers, too many vested interests, too much Cambridge Analytica :) 2/ I though many people in the security community were moving away from proving identity, towards systems that prove entitlement (i.e. credentials are on a need-to-know basis, so if you were say 19, you don't need to say = yur age or show id, = but you can't buy a drink in cambridge MA, but you can in cambridge, UK :) bootstrapping something from a BC to provide the credentials is also probl= ematic, in that BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we ha= ve a circular dependance, no? maybe i missed an important step, if so, sorry! > Folks, > = > I thought to share this WSJ article with the DIN group. Relevant in the = > light of recent interest in using BC for identity. > = > Advance apologies if it offends some people :-) > = > https://blogs.wsj.com/cio/2018/04/03/digital-identity-is-broken-heres-a-= way-to-fix-it/ > = > = > Below is a link to a PDF version. > = > http://hardjono.mit.edu/sites/default/files/documents/WSJ_Digital_Identi= ty_is_Broken.pdf > = > = > Best > = > -- thomas -- > = > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > = From nobody Sun Apr 8 07:06:32 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E4D129C6C for ; Sun, 8 Apr 2018 07:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz1crvIClgqU for ; Sun, 8 Apr 2018 07:06:29 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6118127444 for ; Sun, 8 Apr 2018 07:06:28 -0700 (PDT) X-AuditID: 1209190f-081ff70000006063-bc-5aca21e2a15a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 33.A2.24675.3E12ACA5; Sun, 8 Apr 2018 10:06:27 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w38E6M69001563; Sun, 8 Apr 2018 10:06:24 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w38E6J6R018741; Sun, 8 Apr 2018 10:06:20 -0400 Received: from OC11EXHUB7.exchange.mit.edu (18.9.3.19) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 8 Apr 2018 10:06:08 -0400 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.111]) by OC11EXHUB7.exchange.mit.edu ([18.9.3.19]) with mapi id 14.03.0352.000; Sun, 8 Apr 2018 10:06:19 -0400 From: Thomas Hardjono To: "jon.crowcroft@cl.cam.ac.uk" CC: "din@irtf.org" Thread-Topic: [Din] WSJ article on Identity and Blockchains Thread-Index: AQHTzcUHgLU9VkLMR0+I6ZGjg4OG6aP28xeA///pVR8= Date: Sun, 8 Apr 2018 14:06:18 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AE73FCF8A@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJKsWRmVeSWpSXmKPExsUixG6novtY8VSUwfm5phZLP+5lsXhw8QmT A5PH1tbjLB6TNx5mC2CK4rJJSc3JLEst0rdL4Mo4vnISe8FMo4qGQ6uYGxhbNLoYOTkkBEwk Vjb1MXUxcnEICSxmkvh4o58ZJCEksJ9RYvYxAYjEMUaJuQfmsUA42xglFr68ywhRtZJR4kJH BIjNJqAh0fajlx3EFhGwlZh5YyFYDbOAokTX5CYmEFtYwEpi/b31bF2MHEA11hJ7lodDlFtJ 9Ly4CNbKIqAicefXYSaQEl6BIIlpS7kgNlVITG2+yQpicwoYSazqbAObziggJvH91BomiE3i EreezGeCeExQYtHsPcwQtpjEv10P2SBsWYlfp69DXaYjsWD3JzYIW1ti2cLXYPW8QL0nZz5h mcAoMQvJ2FlIWmYhaZmFpGUBI8sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwSvdSU0k2M oPjjlOTfwTinwfsQowAHoxIP7wzVk1FCrIllxZW5hxglOZiURHkP2h+PEuJLyk+pzEgszogv Ks1JLT7EKMHBrCTCy+sCVM6bklhZlVqUD5OS5mBREuddtH9vlJBAemJJanZqakFqEUxWhoND SYJXFZhmhASLUtNTK9Iyc0oQ0kwcnCDDeYCGP1AAquEtLkjMLc5Mh8ifYjTmmPSxp4eZo+P9 lB5mIZa8/LxUKXFeBZBxAiClGaV5cNPAKZSTWfAVozjQc8K8d0AG8gDTL9y8V0CrmIBWfUo4 AbKqJBEhJdXAWD1bP13nZFlAKu85D6Y3u7wfbZkmzf3jqWrd3fzn/0zOhAksZzi1uLnqruGz fsn4c+s9S7hdjh5Yel+yWGEb5wqnjdVXm3+ZnmG2qlFSyRe7fv7uXrn7y7pCTB55mNz6mMAa lzuvd9/8izGvnu+uyN73hsFFQSler3Bb0M1tATP3/9d8PY1jkRJLcUaioRZzUXEiAFUQ/iZ8 AwAA Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 14:06:31 -0000 Thanks Jon. Aside from the obvious goal of cutting through the current hype about "Self= -Sovereign Identity" and how Blockchains (BC) will achieve "my sovereignty"= , we wanted to communicate to the general reader that the problem of "ide= ntity" is not so simple. >>> so you _are_ your social network...in terms of trustworthy identity...s= ure... No, not so simple, particularly when the social network is FB :-)=20 >>> there's two problems with this though in details... >>> i.e. how we build on this idea technically in the Din context... >>> 1/ its still dependent on technologies, >>> and there's a seperate issue of why we trust them to proxy our social n= et - >>> i certainly would it find it hard to trust any social media app, runnin= g on a cloud platform, >>> using a smart mobile device, to vouch for all these friends & colleague= s - too many layers, too many >>> vested interests, too much Cambridge Analytica :) You've hit the nail, as usual - thank you Jon :-) The question is how to capture/use/protect the human-to-human interaction a= s the basis for trust ("local trust"). Here is an example. So my local town here in the US has a private mailing-l= ist for local residents only. I have to attend town meetings in-person befo= re I can get on to that mailing-list. There is no reason why my local town cannot run their own "social platform"= (we are in the age of VMs, Containers, Clouds). It must legally owned by = the town/community, and available to residents only (i.e. who pay local tax= ), etc. How do we create next-gen architectures/protocols/legal that support local = communities to interact on their own "social platform" , and become the st= arting point for "trust" that can scale out (called "local trust" in the WS= J paper). I think there is huge role for DIN to help. For the future distributed Inte= rnet infrastructure, is it possible to have the following: -- Can my town obtain a "social-platform-on-demand" from a cloud service pr= ovider. -- Can I legally prevent the service-operator from "making use" of my data = (yes they still may be able to steal my data). -- Can I retain legal ownership of my data (same with my town). -- Can I encrypt my data on my town's social-platform so that the service-o= perator doesn't steal it. -- How to do key management. -- How can I use legal smart-contracts to bind the service-operator. -- Etc. etc. lots more questions for DIN RG. >>> 2/ I though many people in the security community were moving away from >>> proving identity, towards systems that prove entitlement (i.e. credenti= als >>> are on a need-to-know basis, so if you were say 19, you don't need to s= ay yur age or show id, >>> but you can't buy a drink in cambridge MA, but you can in cambridge, UK= :) Yes, correct. Currently people are focusing on proving entitlements via sig= ned assertions. Great, no issue there. But the real question is about the *= data* and *algorithms* behind those assertions (that impact my life, like c= redit-score): -- How do I know that an organization has subject-data about me (usual ques= tions of "how, what, when, what are you doing to my data"). -- What is the provenance of the data in their possession (Did they get it= from a data-aggregator? Do they even know?) -- Does the data set have in-built bias? (not intentionally) -- Is the data "fair" (fairness in the sense of machine learning). -- What is the accuracy of the algorithms computed on my data. Does it prop= agate the bias in the data. -- Do I get to see the algorithms that impact my life. -- Can I hire an expert to provide objective review of these algorithms. -- etc. etc. etc. >>> bootstrapping something from a BC to provide the credentials is also pr= oblematic, in that >>> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we= have a circular dependance, no? Yes, agree. There is need to revisit PKI again, maybe opportunity in DIN R= G to improve it. Hashing an identifier (and back-links) to a BC doesn't help the identity/tr= ust problems. Hashing a pub-key to a BC also doesn't add much. >>> maybe i missed an important step, if so, sorry! Nope, you are on the right track :-) Hope you can help solve some these pr= oblems. Best. -- thomas --=20 ________________________________________ From: Jon Crowcroft [Jon.Crowcroft@cl.cam.ac.uk] Sent: Sunday, April 08, 2018 6:38 AM To: Thomas Hardjono Cc: din@irtf.org; Jon Crowcroft Subject: Re: [Din] WSJ article on Identity and Blockchains very nice article... so you _are_ your social network...in terms of trustworthy identity...sure.= .. there's two problems with this though in details... i.e. how we build on this idea technically in the Din context... 1/ its still dependent on technologies, and there's a seperate issue of why we trust them to proxy our social net - i certainly would it find it hard to trust any social media app, running on= a cloud platform, using a smart mobile device, to vouch for all these friends & colleagues - = too many layers, too many vested interests, too much Cambridge Analytica :) 2/ I though many people in the security community were moving away from proving identity, towards systems that prove entitlement (i.e. credentials are on a need-to-know basis, so if you were say 19, you don't need to say y= ur age or show id, but you can't buy a drink in cambridge MA, but you can in cambridge, UK :) bootstrapping something from a BC to provide the credentials is also proble= matic, in that BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we hav= e a circular dependance, no? maybe i missed an important step, if so, sorry! > Folks, > > I thought to share this WSJ article with the DIN group. Relevant in the > light of recent interest in using BC for identity. > > Advance apologies if it offends some people :-) > > https://blogs.wsj.com/cio/2018/04/03/digital-identity-is-broken-heres-a-w= ay-to-fix-it/ > > > Below is a link to a PDF version. > > http://hardjono.mit.edu/sites/default/files/documents/WSJ_Digital_Identit= y_is_Broken.pdf > > > Best > > -- thomas -- > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din >= From nobody Sun Apr 8 07:20:18 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE55B127444 for ; Sun, 8 Apr 2018 07:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd9xQkUKrEvu for ; Sun, 8 Apr 2018 07:20:14 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F20126DED for ; Sun, 8 Apr 2018 07:20:13 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id c24so5870771wrc.6 for ; Sun, 08 Apr 2018 07:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=a9o9q0JVmPUquSNtTL5JKse3oeTaMmYuc4uqM8os3vA=; b=M6mma9aYexUEoHtoFJ7QXLt7QWaBO6Qtibr9UmjKov/rhtw/FOSpv9wfqelNpgIPha Ksfd2KJC9dz78KTy+qQEeXzNDWjXezOzN09fZpyU51RXB5jr9t1QSV/OL8yka2zr+wxD FUui7wIjSGzxEiFL/0T2OcVVx2BgTuoTy9YUtqPOZvA65hns4aIKkugKuY+7TomHjZW+ 6BLBnNbZeNslXY9XRfTIgV5CZldGNTUTUV9naS8azAIUrhAUl9yAN1yEcNj6OllyGKBG EvqkdHyvygZkc+5KDnGkqiDFuWJBDAmlsOTJY+x8AxRM1hLl8S7rIXFKqE8rPoCfDxH2 xM7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=a9o9q0JVmPUquSNtTL5JKse3oeTaMmYuc4uqM8os3vA=; b=lJHW1QNNVpPkpiHN7Fy0S3DdmsjnT7PZ8OQMMqkPfFLYGw57cLW2sla1InbXfQqmXp U3UO6B6E0fwGmj6xc4p3JKhZwlulmH86wLozNziGA6ipwcOxSvF7cZ+X0JS9jy59QhXq hiFkdpsU0qtmI3o07+i4rR/OVhGUSx/+r99esg/zFVmwFL3s463nqIpE4nz18sHgJXHG CMTjYWC789RDrdM366d591yaRM3cSGWNSJUItJF1OuCL+xivfOldreh0C0nJEYo0G7/Z xMS2AH7rjIzPohZwzIa93IUdf8qQy37086GqJ8nrV4tKECFFA+JHYtjUX/EWFL2a8RFT ZmMw== X-Gm-Message-State: ALQs6tCkVnqrRrJSmwtmVo+ijZFQcwQHdR1jUpMecvAh6gHcJMvGOxII LzbvXiLadXe6eU2HKNcET0Ovnqzrh8jXXmB+fjA= X-Google-Smtp-Source: AIpwx49stqjJQ+E98RHnP8AQCL/2NhIoRU3BJSVNCKgd+QtnHiBqG5bntZaGYmoIiNZ+1tucbuuxAsg6NQtlAysQUGE= X-Received: by 10.223.219.10 with SMTP id s10mr4237383wri.241.1523197212043; Sun, 08 Apr 2018 07:20:12 -0700 (PDT) MIME-Version: 1.0 Sender: crowcroft@gmail.com Received: by 10.28.167.86 with HTTP; Sun, 8 Apr 2018 07:20:10 -0700 (PDT) In-Reply-To: <5E393DF26B791A428E5F003BB6C5342AE73FCF8A@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <5E393DF26B791A428E5F003BB6C5342AE73FCF8A@OC11EXPO33.exchange.mit.edu> From: Jon Crowcroft Date: Sun, 8 Apr 2018 15:20:10 +0100 X-Google-Sender-Auth: voWVgPUn_JfDNDC5KJlfOe4hzbA Message-ID: To: Thomas Hardjono Cc: "din@irtf.org" Content-Type: multipart/alternative; boundary="883d24f249c4bf2d75056956fcb7" Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 14:20:17 -0000 --883d24f249c4bf2d75056956fcb7 Content-Type: text/plain; charset="UTF-8" this al sounds excellent - socially rooted, community operated communities - all good - we could think of building instances of this on the infrastructure we've been constructing (i know there are lots of other people building similar, so this is a bit of gratuitous self-aggrandizing:), viz http://www.databoxproject.uk/ there are some decentralisation movements in the certificate space (CA transparency) as wel as self-certifying address allocation. so I assume there's some hope for using these to bootstrap the platforms-on-demand, safely for communities you're envisaging - we're definitely on same page here! On Sun, Apr 8, 2018 at 3:06 PM, Thomas Hardjono wrote: > > Thanks Jon. > > Aside from the obvious goal of cutting through the current hype about > "Self-Sovereign Identity" and how Blockchains (BC) will achieve "my > sovereignty", we wanted to communicate to the general reader that the > problem of "identity" is not so simple. > > >>> so you _are_ your social network...in terms of trustworthy > identity...sure... > > No, not so simple, particularly when the social network is FB :-) > > > >>> there's two problems with this though in details... > >>> i.e. how we build on this idea technically in the Din context... > > >>> 1/ its still dependent on technologies, > >>> and there's a seperate issue of why we trust them to proxy our social > net - > >>> i certainly would it find it hard to trust any social media app, > running on a cloud platform, > >>> using a smart mobile device, to vouch for all these friends & > colleagues - too many layers, too many > >>> vested interests, too much Cambridge Analytica :) > > You've hit the nail, as usual - thank you Jon :-) > > The question is how to capture/use/protect the human-to-human interaction > as the basis for trust ("local trust"). > > Here is an example. So my local town here in the US has a private > mailing-list for local residents only. I have to attend town meetings > in-person before I can get on to that mailing-list. > > There is no reason why my local town cannot run their own "social > platform" (we are in the age of VMs, Containers, Clouds). It must legally > owned by the town/community, and available to residents only (i.e. who pay > local tax), etc. > > How do we create next-gen architectures/protocols/legal that support local > communities to interact on their own "social platform" , and become the > starting point for "trust" that can scale out (called "local trust" in the > WSJ paper). > > > I think there is huge role for DIN to help. For the future distributed > Internet infrastructure, is it possible to have the following: > > -- Can my town obtain a "social-platform-on-demand" from a cloud service > provider. > -- Can I legally prevent the service-operator from "making use" of my data > (yes they still may be able to steal my data). > -- Can I retain legal ownership of my data (same with my town). > -- Can I encrypt my data on my town's social-platform so that the > service-operator doesn't steal it. > -- How to do key management. > -- How can I use legal smart-contracts to bind the service-operator. > -- Etc. etc. lots more questions for DIN RG. > > > > >>> 2/ I though many people in the security community were moving away from > >>> proving identity, towards systems that prove entitlement (i.e. > credentials > >>> are on a need-to-know basis, so if you were say 19, you don't need to > say yur age or show id, > >>> but you can't buy a drink in cambridge MA, but you can in cambridge, > UK :) > > Yes, correct. Currently people are focusing on proving entitlements via > signed assertions. Great, no issue there. But the real question is about > the *data* and *algorithms* behind those assertions (that impact my life, > like credit-score): > > -- How do I know that an organization has subject-data about me (usual > questions of "how, what, when, what are you doing to my data"). > -- What is the provenance of the data in their possession (Did they get > it from a data-aggregator? Do they even know?) > -- Does the data set have in-built bias? (not intentionally) > -- Is the data "fair" (fairness in the sense of machine learning). > -- What is the accuracy of the algorithms computed on my data. Does it > propagate the bias in the data. > -- Do I get to see the algorithms that impact my life. > -- Can I hire an expert to provide objective review of these algorithms. > -- etc. etc. etc. > > > > >>> bootstrapping something from a BC to provide the credentials is also > problematic, in that > >>> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so > we have a circular dependance, no? > > Yes, agree. There is need to revisit PKI again, maybe opportunity in DIN > RG to improve it. > > Hashing an identifier (and back-links) to a BC doesn't help the > identity/trust problems. > Hashing a pub-key to a BC also doesn't add much. > > > >>> maybe i missed an important step, if so, sorry! > > Nope, you are on the right track :-) Hope you can help solve some these > problems. > > Best. > > > -- thomas -- > > ________________________________________ > From: Jon Crowcroft [Jon.Crowcroft@cl.cam.ac.uk] > Sent: Sunday, April 08, 2018 6:38 AM > To: Thomas Hardjono > Cc: din@irtf.org; Jon Crowcroft > Subject: Re: [Din] WSJ article on Identity and Blockchains > > very nice article... > > so you _are_ your social network...in terms of trustworthy > identity...sure... > > there's two problems with this though in details... > i.e. how we build on this idea technically in the Din context... > > 1/ its still dependent on technologies, > and there's a seperate issue of why we trust them to proxy our social net - > i certainly would it find it hard to trust any social media app, running > on a cloud platform, > using a smart mobile device, to vouch for all these friends & colleagues - > too many layers, too many > vested interests, too much Cambridge Analytica :) > > 2/ I though many people in the security community were moving away from > proving identity, towards systems that prove entitlement (i.e. credentials > are on a need-to-know basis, so if you were say 19, you don't need to say > yur age or show id, > but you can't buy a drink in cambridge MA, but you can in cambridge, UK :) > > bootstrapping something from a BC to provide the credentials is also > problematic, in that > BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we > have a circular dependance, no? > > maybe i missed an important step, if so, sorry! > > > > Folks, > > > > I thought to share this WSJ article with the DIN group. Relevant in the > > light of recent interest in using BC for identity. > > > > Advance apologies if it offends some people :-) > > > > https://blogs.wsj.com/cio/2018/04/03/digital-identity- > is-broken-heres-a-way-to-fix-it/ > > > > > > Below is a link to a PDF version. > > > > http://hardjono.mit.edu/sites/default/files/documents/WSJ_ > Digital_Identity_is_Broken.pdf > > > > > > Best > > > > -- thomas -- > > > > _______________________________________________ > > Din mailing list > > Din@irtf.org > > https://www.irtf.org/mailman/listinfo/din > > > --883d24f249c4bf2d75056956fcb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
this al sounds excellent - socially rooted, community oper= ated communities - all good - we could think of building instances of this = on the infrastructure we've been constructing (i know there are lots of= other people building similar, so this is a bit of gratuitous self-aggrand= izing:), viz

there are some decentralisation = movements in the certificate space (CA transparency) as wel as self-certify= ing address allocation. so I assume there's some hope for using these t= o bootstrap the platforms-on-demand, safely for=C2=A0 communities you'r= e envisaging -=C2=A0

we're definitely on same = page here!


On Sun, Apr 8, 2018 at 3:06 PM, Thomas Hardjono <ha= rdjono@mit.edu> wrote:

Thanks Jon.

Aside from the obvious goal of cutting through the current hype about "= ;Self-Sovereign Identity" and how Blockchains (BC) will achieve "= my sovereignty",=C2=A0 we wanted to communicate to the general=C2=A0 r= eader that the problem of "identity" is not so simple.

>>> so you _are_ your social network...in terms of trustworthy ide= ntity...sure...

No, not so simple, particularly when the social network is FB :-)

>>> there's two problems with this though in details...
>>> i.e. how we build on this idea technically in the Din context.= ..

>>> 1/ its still dependent on technologies,
>>> and there's a seperate issue of why we trust them to proxy= our social net -
>>> i certainly would it find it hard to trust any social media ap= p, running on a cloud platform,
>>> using a smart mobile device, to vouch for all these friends &a= mp; colleagues - too many layers, too many
>>> vested interests, too much Cambridge Analytica :)

You've hit the nail, as usual - thank you Jon :-)

The question is how to capture/use/protect the human-to-human interaction a= s the basis for trust ("local trust").

Here is an example. So my local town here in the US has a private mailing-l= ist for local residents only. I have to attend town meetings in-person befo= re I can get on to that mailing-list.

There is no reason why my local town cannot run their own "social plat= form" (we are in the age of VMs, Containers, Clouds).=C2=A0 It must le= gally owned by the town/community, and available to residents only (i.e. wh= o pay local tax), etc.

How do we create next-gen architectures/protocols/legal that support local = communities to interact=C2=A0 on their own "social platform" , an= d become the starting point for "trust" that can scale out (calle= d "local trust" in the WSJ paper).


I think there is huge role for DIN to help. For the future distributed Inte= rnet infrastructure, is it possible to have the following:

-- Can my town obtain a "social-platform-on-demand" from a cloud = service provider.
-- Can I legally prevent the service-operator from "making use" o= f my data (yes they still may be able to steal my data).
-- Can I retain legal ownership of my data (same with my town).
-- Can I encrypt my data on my town's social-platform so that the servi= ce-operator doesn't steal it.
-- How to do key management.
-- How can I use legal smart-contracts to bind the service-operator.
-- Etc. etc. lots more questions for DIN RG.



>>> 2/ I though many people in the security community were moving = away from
>>> proving identity, towards systems that prove entitlement (i.e.= credentials
>>> are on a need-to-know basis, so if you were say 19, you don= 9;t need to say yur age or show id,
>>> but you can't buy a drink in cambridge MA, but you can in = cambridge, UK :)

Yes, correct. Currently people are focusing on proving entitlements = via signed assertions. Great, no issue there. But the real question is abou= t the *data* and *algorithms* behind those assertions (that impact my life,= like credit-score):

-- How do I know that an organization has subject-data about me (usual ques= tions of "how, what, when, what are you doing to my data").
-- What is the provenance of the data in their possession=C2=A0 (Did they g= et it from a data-aggregator? Do they even know?)
-- Does the data set have in-built bias? (not intentionally)
-- Is the data "fair"=C2=A0 (fairness in the sense of machine lea= rning).
-- What is the accuracy of the algorithms computed on my data. Does it prop= agate the bias in the data.
-- Do I get to see the algorithms that impact my life.
-- Can I hire an expert to provide objective review of these algorithms. -- etc. etc. etc.



>>> bootstrapping something from a BC to provide the credentials i= s also problematic, in that
>>> BC needs a PKI to know whether nodes are not sybils, spoofs, e= tc, so we have a circular dependance, no?

Yes, agree.=C2=A0 There is need to revisit PKI again, maybe opportun= ity in DIN RG to improve it.

Hashing an identifier (and back-links) to a BC doesn't help the identit= y/trust problems.
Hashing a pub-key to a BC also doesn't add much.


>>> maybe i missed an important step, if so, sorry!

Nope, you are on the right track :-)=C2=A0 Hope you can help solve s= ome these problems.

Best.


-- thomas --

________________________________________
From: Jon Crowcroft [Jon.Crow= croft@cl.cam.ac.uk]
Sent: Sunday, April 08, 2018 6:38 AM
To: Thomas Hardjono
Cc: din@irtf.org; Jon Crowcroft
Subject: Re: [Din] WSJ article on Identity and Blockchains

very nice article...

so you _are_ your social network...in terms of trustworthy identity...sure.= ..

there's two problems with this though in details...
i.e. how we build on this idea technically in the Din context...

1/ its still dependent on technologies,
and there's a seperate issue of why we trust them to proxy our social n= et -
i certainly would it find it hard to trust any social media app, running on= a cloud platform,
using a smart mobile device, to vouch for all these friends & colleague= s - too many layers, too many
vested interests, too much Cambridge Analytica :)

2/ I though many people in the security community were moving away from
proving identity, towards systems that prove entitlement (i.e. credentials<= br> are on a need-to-know basis, so if you were say 19, you don't need to s= ay yur age or show id,
but you can't buy a drink in cambridge MA, but you can in cambridge, UK= :)

bootstrapping something from a BC to provide the credentials is also proble= matic, in that
BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we hav= e a circular dependance, no?

maybe i missed an important step, if so, sorry!


> Folks,
>
> I thought to share this WSJ article with the DIN group. Relevant in th= e
> light of recent interest in using BC for identity.
>
> Advance apologies if it offends some people :-)
>
> https://b= logs.wsj.com/cio/2018/04/03/digital-identity-is-broken-heres-a-wa= y-to-fix-it/
>
>
> Below is a link to a PDF version.
>
> http://= hardjono.mit.edu/sites/default/files/documents/WSJ_Digital_Identi= ty_is_Broken.pdf
>
>
> Best
>
> -- thomas --
>
> _______________________________________________
> Din mailing list
> Din@irtf.org
> https://www.irtf.org/mailman/listinfo/din
>

--883d24f249c4bf2d75056956fcb7-- From nobody Sun Apr 8 13:41:40 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A3A12D7F3 for ; Sun, 8 Apr 2018 13:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1np5PGJbKpy for ; Sun, 8 Apr 2018 13:41:31 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7671205D3 for ; Sun, 8 Apr 2018 13:41:31 -0700 (PDT) X-AuditID: 1209190f-42dff700000020d2-13-5aca7e7ae737 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 98.0C.08402.A7E7ACA5; Sun, 8 Apr 2018 16:41:30 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w38KfT0d026766; Sun, 8 Apr 2018 16:41:29 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (OC11EXEDGE4.EXCHANGE.MIT.EDU [18.9.3.27]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w38KfRR1013442; Sun, 8 Apr 2018 16:41:27 -0400 Received: from W92EXCAS22.exchange.mit.edu (18.7.71.37) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 8 Apr 2018 16:41:11 -0400 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.111]) by w92excas22.exchange.mit.edu ([18.7.71.37]) with mapi id 14.03.0352.000; Sun, 8 Apr 2018 16:41:26 -0400 From: Thomas Hardjono To: "jon.crowcroft@cl.cam.ac.uk" CC: "din@irtf.org" Thread-Topic: [Din] WSJ article on Identity and Blockchains Thread-Index: AQHTzcUHgLU9VkLMR0+I6ZGjg4OG6aP28xeA///pVR+AAFR/AIAAJgUB Date: Sun, 8 Apr 2018 20:41:25 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AE73FD85D@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <5E393DF26B791A428E5F003BB6C5342AE73FCF8A@OC11EXPO33.exchange.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLKsWRmVeSWpSXmKPExsUixCmqrFtVdyrK4OpPWYulH/eyWDy4+ITJ gclja+txFo/JGw+zBTBFcdmkpOZklqUW6dslcGVM/veVtWCXU8WDXzPZGxj3mHYxcnJICJhI HGl5ztzFyMUhJLCYSeLX+TdMEM5+Ron392Eyxxglnqx4DpXZxijxYf4sFghnFaPE9tULmECG sQloSLT96GUHsUUEbCUOXjwMZjMLKEp0TW4CqxEWsJJYf289WxcjB1CNtcSe5eEQ5W4Skxcf ZAaxWQRUJL78XAnWyisQJLFn4nVGiF0dTBL/5/1iAUlwCgRKtD94yAZiMwqISXw/tYYJYpe4 xK0n85kgnhOUWDR7DzOELSbxbxdEvYSArMSv0yBDQep1JBbs/sQGYWtLLFv4mhlisaDEyZlP WCYwSsxCMnYWkpZZSFpmIWlZwMiyilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdELzezRC81pXQT IzgOJfl3MM5p8D7EKMDBqMTDO0P1ZJQQa2JZcWXuIUZJDiYlUd6D9sejhPiS8lMqMxKLM+KL SnNSiw8xSnAwK4nw3q06FSXEm5JYWZValA+TkuZgURLnXbR/b5SQQHpiSWp2ampBahFMVoaD Q0mC17gWqFGwKDU9tSItM6cEIc3EwQkynAdouClIDW9xQWJucWY6RP4UozHHpI89PcwcHe+n 9DALseTl56VKifNGgpQKgJRmlObBTYOkUmbpV4ziQM8J87KBVPEA0zDcvFdAq5iAVn1KOAGy qiQRISXVwNgyZS4TA0dZd+gUntr8QxIxzv3bW3yex56P+/98xh/Hu1Ya/so738+f85rBb1VJ fBPDWjXGt+r/zcyvLv3YskHsUFnUZ+Zz5WmPPqUY93748dGsbzNfxPlp7St61sgE3PYoEDn5 r0lJ7dvK0nz/hw8OqUi6PNv2/taaj+xuezb+c01Y/MZxmagSS3FGoqEWc1FxIgBtEGr/gAMA AA== Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 20:41:39 -0000 Thanks Jon, >>> this al sounds excellent - socially rooted, community operated=20 >>> communities - all good - we could think of building instances=20 >>> of this on the infrastructure we've been constructing=20 >>> (i know there are lots of other people building similar,=20 >>> so this is a bit of gratuitous self-aggrandizing:), viz >>> http://www.databoxproject.uk/ Very interesting. In the Kantara Initiative we've been looking it mechanisms for controlling access to "resources" -- which translates to files etc located in a data store (including personal data store). There is the access control aspect & and also the consent/receipts aspect. One thing that would be useful is a "Standardized API" (e.g. REST API) for personal data stores (regardless where they sit, e.g. in Cloud; on Mobi= le; on Home-PC). Would this (APIs) be something DIN RG could explore? I will take a close look at databoxproject. -- thomas --=20 ________________________________________ From: crowcroft@gmail.com [crowcroft@gmail.com] on behalf of Jon Crowcroft = [jon.crowcroft@cl.cam.ac.uk] Sent: Sunday, April 08, 2018 10:20 AM To: Thomas Hardjono Cc: din@irtf.org Subject: Re: [Din] WSJ article on Identity and Blockchains this al sounds excellent - socially rooted, community operated communities = - all good - we could think of building instances of this on the infrastruc= ture we've been constructing (i know there are lots of other people buildin= g similar, so this is a bit of gratuitous self-aggrandizing:), viz http://www.databoxproject.uk/ there are some decentralisation movements in the certificate space (CA tran= sparency) as wel as self-certifying address allocation. so I assume there's= some hope for using these to bootstrap the platforms-on-demand, safely for= communities you're envisaging - we're definitely on same page here! On Sun, Apr 8, 2018 at 3:06 PM, Thomas Hardjono > wrote: Thanks Jon. Aside from the obvious goal of cutting through the current hype about "Self= -Sovereign Identity" and how Blockchains (BC) will achieve "my sovereignty"= , we wanted to communicate to the general reader that the problem of "ide= ntity" is not so simple. >>> so you _are_ your social network...in terms of trustworthy identity...s= ure... No, not so simple, particularly when the social network is FB :-) >>> there's two problems with this though in details... >>> i.e. how we build on this idea technically in the Din context... >>> 1/ its still dependent on technologies, >>> and there's a seperate issue of why we trust them to proxy our social n= et - >>> i certainly would it find it hard to trust any social media app, runnin= g on a cloud platform, >>> using a smart mobile device, to vouch for all these friends & colleague= s - too many layers, too many >>> vested interests, too much Cambridge Analytica :) You've hit the nail, as usual - thank you Jon :-) The question is how to capture/use/protect the human-to-human interaction a= s the basis for trust ("local trust"). Here is an example. So my local town here in the US has a private mailing-l= ist for local residents only. I have to attend town meetings in-person befo= re I can get on to that mailing-list. There is no reason why my local town cannot run their own "social platform"= (we are in the age of VMs, Containers, Clouds). It must legally owned by = the town/community, and available to residents only (i.e. who pay local tax= ), etc. How do we create next-gen architectures/protocols/legal that support local = communities to interact on their own "social platform" , and become the st= arting point for "trust" that can scale out (called "local trust" in the WS= J paper). I think there is huge role for DIN to help. For the future distributed Inte= rnet infrastructure, is it possible to have the following: -- Can my town obtain a "social-platform-on-demand" from a cloud service pr= ovider. -- Can I legally prevent the service-operator from "making use" of my data = (yes they still may be able to steal my data). -- Can I retain legal ownership of my data (same with my town). -- Can I encrypt my data on my town's social-platform so that the service-o= perator doesn't steal it. -- How to do key management. -- How can I use legal smart-contracts to bind the service-operator. -- Etc. etc. lots more questions for DIN RG. >>> 2/ I though many people in the security community were moving away from >>> proving identity, towards systems that prove entitlement (i.e. credenti= als >>> are on a need-to-know basis, so if you were say 19, you don't need to s= ay yur age or show id, >>> but you can't buy a drink in cambridge MA, but you can in cambridge, UK= :) Yes, correct. Currently people are focusing on proving entitlements via sig= ned assertions. Great, no issue there. But the real question is about the *= data* and *algorithms* behind those assertions (that impact my life, like c= redit-score): -- How do I know that an organization has subject-data about me (usual ques= tions of "how, what, when, what are you doing to my data"). -- What is the provenance of the data in their possession (Did they get it= from a data-aggregator? Do they even know?) -- Does the data set have in-built bias? (not intentionally) -- Is the data "fair" (fairness in the sense of machine learning). -- What is the accuracy of the algorithms computed on my data. Does it prop= agate the bias in the data. -- Do I get to see the algorithms that impact my life. -- Can I hire an expert to provide objective review of these algorithms. -- etc. etc. etc. >>> bootstrapping something from a BC to provide the credentials is also pr= oblematic, in that >>> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we= have a circular dependance, no? Yes, agree. There is need to revisit PKI again, maybe opportunity in DIN R= G to improve it. Hashing an identifier (and back-links) to a BC doesn't help the identity/tr= ust problems. Hashing a pub-key to a BC also doesn't add much. >>> maybe i missed an important step, if so, sorry! Nope, you are on the right track :-) Hope you can help solve some these pr= oblems. Best. -- thomas -- ________________________________________ From: Jon Crowcroft [Jon.Crowcroft@cl.cam.ac.uk] Sent: Sunday, April 08, 2018 6:38 AM To: Thomas Hardjono Cc: din@irtf.org; Jon Crowcroft Subject: Re: [Din] WSJ article on Identity and Blockchains very nice article... so you _are_ your social network...in terms of trustworthy identity...sure.= .. there's two problems with this though in details... i.e. how we build on this idea technically in the Din context... 1/ its still dependent on technologies, and there's a seperate issue of why we trust them to proxy our social net - i certainly would it find it hard to trust any social media app, running on= a cloud platform, using a smart mobile device, to vouch for all these friends & colleagues - = too many layers, too many vested interests, too much Cambridge Analytica :) 2/ I though many people in the security community were moving away from proving identity, towards systems that prove entitlement (i.e. credentials are on a need-to-know basis, so if you were say 19, you don't need to say y= ur age or show id, but you can't buy a drink in cambridge MA, but you can in cambridge, UK :) bootstrapping something from a BC to provide the credentials is also proble= matic, in that BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we hav= e a circular dependance, no? maybe i missed an important step, if so, sorry! > Folks, > > I thought to share this WSJ article with the DIN group. Relevant in the > light of recent interest in using BC for identity. > > Advance apologies if it offends some people :-) > > https://blogs.wsj.com/cio/2018/04/03/digital-identity-is-broken-heres-a-w= ay-to-fix-it/ > > > Below is a link to a PDF version. > > http://hardjono.mit.edu/sites/default/files/documents/WSJ_Digital_Identit= y_is_Broken.pdf > > > Best > > -- thomas -- > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > From nobody Sun Apr 8 13:47:24 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828B312D7F6 for ; Sun, 8 Apr 2018 13:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 628Orx4P2P2J for ; Sun, 8 Apr 2018 13:47:19 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBBA1205D3 for ; Sun, 8 Apr 2018 13:47:19 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id f15so4517885pfn.0 for ; Sun, 08 Apr 2018 13:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jPInLQQ6IYt1eQ1zbc+H5x1lnegIair2EDDHvXUI1W0=; b=p5Ar3nE0rwnNVPfduZ6XTKejI5UM1cKKV84wUmIgYOWlmd4qmBCq52yDbWUahxBFHW fkKym37w6kc6b3kOPAaowtVHoB1UFdOwYE+yvCSdsXOSJBrhsTTXHdNapb7ViimzBiLM K8cYy6Si86wznWVikVuJzr32BRUk93ePwsy8fXWIDrSF37iVZRtAZ0KyeyQHy99VSsOK HILERnDFIUSjrS6dktSA+0hY9FWtrJEUxPFFuU2Wu/DupPpnpT0yD2a0VNdj5mMaOOJR PK8ZkeePQ95vMvQVH/pNO+lZE/ArouFh9OkhZDAIGSGR9O/q5yKldK2GZtobFLDfDSjU aHRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jPInLQQ6IYt1eQ1zbc+H5x1lnegIair2EDDHvXUI1W0=; b=g34WCn98rHJhLr7WFHadXTdJE8UaAiL/DdxQPBjlBkqyqilPYjHRE2h3qItFqzkX+B VVeZBsgzEBHO5lR31OJvq1lgkd+5VK6DL9DQDxg4HxqkHxcSVqnwRYHIKTdBb1ukbEuH r+Fc9cq58Z7J/vkkWgbr34dqga3K6h6fk9z5o8CuP22X+rnCROoAs3wLszSts6/Xi83x aQAV/MsSR+UtDw2se0dK8NYCF0K5cRTGippAmz6PlLo707RQY6xvN+pdGWbQPPUz4Vwo 3gi1Owt5ODCYcZ2KsVMCHTvWQLfprrSFC/dPmacRIiGQKKDiDdrc2NeUb77B064u1tm0 LW7g== X-Gm-Message-State: AElRT7Hyv8F011QKGrSkWlAu6M9M8zEJIumsKx1n67vj2JUBQZUSOmlX 9Gw+SIqpjpqjoLT7GPznrs0UIA== X-Google-Smtp-Source: AIpwx4/RGtYGze+7SLO5I7LJfcoDEPGI7uNpff3dlWwSLAW7Xz29sHkNyEY7+zCSeO2bpGQBQaX58Q== X-Received: by 10.98.223.16 with SMTP id u16mr27101313pfg.146.1523220438927; Sun, 08 Apr 2018 13:47:18 -0700 (PDT) Received: from [192.168.178.26] (207.26.255.123.static.snap.net.nz. [123.255.26.207]) by smtp.gmail.com with ESMTPSA id p20sm27862501pff.41.2018.04.08.13.47.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Apr 2018 13:47:18 -0700 (PDT) Sender: Brian Carpenter To: Jon Crowcroft , Thomas Hardjono Cc: "din@irtf.org" References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> From: Brian E Carpenter Message-ID: Date: Mon, 9 Apr 2018 08:47:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 20:47:22 -0000 This rang some bells for me, going back to some of the discussions about = grid computing 15 years ago. So the paper [1] is quite long but the relevant b= it said: "We contend that all existing SA technologies (most notably SAML, among the most recent ones) use some subset of the following semantic fields: 1. User ID (subject NameIdentifier in SAML) 2. Authentication method and strength and context (authentication method in SAML) 3. Group/attributes (user attributes in SAML) 4. Resources granted (resources in SAML) 5. Entitlements granted (resource attributes in SAML, =E2=80=9Cwild cards=E2=80=9D in the proposal [13]) 6 Operations granted (actions in SAML) 7. Privacy restrictions (conditions in SAML or obligations in XACML [15] [Extensible Access Control Markup Language]) It should be noted that the first three of these fields pertain to and are defined in a user=01's home service domain while the last four pertain to and are controlled by the service domain where the affected resources reside." The point being that even if the user name is known, it's actually irrelevant to the bartender; the only relevant bit is one of the user attributes certified by the home domain (age) and the entitlement granted= to that age by the visited domain (alcohol or not alcohol). Our conclusion in 2004 was that a standard abstraction for such assertion= s was needed. I think that's still true. Also we thought that inter-domain = trust was an orthogonal question. I'm sure that's still true, and BC doesn't fi= x it. Regards Brian Carpenter [1] B.E. Carpenter & P. Janson, Abstract interdomain security assertions:= A basis for extra-grid virtual organizations, IBM Systems Journal, 43(4)= (2004) 689-701 http://ieeexplore.ieee.org/document/5386759/ On 08/04/2018 22:38, Jon Crowcroft wrote: > very nice article... >=20 > so you _are_ your social network...in terms of trustworthy identity...s= ure... >=20 > there's two problems with this though in details... > i.e. how we build on this idea technically in the Din context... >=20 > 1/ its still dependent on technologies,=20 > and there's a seperate issue of why we trust them to proxy our social n= et - > i certainly would it find it hard to trust any social media app, runnin= g on a cloud platform, > using a smart mobile device, to vouch for all these friends & colleague= s - too many layers, too many > vested interests, too much Cambridge Analytica :) >=20 > 2/ I though many people in the security community were moving away from= > proving identity, towards systems that prove entitlement (i.e. credenti= als > are on a need-to-know basis, so if you were say 19, you don't need to s= ay yur age or show id,=20 > but you can't buy a drink in cambridge MA, but you can in cambridge, UK= :) >=20 > bootstrapping something from a BC to provide the credentials is also pr= oblematic, in that > BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we= have a circular dependance, no? >=20 > maybe i missed an important step, if so, sorry! >=20 >=20 >> Folks, >> >> I thought to share this WSJ article with the DIN group. Relevant in th= e=20 >> light of recent interest in using BC for identity. >> >> Advance apologies if it offends some people :-) >> >> https://blogs.wsj.com/cio/2018/04/03/digital-identity-is-broken-heres-= a-way-to-fix-it/ >> >> >> Below is a link to a PDF version. >> >> http://hardjono.mit.edu/sites/default/files/documents/WSJ_Digital_Iden= tity_is_Broken.pdf >> >> >> Best >> >> -- thomas -- >> >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >> > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > . >=20 From nobody Sun Apr 8 15:28:32 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB8712D880 for ; Sun, 8 Apr 2018 15:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhUbwI5sosRD for ; Sun, 8 Apr 2018 15:28:28 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658AB12D87E for ; Sun, 8 Apr 2018 15:28:28 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id d5so7429622iob.9 for ; Sun, 08 Apr 2018 15:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IMZKkUkVikfdKKdTQ5JuENaaN85tM4ZtWSmR+J7YRMo=; b=f8ZXYl9VhNSGeDqqjCDp7PBIpZlj4zLI6IdX0cGgWfWrgylleEx+5yiKLx21cnzk7v omLksTUtKMIYNSUFmURb0TUdUr8EGb00wIGM7S6igSREjwLpGtPEFMQV1eThUc+G/ay9 pzQsCp2lkDQsKJ6dufHvgaHrvMORcs+NDSIywEPqMnKbJc7yPSB7p/EDCQ2Lr5TSDnjz yE5fE1igbioOc6p/zPeY9Y2JK+ZQQd9m+AWozfYkzpS3fLlR/cC/ar/ikhWxw4up17Md xtQmM42T7XlSQVX2nA7eeuWc3XQFjDGRvjNFC7NlTtzn9j9xseS6zRHGZYO3ORYQvkF3 9IRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IMZKkUkVikfdKKdTQ5JuENaaN85tM4ZtWSmR+J7YRMo=; b=b0/I4AN1ov4mZ6I0LeV9MtWjPTF+JaXMoYLB3DT2b9v0e+C0pQzGsK93Bf1WoGhIE0 0sFsZKa8MB+A4iOBqMH3C1DQLjYxSMu3YflyF8XiewNSYSc2FlS/DFHbyWzSK9yWDuoU WyBoPGfglGFnEYMKc5b3yTb6ggcUT9R771/h/Pz9fo336FnfEKNhkyF8zIPEXPaeaM5+ odk1pO5E63q6h7i38N2sUZKyrhueH+p7StpWMXkGyiCum7PagbV2zBRbLZagQFw+7S1c dJ1RjZwA3nFJHRw6SXYZq6BDj/ybAOSwy/2A+iSxiuQrRHW5AonmBDDnmsJPMhSWMson AyyQ== X-Gm-Message-State: AElRT7HjtsIXqk/4xrGbbTBQxg99j0Sovlzncc42iRjzfsp7ylHR8sgm 6NK3tIhayhA51I1iGgZDe0d/xD6XeRr8qiDud8Q= X-Google-Smtp-Source: AIpwx48NO5Eo6qvyDIBMS32JXrqHtaCW+Z6KPHNMjQrkKZ0EIhOFLaws87HqtXQgC0fR4z2afpA3lXY3vRGr/dG08i4= X-Received: by 10.107.37.5 with SMTP id l5mr31248542iol.47.1523226507719; Sun, 08 Apr 2018 15:28:27 -0700 (PDT) MIME-Version: 1.0 Sender: arjuna.sathiaseelan@gmail.com Received: by 10.79.198.5 with HTTP; Sun, 8 Apr 2018 15:28:27 -0700 (PDT) In-Reply-To: References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> From: Arjuna Sathiaseelan Date: Mon, 9 Apr 2018 00:28:27 +0200 X-Google-Sender-Auth: gVGvBO39TCfJHAU85dDR1l4WHDA Message-ID: To: Jon Crowcroft Cc: Thomas Hardjono , "din@irtf.org" Content-Type: multipart/alternative; boundary="001a1140f418e7bb0805695dceaf" Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 22:28:30 -0000 --001a1140f418e7bb0805695dceaf Content-Type: text/plain; charset="UTF-8" > > 2/ I though many people in the security community were moving away from > proving identity, towards systems that prove entitlement (i.e. credentials > are on a need-to-know basis, so if you were say 19, you don't need to say > yur age or show id, > but you can't buy a drink in cambridge MA, but you can in cambridge, UK :) > digital id plays a major role for all the KYC/AML - massive market.. + for employment etc.. like the idea of proving entitlement - works nicely with crypto charities/aid delivery.. Regards > bootstrapping something from a BC to provide the credentials is also > problematic, in that > BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we > have a circular dependance, no? > > maybe i missed an important step, if so, sorry! > > > > Folks, > > > > I thought to share this WSJ article with the DIN group. Relevant in the > > light of recent interest in using BC for identity. > > > > Advance apologies if it offends some people :-) > > > > https://blogs.wsj.com/cio/2018/04/03/digital-identity- > is-broken-heres-a-way-to-fix-it/ > > > > > > Below is a link to a PDF version. > > > > http://hardjono.mit.edu/sites/default/files/documents/WSJ_ > Digital_Identity_is_Broken.pdf > > > > > > Best > > > > -- thomas -- > > > > _______________________________________________ > > Din mailing list > > Din@irtf.org > > https://www.irtf.org/mailman/listinfo/din > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > -- Arjuna Sathiaseelan University of Cambridge | Ammbr Research Labs Personal: http://www.cl.cam.ac.uk/~as2330/ N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d --001a1140f418e7bb0805695dceaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=

2/ I though many people in the security community were moving away from
proving identity, towards systems that prove entitlement (i.e. credentials<= br> are on a need-to-know basis, so if you were say 19, you don't need to s= ay yur age or show id,
but you can't buy a drink in cambridge MA, but you can in cambridge, UK= :)

digital id plays a major role for a= ll the KYC/AML - massive market.. + for employment etc..

like the idea of proving entitlement - works nicely with crypto char= ities/aid delivery..

Regards

<= div>=C2=A0
=C2=A0
bootstrapping something from a BC to provide the credentials is also proble= matic, in that
BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we hav= e a circular dependance, no?

maybe i missed an important step, if so, sorry!


> Folks,
>
> I thought to share this WSJ article with the DIN group. Relevant in th= e
> light of recent interest in using BC for identity.
>
> Advance apologies if it offends some people :-)
>
> https://b= logs.wsj.com/cio/2018/04/03/digital-identity-is-broken-heres-a-wa= y-to-fix-it/
>
>
> Below is a link to a PDF version.
>
> http://= hardjono.mit.edu/sites/default/files/documents/WSJ_Digital_Identi= ty_is_Broken.pdf
>
>
> Best
>
> -- thomas --
>
> _______________________________________________
> Din mailing list
> Din@irtf.org
> https://www.irtf.org/mailman/listinfo/din
>
_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din



--
=

Arjuna Sathiaseelan
U= niversity of Cambridge | Ammbr Research Labs
Personal: http://www.cl.cam.ac.uk/~as23= 30/
N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d
=
--001a1140f418e7bb0805695dceaf-- From nobody Sun Apr 8 18:44:42 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3E126C83 for ; Sun, 8 Apr 2018 18:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ9UdEZQD0ML for ; Sun, 8 Apr 2018 18:44:38 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BB2124D68 for ; Sun, 8 Apr 2018 18:44:38 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id j2so4854706pff.10 for ; Sun, 08 Apr 2018 18:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pf/TbyR54waTyoQ0coLhZ05tUZQElOZ9DlikG8VbA0U=; b=PUjcSNmZFCwh+rV8/GDPqek5b5tEq7SXiVNLvlfS9LpK0jrE0nDTg4x2V1ynM08kzk qmzhrc7stupE3ZuBrPqtK1EtprNbZ3pvCXTdoVeVIUcybscbkPrJmJ1HFg75EL0aIyD1 Al4OSpQ3XwFa774CxRJ7cTMlO6ntzzXXP3S0e5WTJPwBDi0w7FfeArsLpCHjXV7YQuXX zy4ubYeCMPpKWp7DZTqs10FBH6rb7JW07YyUzFQID8hGTC88liO7gLKsrb6Pji4HfSW9 VsjbB2ru+xM9/saOLhVXtFrGUTvDH1diaAnZCi3XYH2oiLC6UhcBzYrmalIjUciz8MOG e+fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=pf/TbyR54waTyoQ0coLhZ05tUZQElOZ9DlikG8VbA0U=; b=oCUOiya/Sr/qgfVY5ahPYmRARaT2Fex83ummuXSLIuQtWhM5ERo86Vdo1TonpUitu+ Vm6cYxzTBRQ5NO4aHKqicgys69VK+BQvZD1YfkdoVynTlnw/FOvHoxULAbIH/VUPv24v TDl1DhWXhoGUeriuRS/BZU5wH8DCGm2DAPjCiheWQF+W+ynF/Ojz/iW9c/+/vJoZ4pht G8kLiY3E5MvZJAjySrEAz+HfHD221zEMoMMJVAp5rY9N0XNTFQyHC9KScdn+sTWotVxc YCcPYXDO1EXVPZOBNcSUKfD7TkMox55WNorOx9lLUz3LR63ywZ5xmcy9cqO1CXQlZTry EnCg== X-Gm-Message-State: AElRT7HoJofT4JDuJ7+B6wrQAt31HkXPTFXqCqdXfbKY0qOefnnMWPXQ f0YLxCtZq569blGAc7P2YCLssQ== X-Google-Smtp-Source: AIpwx48RowSeUQv/+03r5F9Mmpn69aSKfq8FSOQYbnBkbMJ04FAaedzoyontp/u4PwbQgcwNjKKuZQ== X-Received: by 10.101.75.12 with SMTP id r12mr23558578pgq.36.1523238277387; Sun, 08 Apr 2018 18:44:37 -0700 (PDT) Received: from [192.168.178.26] (207.26.255.123.static.snap.net.nz. [123.255.26.207]) by smtp.gmail.com with ESMTPSA id a10sm17122643pfo.131.2018.04.08.18.44.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Apr 2018 18:44:36 -0700 (PDT) To: din@irtf.org References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 9 Apr 2018 13:44:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 01:44:40 -0000 On 09/04/2018 10:28, Arjuna Sathiaseelan wrote: >> >> 2/ I though many people in the security community were moving away from >> proving identity, towards systems that prove entitlement (i.e. credentials >> are on a need-to-know basis, so if you were say 19, you don't need to say >> yur age or show id, >> but you can't buy a drink in cambridge MA, but you can in cambridge, UK :) >> > > digital id plays a major role for all the KYC/AML - massive market.. + for > employment etc.. Right, but *international* digital ID is a hopeless mess. Just try dealing with a USA bank's KYC department when living in New Zealand with a UK passport. Nothing works. That isn't a marginal case. Tens or hundreds of millions of people would need cross-border digital ID these days. Sales argument: would help to defeat money laundering. Brian > like the idea of proving entitlement - works nicely with crypto > charities/aid delivery.. > > Regards > > > > >> bootstrapping something from a BC to provide the credentials is also >> problematic, in that >> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we >> have a circular dependance, no? >> >> maybe i missed an important step, if so, sorry! >> >> >>> Folks, >>> >>> I thought to share this WSJ article with the DIN group. Relevant in the >>> light of recent interest in using BC for identity. >>> >>> Advance apologies if it offends some people :-) >>> >>> https://blogs.wsj.com/cio/2018/04/03/digital-identity- >> is-broken-heres-a-way-to-fix-it/ >>> >>> >>> Below is a link to a PDF version. >>> >>> http://hardjono.mit.edu/sites/default/files/documents/WSJ_ >> Digital_Identity_is_Broken.pdf >>> >>> >>> Best >>> >>> -- thomas -- >>> >>> _______________________________________________ >>> Din mailing list >>> Din@irtf.org >>> https://www.irtf.org/mailman/listinfo/din >>> >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >> > > > > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > From nobody Tue Apr 10 09:49:40 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C43012E042 for ; Tue, 10 Apr 2018 09:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0FExu6HpcYt for ; Tue, 10 Apr 2018 09:49:30 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B2D12E04A for ; Tue, 10 Apr 2018 09:49:28 -0700 (PDT) X-AuditID: 12074424-c8fff700000042c3-a9-5acceb1683eb Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 24.94.17091.61BECCA5; Tue, 10 Apr 2018 12:49:26 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w3AGnOCJ017620; Tue, 10 Apr 2018 12:49:25 -0400 Received: from W92EXEDGE5.EXCHANGE.MIT.EDU (W92EXEDGE5.EXCHANGE.MIT.EDU [18.7.73.22]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id w3AGnMiG019183; Tue, 10 Apr 2018 12:49:24 -0400 Received: from OC11EXCAS22.exchange.mit.edu (18.9.1.47) by W92EXEDGE5.EXCHANGE.MIT.EDU (18.7.73.22) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 10 Apr 2018 12:49:06 -0400 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.111]) by oc11excas22.exchange.mit.edu ([18.9.1.47]) with mapi id 14.03.0352.000; Tue, 10 Apr 2018 12:49:22 -0400 From: Thomas Hardjono To: Brian E Carpenter , "din@irtf.org" Thread-Topic: [Din] WSJ article on Identity and Blockchains Thread-Index: AQHTzcUHgLU9VkLMR0+I6ZGjg4OG6aP28xeAgADGQICAADbKgIACSeiT Date: Tue, 10 Apr 2018 16:49:21 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AE7404E4C@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNKsWRmVeSWpSXmKPExsUixCmqrSv2+kyUwZVvNhZtF/cxWSz9uJfF gclj56y77B6TNx5mC2CK4rJJSc3JLEst0rdL4MqY8OU1Y0GfbMX6w8vZGhhPiHcxcnJICJhI TLz3hLWLkYtDSGAxk8TD6+eYIJwDjBKNe1uhMscYJTZ9bGOBcLYzSmz5eooZwlnNKPFnyXwm kGFsAhoSbT962UFsEYFYiS0nvjCC2MICVhLr761n62LkAIpbS+xZHg5R4iaxbN5uVhCbRUBV 4lvnfjYQm1cgSGLH/2dQmz8xSjw98BxsDqeArUTH5iYWEJtRQEzi+6k1YHuZBcQlbj2BuEFC QFBi0ew9zBC2mMS/XQ/ZIGxZiV+nrzNC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUn4Vk 7CwkLbOQtMxC0rKAkWUVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGULyxu6js YOzu8T7EKMDBqMTDe+HWmSgh1sSy4srcQ4ySHExKorw7rgGF+JLyUyozEosz4otKc1KLDzFK cDArifD+uAeU401JrKxKLcqHSUlzsCiJ8y7evzdKSCA9sSQ1OzW1ILUIJivDwaEkwSv0CqhR sCg1PbUiLTOnBCHNxMEJMpwHaPiflyDDiwsSc4sz0yHypxh1OTreT+lhFmLJy89LlRLn9QAZ JABSlFGaBzcHnCbZPcVeMYoDvSXM+xtkFA8wxcJNegW0hAloyTEfsCUliQgpqQbGTbOnX+o6 VbXmm0v004SQyQu6fmq975mQkqYxf+ae38sPL1Jk/SJ0/+e/ayp8p0+yMbsWPwjbM4tXfiVb XoIrr/GZ/WGT3n7d9um609m/gvu3WF7RjohpyxFJqNBXzOO0aRQT2OCu+mBm8PMew2rWO7EK Xzcm6QZu3bKQObYtY8nS52LtL87LKrEUZyQaajEXFScCABhSgSVuAwAA Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 16:49:39 -0000 >>> From: Din [din-bounces@irtf.org] on behalf of Brian E Carpenter [brian.= e.carpenter@gmail.com] >>> ... >>> That isn't a marginal case. Tens or hundreds of millions of people >>> would need cross-border digital ID these days. Sales argument: would >>> help to defeat money laundering. Lots of people seem to want to provide digital-identity on a global scale i= mmediately. from day 1. Some folks even imagine there will be one huge global blockchain for the en= tire world :-) But there is a lot to be learned from the history how IP routing emerged (e= .g. days when we only had IS-IS for local routing, not even OSPF). Just like there is "autonomous systems" (AS) concept in routing and connect= ed via backbone routing, in the area of identity there needs to be the equivalent of an AS. I've been calling it "communities" (data communities) for humans and person= al data. Its by interlinking ASes (communities) do we get scale and get identity ser= vices to be globally reachable. So anytime I hear about a global blockchain to rule them all, I cringe :-) -- thomas --=20 ________________________________________ From: Din [din-bounces@irtf.org] on behalf of Brian E Carpenter [brian.e.ca= rpenter@gmail.com] Sent: Sunday, April 08, 2018 9:44 PM To: din@irtf.org Subject: Re: [Din] WSJ article on Identity and Blockchains On 09/04/2018 10:28, Arjuna Sathiaseelan wrote: >> >> 2/ I though many people in the security community were moving away from >> proving identity, towards systems that prove entitlement (i.e. credentia= ls >> are on a need-to-know basis, so if you were say 19, you don't need to sa= y >> yur age or show id, >> but you can't buy a drink in cambridge MA, but you can in cambridge, UK = :) >> > > digital id plays a major role for all the KYC/AML - massive market.. + fo= r > employment etc.. Right, but *international* digital ID is a hopeless mess. Just try dealing with a USA bank's KYC department when living in New Zealand with a UK passport. Nothing works. That isn't a marginal case. Tens or hundreds of millions of people would need cross-border digital ID these days. Sales argument: would help to defeat money laundering. Brian > like the idea of proving entitlement - works nicely with crypto > charities/aid delivery.. > > Regards > > > > >> bootstrapping something from a BC to provide the credentials is also >> problematic, in that >> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we >> have a circular dependance, no? >> >> maybe i missed an important step, if so, sorry! >> >> >>> Folks, >>> >>> I thought to share this WSJ article with the DIN group. Relevant in the >>> light of recent interest in using BC for identity. >>> >>> Advance apologies if it offends some people :-) >>> >>> https://blogs.wsj.com/cio/2018/04/03/digital-identity- >> is-broken-heres-a-way-to-fix-it/ >>> >>> >>> Below is a link to a PDF version. >>> >>> http://hardjono.mit.edu/sites/default/files/documents/WSJ_ >> Digital_Identity_is_Broken.pdf >>> >>> >>> Best >>> >>> -- thomas -- >>> >>> _______________________________________________ >>> Din mailing list >>> Din@irtf.org >>> https://www.irtf.org/mailman/listinfo/din >>> >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >> > > > > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > _______________________________________________ Din mailing list Din@irtf.org https://www.irtf.org/mailman/listinfo/din= From nobody Tue Apr 10 15:41:00 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4768F12D7F4 for ; Tue, 10 Apr 2018 15:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJDctcObWMxS for ; Tue, 10 Apr 2018 15:40:55 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50099.outbound.protection.outlook.com [40.107.5.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF0712421A for ; Tue, 10 Apr 2018 15:40:54 -0700 (PDT) Received: from HE1PR0602MB2921.eurprd06.prod.outlook.com (10.175.33.12) by HE1PR0602MB2826.eurprd06.prod.outlook.com (10.175.31.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 22:40:51 +0000 Received: from HE1PR0602MB2921.eurprd06.prod.outlook.com ([fe80::2c62:cbc1:f8cb:8662]) by HE1PR0602MB2921.eurprd06.prod.outlook.com ([fe80::2c62:cbc1:f8cb:8662%18]) with mapi id 15.20.0653.015; Tue, 10 Apr 2018 22:40:51 +0000 From: "Diego R. Lopez" To: Thomas Hardjono , Brian E Carpenter , "din@irtf.org" Thread-Topic: [Din] WSJ article on Identity and Blockchains Thread-Index: AQHTzcUHgLU9VkLMR0+I6ZGjg4OG6aP2sAmAgADGQICAADbKgIACjyKAgACDuAA= Date: Tue, 10 Apr 2018 22:40:50 +0000 Message-ID: References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <5E393DF26B791A428E5F003BB6C5342AE7404E4C@OC11EXPO33.exchange.mit.edu> In-Reply-To: <5E393DF26B791A428E5F003BB6C5342AE7404E4C@OC11EXPO33.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180401 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [92.103.206.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0602MB2826; 7:0scSzTAwvbtwLpfoah9DN7oYJlVcULhkt4N3MJ8LxaIo2AjMxFzrK9Lbm/OuDVzpEBB7FRzgpJypHqpL6A1W5ynV3tIPJ4f1xZIaxq0olig4R03Wx7mJ3lBbX+ouZsSXM8fCVGNHC2aG5ZIAOrhasjuc24l8a6fmHUxl5Ffhm/XGrSSncloy5GL5yVsquoeCam2Jgp7rP0Qw+CwhH9h/ukHah2raBrIw85ZncHvtWCTLiQ3vNfseBKUTQg2qdogu x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(40392960112811); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(48565401081)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:HE1PR0602MB2826; x-ms-traffictypediagnostic: HE1PR0602MB2826: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(17744754593026)(244540007438412)(192374486261705)(178670569857331)(85827821059158)(15185016700835)(128460861657000)(81160342030619)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR0602MB2826; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0602MB2826; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(396003)(346002)(39860400002)(376002)(252514010)(25724002)(23363002)(40134004)(199004)(189003)(186003)(82746002)(966005)(486006)(33656002)(1720100001)(97736004)(2501003)(2906002)(7736002)(5250100002)(6486002)(14454004)(6436002)(6306002)(53936002)(305945005)(316002)(6512007)(229853002)(3280700002)(102836004)(6116002)(81156014)(68736007)(58126008)(26005)(8936002)(110136005)(3846002)(2900100001)(3660700001)(39060400002)(66066001)(786003)(106356001)(36756003)(83716003)(81166006)(6506007)(76176011)(86362001)(11346002)(476003)(105586002)(5660300001)(2171002)(59450400001)(99286004)(478600001)(6246003)(446003)(2616005)(25786009)(45080400002)(53546011)(93886005)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0602MB2826; H:HE1PR0602MB2921.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: hi+Xzs8ldTeK4mLSKEj9hKS0Xk2PdwpwS5UPwocel/cdJ/l08158Ts/eshuGYqKuINHWwL/fJa8gmBHJZ5F4RWf51Ptb5IDWW4cXUO0KU1hw+6VAKwnC/z5eKrrvygJXkYjVCfCTZwImtk4boPaQrPLA8uqwdvVPdGMYM6cszLgzX7u1Is4XxrMcOctUjh9xT6v5HC2EQlfV1cEZGUpzuabM0IYYLf6dyjMcek60Sb2wKknvoytTa3JDv2YoLkSSu7AfG6ppFzs5Hkp7Z2wPkc0pgrsGnsSwT2jfpBuFECU5oxzSOU4bYCWSQigsrE6lWhXWFZyDBpr6dwsZ2kZ2GauMWfG9+LR55KBbqkYPYDYX51zJjSQaTzu90SHRbA1RWMElFHhy3k6o0jNjGuDenBjAGVVL2q5JJlP00c9NZfQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8D4360496982E143AD3A4795D3F95E86@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1fda5368-94e5-48da-9780-08d59f341ca0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1fda5368-94e5-48da-9780-08d59f341ca0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 22:40:50.8008 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0602MB2826 Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 22:40:59 -0000 SGksDQoNCkknZCByZWNvbW1lbmQgdGhlIGdyb3VwIHRvIGhhdmUgYSBsb29rIGFyb3VuZCB0aGUg ZGlnaXRhbCBpZGVudGl0eSBjb25jZXB0cyB0aGUgYWNhZGVtaWMgbmV0d29ya3Mgc2hhcGVkIGR1 cmluZyB0aGUgZWFybHkgMjAwMHMsIGFuZCB0aGF0IGFyZSBmb3JtdWxhdGVkIGluIGEgZ2xvYmFs IHNjb3BlIGJ5IHRoZSBSRUZFRFMgaW5pdGlhdGl2ZTogaHR0cHM6Ly9yZWZlZHMub3JnLw0KDQpC ZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8i DQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cHM6Ly93d3cubGlua2Vk aW4uY29tL2luL2RyMmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5j b20NClRlbDogICAgICAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogICszNCA2ODIgMDUxIDA5 MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K77u/T24gMTAvMDQvMjAxOCwg MTg6NDksICJEaW4gb24gYmVoYWxmIG9mIFRob21hcyBIYXJkam9ubyIgPGRpbi1ib3VuY2VzQGly dGYub3JnIG9uIGJlaGFsZiBvZiBoYXJkam9ub0BtaXQuZWR1PiB3cm90ZToNCg0KDQogICAgPj4+ IEZyb206IERpbiBbZGluLWJvdW5jZXNAaXJ0Zi5vcmddIG9uIGJlaGFsZiBvZiBCcmlhbiBFIENh cnBlbnRlciBbYnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KICAgID4+PiAuLi4NCiAgICA+ Pj4gVGhhdCBpc24ndCBhIG1hcmdpbmFsIGNhc2UuIFRlbnMgb3IgaHVuZHJlZHMgb2YgbWlsbGlv bnMgb2YgcGVvcGxlDQogICAgPj4+IHdvdWxkIG5lZWQgY3Jvc3MtYm9yZGVyIGRpZ2l0YWwgSUQg dGhlc2UgZGF5cy4gU2FsZXMgYXJndW1lbnQ6IHdvdWxkDQogICAgPj4+IGhlbHAgdG8gZGVmZWF0 IG1vbmV5IGxhdW5kZXJpbmcuDQoNCiAgICBMb3RzIG9mIHBlb3BsZSBzZWVtIHRvIHdhbnQgdG8g cHJvdmlkZSBkaWdpdGFsLWlkZW50aXR5IG9uIGEgZ2xvYmFsIHNjYWxlIGltbWVkaWF0ZWx5LiBm cm9tIGRheSAxLg0KDQogICAgU29tZSBmb2xrcyBldmVuIGltYWdpbmUgdGhlcmUgd2lsbCBiZSBv bmUgaHVnZSBnbG9iYWwgYmxvY2tjaGFpbiBmb3IgdGhlIGVudGlyZSB3b3JsZCA6LSkNCg0KICAg IEJ1dCB0aGVyZSBpcyBhIGxvdCB0byBiZSBsZWFybmVkIGZyb20gdGhlIGhpc3RvcnkgaG93IElQ IHJvdXRpbmcgZW1lcmdlZCAoZS5nLiBkYXlzIHdoZW4NCiAgICB3ZSBvbmx5IGhhZCBJUy1JUyBm b3IgbG9jYWwgcm91dGluZywgbm90IGV2ZW4gT1NQRikuDQoNCiAgICBKdXN0IGxpa2UgdGhlcmUg aXMgImF1dG9ub21vdXMgc3lzdGVtcyIgKEFTKSBjb25jZXB0IGluIHJvdXRpbmcgYW5kIGNvbm5l Y3RlZCB2aWEgYmFja2JvbmUgcm91dGluZywNCiAgICBpbiB0aGUgYXJlYSBvZiBpZGVudGl0eSB0 aGVyZSBuZWVkcyB0byBiZSB0aGUgZXF1aXZhbGVudCBvZiBhbiBBUy4NCg0KICAgIEkndmUgYmVl biBjYWxsaW5nIGl0ICJjb21tdW5pdGllcyIgKGRhdGEgY29tbXVuaXRpZXMpIGZvciBodW1hbnMg YW5kIHBlcnNvbmFsIGRhdGEuDQoNCiAgICBJdHMgYnkgaW50ZXJsaW5raW5nIEFTZXMgKGNvbW11 bml0aWVzKSBkbyB3ZSBnZXQgc2NhbGUgYW5kIGdldCBpZGVudGl0eSBzZXJ2aWNlcyB0byBiZSBn bG9iYWxseSByZWFjaGFibGUuDQoNCiAgICBTbyBhbnl0aW1lIEkgaGVhciBhYm91dCBhIGdsb2Jh bCBibG9ja2NoYWluIHRvIHJ1bGUgdGhlbSBhbGwsIEkgY3JpbmdlIDotKQ0KDQoNCiAgICAtLSB0 aG9tYXMgLS0NCg0KDQoNCg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgIEZyb206IERpbiBbZGluLWJvdW5jZXNAaXJ0Zi5vcmddIG9uIGJlaGFsZiBv ZiBCcmlhbiBFIENhcnBlbnRlciBbYnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KICAgIFNl bnQ6IFN1bmRheSwgQXByaWwgMDgsIDIwMTggOTo0NCBQTQ0KICAgIFRvOiBkaW5AaXJ0Zi5vcmcN CiAgICBTdWJqZWN0OiBSZTogW0Rpbl0gV1NKIGFydGljbGUgb24gSWRlbnRpdHkgYW5kIEJsb2Nr Y2hhaW5zDQoNCiAgICBPbiAwOS8wNC8yMDE4IDEwOjI4LCBBcmp1bmEgU2F0aGlhc2VlbGFuIHdy b3RlOg0KICAgID4+DQogICAgPj4gMi8gSSB0aG91Z2ggbWFueSBwZW9wbGUgaW4gdGhlIHNlY3Vy aXR5IGNvbW11bml0eSB3ZXJlIG1vdmluZyBhd2F5IGZyb20NCiAgICA+PiBwcm92aW5nIGlkZW50 aXR5LCB0b3dhcmRzIHN5c3RlbXMgdGhhdCBwcm92ZSBlbnRpdGxlbWVudCAoaS5lLiBjcmVkZW50 aWFscw0KICAgID4+IGFyZSBvbiBhIG5lZWQtdG8ta25vdyBiYXNpcywgc28gaWYgeW91IHdlcmUg c2F5IDE5LCB5b3UgZG9uJ3QgbmVlZCB0byBzYXkNCiAgICA+PiB5dXIgYWdlIG9yIHNob3cgaWQs DQogICAgPj4gYnV0IHlvdSBjYW4ndCBidXkgYSBkcmluayBpbiBjYW1icmlkZ2UgTUEsIGJ1dCB5 b3UgY2FuIGluIGNhbWJyaWRnZSwgVUsgOikNCiAgICA+Pg0KICAgID4NCiAgICA+IGRpZ2l0YWwg aWQgcGxheXMgYSBtYWpvciByb2xlIGZvciBhbGwgdGhlIEtZQy9BTUwgLSBtYXNzaXZlIG1hcmtl dC4uICsgZm9yDQogICAgPiBlbXBsb3ltZW50IGV0Yy4uDQoNCiAgICBSaWdodCwgYnV0ICppbnRl cm5hdGlvbmFsKiBkaWdpdGFsIElEIGlzIGEgaG9wZWxlc3MgbWVzcy4gSnVzdCB0cnkgZGVhbGlu Zw0KICAgIHdpdGggYSBVU0EgYmFuaydzIEtZQyBkZXBhcnRtZW50IHdoZW4gbGl2aW5nIGluIE5l dyBaZWFsYW5kIHdpdGggYSBVSw0KICAgIHBhc3Nwb3J0LiBOb3RoaW5nIHdvcmtzLg0KDQogICAg VGhhdCBpc24ndCBhIG1hcmdpbmFsIGNhc2UuIFRlbnMgb3IgaHVuZHJlZHMgb2YgbWlsbGlvbnMg b2YgcGVvcGxlDQogICAgd291bGQgbmVlZCBjcm9zcy1ib3JkZXIgZGlnaXRhbCBJRCB0aGVzZSBk YXlzLiBTYWxlcyBhcmd1bWVudDogd291bGQNCiAgICBoZWxwIHRvIGRlZmVhdCBtb25leSBsYXVu ZGVyaW5nLg0KDQogICAgICAgQnJpYW4NCg0KICAgID4gbGlrZSB0aGUgaWRlYSBvZiBwcm92aW5n IGVudGl0bGVtZW50IC0gd29ya3MgbmljZWx5IHdpdGggY3J5cHRvDQogICAgPiBjaGFyaXRpZXMv YWlkIGRlbGl2ZXJ5Li4NCiAgICA+DQogICAgPiBSZWdhcmRzDQogICAgPg0KICAgID4NCiAgICA+ DQogICAgPg0KICAgID4+IGJvb3RzdHJhcHBpbmcgc29tZXRoaW5nIGZyb20gYSBCQyB0byBwcm92 aWRlIHRoZSBjcmVkZW50aWFscyBpcyBhbHNvDQogICAgPj4gcHJvYmxlbWF0aWMsIGluIHRoYXQN CiAgICA+PiBCQyBuZWVkcyBhIFBLSSB0byBrbm93IHdoZXRoZXIgbm9kZXMgYXJlIG5vdCBzeWJp bHMsIHNwb29mcywgZXRjLCBzbyB3ZQ0KICAgID4+IGhhdmUgYSBjaXJjdWxhciBkZXBlbmRhbmNl LCBubz8NCiAgICA+Pg0KICAgID4+IG1heWJlIGkgbWlzc2VkIGFuIGltcG9ydGFudCBzdGVwLCBp ZiBzbywgc29ycnkhDQogICAgPj4NCiAgICA+Pg0KICAgID4+PiBGb2xrcywNCiAgICA+Pj4NCiAg ICA+Pj4gSSB0aG91Z2h0IHRvIHNoYXJlIHRoaXMgV1NKIGFydGljbGUgd2l0aCB0aGUgRElOIGdy b3VwLiBSZWxldmFudCBpbiB0aGUNCiAgICA+Pj4gbGlnaHQgb2YgcmVjZW50IGludGVyZXN0IGlu IHVzaW5nIEJDIGZvciBpZGVudGl0eS4NCiAgICA+Pj4NCiAgICA+Pj4gQWR2YW5jZSBhcG9sb2dp ZXMgaWYgaXQgb2ZmZW5kcyBzb21lIHBlb3BsZSA6LSkNCiAgICA+Pj4NCiAgICA+Pj4gaHR0cHM6 Ly9ibG9ncy53c2ouY29tL2Npby8yMDE4LzA0LzAzL2RpZ2l0YWwtaWRlbnRpdHktDQogICAgPj4g aXMtYnJva2VuLWhlcmVzLWEtd2F5LXRvLWZpeC1pdC8NCiAgICA+Pj4NCiAgICA+Pj4NCiAgICA+ Pj4gQmVsb3cgaXMgYSBsaW5rIHRvIGEgUERGIHZlcnNpb24uDQogICAgPj4+DQogICAgPj4+IGh0 dHA6Ly9oYXJkam9uby5taXQuZWR1L3NpdGVzL2RlZmF1bHQvZmlsZXMvZG9jdW1lbnRzL1dTSl8N CiAgICA+PiBEaWdpdGFsX0lkZW50aXR5X2lzX0Jyb2tlbi5wZGYNCiAgICA+Pj4NCiAgICA+Pj4N CiAgICA+Pj4gQmVzdA0KICAgID4+Pg0KICAgID4+PiAtLSB0aG9tYXMgLS0NCiAgICA+Pj4NCiAg ICA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICA+Pj4gRGluIG1haWxpbmcgbGlzdA0KICAgID4+PiBEaW5AaXJ0Zi5vcmcNCiAgICA+Pj4gaHR0 cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW4NCiAgICA+Pj4NCiAgICA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+IERp biBtYWlsaW5nIGxpc3QNCiAgICA+PiBEaW5AaXJ0Zi5vcmcNCiAgICA+PiBodHRwczovL3d3dy5p cnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpbg0KICAgID4+DQogICAgPg0KICAgID4NCiAgICA+ DQogICAgPg0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgPiBEaW4gbWFpbGluZyBsaXN0DQogICAgPiBEaW5AaXJ0Zi5vcmcN CiAgICA+IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vZGluDQogICAgPg0K DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICBEaW4gbWFpbGluZyBsaXN0DQogICAgRGluQGlydGYub3JnDQogICAgaHR0cHM6Ly93d3cuaXJ0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW4NCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIERpbiBtYWlsaW5nIGxpc3QNCiAgICBEaW5AaXJ0 Zi5vcmcNCiAgICBodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpbg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHkgc3Vz IGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1 ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBl cyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4g U2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2Fk byBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24geS9vIGNvcGlh IHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0dWQgZGUgbGEg bGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2FqZSBwb3IgZXJy b3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVudGUgcG9yIGVz dGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29u ZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVz c2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZp ZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhp cyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGlt bWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpFc3RhIG1lbnNh Z2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGlu YXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRl bmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRl c3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRv LCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdh w6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBl bSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2Fn ZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50 ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbw0K From nobody Tue Apr 10 16:52:10 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A0412D872 for ; Tue, 10 Apr 2018 16:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-QJdBZbK1WI for ; Tue, 10 Apr 2018 16:52:04 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A309212D80F for ; Tue, 10 Apr 2018 16:52:04 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id h69so15896pfe.13 for ; Tue, 10 Apr 2018 16:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8RddlPj6f6NEG2xJUbQ25ey4tEmaeHoDstPGajd668c=; b=Y26uBGRslB1l8owI4G2bGuJRADzMLkh8bpOcPGc2LQqKkRi8ht+6hhnHseoR8tlpvM Y7s4y8TIYXjIaMv0e1HRpwmKeQIUG6sJJ5rJxSKdhG7Z6j5E7e5tES/U5KK/PDhayIx9 HB2pO0udpsCLaEDjMRf7UM1C6BSrV1TZQmJo1svyjKaR2yZIHK9+o2A6GfbEAtoUYZH8 C+3V1yJtJtmltNF/tETyv5iSJS+V5VJRFFEfphLLWYzrnN9h8ys6YKx6Ro7Gb1juVST2 wPaPjRRIubj5mZ7UyAUZf4rLVyc2QJoE+9jHWGHKQ//0b675Ytv87vSArvs3g2QaK8Qx 4Ldg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8RddlPj6f6NEG2xJUbQ25ey4tEmaeHoDstPGajd668c=; b=YsVpxP6xamrsW8trpO5MXl8hg/7IZa4/dA3ylTUxaGI3pwm4htFYWUbLQ9qmwmSDg8 U5Dxy4UEY2+TGXh66uqDqtkRaZfzLx00Wp6Fl9OnfIzEf+3DM3/DLSjR7geeaQHE/4Gq QDBBeRdFtREkdIvBsII6scAJep7cU13/+A+UFLZOdHpwJyxG6zWIR8IaJywX/1k0Ywcz g0ypUPOUwpJ8Dcn5EmKxuuLzZf3sjlcUwLpTey94RXkVeVTuM2A1mkq3GBa6NjVlpPH+ pW+cCicu67VeIGxcxoFmqoxUdHrQCqZyG4PVgHDInz6vxb5utFpPJZkxKHdAFOc83zYL 35zA== X-Gm-Message-State: ALQs6tDvD+j3pIfrQs5DuWYxB5qriNpd4lrQgLcPdOa+CrpzNvkkoB4j +VevK37CxLVKomQUI9FwaKgIRg== X-Google-Smtp-Source: AIpwx48qcqmrJ3CFTKRWBCd4sKUVFonTUF/A9qzaRSjicfT+Q/3P+Of08gUYKfvdKdHOiktQe6w/Xw== X-Received: by 10.98.58.75 with SMTP id h72mr1970720pfa.209.1523404323768; Tue, 10 Apr 2018 16:52:03 -0700 (PDT) Received: from [192.168.178.26] ([118.148.68.60]) by smtp.gmail.com with ESMTPSA id c186sm6816732pfb.40.2018.04.10.16.52.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 16:52:02 -0700 (PDT) Sender: Brian Carpenter To: "Diego R. Lopez" , Thomas Hardjono , "din@irtf.org" References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <5E393DF26B791A428E5F003BB6C5342AE7404E4C@OC11EXPO33.exchange.mit.edu> From: Brian E Carpenter Message-ID: <83096c6a-67f9-bede-df41-9d739b22670f@gmail.com> Date: Wed, 11 Apr 2018 11:52:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 23:52:09 -0000 On 11/04/2018 10:40, Diego R. Lopez wrote: > Hi, >=20 > I'd recommend the group to have a look around the digital identity conc= epts the academic networks shaped during the early 2000s, and that are fo= rmulated in a global scope by the REFEDS initiative: https://refeds.org/ Agreed. And REFEDS descended from the discussions around grid virtual org= anisations where the problem first became apparent, plus the old Shibbole= th system. There's a lot of current practice to look at, and no particula= r reason to bring blockchains into the picture. What you need is an expli= cit, transparent, human-validated model for federating individual trust d= omains. (Exactly what the crypto-currencies lack, as far as I can see.) R= EFEDS federates 72 national trust domains, according to their site, and I= assume that each of those is itself a federation of local domains. Here's more info: https://www.geant.org/Services/Trust_identity_and_security/eduGAIN "... over 2,500 identity providers ..." Brian >=20 > Be goode, >=20 > -- > "Esta vez no fallaremos, Doctor Infierno" >=20 > Dr Diego R. Lopez > Telefonica I+D > https://www.linkedin.com/in/dr2lopez/ >=20 > e-mail: diego.r.lopez@telefonica.com > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- > =EF=BB=BFOn 10/04/2018, 18:49, "Din on behalf of Thomas Hardjono" wrote: >=20 >=20 > >>> From: Din [din-bounces@irtf.org] on behalf of Brian E Carpenter= [brian.e.carpenter@gmail.com] > >>> ... > >>> That isn't a marginal case. Tens or hundreds of millions of peo= ple > >>> would need cross-border digital ID these days. Sales argument: = would > >>> help to defeat money laundering. >=20 > Lots of people seem to want to provide digital-identity on a global= scale immediately. from day 1. >=20 > Some folks even imagine there will be one huge global blockchain fo= r the entire world :-) >=20 > But there is a lot to be learned from the history how IP routing em= erged (e.g. days when > we only had IS-IS for local routing, not even OSPF). >=20 > Just like there is "autonomous systems" (AS) concept in routing and= connected via backbone routing, > in the area of identity there needs to be the equivalent of an AS. >=20 > I've been calling it "communities" (data communities) for humans an= d personal data. >=20 > Its by interlinking ASes (communities) do we get scale and get iden= tity services to be globally reachable. >=20 > So anytime I hear about a global blockchain to rule them all, I cri= nge :-) >=20 >=20 > -- thomas -- >=20 >=20 >=20 >=20 >=20 > ________________________________________ > From: Din [din-bounces@irtf.org] on behalf of Brian E Carpenter [br= ian.e.carpenter@gmail.com] > Sent: Sunday, April 08, 2018 9:44 PM > To: din@irtf.org > Subject: Re: [Din] WSJ article on Identity and Blockchains >=20 > On 09/04/2018 10:28, Arjuna Sathiaseelan wrote: > >> > >> 2/ I though many people in the security community were moving aw= ay from > >> proving identity, towards systems that prove entitlement (i.e. c= redentials > >> are on a need-to-know basis, so if you were say 19, you don't ne= ed to say > >> yur age or show id, > >> but you can't buy a drink in cambridge MA, but you can in cambri= dge, UK :) > >> > > > > digital id plays a major role for all the KYC/AML - massive marke= t.. + for > > employment etc.. >=20 > Right, but *international* digital ID is a hopeless mess. Just try = dealing > with a USA bank's KYC department when living in New Zealand with a = UK > passport. Nothing works. >=20 > That isn't a marginal case. Tens or hundreds of millions of people > would need cross-border digital ID these days. Sales argument: woul= d > help to defeat money laundering. >=20 > Brian >=20 > > like the idea of proving entitlement - works nicely with crypto > > charities/aid delivery.. > > > > Regards > > > > > > > > > >> bootstrapping something from a BC to provide the credentials is = also > >> problematic, in that > >> BC needs a PKI to know whether nodes are not sybils, spoofs, etc= , so we > >> have a circular dependance, no? > >> > >> maybe i missed an important step, if so, sorry! > >> > >> > >>> Folks, > >>> > >>> I thought to share this WSJ article with the DIN group. Relevan= t in the > >>> light of recent interest in using BC for identity. > >>> > >>> Advance apologies if it offends some people :-) > >>> > >>> https://blogs.wsj.com/cio/2018/04/03/digital-identity- > >> is-broken-heres-a-way-to-fix-it/ > >>> > >>> > >>> Below is a link to a PDF version. > >>> > >>> http://hardjono.mit.edu/sites/default/files/documents/WSJ_ > >> Digital_Identity_is_Broken.pdf > >>> > >>> > >>> Best > >>> > >>> -- thomas -- > >>> > >>> _______________________________________________ > >>> Din mailing list > >>> Din@irtf.org > >>> https://www.irtf.org/mailman/listinfo/din > >>> > >> _______________________________________________ > >> Din mailing list > >> Din@irtf.org > >> https://www.irtf.org/mailman/listinfo/din > >> > > > > > > > > > > > > _______________________________________________ > > Din mailing list > > Din@irtf.org > > https://www.irtf.org/mailman/listinfo/din > > >=20 > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din >=20 >=20 >=20 > ________________________________ >=20 > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario= , puede contener informaci=C3=B3n privilegiada o confidencial y es para u= so exclusivo de la persona o entidad de destino. Si no es usted. el desti= natario indicado, queda notificado de que la lectura, utilizaci=C3=B3n, d= ivulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en = virtud de la legislaci=C3=B3n vigente. Si ha recibido este mensaje por er= ror, le rogamos que nos lo comunique inmediatamente por esta misma v=C3=AD= a y proceda a su destrucci=C3=B3n. >=20 > The information contained in this transmission is privileged and confid= ential information intended only for the use of the individual or entity = named above. If the reader of this message is not the intended recipient,= you are hereby notified that any dissemination, distribution or copying = of this communication is strictly prohibited. If you have received this t= ransmission in error, do not read it. Please immediately reply to the sen= der that you have received this communication in error and then delete it= =2E >=20 > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3= =A9 para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9= vossa senhoria o destinat=C3=A1rio indicado, fica notificado de que a le= itura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem aut= oriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o= vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comuni= que imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o= >=20 From nobody Tue Apr 10 17:04:58 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96FD12D876 for ; Tue, 10 Apr 2018 17:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fe8fVPFJmF8 for ; Tue, 10 Apr 2018 17:04:55 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5835012D944 for ; Tue, 10 Apr 2018 17:04:55 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id w3B04nF5033642; Tue, 10 Apr 2018 17:04:49 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id w3B04nrX040743; Tue, 10 Apr 2018 17:04:49 -0700 (PDT) From: David Mazieres To: Thomas Hardjono , Brian E Carpenter , "din\@irtf.org" In-Reply-To: <5E393DF26B791A428E5F003BB6C5342AE7404E4C@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <5E393DF26B791A428E5F003BB6C5342AE7404E4C@OC11EXPO33.exchange.mit.edu> Reply-To: David Mazieres expires 2018-07-09 PDT Date: Tue, 10 Apr 2018 17:04:54 -0700 Message-ID: <87h8oimwux.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 00:04:57 -0000 Thomas Hardjono writes: > Just like there is "autonomous systems" (AS) concept in routing and > connected via backbone routing, in the area of identity there needs to > be the equivalent of an AS. Yes, but obviously AS numbers are centrally allocated and a flat namespace. If we are going to have various identity providers, I would argue we need two things unlike AS numbers: 1. The identifiers should be self-authenticating (public keys, not integers), so allocation is "self-server," and 2. We need some notion of a "symbolic link", so that I can name not just someone else's key, but someone else's name, as that's very powerful. These points of course were ones that many of us were making in the 1990s. See, for instance SPKI/SDSI. > So anytime I hear about a global blockchain to rule them all, I cringe > :-) The blockchain is useful, but sort of orthogonal to the namespace itself. What it provides, that we couldn't do before, is the ability to voluntarily restrict what you do with your own namespace. E.g., maybe you want to delegate a name and then restrict yourself from revoking it without seven days notice. David From nobody Wed Apr 11 07:38:03 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696BE1241F3 for ; Wed, 11 Apr 2018 07:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYEo_UAUCFRG for ; Wed, 11 Apr 2018 07:37:59 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878F9120725 for ; Wed, 11 Apr 2018 07:37:58 -0700 (PDT) X-AuditID: 12074425-e43ff7000000696f-4a-5ace1dc3f0d6 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id F6.2F.26991.4CD1ECA5; Wed, 11 Apr 2018 10:37:57 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w3BEbp2D016708; Wed, 11 Apr 2018 10:37:52 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w3BEbkR6023728; Wed, 11 Apr 2018 10:37:49 -0400 Received: from W92EXHUB15.exchange.mit.edu (18.7.73.26) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 11 Apr 2018 10:37:44 -0400 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.111]) by W92EXHUB15.exchange.mit.edu ([18.7.73.26]) with mapi id 14.03.0352.000; Wed, 11 Apr 2018 10:37:46 -0400 From: Thomas Hardjono To: David Mazieres expires 2018-07-09 PDT , Brian E Carpenter , "din@irtf.org" Thread-Topic: [Din] WSJ article on Identity and Blockchains Thread-Index: AQHTzcUHgLU9VkLMR0+I6ZGjg4OG6aP28xeAgADGQICAADbKgIACSeiTgAC+6wCAAK6h9g== Date: Wed, 11 Apr 2018 14:37:46 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AE7408B6D@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <5E393DF26B791A428E5F003BB6C5342AE7404E4C@OC11EXPO33.exchange.mit.edu>, <87h8oimwux.fsf@ta.scs.stanford.edu> In-Reply-To: <87h8oimwux.fsf@ta.scs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKKsWRmVeSWpSXmKPExsUixG6nontU9lyUwbnnQhZtF/cxWSz9uJfF YupGcwdmj52z7rJ7TN54mM3j0t9tTAHMUVw2Kak5mWWpRfp2CVwZ19vusxT0C1fMPLiIuYHx F18XIweHhICJxPSe7C5GLg4hgcVMElPm3maHcA4wStzasZcRwjnGKPH09X0oZwejxLRjfcwQ zmpGifX/3gD1cHKwCWhItP3oBbNFBG4wSpxqUwCxhQWsJNbfW88Gsk9EwFpiz/JwCDNM4tXy NJAKFgFViQlP3zOBhHkFgiT2N0pBTH/EJNG9aBEzSA2ngKHExEuTWEFsRgExie+n1jCB2MwC 4hK3nswHsyUEBCUWzd7DDGGLSfzb9ZANwpaVaPl8kxWiXkdiwe5PbBC2tsSyha/B6nmBek/O fMIygVF8FpKxs5C0zELSMgtJywJGllWMsim5Vbq5iZk5xanJusXJiXl5qUW6Fnq5mSV6qSml mxjBseeiuoNxzl+vQ4wCHIxKPLwXbp2JEmJNLCuuzD3EKMnBpCTKe4D7XJQQX1J+SmVGYnFG fFFpTmrxIUYJDmYlEd6jv89GCfGmJFZWpRblw6SkOViUxHkX798bJSSQnliSmp2aWpBaBJOV 4eBQkuANkAEaKliUmp5akZaZU4KQZuLgBBnOAzQ8DaSGt7ggMbc4Mx0if4pRUUqctx8kIQCS yCjNg+uFpEZPgVeM4kCvCPOWgFTxANMqXPcroMFMQIOP+ZwBGVySiJCSamDUWsRzYvLKVUdf fvOaWvmi+rxjuvfeV7OeBlr/sWfgSux9f6NDXuRpqA/v0zSGFaYXeX1U+wyrdf5+M8qNDCt3 Uar8Jszxj7Fkz7M5R1QWz+G1uX01JEl36iZNESNBgX9i+lM/zPqsyNAk/t8zvX37U17RY1Nr H02yOMR5Y6/tBJ2lGzfWy/QosRRnJBpqMRcVJwIAAORgSmgDAAA= Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 14:38:01 -0000 Hi David, >>> 2. We need some notion of a "symbolic link", so that I can name not >>> just someone else's key, but someone else's name, as that's very >>> powerful. Yes the symbolic link is needed, but more importantly (and more difficult) = is the binding to the owners person. How do I know that the person Alice f= or pubkey X is the same Alice who owns pub key Y. >>> These points of course were ones that many of us were making in the >>> 1990s. See, for instance SPKI/SDSI. Agree, that was Car Ellison's proposal. >>> The blockchain is useful, but sort of orthogonal to the namespace >>> itself. =20 Agree. >>> What it provides, that we couldn't do before, is the ability to >>> voluntarily restrict what you do with your own namespace. E.g., maybe >>> you want to delegate a name and then restrict yourself from revoking it >>> without seven days notice. Could we use DNSSEC for this?=20 -- thomas --=20 ________________________________________ From: David Mazieres [dm-list-ietf-ilc@scs.stanford.edu] Sent: Tuesday, April 10, 2018 8:04 PM To: Thomas Hardjono; Brian E Carpenter; din@irtf.org Subject: Re: [Din] WSJ article on Identity and Blockchains Thomas Hardjono writes: > Just like there is "autonomous systems" (AS) concept in routing and > connected via backbone routing, in the area of identity there needs to > be the equivalent of an AS. Yes, but obviously AS numbers are centrally allocated and a flat namespace. If we are going to have various identity providers, I would argue we need two things unlike AS numbers: 1. The identifiers should be self-authenticating (public keys, not integers), so allocation is "self-server," and 2. We need some notion of a "symbolic link", so that I can name not just someone else's key, but someone else's name, as that's very powerful. These points of course were ones that many of us were making in the 1990s. See, for instance SPKI/SDSI. > So anytime I hear about a global blockchain to rule them all, I cringe > :-) The blockchain is useful, but sort of orthogonal to the namespace itself. What it provides, that we couldn't do before, is the ability to voluntarily restrict what you do with your own namespace. E.g., maybe you want to delegate a name and then restrict yourself from revoking it without seven days notice. David= From nobody Wed Apr 11 13:35:01 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2071412AF84 for ; Wed, 11 Apr 2018 13:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0Yiw-9o26Ns for ; Wed, 11 Apr 2018 13:34:58 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148DD1271FD for ; Wed, 11 Apr 2018 13:34:58 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id f15so1643049pfn.0 for ; Wed, 11 Apr 2018 13:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CprcTmn8r9VveZJYVKBEyH14fjDuNJDl3iRCGyWxdrw=; b=o3DE/L33pNtKv5SgkPgG7MW+d61yAaB/j1WSZ9TH6rc82T5SAwqo4wEYe7U1+tHgev bc5q4yXelxfJBltn3RWBZUbiDsVK/e8Qx2kj2KjtknbpKM8fCJ2rqn0VPRNQ5tLZTw5r aHHPNiW2cW1+gP9xeleGivk//0HGkyGRmzZRMjGnOc85UCLx5i1ui6CgWFEdrvbH00AX 95lHLAeSwP/4wAnVUdPzxtwNFY+Itmpx56m0wqsxaSn1dhH0d45c4E3lieVKn97J0Csk qE9jK48R7wxYPtt1gplicBS9Tpdy/VriffOQLo5OABHFXy8hyan1X4r3i0ER7neeXtD3 LUvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CprcTmn8r9VveZJYVKBEyH14fjDuNJDl3iRCGyWxdrw=; b=c+hl/Y0WrhjORnSIYYFy6dgPofB7nxYe7eTMec3BYPxXts/JBLRXSUNbU1qOSm2nen BoM/ljqbOeFCIL6sUDvFQmo4OllSb/w77m8vwR0uzyawm2eluTDfI4982j0D5KcNE1xq TCVuxaaa63MNx6BmuO7aR8Gwju/uvVabohMIQcqogIGPAxk0eHhwnC+WfWvxgWlFQPvv 8ciSfVksFZIurpTgKqDkVZ9A1CJDPsOHGssS4OU1zq6poC0TjKQQPQiANORLMLoClezy uVUipWPO6KAGCFjPU1CK3WI8Y68fWkiTknXMB0seEhJV7GWMLtuJsCuXNlrN+W2gG+LD p31A== X-Gm-Message-State: ALQs6tCaZp2XOV/UxbTi/mtUdvy5v3B7aD2ZxFDQPL9U47DS/YGBerk5 kyxrhB0HhS2YFC+3aUb/2fFJWQ== X-Google-Smtp-Source: AIpwx4/bOKekeh9iZFKEaQ9txIoZ5M9XI8mKgfksqfm8OuU/uo4k/y171e9R+KZ9Mw9G2cpfVPRFIg== X-Received: by 10.99.126.92 with SMTP id o28mr4529253pgn.50.1523478897269; Wed, 11 Apr 2018 13:34:57 -0700 (PDT) Received: from [192.168.178.26] ([118.148.68.60]) by smtp.gmail.com with ESMTPSA id 133sm4205332pfy.113.2018.04.11.13.34.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 13:34:56 -0700 (PDT) Sender: Brian Carpenter To: Thomas Hardjono , David Mazieres expires 2018-07-09 PDT , "din@irtf.org" References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <5E393DF26B791A428E5F003BB6C5342AE7404E4C@OC11EXPO33.exchange.mit.edu> <87h8oimwux.fsf@ta.scs.stanford.edu> <5E393DF26B791A428E5F003BB6C5342AE7408B6D@OC11EXPO33.exchange.mit.edu> From: Brian E Carpenter Message-ID: Date: Thu, 12 Apr 2018 08:34:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5E393DF26B791A428E5F003BB6C5342AE7408B6D@OC11EXPO33.exchange.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 20:35:00 -0000 On 12/04/2018 02:37, Thomas Hardjono wrote: > > Hi David, > > >>>> 2. We need some notion of a "symbolic link", so that I can name not >>>> just someone else's key, but someone else's name, as that's very >>>> powerful. > > Yes the symbolic link is needed, but more importantly (and more difficult) is the binding to the owners person. How do I know that the person Alice for pubkey X is the same Alice who owns pub key Y. Do you need to know? Surely what you need to know is what capabilities to grant to the holder of pubkey X, and what capabilities to grant to the holder of pubkey Y. Alice might prefer to have disjoint identities for different purposes. In some countries that might be essential for personal safety. Brian >>>> These points of course were ones that many of us were making in the >>>> 1990s. See, for instance SPKI/SDSI. > > Agree, that was Car Ellison's proposal. > > >>>> The blockchain is useful, but sort of orthogonal to the namespace >>>> itself. > > Agree. > > >>>> What it provides, that we couldn't do before, is the ability to >>>> voluntarily restrict what you do with your own namespace. E.g., maybe >>>> you want to delegate a name and then restrict yourself from revoking it >>>> without seven days notice. > > Could we use DNSSEC for this? > > > -- thomas -- > > > ________________________________________ > From: David Mazieres [dm-list-ietf-ilc@scs.stanford.edu] > Sent: Tuesday, April 10, 2018 8:04 PM > To: Thomas Hardjono; Brian E Carpenter; din@irtf.org > Subject: Re: [Din] WSJ article on Identity and Blockchains > > Thomas Hardjono writes: > >> Just like there is "autonomous systems" (AS) concept in routing and >> connected via backbone routing, in the area of identity there needs to >> be the equivalent of an AS. > > Yes, but obviously AS numbers are centrally allocated and a flat > namespace. If we are going to have various identity providers, I would > argue we need two things unlike AS numbers: > > 1. The identifiers should be self-authenticating (public keys, not > integers), so allocation is "self-server," and > > 2. We need some notion of a "symbolic link", so that I can name not > just someone else's key, but someone else's name, as that's very > powerful. > > These points of course were ones that many of us were making in the > 1990s. See, for instance SPKI/SDSI. > >> So anytime I hear about a global blockchain to rule them all, I cringe >> :-) > > The blockchain is useful, but sort of orthogonal to the namespace > itself. What it provides, that we couldn't do before, is the ability to > voluntarily restrict what you do with your own namespace. E.g., maybe > you want to delegate a name and then restrict yourself from revoking it > without seven days notice. > > David > From nobody Wed Apr 11 14:08:27 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C5012D77C for ; Wed, 11 Apr 2018 14:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dj4ouvST785h for ; Wed, 11 Apr 2018 14:08:24 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA4C124217 for ; Wed, 11 Apr 2018 14:08:24 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id w3BL8EOB022029; Wed, 11 Apr 2018 14:08:14 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id w3BL8DOe086185; Wed, 11 Apr 2018 14:08:13 -0700 (PDT) From: David Mazieres To: Thomas Hardjono , Brian E Carpenter , "din\@irtf.org" In-Reply-To: <5E393DF26B791A428E5F003BB6C5342AE7408B6D@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <5E393DF26B791A428E5F003BB6C5342AE7404E4C@OC11EXPO33.exchange.mit.edu> <87h8oimwux.fsf@ta.scs.stanford.edu> <5E393DF26B791A428E5F003BB6C5342AE7408B6D@OC11EXPO33.exchange.mit.edu> Reply-To: David Mazieres expires 2018-07-10 PDT Date: Wed, 11 Apr 2018 14:08:22 -0700 Message-ID: <87vacx4fjt.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 21:08:26 -0000 Thomas Hardjono writes: >>>> 2. We need some notion of a "symbolic link", so that I can name not >>>> just someone else's key, but someone else's name, as that's very >>>> powerful. > > Yes the symbolic link is needed, but more importantly (and more > difficult) is the binding to the owners person. How do I know that > the person Alice for pubkey X is the same Alice who owns pub key Y. This doesn't seem hard conceptually--just have pubkey Y sign some statement about Alice and pubkey X. The more interesting question in my mind is tying together non-pubkey identities. How do I know this person submitting pull requests to my project is also the former Stanford student I've been chatting with online? I think Keybase in particular has made some pretty good headway in addressing the problem, but that is a centralized system to some extent, and could definitely benefit from some decentralized internet infrastructure... >>>> What it provides, that we couldn't do before, is the ability to >>>> voluntarily restrict what you do with your own namespace. E.g., maybe >>>> you want to delegate a name and then restrict yourself from revoking it >>>> without seven days notice. > > Could we use DNSSEC for this? I don't see how to do this without some new kind of system for encoding such update rules and a consensus mechanism for enforcing it. And obviously I believe the SCP draft is a step in the right direction for the enforcement side of this problem... https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/ David From nobody Mon Apr 16 01:42:42 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11A6126BF0 for ; Mon, 16 Apr 2018 01:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUcxi00I8wEQ for ; Mon, 16 Apr 2018 01:42:39 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC370124239 for ; Mon, 16 Apr 2018 01:42:38 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id d6so17140912iog.1 for ; Mon, 16 Apr 2018 01:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XRL0UcuAPmgrAfWnjgR16WcPOR8djHegLTO8PyWziqU=; b=GQxpuy2cZ9gXLTUWIVsdIOyYuBiQ8osz7S6pAXDhK4dkZefpsjM0W5B6R90BfP+QKa yNccb80IT0GdNZ3pGX//T+yxujQ7xVww2nRShJEXvu7FjyPIHTwAQhoPet28ySOD1mT4 G2bLgn0duVuEqnma0BTddSlBkDb9rBzPiX7fBizXWTHAWQcSXDNQctwXoYNQkj8k/kaq HFujUjCUu79SF0zSgZdz80f7XnvbdI9cAV7csabgXiJdm27dhdLTff8lJWjshCbMt2jz 9jUn0mz8XIT9DfSI7NEe8EG4lJlDM4wtpl1Xi1mrt+qcELPBqabxKKbpLHGSFMwuP9ov 54Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XRL0UcuAPmgrAfWnjgR16WcPOR8djHegLTO8PyWziqU=; b=jM/lbFTSHsnrdUAUKBycl5oXMpWFyn6q/6/AfZY7hSalo/jzJysB110oRk4EH7kXdS O3safJXt5VfpxE8PZo5oJpB1t2TRxJx4XJ0F5UJeaZrRuRrtjzDD8NN/Vr7pJvBgDpkw ngF6G8keypFm05tb3rN0402bJLTcmWTkxvxakzsR+k15G+40Rr5fNtyetxA/ifXaxO0D jDhP892HFypUoprYT9Vj67yWXa24uCbjb39VDaKzoK8t4t4QIc8RDqejFfp/hrTFTxPU MItF75lVEFfXdFc0dy8M/78Uef3kGB1uAZu3DgC0JpbJgVWH74obopm7HdGGFZVw1329 HESA== X-Gm-Message-State: ALQs6tApIn3+7KqLkQyYYnUHGc8+l8fT8bToyh/Ta+1kMyIRRbmtcjym Qsj8LIz+3wSD9kHvq9F5ronvvEBRi6qOSzO+Jgs= X-Google-Smtp-Source: AIpwx4+PvGALcnz7MUl22SpXNqxAcCUNxzIy2pMGOFpZTCWTlTHcRVVxHDxYOvxHp1ZSmZ0GGkm+RvLIZDEUpxteUgc= X-Received: by 10.107.204.1 with SMTP id c1mr21949789iog.304.1523868158105; Mon, 16 Apr 2018 01:42:38 -0700 (PDT) MIME-Version: 1.0 Sender: arjuna.sathiaseelan@gmail.com Received: by 10.79.198.5 with HTTP; Mon, 16 Apr 2018 01:42:37 -0700 (PDT) In-Reply-To: References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> From: Arjuna Sathiaseelan Date: Mon, 16 Apr 2018 09:42:37 +0100 X-Google-Sender-Auth: _VKwxaLccQ_2Sat3ENSY88hxvW4 Message-ID: To: Brian E Carpenter Cc: din@irtf.org Content-Type: multipart/alternative; boundary="94eb2c1b779a3f9f170569f33443" Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 08:42:41 -0000 --94eb2c1b779a3f9f170569f33443 Content-Type: text/plain; charset="UTF-8" this is something we are working on via https://www.verif-y.com/ hope to get some experiences and I would share here for sure. Regards On 9 April 2018 at 02:44, Brian E Carpenter wrote: > On 09/04/2018 10:28, Arjuna Sathiaseelan wrote: > >> > >> 2/ I though many people in the security community were moving away from > >> proving identity, towards systems that prove entitlement (i.e. > credentials > >> are on a need-to-know basis, so if you were say 19, you don't need to > say > >> yur age or show id, > >> but you can't buy a drink in cambridge MA, but you can in cambridge, UK > :) > >> > > > > digital id plays a major role for all the KYC/AML - massive market.. + > for > > employment etc.. > > Right, but *international* digital ID is a hopeless mess. Just try dealing > with a USA bank's KYC department when living in New Zealand with a UK > passport. Nothing works. > > That isn't a marginal case. Tens or hundreds of millions of people > would need cross-border digital ID these days. Sales argument: would > help to defeat money laundering. > > Brian > > > like the idea of proving entitlement - works nicely with crypto > > charities/aid delivery.. > > > > Regards > > > > > > > > > >> bootstrapping something from a BC to provide the credentials is also > >> problematic, in that > >> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we > >> have a circular dependance, no? > >> > >> maybe i missed an important step, if so, sorry! > >> > >> > >>> Folks, > >>> > >>> I thought to share this WSJ article with the DIN group. Relevant in the > >>> light of recent interest in using BC for identity. > >>> > >>> Advance apologies if it offends some people :-) > >>> > >>> https://blogs.wsj.com/cio/2018/04/03/digital-identity- > >> is-broken-heres-a-way-to-fix-it/ > >>> > >>> > >>> Below is a link to a PDF version. > >>> > >>> http://hardjono.mit.edu/sites/default/files/documents/WSJ_ > >> Digital_Identity_is_Broken.pdf > >>> > >>> > >>> Best > >>> > >>> -- thomas -- > >>> > >>> _______________________________________________ > >>> Din mailing list > >>> Din@irtf.org > >>> https://www.irtf.org/mailman/listinfo/din > >>> > >> _______________________________________________ > >> Din mailing list > >> Din@irtf.org > >> https://www.irtf.org/mailman/listinfo/din > >> > > > > > > > > > > > > _______________________________________________ > > Din mailing list > > Din@irtf.org > > https://www.irtf.org/mailman/listinfo/din > > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > -- Arjuna Sathiaseelan University of Cambridge | Ammbr Research Labs Personal: http://www.cl.cam.ac.uk/~as2330/ N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d --94eb2c1b779a3f9f170569f33443 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
this is something we are working on via=C2=A0https://www.verif-y.com/

hop= e to get some experiences and I would share here for sure.

Regards

On 9 April 2018 at 02:44, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 09/04/2018 10:28, Arjuna Sathiaseelan wrote:
>>
>> 2/ I though many people in the security community were moving away= from
>> proving identity, towards systems that prove entitlement (i.e. cre= dentials
>> are on a need-to-know basis, so if you were say 19, you don't = need to say
>> yur age or show id,
>> but you can't buy a drink in cambridge MA, but you can in camb= ridge, UK :)
>>
>
> digital id plays a major role for all the KYC/AML - massive market.. += for
> employment etc..

Right, but *international* digital ID is a hopeless mess. Just try d= ealing
with a USA bank's KYC department when living in New Zealand with a UK passport. Nothing works.

That isn't a marginal case. Tens or hundreds of millions of people
would need cross-border digital ID these days. Sales argument: would
help to defeat money laundering.

=C2=A0 =C2=A0Brian
=C2=A0
> like the idea of proving entitlement - works nicely with crypto
> charities/aid delivery..
>
> Regards
>
>
>
>
>> bootstrapping something from a BC to provide the credentials is al= so
>> problematic, in that
>> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, = so we
>> have a circular dependance, no?
>>
>> maybe i missed an important step, if so, sorry!
>>
>>
>>> Folks,
>>>
>>> I thought to share this WSJ article with the DIN group. Releva= nt in the
>>> light of recent interest in using BC for identity.
>>>
>>> Advance apologies if it offends some people :-)
>>>
>>> https://blogs.wsj.com/cio/20= 18/04/03/digital-identity-
>> is-broken-heres-a-way-to-fix-it/
>>>
>>>
>>> Below is a link to a PDF version.
>>>
>>> http://hardjono.mit.edu/sites= /default/files/documents/WSJ_
>> Digital_Identity_is_Broken.pdf
>>>
>>>
>>> Best
>>>
>>> -- thomas --
>>>
>>> _______________________________________________
>>> Din mailing list
>>> Din@irtf.org
>>> https://www.irtf.org/mailman/listinfo/din=
>>>
>> _______________________________________________
>> Din mailing list
>> Din@irtf.org
>> https://www.irtf.org/mailman/listinfo/din=
>>
>
>
>
>
>
> _______________________________________________
> Din mailing list
> Din@irtf.org
> https://www.irtf.org/mailman/listinfo/din
>

_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din



--
=

Arjuna Sathiaseelan
U= niversity of Cambridge | Ammbr Research Labs
Personal: http://www.cl.cam.ac.uk/~as23= 30/
N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d
=
--94eb2c1b779a3f9f170569f33443-- From nobody Sun Apr 22 19:30:00 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775171243FE for ; Sun, 22 Apr 2018 19:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBgSv04eGB2V for ; Sun, 22 Apr 2018 19:29:57 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7985A126DCA for ; Sun, 22 Apr 2018 19:29:57 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id j11so7309525pgf.2 for ; Sun, 22 Apr 2018 19:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=N+RLvm+vN39CbqhvWuZrzIFCv8vNZXZ2U4n5/IzQ+Hs=; b=PlKvb6sEobuJ8aY1EnfEpvCIAqHOs+zmhUYrMyTAjZkXpK0pKcyFoMDvsI0LIaIpJC yxWrQaBmyE6XJjpWA6a7UAWXes9VhDfvn68v/b6kX9KBb/eK3D8UyrAWy+VTJfjNVXGR GCVEg1IJFpJQUAow+zwAWsS6I8dTGVdMS8D1ZDjQECoxptJF6f0V8VytzK5fpolrVwcc dcxK05cTJ5pHdoHNpZokP4ld2e0yEF1+y0d+vaRrfl8OrgQ4k1FvWYF9PAiN6rG0n9aF WvFU9kqbz1UbcdF2p3JAx54AxyCugPF2ZQpohPpAn64BQAanu69nX5vPlpIZCmy2jnJ9 F3lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N+RLvm+vN39CbqhvWuZrzIFCv8vNZXZ2U4n5/IzQ+Hs=; b=D+Y3gzYqSxU2YzeqyF2VF1eKoFzGkcpOVdrLffDYNJZluTr1tN4QzX6HD4I6/rBB3u j7cRNt6c/hGbhicFCJ4ci/NyBEl7KWi7J6O4rephJag7YizYIDiAooUyrf50R8lf+TzE RCsQA1SRQcQbu806Fd1hOWCW5VMcYPGaGdZYofx4d49MZg4EU1ECyTC7Xp74/5gXfWba 0FxxUz02qWRctoBG4eCehQCJJIVbCPnwZdZfrsilMGgbfUUtipsbOE598v1cFrZK15nu hrpCCwyZUGd01HnX8qtYBkadPAKh72QFY5NVjQLyqAwJHnJiykxIEBjE9Gsc3h4e/lRg pxVg== X-Gm-Message-State: ALQs6tCXNYXQRPvampJRnXBbRw7nCQpPM/eL/rvSt+EWkwMOY1muIfhO 0h/BSvqeS39T8A/BR7pc7N0Jyw== X-Google-Smtp-Source: AIpwx49JAUx6IKfRkoZil9lcVI3S5jMHfwayMu2mPQhgDqqdxZdoPq3R0t5GO+LXWIO400SRkaSERA== X-Received: by 2002:a17:902:6bc3:: with SMTP id m3-v6mr18694898plt.363.1524450596689; Sun, 22 Apr 2018 19:29:56 -0700 (PDT) Received: from [130.216.38.11] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.11]) by smtp.gmail.com with ESMTPSA id c187sm20286328pfa.181.2018.04.22.19.29.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Apr 2018 19:29:55 -0700 (PDT) Sender: Brian Carpenter To: Arjuna Sathiaseelan Cc: din@irtf.org References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> From: Brian E Carpenter Message-ID: <8dae9467-f190-6903-56d8-99a7effd4954@gmail.com> Date: Mon, 23 Apr 2018 14:29:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 02:29:59 -0000 Arjuna On 16/04/2018 20:42, Arjuna Sathiaseelan wrote: > this is something we are working on via https://www.verif-y.com/ "The Verif-y KYC service allows businesses utilizing blockchain technology to trust unknown customers and token purchasers in an efficient, auditable and secure manner." I'm confused. KYC is largely about detecting money laundering, and other malfeasance, so the last thing a KYC desk cares about is unknown customers. On the contrary, they want to know the legal identity of the customer and of the source of funds. Direct access to PII is part of the process. Believe me, I've been there, not 10 km from cl.cam.ac.uk, when my bank tried to cut me off from my money soon after I relocated from Auckland to Cambridge in 2012. Somehow they had failed to update my residence address and I had to get documents certified and rubber-stamped at Cambridge police station, and sent by snail mail to the bank's KYC desk, before we got our money back. How does block chain solve that? (Not a rhetorical question; I would really like to understand.) Brian > > hope to get some experiences and I would share here for sure. > > Regards > > On 9 April 2018 at 02:44, Brian E Carpenter > wrote: > >> On 09/04/2018 10:28, Arjuna Sathiaseelan wrote: >>>> >>>> 2/ I though many people in the security community were moving away from >>>> proving identity, towards systems that prove entitlement (i.e. >> credentials >>>> are on a need-to-know basis, so if you were say 19, you don't need to >> say >>>> yur age or show id, >>>> but you can't buy a drink in cambridge MA, but you can in cambridge, UK >> :) >>>> >>> >>> digital id plays a major role for all the KYC/AML - massive market.. + >> for >>> employment etc.. >> >> Right, but *international* digital ID is a hopeless mess. Just try dealing >> with a USA bank's KYC department when living in New Zealand with a UK >> passport. Nothing works. >> >> That isn't a marginal case. Tens or hundreds of millions of people >> would need cross-border digital ID these days. Sales argument: would >> help to defeat money laundering. >> >> Brian >> >>> like the idea of proving entitlement - works nicely with crypto >>> charities/aid delivery.. >>> >>> Regards >>> >>> >>> >>> >>>> bootstrapping something from a BC to provide the credentials is also >>>> problematic, in that >>>> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we >>>> have a circular dependance, no? >>>> >>>> maybe i missed an important step, if so, sorry! >>>> >>>> >>>>> Folks, >>>>> >>>>> I thought to share this WSJ article with the DIN group. Relevant in the >>>>> light of recent interest in using BC for identity. >>>>> >>>>> Advance apologies if it offends some people :-) >>>>> >>>>> https://blogs.wsj.com/cio/2018/04/03/digital-identity- >>>> is-broken-heres-a-way-to-fix-it/ >>>>> >>>>> >>>>> Below is a link to a PDF version. >>>>> >>>>> http://hardjono.mit.edu/sites/default/files/documents/WSJ_ >>>> Digital_Identity_is_Broken.pdf >>>>> >>>>> >>>>> Best >>>>> >>>>> -- thomas -- >>>>> >>>>> _______________________________________________ >>>>> Din mailing list >>>>> Din@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/din >>>>> >>>> _______________________________________________ >>>> Din mailing list >>>> Din@irtf.org >>>> https://www.irtf.org/mailman/listinfo/din >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Din mailing list >>> Din@irtf.org >>> https://www.irtf.org/mailman/listinfo/din >>> >> >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >> > > > From nobody Mon Apr 23 12:10:22 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF26126C0F for ; Mon, 23 Apr 2018 12:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRYwMiAQQLWB for ; Mon, 23 Apr 2018 12:10:18 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF25D126B6E for ; Mon, 23 Apr 2018 12:10:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0FED621A21 for ; Mon, 23 Apr 2018 15:10:18 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 23 Apr 2018 15:10:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=tpixBV A8YqWb/DLvhsvTCLViHFNkGA942yjnzRl1C7Q=; b=c5dd/VUqNxzupMCoCYbA3s e0pCqVP5J44J8kO9Nl91v/q0SZyC3l8QYs5spJ+YiUD4i5jwQcDUssyxTxTTKsQa Jmh5TCujg4QWJFEaS/+DObyI+jhZEyHA9tQxZvsuIGEjUbSgyKekcF0RGeOHbges wOz31r27VDCA/YKMPLz5dd9YaQSTaN5jYH9BE2VSSC6bcjHbsfD23YJv7Gycbqm8 Ykt2KoEOs/aA/IYEtlD+SwqW73ZiK8unzvT0QOy0NE8IOR+7VPj/4gqMh44DkOFS +UY/2YMI8Uh1+a0ifYTXmHmlqY0xUNaGPgkxuSOoWtGkagqSlXHkgmJl9LWq+Z6Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DB56EBA780; Mon, 23 Apr 2018 15:10:17 -0400 (EDT) Message-Id: <1524510617.1799095.1348018112.59AF727D@webmail.messagingengine.com> From: Jehan Tremback To: din@irtf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f3006b89 Date: Mon, 23 Apr 2018 12:10:17 -0700 In-Reply-To: <8dae9467-f190-6903-56d8-99a7effd4954@gmail.com> References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <8dae9467-f190-6903-56d8-99a7effd4954@gmail.com> Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:10:21 -0000 As far as I understand the use-case of blockchain in KYC (from the perspective of someone who is vouching for an identity), the main thing is that you can sign off that someone meets some standard of identification (they have a certain address, net worth, etc) and then put it on the blockchain. Of course you could also just give them the signature to present when they need to use it. But putting it on the blockchain allows you to revoke it later. -- Jehan Tremback jehan@altheamesh.com On Sun, Apr 22, 2018, at 7:29 PM, Brian E Carpenter wrote: > Arjuna > > On 16/04/2018 20:42, Arjuna Sathiaseelan wrote: > > this is something we are working on via https://www.verif-y.com/ > > "The Verif-y KYC service allows businesses utilizing blockchain > technology to trust unknown customers and token purchasers in an > efficient, auditable and secure manner." > > I'm confused. KYC is largely about detecting money laundering, and other > malfeasance, so the last thing a KYC desk cares about is unknown > customers. On the contrary, they want to know the legal identity of the > customer and of the source of funds. Direct access to PII is part of the > process. > > Believe me, I've been there, not 10 km from cl.cam.ac.uk, when my bank > tried to cut me off from my money soon after I relocated from Auckland > to Cambridge in 2012. Somehow they had failed to update my residence > address and I had to get documents certified and rubber-stamped at > Cambridge police station, and sent by snail mail to the bank's KYC desk, > before we got our money back. How does block chain solve that? (Not a > rhetorical question; I would really like to understand.) > > Brian > > > > > hope to get some experiences and I would share here for sure. > > > > Regards > > > > On 9 April 2018 at 02:44, Brian E Carpenter > > wrote: > > > >> On 09/04/2018 10:28, Arjuna Sathiaseelan wrote: > >>>> > >>>> 2/ I though many people in the security community were moving away from > >>>> proving identity, towards systems that prove entitlement (i.e. > >> credentials > >>>> are on a need-to-know basis, so if you were say 19, you don't need to > >> say > >>>> yur age or show id, > >>>> but you can't buy a drink in cambridge MA, but you can in cambridge, UK > >> :) > >>>> > >>> > >>> digital id plays a major role for all the KYC/AML - massive market.. + > >> for > >>> employment etc.. > >> > >> Right, but *international* digital ID is a hopeless mess. Just try dealing > >> with a USA bank's KYC department when living in New Zealand with a UK > >> passport. Nothing works. > >> > >> That isn't a marginal case. Tens or hundreds of millions of people > >> would need cross-border digital ID these days. Sales argument: would > >> help to defeat money laundering. > >> > >> Brian > >> > >>> like the idea of proving entitlement - works nicely with crypto > >>> charities/aid delivery.. > >>> > >>> Regards > >>> > >>> > >>> > >>> > >>>> bootstrapping something from a BC to provide the credentials is also > >>>> problematic, in that > >>>> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we > >>>> have a circular dependance, no? > >>>> > >>>> maybe i missed an important step, if so, sorry! > >>>> > >>>> > >>>>> Folks, > >>>>> > >>>>> I thought to share this WSJ article with the DIN group. Relevant in the > >>>>> light of recent interest in using BC for identity. > >>>>> > >>>>> Advance apologies if it offends some people :-) > >>>>> > >>>>> https://blogs.wsj.com/cio/2018/04/03/digital-identity- > >>>> is-broken-heres-a-way-to-fix-it/ > >>>>> > >>>>> > >>>>> Below is a link to a PDF version. > >>>>> > >>>>> http://hardjono.mit.edu/sites/default/files/documents/WSJ_ > >>>> Digital_Identity_is_Broken.pdf > >>>>> > >>>>> > >>>>> Best > >>>>> > >>>>> -- thomas -- > >>>>> > >>>>> _______________________________________________ > >>>>> Din mailing list > >>>>> Din@irtf.org > >>>>> https://www.irtf.org/mailman/listinfo/din > >>>>> > >>>> _______________________________________________ > >>>> Din mailing list > >>>> Din@irtf.org > >>>> https://www.irtf.org/mailman/listinfo/din > >>>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Din mailing list > >>> Din@irtf.org > >>> https://www.irtf.org/mailman/listinfo/din > >>> > >> > >> _______________________________________________ > >> Din mailing list > >> Din@irtf.org > >> https://www.irtf.org/mailman/listinfo/din > >> > > > > > > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din From nobody Mon Apr 23 15:49:00 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA70124BE8 for ; Mon, 23 Apr 2018 15:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkDoh9RahQxj for ; Mon, 23 Apr 2018 15:48:56 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F60124319 for ; Mon, 23 Apr 2018 15:48:56 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id f132so9370308pgc.10 for ; Mon, 23 Apr 2018 15:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=759thNCNhv1qGPsKhieKeMYNYxukHfph2F4XyIDtRhs=; b=LSsmjt5FAzZE40Dy2dcUa3pq9pn8ashPO8yB4z5i/x3ZqW2usEPT3XOa2WPHevqO+K taq3B5GigR7bHNEZVl/yjSk08qcRmJ619A/3RdPO/uFsHHJOHckkZFD3pDiv03Dfavi0 l5eQsyGmq44xrAlkBMyk/sbfukwNC2SI/k2Xx5oBI7PDsvlbjPTYhoa1JXo7DmknMCcm nt4CagpOy9PrhT461SzNg05Vz1OzXD47F099YjvxD9nWU1s1A2qMOUV9+7CeWtUuUzV+ 0KjT1h4RH0wMueJeAUy/7tVUQ248d0VnuAtwnDJQGW70hx5w+/325LmXwiuaM620G5W6 OO9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=759thNCNhv1qGPsKhieKeMYNYxukHfph2F4XyIDtRhs=; b=Va+wrP+j+NCpZ9KbFwpTMP8qlhtq//lnumnNsXp0Ryh5mTd40QB/duLBwX1kbjbSdz Lr+NNWzfutml2AxHnkO79vVkkXmbMQ3TsCvFXJUmDGSCVfYGMUXw2MG6XKk1IRrsS5lO F6GdW5r5Wp1qh+ZFzB91CiR3Esm1GdTO3BpPkXmfrCJlAESe9il4MJvP92GhAnhTPmp7 R3thy/36zyZUigdxg/S8gyfVxoXK1auiJPeUOBrNqkNYYkbU8xuZpg76t+PAUWuWWDhh ZolSAjzjb+IWC2egbTfaP8nWvLqwHn0fqLRPC6LvxGP/FCgsopOxQU4OBvOxswD0Lp/J biSA== X-Gm-Message-State: ALQs6tDU8enGua4nFunaWr4a9aeDVR+p3D/t9nCycujG6lE+rDB2lFAj RC0SSIsEZHOHV5l3yKohtT755A== X-Google-Smtp-Source: AIpwx49wcts7pEQKv/+anFa7KCXwAu6E0JOT++Su0/YlqmhXXCBCGA5x2lkZBZc3ODAAuvR8ALqHpw== X-Received: by 10.101.82.11 with SMTP id o11mr2583310pgp.152.1524523735957; Mon, 23 Apr 2018 15:48:55 -0700 (PDT) Received: from [192.168.178.26] ([118.149.104.73]) by smtp.gmail.com with ESMTPSA id h26sm11438920pfn.106.2018.04.23.15.48.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 15:48:54 -0700 (PDT) Sender: Brian Carpenter To: Jehan Tremback , din@irtf.org References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <8dae9467-f190-6903-56d8-99a7effd4954@gmail.com> <1524510617.1799095.1348018112.59AF727D@webmail.messagingengine.com> From: Brian E Carpenter Message-ID: <5b0a095f-dbc9-de1d-b317-82d14fd4baa0@gmail.com> Date: Tue, 24 Apr 2018 10:48:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1524510617.1799095.1348018112.59AF727D@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 22:49:00 -0000 On 24/04/2018 07:10, Jehan Tremback wrote: > As far as I understand the use-case of blockchain in KYC (from the perspective of someone who is vouching for an identity), the main thing is that you can sign off that someone meets some standard of identification (they have a certain address, net worth, etc) and then put it on the blockchain. Of course you could also just give them the signature to present when they need to use it. > > But putting it on the blockchain allows you to revoke it later. Yes. But it was the "unkown" in "trust unknown customers and token purchasers" that puzzled me on the verif-y.com site. As you imply, KYC is about *knowing* your customer. If it said "identify and trust new customers and token purchasers" I would not have asked my question. Brian > > -- > Jehan Tremback > jehan@altheamesh.com > > On Sun, Apr 22, 2018, at 7:29 PM, Brian E Carpenter wrote: >> Arjuna >> >> On 16/04/2018 20:42, Arjuna Sathiaseelan wrote: >>> this is something we are working on via https://www.verif-y.com/ >> >> "The Verif-y KYC service allows businesses utilizing blockchain >> technology to trust unknown customers and token purchasers in an >> efficient, auditable and secure manner." >> >> I'm confused. KYC is largely about detecting money laundering, and other >> malfeasance, so the last thing a KYC desk cares about is unknown >> customers. On the contrary, they want to know the legal identity of the >> customer and of the source of funds. Direct access to PII is part of the >> process. >> >> Believe me, I've been there, not 10 km from cl.cam.ac.uk, when my bank >> tried to cut me off from my money soon after I relocated from Auckland >> to Cambridge in 2012. Somehow they had failed to update my residence >> address and I had to get documents certified and rubber-stamped at >> Cambridge police station, and sent by snail mail to the bank's KYC desk, >> before we got our money back. How does block chain solve that? (Not a >> rhetorical question; I would really like to understand.) >> >> Brian >> >>> >>> hope to get some experiences and I would share here for sure. >>> >>> Regards >>> >>> On 9 April 2018 at 02:44, Brian E Carpenter >>> wrote: >>> >>>> On 09/04/2018 10:28, Arjuna Sathiaseelan wrote: >>>>>> >>>>>> 2/ I though many people in the security community were moving away from >>>>>> proving identity, towards systems that prove entitlement (i.e. >>>> credentials >>>>>> are on a need-to-know basis, so if you were say 19, you don't need to >>>> say >>>>>> yur age or show id, >>>>>> but you can't buy a drink in cambridge MA, but you can in cambridge, UK >>>> :) >>>>>> >>>>> >>>>> digital id plays a major role for all the KYC/AML - massive market.. + >>>> for >>>>> employment etc.. >>>> >>>> Right, but *international* digital ID is a hopeless mess. Just try dealing >>>> with a USA bank's KYC department when living in New Zealand with a UK >>>> passport. Nothing works. >>>> >>>> That isn't a marginal case. Tens or hundreds of millions of people >>>> would need cross-border digital ID these days. Sales argument: would >>>> help to defeat money laundering. >>>> >>>> Brian >>>> >>>>> like the idea of proving entitlement - works nicely with crypto >>>>> charities/aid delivery.. >>>>> >>>>> Regards >>>>> >>>>> >>>>> >>>>> >>>>>> bootstrapping something from a BC to provide the credentials is also >>>>>> problematic, in that >>>>>> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we >>>>>> have a circular dependance, no? >>>>>> >>>>>> maybe i missed an important step, if so, sorry! >>>>>> >>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> I thought to share this WSJ article with the DIN group. Relevant in the >>>>>>> light of recent interest in using BC for identity. >>>>>>> >>>>>>> Advance apologies if it offends some people :-) >>>>>>> >>>>>>> https://blogs.wsj.com/cio/2018/04/03/digital-identity- >>>>>> is-broken-heres-a-way-to-fix-it/ >>>>>>> >>>>>>> >>>>>>> Below is a link to a PDF version. >>>>>>> >>>>>>> http://hardjono.mit.edu/sites/default/files/documents/WSJ_ >>>>>> Digital_Identity_is_Broken.pdf >>>>>>> >>>>>>> >>>>>>> Best >>>>>>> >>>>>>> -- thomas -- From nobody Mon Apr 23 16:31:17 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319A412DA50 for ; Mon, 23 Apr 2018 16:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq9gXHDNEbE7 for ; Mon, 23 Apr 2018 16:31:14 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F5F12DA4D for ; Mon, 23 Apr 2018 16:31:14 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6D62D21BF6; Mon, 23 Apr 2018 19:31:13 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 23 Apr 2018 19:31:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Ub0kkO W8dAahJJaDgCRDPRoxwJEaf7yzK0oROZP3FLA=; b=JEBywi7nCOMgQX/DZnyWP+ ohH/arkBXQkg+loZxbNEFKF5cRGZvhZNaQbkmIWLSm5iAi2E545cRbK73OZ06x3y LnL+YTawEWsvyUEaUtGPTM/QGytLtgyi28sVsio2/X7ikB/CxVMNtl34irfxB1aj 4o9ol5Z9jdlr/Z1NyJ1+wJld+IKw6/6B5FUtloO+ycmU17P+SJ1RgzpE2pE9bZzw +dErwz1oCcq3l9fSARFq345oDgyrP8Uoxir/oV4x411qqSrRrhgsrtZwPuufdzET i8cq/bu3g/NMRDBYTCly+b6z+cYujDfPzjyfhVINsIalRsSGVPxv9QQhDHxpsoDQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E0AB1BA780; Mon, 23 Apr 2018 19:31:12 -0400 (EDT) Message-Id: <1524526272.2684411.1348280336.4C87EB7F@webmail.messagingengine.com> From: Jehan Tremback To: Brian E Carpenter , din@irtf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f3006b89 In-Reply-To: <5b0a095f-dbc9-de1d-b317-82d14fd4baa0@gmail.com> Date: Mon, 23 Apr 2018 16:31:12 -0700 References: <5E393DF26B791A428E5F003BB6C5342AE73F70FC@OC11EXPO33.exchange.mit.edu> <8dae9467-f190-6903-56d8-99a7effd4954@gmail.com> <1524510617.1799095.1348018112.59AF727D@webmail.messagingengine.com> <5b0a095f-dbc9-de1d-b317-82d14fd4baa0@gmail.com> Archived-At: Subject: Re: [Din] WSJ article on Identity and Blockchains X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 23:31:16 -0000 There are many jurisdictions in which it may be illegal to sell tokens to people not meeting certain criteria (they must be rich), so sellers must be careful to make sure that the buyers meet this criteria. However, proving this requires a lot of personal information, that the seller neither wants nor needs. Having a service which would let you set up a smart contract and sell tokens to only those who you are allowed to sell to, while all of their actual personal details remained unknown. Not sure if this is what they are trying to do. -- Jehan Tremback jehan@altheamesh.com On Mon, Apr 23, 2018, at 3:48 PM, Brian E Carpenter wrote: > On 24/04/2018 07:10, Jehan Tremback wrote: > > As far as I understand the use-case of blockchain in KYC (from the perspective of someone who is vouching for an identity), the main thing is that you can sign off that someone meets some standard of identification (they have a certain address, net worth, etc) and then put it on the blockchain. Of course you could also just give them the signature to present when they need to use it. > > > > But putting it on the blockchain allows you to revoke it later. > > Yes. But it was the "unkown" in "trust unknown customers and token > purchasers" that puzzled me on the verif-y.com site. As you imply, KYC > is about *knowing* your customer. > > If it said "identify and trust new customers and token purchasers" I > would not have asked my question. > > Brian > > > > > -- > > Jehan Tremback > > jehan@altheamesh.com > > > > On Sun, Apr 22, 2018, at 7:29 PM, Brian E Carpenter wrote: > >> Arjuna > >> > >> On 16/04/2018 20:42, Arjuna Sathiaseelan wrote: > >>> this is something we are working on via https://www.verif-y.com/ > >> > >> "The Verif-y KYC service allows businesses utilizing blockchain > >> technology to trust unknown customers and token purchasers in an > >> efficient, auditable and secure manner." > >> > >> I'm confused. KYC is largely about detecting money laundering, and other > >> malfeasance, so the last thing a KYC desk cares about is unknown > >> customers. On the contrary, they want to know the legal identity of the > >> customer and of the source of funds. Direct access to PII is part of the > >> process. > >> > >> Believe me, I've been there, not 10 km from cl.cam.ac.uk, when my bank > >> tried to cut me off from my money soon after I relocated from Auckland > >> to Cambridge in 2012. Somehow they had failed to update my residence > >> address and I had to get documents certified and rubber-stamped at > >> Cambridge police station, and sent by snail mail to the bank's KYC desk, > >> before we got our money back. How does block chain solve that? (Not a > >> rhetorical question; I would really like to understand.) > >> > >> Brian > >> > >>> > >>> hope to get some experiences and I would share here for sure. > >>> > >>> Regards > >>> > >>> On 9 April 2018 at 02:44, Brian E Carpenter > >>> wrote: > >>> > >>>> On 09/04/2018 10:28, Arjuna Sathiaseelan wrote: > >>>>>> > >>>>>> 2/ I though many people in the security community were moving away from > >>>>>> proving identity, towards systems that prove entitlement (i.e. > >>>> credentials > >>>>>> are on a need-to-know basis, so if you were say 19, you don't need to > >>>> say > >>>>>> yur age or show id, > >>>>>> but you can't buy a drink in cambridge MA, but you can in cambridge, UK > >>>> :) > >>>>>> > >>>>> > >>>>> digital id plays a major role for all the KYC/AML - massive market.. + > >>>> for > >>>>> employment etc.. > >>>> > >>>> Right, but *international* digital ID is a hopeless mess. Just try dealing > >>>> with a USA bank's KYC department when living in New Zealand with a UK > >>>> passport. Nothing works. > >>>> > >>>> That isn't a marginal case. Tens or hundreds of millions of people > >>>> would need cross-border digital ID these days. Sales argument: would > >>>> help to defeat money laundering. > >>>> > >>>> Brian > >>>> > >>>>> like the idea of proving entitlement - works nicely with crypto > >>>>> charities/aid delivery.. > >>>>> > >>>>> Regards > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> bootstrapping something from a BC to provide the credentials is also > >>>>>> problematic, in that > >>>>>> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we > >>>>>> have a circular dependance, no? > >>>>>> > >>>>>> maybe i missed an important step, if so, sorry! > >>>>>> > >>>>>> > >>>>>>> Folks, > >>>>>>> > >>>>>>> I thought to share this WSJ article with the DIN group. Relevant in the > >>>>>>> light of recent interest in using BC for identity. > >>>>>>> > >>>>>>> Advance apologies if it offends some people :-) > >>>>>>> > >>>>>>> https://blogs.wsj.com/cio/2018/04/03/digital-identity- > >>>>>> is-broken-heres-a-way-to-fix-it/ > >>>>>>> > >>>>>>> > >>>>>>> Below is a link to a PDF version. > >>>>>>> > >>>>>>> http://hardjono.mit.edu/sites/default/files/documents/WSJ_ > >>>>>> Digital_Identity_is_Broken.pdf > >>>>>>> > >>>>>>> > >>>>>>> Best > >>>>>>> > >>>>>>> -- thomas --