Date: Wed, 11 Nov 1998 12:38:26 -0200 (EDT) From: Ed Gerck To: 302146 Subject: Important, was Re: [MCG] Identification Pathologies On Tue, 10 Nov 1998, 302146 wrote: >Ed, > >Thanks for the thoughtful treatment of the "Mind Transfer" and the >"Multiple Personalities" examples. To summarize, I paraphrase your >lesson to be: > > who/what (a thing) "is" depends on the metric > you use to evaluate coherence. > [IMO, this is an important and mostly useful message. In order not to spoil the line of thought to be developed here, the new title just reflects that -- yet an Obscure type.] Tony: Yes, but more precisely: Identification depends on the metric you use to evaluate coherence. This points out to my statement when I motivated this approach, to the effect that identity should be "measured" and not assumed. Thus, the pair (identification,metric) is what should be seen as the "identity" -- not any ad hoc issued document by a third-party. So, conceptually, even if a third-party issues a document to you (say, a driver's license issued by the California DMV) it is my acceptance of that document by myself which confers a nexus to it -- within my metric. This nexus is characterized by the pair (document, my metric) and clearly depends on "my metric". For example, I may accept an expired diver's license in order to clear a check -- but if I am also a policeman I will not accept it on the road. As commented in the cie.htm paper, the whole certificate itself (X.509, PGP, MC-ware, etc.) constitutes a "name". In other words and using current terminology, the pair (cert, cert metric) is almost certainly (due to the randomness and large size of public-key numbers) a Distinguished identity for the subject -- since the cert is also a nexus you can measure, for example by key challenge-response. The pair (cert, cert metric) is thus a Distinguished-Name even if the subject's name in it is just "John Smith" and without any privacy concerns raised by current X.509 DN usage of "real name" + "real address". Now, as we allow "cert metric" to change (eg, accepting expired but valid certs, accepting only for encryption, accepting only to decrypt data, etc.), we also allow "identity" to change -- ie, different IDs, to suit our mutual needs in terms of risk/cost and privacy. And, in combination with other IDs I may perceive other nexus (such as non-repudiation, anonymous, etc.), with further derived IDs. For example, the (cert, cert metric) ID1 together with a (document, my metric) ID2 make up the nexus [ID1,ID2] -- which I may identify by coherence and thus define a new "identity" ID3. >If you also had a chance to read my last post in (belated) response >.. I will comment about this in a separate msg. >I attempt to address your "ID the Extraterrestrial" issue. > >You said: > >>How can we identify and deal with an alien (ie, non-terrestrial)? >>Would we ask for "his" "planet-ID"? Would we ask for "his" insurance >>policy? For "his" law code? How can we identify the unknown, and deal >>with it in an exchange of mutual understanding? > >This is a wide-open question, since I am not sure if the alien in >question is here in person, can speak my language, etc. This question was wide-open on intention. I 100% agree with your line of thought, that led you to conclude what would be the best strategy: > >I think that the best I could do is to "give him" ID, in the form >of teaching him something I know, which he does not currently know. >Perhaps, how to play "Go". After many games, I may get a sense of >how he views the game, thinks strategically vs tactically, etc. And, guess what? You have just reinvented MC-ware certification! ;-) =================================================== The "game" you teach him is akin to MC-ware's MC-private cert you "teach" Bob to accept (by various exchanges with your MCC and your MC-public certs) in order for him to communicate with your MCC cert -- which issued the MC-private and MC-public certs, and is "paired" with them in the same "game". This accomodates both intrinsic certification -- which you just did in your example -- as well as extrinsic certification if one of your MC-public is accepted by him because it is signed by the "Star Federation" ;-) And, in the same way that you can teach him a slightly personal variant of the "game", you can also "teach" him to accept a personal MC-private, so that you can recognize different parties because they play different variants of the "game" (as indexed by you, but unbeknownst to other parties, such as the enemy Klingons). The general principle behind the MC-ware strategy is however still a bit more subtle -- you are not only identifying that he can now play the "game" (hence, can regonize him by that nexus which he imported from you) but as you wrote above, you can now pry into "how he views the game, thinks strategically vs tactically, etc.". The importance of this statement cannot be overstated -- even though it has already been stated quite frequently ;-) This is a level deeper -- this reaches into his formerly inaccessible nexus! You are now communicating with the unknown -- you built an interface with it. Let me rephrase the point, in order to see the important and surprising implications of it -- as well as to properly highlight the significance of your comment. I think we all agree that you cannot identify unless you perceive a nexus. But, if you and the other party agree on a certain common nexus (eg, a game) that you teach, how can that nexus be more than simply a reflection of your own coherence? How can the rules of a chess program be different from the rules of chess built into it by you -- the programmer? I note that I am not talking about chess strategy/tatics -- I am talking about rules. The obvious (and wrong) answer is to allow it to learn new rules from other players, like a "neural net" can learn to recognize new pattern rules, or as a PC can take in new programs. The answer is wrong because in order to be secure to you, the chess program would have to learn rules only from you -- otherwise someone might plant a rule which you are not aware of and which may allow outside tampering with the game. The not so obvious but IMO only correct answer is given by intrinsic certification -- where certification is viewed as a secure communication channel as discussed in cie.htm. Let me restate the problem, following what is in cie.htm just before item 3.1. You want to communicate with the unknown -- which is supposed to be cooperative (ie, willing to communicate with you -- see the posting on certification cycles to see why this can be assumed) but you both are surrounded by enemies, who are free to do whatever they want both actively and passively. The difficulty you face is that any nexus you can identify at this time must be *incoherent* with the unknown nexus -- by hypothesis. You do not know what coherence the unknown has, if any. In cie.htm, where you are V (Verifier) and the unknown is S (Subject) we read: "It is easy to see that the basic hypothesis above do not establish any link between V and S, implicit or otherwise. This is expressed by the fact that X and Y are empty." That is why it is unknown to you -- you see no coherence in it, you cannot identify it. The solution is: In order to perceive a nexus on the unknown you have to first enter into an agreement process (eg, teaching a game) were you know the rules and can use them as diagnostic tools (interfaces) into the other deeper nexus you could not reach in the first place. This may allow you to identify a "primal nexus" (ie, not planted by you) -- which you could not reach otherwise, and which intrinsically identifies him to you! Thus, intrinsically certified. Of course, one still has to add a couple things in order to get an Internet protocol that Joe and Bill can use ;-) >Of course, if he is part of a "common consciousness" which all >learn and react to whatever he does, then even this method fails >to identify "him", but there really is no "him". If the next >visit were from another of this species, it would still be "him". > If the "common consciousness" is perfect and lossless, this is reflected in 100% coherence. As an analogy, if you accept that a photon can only interfere with itself (a theoretical fact), then you may still accept that different photons emitted by different sources at different times may still interfere -- if they are coherent to some extent. This is why I like to define collaboration by that metaphor. Contrary to usual thinking, collaboration is not a group of similar people doing the same thing. Collaboration is different people doing different things, at different times, but with the same objective! >Clearly, this is a "time-intensive" way of performing ID, but in >software such exchanges may be codified to occur rapidly. Exactly. MC-ware. Congratulations on intrinsic certification explained by Tony! And, in order to reach this common "game" -- intrinsic certification methods were used by myself in our series of e-mails, in order to develop a nexus which could not be simply the reflection of my own nexus. If they were, there would be no realization, just reflection. IMO, that is the difficulty we face with MC-ware. It takes intrinsic to explain intrinsic ;-) All extrinsic explanations fail to a large extent due to the lack of realization by the reader -- since day-to-day examples are largely unnoticed. The reader has nothing much similar that he can consciously grasp to. The problem thus is how to communicate with the unknown in order to explain how to communicate with the unkown ... Cheers, Ed Gerck ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@mcwg http://mcwg