Re: [Ideas] Diasambugating Identifier and Identity

"Liubingyang (Bryan)" <liubingyang@huawei.com> Fri, 28 April 2017 02:06 UTC

Return-Path: <liubingyang@huawei.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E6912953D for <ideas@ietfa.amsl.com>; Thu, 27 Apr 2017 19:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 1I4P2Ctx2cum for <ideas@ietfa.amsl.com>; Thu, 27 Apr 2017 19:06:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91895124282 for <ideas@ietf.org>; Thu, 27 Apr 2017 19:04:07 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFQ34095; Fri, 28 Apr 2017 02:04:03 +0000 (GMT)
Received: from SZXEMI403-HUB.china.huawei.com (10.82.75.35) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 28 Apr 2017 03:04:02 +0100
Received: from SZXEMI508-MBS.china.huawei.com ([169.254.10.152]) by SZXEMI403-HUB.china.huawei.com ([10.83.65.55]) with mapi id 14.03.0235.001; Fri, 28 Apr 2017 10:03:52 +0800
From: "Liubingyang (Bryan)" <liubingyang@huawei.com>
To: Michael Menth <menth@uni-tuebingen.de>, Alexander Clemm <alexander.clemm@huawei.com>, Dino Farinacci <farinacci@gmail.com>
CC: "ideas@ietf.org" <ideas@ietf.org>, Robert Moskowitz <rgm-ietf@htt-consult.com>
Thread-Topic: [Ideas] Diasambugating Identifier and Identity
Thread-Index: AQHSp914j5eOmWLOQkutGf2RD5x5MqHDjbwAgABx9QCAAMPZAIAAAjuAgBAfzYCAAWJVgIABSuQw///7zQCAACT0gIAABM6AgABlzACAAM2TgIAAYU0AgAAjwwCAALtiQA==
Date: Fri, 28 Apr 2017 02:03:51 +0000
Message-ID: <C1CE72EE84AF224E94DA21AE134209EE0102F68B@SZXEMI508-MBS.china.huawei.com>
References: <7443f8eb-181c-be31-8e80-9250b4a54e60@htt-consult.com> <abd7608c-54b9-a381-fdf2-c5964dc37078@htt-consult.com> <082a1bcc-d79a-75b0-18e6-6db705627ce5@uni-tuebingen.de> <afbac9ba-0b9c-c479-8db5-8abc4e8a998a@htt-consult.com> <c260d5f8-d349-8a33-5bc6-8cbf375cf908@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF92CB0@SJCEML701-CHM.china.huawei.com> <161f2434-d3ab-efdc-2b5b-5582d80c6b9c@uni-tuebingen.de> <C1CE72EE84AF224E94DA21AE134209EE0102F0EF@SZXEMI508-MBS.china.huawei.com> <454B13B3-E2E5-41DB-84F4-BF880374F696@gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93415@SJCEML701-CHM.china.huawei.com> <a4f0687d-917f-6507-50a0-63b3b77a0caa@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93894@SJCEML701-CHM.china.huawei.com> <1ae6eac8-3d56-d838-14dc-94a6abccd47f@uni-tuebingen.de> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF93AFB@SJCEML701-CHM.china.huawei.com> <54c3d757-bcd6-051e-7785-3941bb41c5c4@uni-tuebingen.de>
In-Reply-To: <54c3d757-bcd6-051e-7785-3941bb41c5c4@uni-tuebingen.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.168.116]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5902A313.0132, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.10.152, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9bbd9fb42d3f22b96b673e9c96398629
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/Gr5Dm3oqdhry9nHxejwRbEpMM1M>
Subject: Re: [Ideas] Diasambugating Identifier and Identity
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Apr 2017 02:06:42 -0000

See inline [Bryan]
I highly suggest that we can leave the term definition aside, and talk about what functionalities we need in IDEAS. If the functions are decided, we can give whatever terms everyone is comfortable with. The functions are really important things, then the terms.

Best
Bingyang (Bryan)

-----Original Message-----
From: Michael Menth [mailto:menth@uni-tuebingen.de] 
Sent: Friday, April 28, 2017 6:12 AM
To: Alexander Clemm <alexander.clemm@huawei.com>;; Dino Farinacci <farinacci@gmail.com>;; Liubingyang (Bryan) <liubingyang@huawei.com>;
Cc: ideas@ietf.org; Robert Moskowitz <rgm-ietf@htt-consult.com>;
Subject: Re: [Ideas] Diasambugating Identifier and Identity

Hi Alex,

Am 27.04.2017 um 22:04 schrieb Alexander Clemm:
> Hi Michael,
> 
> In your example, it sounds as if you are effectively having the cidX take on a similar role of an identity - various identifiers are grouped together under the umbrella of their unifying cidX, which is now used in lieu of - but similar role as (minus the authentication) - an identity.
Right. I just want to say that an identity is not necessarily needed to provide joint information for a set of identifiers.

  You can do that, but what you are arguing, then, is in effect to restrict the discussion to identifiers and identifier-enabled networks; identity and identity-enabled networks would be a misnomer unless used as a synonym.  The thread started with disambiguating identifier and identity; if we decided that we want to have as scope for the work identifier-enabled networks (without need for the notion of identity distinct from an identifier), the disambiguation would no longer matter.
I don't want to get rid of the term identity, I'd rather like to filter out the very essence of an identity.
Is it just the authentication part or something else?
  [Bryan] Agreed with all the above. Btw, an identity by itself may not be sufficient to provide authentication unless accompanied with some keys, tokens, etc. And it is not necessary neither since one can do authentication without the definition of identity. 

Certainly not - because we may have a "cidX" whithout authentication features which is still able to bind several identifiers together.
Is an identity just a "collection of data"? No, because if we have another identical collection of data, then we don't know which is which.
  [Bryan] if we want to bind some identifiers together, we just need a set. If we need to give the set a unique reference, that could just be a set ID, which can be just an index in database internal implementation and doesn't have to be given an explicit meaning. 
  However, if the set ID itself has some properties, the set ID can have some meaning. We can use the properties to indicate, e.g., this set maps to a real entity in the real world. 

Can we say it is a distinguishable entity? It may have a collection of data and may also have some means for authentication. If we have equal products without a serial number, we probably wouldn't talk about identities. But with a serial number, they can be distinguished, so that we can talk about identities. However, it's not the serial number or identifier that makes them an identity, it rather the distinguishability which could alternatively be achieved through a collection of data. Hm, too philosophical?
  [Bryan] To my understanding, people have so different understanding of the term "identity". Some may think it is just for authentication of ownership of identifiers, like HI for HIT. Some may think it is an avatar of a real world entity. 
  I highly suggest that we can leave the term definition aside, and talk about what functionalities we need in IDEAS. If the functions are decided, we can give whatever terms everyone is comfortable with. The functions are really important things, then the terms. 

Regards,

Michael


> 
> One other clarification inline, <ALEX>
> 
> Cheers
> --- Alex
> 
> -----Original Message-----
> From: Michael Menth [mailto:menth@uni-tuebingen.de]
> Sent: Thursday, April 27, 2017 7:16 AM
> To: Alexander Clemm <alexander.clemm@huawei.com>;; Dino Farinacci 
> <farinacci@gmail.com>;; Liubingyang (Bryan) <liubingyang@huawei.com>;
> Cc: ideas@ietf.org; Robert Moskowitz <rgm-ietf@htt-consult.com>;
> Subject: Re: [Ideas] Diasambugating Identifier and Identity
> 
> Hi Alex,
> 
> Am 27.04.2017 um 04:00 schrieb Alexander Clemm:
>> Hi Michael,
>>
>> For your example: yes, you can do what you describe.  Of course, you need to have the same metadata replicated for each identifier.  
> No, the metadate is mapped only to the single "cidX". But multiplce nidn are mapped to this single contract id.
> 
> When the entity decides to use another identifier, its metadata needs to be copied as well.
> No, we just need another mapping nid3 -> cidX
> 
> When you change the metadata, you need to change it in all records.
> No, we just need to change the metadata associated to the single "cidX".
> 
> And there may be more than one piece of metadata; for example, I may be an entity of a certain type.  With a flat identifier-only scheme, the data must be maintained redundantly.
> Hm, not sure what you mean.
> 
> <ALEX>  What I meant here is there can be other metadata associated with an entity, not just the contract, but for example information of which type a certain endpoint is - for example, if it is a connected vehicle, a server, a mobile CPE.  If an entity has several identifiers, and the same metadata applies to each, it needs to be maintained redundantly (unless you put it under some common umbrella that "unites" the identifiers, such as an identity).  
> </ALEX>
>   
> Regards, Michael
> 
> 
>>
>> --- Alex
>>
>> -----Original Message-----
>> From: Michael Menth [mailto:menth@uni-tuebingen.de]
>> Sent: Wednesday, April 26, 2017 12:56 PM
>> To: Alexander Clemm <alexander.clemm@huawei.com>;; Dino Farinacci 
>> <farinacci@gmail.com>;; Liubingyang (Bryan) <liubingyang@huawei.com>;
>> Cc: Robert Moskowitz <rgm-ietf@htt-consult.com>;; ideas@ietf.org
>> Subject: Re: [Ideas] Diasambugating Identifier and Identity
>>
>> Hi Alex,
>>
>> can't a contract be represented by a contract identifier (cidX) to which several networking identifiers (nidn) are mapped?
>>
>> nid0 -> cidX
>> nid1 -> cidX
>> nid2 -> cidX
>> cidX -> someProperty
>>
>> This contract identifier may be mapped to some property yielding a kind of hierarchical mapping. What I want to say is, I don't see the gain of an identity concept in this example.
>>
>> I ask again: what's the value of identities beyond authentication for registration purposes?
>>
>> Regards,
>>
>> Michael
>>
>>
>> Am 26.04.2017 um 21:38 schrieb Alexander Clemm:
>>> Yes, I think we agree on the notion of identifier.  
>>>
>>> Of course, this is not just about identifier- but identity-enabled networking, so there is still that other aspect needing to be fleshed out. Re: Michael's question, authentication is one of its applications, but I think there are others, for example related to metadata (back to the earlier point of whether identity is a data record) - an example would be the "type" of endpoint which applies regardless whether one or many identifiers are being used.  Related to metadata, you could have policies that are applied based on identity (e.g. an entity with a paid contract), not based on which one of several identifiers an entity happens to use.   
>>>
>>> -- Alex
>>>
>>> -----Original Message-----
>>> From: Dino Farinacci [mailto:farinacci@gmail.com]
>>> Sent: Wednesday, April 26, 2017 10:26 AM
>>> To: Liubingyang (Bryan) <liubingyang@huawei.com>;
>>> Cc: Michael Menth <menth@uni-tuebingen.de>;; Alexander Clemm 
>>> <alexander.clemm@huawei.com>;; Robert Moskowitz 
>>> <rgm-ietf@htt-consult.com>;; ideas@ietf.org
>>> Subject: Re: [Ideas] Diasambugating Identifier and Identity
>>>
>>>> For example, (one of) the real reason we want identifiers is that we want something that does not change with topology locations to identify mobile communication end point, which functions that cannot be carried by IP addresses. Since (I believe) we all have consensus on this function, we can at least agree that identifier is topology-independent label that identifies a communication end point. 
>>>
>>> Exactly.
>>>
>>> So to extend the definition to be specific. The identifier is used for a host stack transport connection. Its the “thing” (the arguments) you pass to connect(), bind(), sendto(), etc, socket API calls. And what you “get back” from gethostbyname().
>>>
>>> Dino
>>>
>>
>> --
>> Prof. Dr. habil. Michael Menth
>> University of Tuebingen
>> Faculty of Science
>> Department of Computer Science
>> Chair of Communication Networks
>> Sand 13, 72076 Tuebingen, Germany
>> phone: (+49)-7071/29-70505
>> fax: (+49)-7071/29-5220
>> mailto:menth@uni-tuebingen.de
>> http://kn.inf.uni-tuebingen.de
>> _______________________________________________
>> Ideas mailing list
>> Ideas@ietf.org
>> https://www.ietf.org/mailman/listinfo/ideas
>>
> 
> --
> Prof. Dr. habil. Michael Menth
> University of Tuebingen
> Faculty of Science
> Department of Computer Science
> Chair of Communication Networks
> Sand 13, 72076 Tuebingen, Germany
> phone: (+49)-7071/29-70505
> fax: (+49)-7071/29-5220
> mailto:menth@uni-tuebingen.de
> http://kn.inf.uni-tuebingen.de
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
> 

--
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:menth@uni-tuebingen.de
http://kn.inf.uni-tuebingen.de