Re: [Iotsi] Sticky Policy: Attaching privacy policies to data

Michel Kohanim <michel@universal-devices.com> Tue, 22 March 2016 02:39 UTC

Return-Path: <michel@universal-devices.com>
X-Original-To: iotsi@ietfa.amsl.com
Delivered-To: iotsi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7C512D1DB for <iotsi@ietfa.amsl.com>; Mon, 21 Mar 2016 19:39:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=universaldevices.onmicrosoft.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 Vyu8n0doTeMC for <iotsi@ietfa.amsl.com>; Mon, 21 Mar 2016 19:39:49 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038E812D127 for <iotsi@iab.org>; Mon, 21 Mar 2016 19:39:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=universaldevices.onmicrosoft.com; s=selector1-universaldevices-com02c; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v1qo1rxoRqSxZVYxLHONUauuY4A0A79uOeQTUHZTDFE=; b=XJnGoQssNwrJKk3MeeQbo+lJ4YJ5TGxRwR/JruFKmM8MYQ0rPZPiQ54TDqDSiFPxp0opizHbz6H69RUnJyqUfnfOJ4CmpsjQQ+KRYSL6XqVmuV/lS8puzkwVhBOPCydXD/IEZTCcuHBTSarPlqz9/o1lUJcg6dresXPF79ke/qY=
Received: from SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) by SN1PR0201MB1534.namprd02.prod.outlook.com (10.163.129.21) with Microsoft SMTP Server (TLS) id 15.1.434.16; Tue, 22 Mar 2016 02:39:27 +0000
Received: from SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) by SN1PR0201MB1534.namprd02.prod.outlook.com ([10.163.129.21]) with mapi id 15.01.0434.021; Tue, 22 Mar 2016 02:39:27 +0000
From: Michel Kohanim <michel@universal-devices.com>
To: "Subramaniam, Ravi" <ravi.subramaniam@intel.com>, "Smith, Ned" <ned.smith@intel.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "iotsi@iab.org" <iotsi@iab.org>
Thread-Topic: [Iotsi] Sticky Policy: Attaching privacy policies to data
Thread-Index: AQHRg5pswcubxTHCtkGfNI03+7PJxJ9krlqAgAASjFw=
Date: Tue, 22 Mar 2016 02:39:27 +0000
Message-ID: <SN1PR0201MB153406355BDCCC877E1EACF298800@SN1PR0201MB1534.namprd02.prod.outlook.com>
References: <D3157922.4B301%ned.smith@intel.com> <D40BA8183A12B448ACB9448546032E089C9345BC@ORSMSX116.amr.corp.intel.com>
In-Reply-To: <D40BA8183A12B448ACB9448546032E089C9345BC@ORSMSX116.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=universal-devices.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [76.91.5.158]
x-ms-office365-filtering-correlation-id: 7ef39565-6205-47d8-cbde-08d351fb304c
x-microsoft-exchange-diagnostics: 1; SN1PR0201MB1534; 5:QrVFnuQrwFWSxo8vm/jYwn+yDpsxYEBuE/cGEgUMIqM3QxjOQtiwN0zTP34o3BROMssLu1FdPCAhFgjElS/gT9TI3ouhToTSBgDo9JnBmo+zq51FbUc6tLl3k46IOqoi6nexTo4IVjsmLvKY1ZySfA==; 24:oeXGcgJFSN4aHAvS5R9gcyKhPBo6A2lqFjvDUG79ezYteUTSX2mVJ+JNllP4nH7yByIMtfGwqKLSf8QJ3aAAVRHMCcC4DFTvjcRLlNXqyGc=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0201MB1534;
x-microsoft-antispam-prvs: <SN1PR0201MB1534B56C2953819CFF55753B98800@SN1PR0201MB1534.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040046)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046); SRVR:SN1PR0201MB1534; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0201MB1534;
x-forefront-prvs: 08897B549D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(53754006)(71364002)(24454002)(13464003)(2501003)(16601075003)(92566002)(5890100001)(3280700002)(3660700001)(2906002)(16236675004)(551934003)(87936001)(19617315012)(5003600100002)(5001770100001)(5002640100001)(106116001)(86362001)(1220700001)(5008740100001)(74316001)(15975445007)(107886002)(19580395003)(102836003)(3846002)(122556002)(10400500002)(66066001)(76576001)(586003)(6116002)(99286002)(1096002)(11100500001)(189998001)(50986999)(76176999)(54356999)(77096005)(5004730100002)(33656002)(81166005)(19580405001)(2950100001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0201MB1534; H:SN1PR0201MB1534.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR0201MB153406355BDCCC877E1EACF298800SN1PR0201MB1534_"
MIME-Version: 1.0
X-OriginatorOrg: universal-devices.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2016 02:39:27.6946 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d628f750-5cc1-4a42-9d4c-463ac737d54f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1534
Archived-At: <http://mailarchive.ietf.org/arch/msg/iotsi/YzIH3uZih15vRDqs6CKS7VB__I0>
Subject: Re: [Iotsi] Sticky Policy: Attaching privacy policies to data
X-BeenThere: iotsi@iab.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Internet of Things Semantic Interoperability Workshop <iotsi.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/iotsi>, <mailto:iotsi-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotsi/>
List-Post: <mailto:iotsi@iab.org>
List-Help: <mailto:iotsi-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/iotsi>, <mailto:iotsi-request@iab.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2016 02:39:52 -0000

Although I missed the F2F, I am very concerned with the concept of IDs especially with respect to privacy. The reason is that any implementor must have a priori knowledge of these IDs (not to mention collision).

I propose a very simple meta X (don't know what to call it) tied to each interaction between users of objects and its properties and services (inherited from object):
Object: create, read, query, mutate, destroy, move, subscribe, etc
Property: read, query, mutate, subscribe, etc.
Service: invoke, callback, start, stop, terminate, etc.

Objects, services, and properties have meaningful representations themselves based on concepts such as the one I proposed, HATEOS, IOTDB, or similar.

With kind regards,
**********************************************
Michel Kohanim
CEO

(p) 818.631.0333<tel:818.631.0333>
(f)  818.436.0702<tel:818.436.0702>
http://www.universal-devices.com<http://www.universal-devices.com/>
**********************************************


On March 21, 2016 6:54:28 PM "Subramaniam, Ravi" <ravi.subramaniam@intel.com> wrote:

Hi,

+1 with Ned

It would be beneficial to view security (incl Trust) as a context in which IMs and DMs are interpreted/actioned. In that case, using system IM/DM to inform context would be preferred.

Ravi

-----Original Message-----
From: Iotsi [mailto:iotsi-bounces@iab.org] On Behalf Of Smith, Ned
Sent: Monday, March 21, 2016 10:52 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; iotsi@iab.org
Subject: Re: [Iotsi] Sticky Policy: Attaching privacy policies to data

Thanks Hannes!

RFC4119 could be characterized as an information model and data model expression of a set of context attributes (location, presence) that when extant represent possible privacy sensitive attributes for which some form of privacy preservation strategy may be needed. The paper suggests a few possible strategies such as retention limitations / data expiry and retransmission rules.

It was noted at the F2F that 'context' was an aspect of information modeling that represented a form of meta-data that has value (hence shouldn't be ignored?). Given IM practice will be inclusive of context attributes (which normally might include location, presence etc...), the IM can inform the trust model seeking to realize privacy goals.

It could be observed that at least part of the objectives of RFC4119 could be realized, namely that contextual metadata (location, presence) may be available through a more comprehensive IM - one that is inclusive of context. That suggests to me at least, that an existing IM and DM may satisfy some of the RFC4119 objectives though possibly not being RFC4119 compliant.

It would be preferable, IMO, if the IM that describes the "system" informs the Trust Model (security / privacy) rather than having the Trust Model define the IM and DM that then must be retrofitted into the system IM/DM.
I'm not suggesting there won't be a need for security / privacy goals of an IM to inform the system IM, but it should do so using the languages of the system IM and DM.

Given a comprehensive system IM and DM, this may be sufficient toward properly informing privacy models regarding privacy context. If there are gaps, they likely are small. For example, the system IM/DM that defines an identifier, might leave undefined intended mutability properties.
Normally, we'd expect the DM would specify the identifier's possible values, but it might not specify its uniqueness properties. Uniqueness may be understood within some context, such as a life expectancy for reuse or a namespace authority that can manage / check for namespace collision.

A 32-bit identifier can uniquely identify 4B things at a given time. The
4B+1 item could collide with an existing identifier. If the rollover
4B+rate
is specified, then a privacy model could use that information to manage privacy risk because there is a window in which the transaction associated with the identifier will be extant. It may be appropriate for IOTSI to consider defining rollover rate parameters as a possible 'range' attribute that is associated with identifiers.

This is more the approach I would advocate vs. an RFC4119 approach.

-Ned

Ned Smith
Principal IoT Security Architect
Intel SSG-OTC
Ned.smith@intel.com
+1.503.712.3695



On 3/21/16, 1:58 AM, "Iotsi on behalf of Hannes Tschofenig"
<iotsi-bounces@iab.org on behalf of Hannes.Tschofenig@arm.com> wrote:

Hi all,

During the security discussion the idea of attaching privacy policies
to data was mentioned and I noted that there has been work in the IETF
on that topic.

Here are the relevant pointers: RFC 4119 (see
https://www.ietf.org/rfc/rfc4119.txt) specified a way to convey
usage-rules along with location data. These usage-rules contain four
pieces of information:
- retransmission-allowed
- retention-expires
- ruleset-reference
- note-well

The ruleset-reference contains richer information about what a
recipient of location information is allowed to do with that
information. RFC 4745 (see http://tools.ietf.org/html/rfc4745) defines
the format of those policies and they have been extended for use with
application specific domains, such as presence information and
geolocation information. The former can be found in
https://tools.ietf.org/html/rfc5025 and the latter in
http://tools.ietf.org/html/rfc6772

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.

_______________________________________________
Iotsi mailing list
Iotsi@iab.org
https://www.iab.org/mailman/listinfo/iotsi

_______________________________________________
Iotsi mailing list
Iotsi@iab.org
https://www.iab.org/mailman/listinfo/iotsi

_______________________________________________
Iotsi mailing list
Iotsi@iab.org
https://www.iab.org/mailman/listinfo/iotsi