Restricting usage of shared contact information

Abstract

A method comprises creating (101) first contact information for contacting a first party and transmitting (103) the first contact information to a system of a second party. The first contact information is specific for the second party. The method further comprises deriving (107), at the system of the second party, from the first contact information, second contact information for contacting the first party and transmitting (109) the second contact information to a system of a third party. The second contact information is specific for the third party and comprises an identifier of the second party. The method further comprises transmitting (111) a message which includes the second contact information to a system associated with the first party. The method further comprises obtaining (113) a sharing policy associated with the identifier and establishing (115) the communication relationship between the first party and the third party in dependence on the sharing policy.

Description

[0001] RESTRICTING USAGE OF SHARED CONTACT INFORMATION

[0002] FIELD OF THE INVENTION

[0003] The invention relates to a method of creating and deriving contact information and establishing a communication relationship, a method of deriving contact information, and a method of establishing a communication relationship.

[0004] The invention also relates to computer program products enabling systems to perform steps of such methods.

[0005] The invention further relates to a system for deriving contact information and a system for establishing a communication relationship.

[0006] BACKGROUND OF THE INVENTION

[0007] Communication identifiers can easily be abused to invade a user’s privacy. If a party shares an email address or phone number with a counterparty, then that counterparty can continue bothering the party via email or phone long thereafter. Even worse, the counterparty can share the party’s communication identifiers with third parties, who can use them for spam, phishing and other privacy -invading practices. Furthermore, counterparties and third parties can use the party’s contact information for correlation, which enables them to combine data about the party in ways that may turn out negatively for the party. For example, IP addresses allow easy correlation, as Internet Service Providers (ISPs) rarely rotate IP addresses.

[0008] Techniques are known that enable communication while reducing privacyinvading practices. An example of such a technique is Decentralized IDentity (DID) communication. DID communication (DIDcomm) is a set of tools to allow power-neutral and bidirectional channels of communication between two entities that know each other’s DIDs and nothing else. DIDcomm provides a way to do mutual authentication between any two parties.

[0009] The DID Exchange Protocol 1.0 (Aries RFC 0023, https: / / github.com / hyperledger / aries-rfcs / tree / main / features / 0023-did-exchange) is used for establishing a DIDcomm relationship between two parties. A “requester” uses information from an invitation message to start the DID Exchange Protocol with a “responder”. After a successful completion of the protocol, each party can send simplex DIDcomm messages to each other. As those messages are encrypted and signed, only the party and the counterparty can send and receive / read those messages. This means that third parties cannot eavesdrop or insert any spam, phishing, or other.

[0010] Aries RFC 0023 presumes that the DID Exchange Protocol is preceded by an out-of-band invitation message (using RFC 0434). This out-of-band invitation message can be shared with third parties, who could use it to start the DID Exchange Protocol with the responder. These invitation messages could be abused to bother the responder. If a communication channel responder-to-requester does not already exist, then it is unclear how the relationship can be established / bootstrapped without the loss of privacy associated with third-party sharing of contact information.

[0011] SUMMARY OF THE INVENTION

[0012] It is a first objective of the invention to provide a method, which can be used to reduce privacy-invading practices while establishing a communication relationship.

[0013] It is a second objective of the invention to provide systems, which can be used to reduce privacy-invading practices while establishing a communication relationship.

[0014] In a first aspect of the invention, a method of creating and deriving contact information and establishing a communication relationship comprises creating first contact information for contacting a first party, the first contact information being specific for a second party, transmitting the first contact information to a system of the second party, deriving, at the system of the second party, from the first contact information, second contact information for contacting the first party, the second contact information being specific for a third party and comprising an identifier of the second party, transmitting the second contact information from the system of the second party to a system of the third party, transmitting a message from the system of the third party to a system associated with the first party, the message including the second contact information, obtaining a sharing policy associated with the identifier of the second party, and establishing the communication relationship between the first party and the third party in dependence on the sharing policy.

[0015] By including the identifier of a party who derives contact information, i.e. the referrer / second party, in this contact information, this identifier can be used to determine whether to establish a communication relationship between the party who wants the relationship, i.e. the third party, and the party to whom the contact information pertains, i.e. the first party. This way, the first party, e.g. Bob, can determine the provenance of the contact information that was used to contact him. Based on this provenance, Bob can create policies to handle incoming initial messages. For example, Bob could immediately read referrals from party A, he could ignore / block referrals from party B, and he could store referrals from party C to read later. This provides Bob greater insight and control over who reaches him, and how those parties were referred to him. In particular, Bob may be enabled to block whole categories of spam / phishing messages that were caused by a single leak of contact information. To achieve backwards compatibility, the method may be used to extend current communication identifiers while messages without this extension can still be received.

[0016] Thus, the sharing of contact information with third parties is considered to be fully legitimate. Currently, most contact information is still received via referrals. Examples of such referrals are directories, email cc, and passing of phone numbers. The problem is not with the referral per se, but the referrals getting out of control. Spam and phishing via phone, email and other electronic means are examples of referrals getting out of control. With the above method, it may be prevented that Bob has no idea how some spammer / phisher obtained Bob’s contact information.

[0017] The sharing policy may comprise a white list of identifiers of parties or a black list of identifiers of parties. If the usage of the contact information shared by the second party should be restricted, the second party may be added to the black list or removed from the white list. The second party may be a person or a company, for example. At the same time, e.g. after a referral by the second party has led to spam, the second party could separately be blocked from communicating with the first party, e.g. via DIDcomm, but this is not required.

[0018] The method may further comprise transmitting communication information to the third party if the communication relationship is established, e.g. transmit the response specified in the DID Exchange Protocol or the first cryptographic information and the second cryptographic information described in the patent application titled “Privacy Routing System” (European patent application EP22184205.77). The method may further comprise informing the third party that the communication relationship cannot be established if the communication relationship is not established, e.g. by transmitting the DIDcomm “request not accepted” rejection specified in the DID Exchange Protocol.

[0019] The second contact information may be derived from the first contact information by applying a one-way cryptographic algorithm to at least part of the first contact information. This may be done to prevent that the third party is able to obtain the first contact information based on the second contact information, while making it possible, e.g. for the first party, to verify the validity of the second contact information received from the third party based on the first contact information. It may also prevent the modification or removal of the identifier of the second party from second contact information by either the second party or the third party. The first contact information and the second contact information may be part of a contact information tree, the first contact information being at a higher hierarchical level in the contact information tree than the second contact information. The advantage of using a tree is that it provides scalability and allows contact information to be derived for and by many different parties. The tree could in theory have unlimited depth and width. The contact information may have a similar tree structure as a Hierarchical Deterministic (HD) wallet, for example.

[0020] The method may comprise generating a root secret, determining the first contact information by deriving the first contact information from the root secret, and deriving, at the system of the first party, third contact information for contacting the first party from the root secret, the third contact information being specific for a fourth party, the first contact information and the third contact information being at the same hierarchical level in the contact information tree. The root secret may be a random number, for example. By making it possible to verify the validity of contact information based on the root secret, it may be easier to verify the validity of contact information items shared via different first order contacts of the first party. HD wallets are also created from root secrets / seeds.

[0021] The first contact information may comprise an index in the contact information tree and a value, the identifier of the second party may comprise the index and a subindex of the index, and the second contact information may further comprise a result of applying a one-way cryptographic algorithm to both the value and the subindex. The oneway cryptographic algorithm may comprise a hash function and the value may comprise a hash value, for example.

[0022] For example, the first party, e.g. Bob, may calculate what the hash should have been, based on his root secret and the indices. If the received hash and the expected hash do not match, then Bob’s system may ignore the message. If the received hash and the expected hash do match, then Bob’s system has verified that the contact information is genuine / valid. Based on his sharing policy for the specific index, Bob’s system may decide what to do with the message, e.g. present the message to Bob immediately, store the message for later use, reject the message with a rejection message, reject the message without a rejection message, or forward the message. The purpose of the one-way algorithm is that the second party, the third party and third parties cannot reverse up the tree, and this prevents them from using or deriving contact information that they are not authorized to use or derive.

[0023] The first contact information may comprise a public key of the first party or of a privacy routing service provider and encrypted information encrypted with the public key, the encrypted information comprising an index in the contact information tree, the second contact information may comprise a result of encrypting a combination of the encrypted information and a subindex of the index with the public key, the result comprising, in encrypted form, the identifier of the second party, and the identifier of the second party may comprise the index and the subindex.

[0024] In the case a public key encryption algorithm is used and e.g. the first party receives a message, the first party may decrypt and unpeel the onion to verify the contact information. If there is a match with e.g. the first party’s root secret, then the first party has verified that the contact information was valid / genuine, and the first party may apply his sharing policy to the unpeeled index. Each derivation would include an encryption step with this public key. The benefit of using public key cryptography is that the depth of the contact information tree is hidden to anyone other than the first party. The public key encryption algorithm may be RSA, Elliptic Curve, or El-Gamal, for example.

[0025] The sharing policy may be obtained, and the communication relationship may be established, at a system of the first party or at a system of a privacy routing service provider. The first party may be able to outsource the verification of incoming messages to a Privacy Routing Service Provider (PRSP) and provide the PRSP with contact information of first order contacts or with a root secret. The PRSP can verify incoming messages for the first party with that information. This saves the first party work for vetting incoming messages, and saves bandwidth if many messages would be rejected.

[0026] When the first party wants to block an index, the first party would need to inform the PRSP to update the sharing policy associated with the first party with respect to that index. An example of a PRSP has been described in the patent application titled “Privacy Routing System” (European patent application EP22184205.7). The first party may also outsource the creation of the first contact information and / or the generation of the root secret to the PRSP.

[0027] The first contact information and the second contact information may comprise a communication identifier of the first party or a communication identifier of a privacy routing service provider. This communication identifier identifies the system associated with the first party to which the third party transmits the third party’s message. When the first party uses a PRSP, a communication identifier of the PRSP may be included instead of the first party’s own communication identifier. This may be signaled in the contact information. When this is signaled, the PRSP may take the root secrets or private keys of all its customers and verify the contact information in the received message based on each customer’s root secret or private key to determine for which customer the message is intended.

[0028] By using the communication identifier of the PRSP, the communication identifier of the first party may be kept private to prevent correlation by eavesdroppers, or to prevent the second party or third party to send messages to the first party directly and bypass a PRSP vetting system. When using the public key of the PRSP to encrypt both the value and the index, as described above, the first party’s communication identifier may also be hidden / encrypted in the encrypted onion and only becomes visible to the PRSP. The unpeeling decryption would need to be executed only once per incoming message. It would not be necessary to try to verify received contact information with different root secrets of different parties or different private keys of different parties.

[0029] The first contact information may comprise a referral limit, the referral limit specifying how often contact information may be derived from the first contact information, and the method may further comprise verifying, at the system of the second party, that the referral limit has not been reached before deriving the second contact information from the first contact information. For example, the first contact information may include “maxreferrals=3” to indicate that only three referrals can be made from this contact information, e.g. “x.l”, “x.2” and “x.3”. There may also be an associated limit to the depth of referrals. By refraining from unlimited referrals, potential abuse may be reduced. The number of referrals may be limited per time unit, e.g. “maxreferralsperday=20”.

[0030] The method may further comprise transmitting a notification from the system of the second party to the system associated with the first party upon deriving the second contact information and transmitting the second contact information to the system of the third party. For example, an address-book application may send out this notification to the original contact whenever derived contact information is shared. The second contact information and the notification may be transmitted with a single message with the help of a new recipient field.

[0031] It may be configurable whether such notification will always be sent or never be sent or whether this should be decided by the party on a case-by-case basis. The advantage of this notification is similar to that of email receipt notifications, where here the first party learns that new contact information was derived, and that an incoming message from another party may be expected. It could also be used as a trigger by the first party to already start taking preparatory measures for this, like updating a sharing policy.

[0032] The second contact information may further comprise encrypted information relating to a context in which the second contact information is derived. This information may comprise a time stamp, a GPS location, and / or a picture, for example. This provides a memento to the first party, when being contacted by the third party using the second contact information, about the second party and about the context in which first contact information was shared. In a second aspect of the invention, a method of deriving contact information comprises deriving, from first contact information for contacting a first party, second contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party, and transmitting the second contact information to a system of the third party. This method may be performed by a system of the second party. The method may be performed by a terminal, for example. The method may be performed by a directory service, for example. A company or organization that offers a PRSP service might also offer such a directory service.

[0033] In a third aspect of the invention, a method of establishing a communication relationship comprises receiving a message from a system of a third party, the message comprising second contact information for contacting a first party, the second contact information being derived from first contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party, obtaining a sharing policy associated with the identifier of the second party, and establishing the communication relationship between the first party and the third party in dependence on the sharing policy.

[0034] This method may be performed by a system associated with the first party, e.g. a system of the first party or a PRSP. This method may further comprise creating the first contact information and transmitting the first contact information to a system of the second party.

[0035] In a fourth aspect of the invention, a system for deriving contact information comprises at least one processor configured to derive, from first contact information for contacting a first party, second contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party, and transmit the second contact information to a system of the third party.

[0036] In a fifth aspect of the invention, a system for establishing a communication relationship comprises at least one processor configured to receive a message from a system of a third party, the message comprising second contact information for contacting a first party, the second contact information being derived from first contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party, obtain a sharing policy associated with the identifier of the second party, and establish the communication relationship between the first party and the third party in dependence on the sharing policy.

[0037] In a sixth aspect of the invention, a system for deriving contact information and establishing a communication relationship, the system comprising the system for deriving contact information and the system for establishing a communication relationship.

[0038] Moreover, a computer program for carrying out the methods described herein, as well as a non-transitory computer readable storage-medium storing the computer program are provided. A computer program may, for example, be downloaded by or uploaded to an existing device or be stored upon manufacturing of these systems.

[0039] A non-transitory computer-readable storage medium stores at least a first software code portion, the first software code portion, when executed or processed by a computer, being configured to perform executable operations for deriving contact information.

[0040] The executable operations comprise deriving, from first contact information for contacting a first party, second contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party, and transmitting the second contact information to a system of the third party.

[0041] A non-transitory computer-readable storage medium stores at least a second software code portion, the second software code portion, when executed or processed by a computer, being configured to perform executable operations for establishing a communication relationship.

[0042] The executable operations comprise receiving a message from a system of a third party, the message comprising second contact information for contacting a first party, the second contact information being derived from first contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party, obtaining a sharing policy associated with the identifier of the second party, and establishing the communication relationship between the first party and the third party in dependence on the sharing policy.

[0043] As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a device, a method or a computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system." Functions described in this disclosure may be implemented as an algorithm executed by a processor / microprocessor of a computer. Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied, e.g., stored, thereon.

[0044] Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a computer readable storage medium may include, but are not limited to, the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of the present invention, a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device.

[0045] A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0046] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber, cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java(TM), Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0047] Aspects of the present invention are described below with reference to flowchart illustrations, sequence diagrams and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor, in particular a microprocessor or a central processing unit (CPU), of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer, other programmable data processing apparatus, or other devices create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0048] These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0049] The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0050] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).

[0051] It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0052] BRIEF DESCRIPTION OF THE DRAWINGS

[0053] These and other aspects of the invention are apparent from and will be further elucidated, by way of example, with reference to the drawings, in which:

[0054] Fig. 1 is a sequence diagram of a first embodiment of the method of creating and deriving contact information and establishing a communication relationship;

[0055] Fig. 2 illustrates an embodiment of the method in which a one-way cryptographic algorithm is used;

[0056] Fig. 3 shows a first example of a contact information tree;

[0057] Fig. 4 shows a second example of a contact information tree;

[0058] Fig. 5 illustrates an embodiment of the method in which a hash function is used;

[0059] Fig. 6 illustrates an embodiment of the method in which a public key encryption algorithm is used;

[0060] Fig. 7 is a flowchart of a second embodiment of the method of establishing a communication relationship;

[0061] Fig. 8 is a flowchart of a second embodiment of the method of deriving contact information;

[0062] Fig. 9 is a block diagram of a first embodiment of the system for deriving contact information and establishing a communication relationship;

[0063] Fig. 10 is a block diagram of a second embodiment of the system for deriving contact information and establishing a communication relationship;

[0064] Fig. 11 illustrates an embodiment of the method in which hierarchic deterministic cryptography is applied; and

[0065] Fig. 12 is a block diagram of an exemplary data processing system for performing the steps of the method of the invention.

[0066] Corresponding elements in the drawings are denoted by the same reference numeral.

[0067] DETAILED DESCRIPTION OF THE DRAWINGS A first embodiment of the method of creating and deriving contact information and establishing a communication relationship is shown in Fig. 1. In the embodiment of Fig. 1, three roles are distinguished:

[0068] • Alice, who wants to refer her friend Carol to Bob;

[0069] • Bob, who wants to control the reception of messages from friends of Alice;

[0070] • Carol, a friend of Alice who wants to send a message to Bob.

[0071] In more general terms, Bob is the first party, Alice is the second party, and Carol is the third party. In the embodiment of Fig. 1, steps 101, 103, 127, 113, and 115 are performed by a system associated with the first party (Bob), e.g. a system of the first party (Bob) or a system of a Privacy Routing Service Provider (PRSP), which provides privacy routing as service to the first party (Bob). In the embodiment of Fig. 1, steps 105, 107, and 121 are performed by a system of the second party (Alice) and steps 123 and 125 are performed by a system of the third party (Carol).

[0072] Step 101 comprises creating, at the system associated with the first party (Bob), first contact information for contacting the first party (Bob). This first contact information is created specifically for the second party (Alice) and thereby specific for the second party (Alice). Step 103 comprises transmitting, at the system associated with the first party (Bob), the first contact information to the system of the second party (Alice).

[0073] Step 105 comprises receiving the first contact information at the system of the second party (Alice). Step 107 comprises deriving, at the system of the second party (Alice), from the first contact information, second contact information for contacting the first party (Bob). The second contact information is specific for a third party (Carol) and comprises an identifier of the second party (Alice). The second contact information may be derived from the first contact information, for example, by applying a one-way cryptographic algorithm to at least part of the first contact information.

[0074] A step 109 comprises transmitting the second contact information from the system of the second party (Alice) to a system of the third party (Carol). Step 109 comprises steps 121 and 123. Step 121 comprises transmitting, at the system of the second party (Alice), the second contact information to the system of the third party (Carol). Step 123 comprises receiving the second contact information at the system of the third party (Carol).

[0075] A step 111 comprises transmitting a message from the system of the third party (Carol) to the system associated with the first party (Bob). The message includes the second contact information. Step 111 comprises steps 125 and 127. Step 125 comprises transmitting, at the system of the third party (Carol), the message to the system associated with the first party (Bob). Step 127 comprises receiving the second contact information at the system associated with the first party (Bob). Step 113 comprises obtaining, at the system associated with the first party (Bob), a sharing policy associated with the identifier of the second party (Alice). Step 115 comprises establishing the communication relationship between the first party (Bob) and the third party (Carol) in dependence on the sharing policy obtained in step 113.

[0076] By including the identifier of a party who derives contact information, e.g. the second party, in this contact information, this identifier can be used to determine whether to establish a communication relationship between the party who wants the relationship, e.g. the third party, and the party to whom the contact information pertains, i.e. the first party. This way, the first party, e.g. Bob, can determine the provenance of the contact information that was used to contact him.

[0077] This provides Bob greater insight and control over who reaches him, and how those parties were referred to him. In particular, Bob may be enabled to block whole categories of spam / phishing messages that were caused by a single leak of contact information. Thus, the sharing of contact information with third parties is considered to be fully legitimate, but with the above method, it may be prevented that Bob has no idea how some spammer / phisher obtained Bob’s contact information.

[0078] The sharing policy may comprise a white list of identifiers of parties or a black list of identifiers of parties, for example. If the usage of the contact information shared by the second party should be restricted, the second party may be added to the black list or removed from the white list. The second party may be a person or a company, for example. At the same time, e.g. after a referral by the second party has led to spam, the second party could separately be blocked from communicating with the first party, e.g. via DIDcomm, but this is not required.

[0079] As mentioned above, Bob may be able to outsource the verification of incoming messages to a PRSP. The PRSP would then verify incoming messages for Bob with first contact information received from, or generated for, Bob. This saves Bob work vetting incoming messages and bandwidth if many messages would be rejected or blocked. When Bob blocks an identifier of a party, he would need to inform the PRSP to update its whitelists and / or blacklists.

[0080] In the embodiment of Fig. 1, steps 101, 103, 127, 113, and 115 are performed by the same system. In an alternative embodiment, these steps are performed by multiple systems. For example, the system of the first party (Bob) may perform steps 101 and 103 and the system of the PRSP may perform steps 127, 113, 115. In this alternative embodiment, the system of the first party (Bob) provides information, e.g. the first contact information, to the system of the PRSP to allow the PRSP to perform steps 113 and 115. In the example of Fig.1, the first party, second party, and third party are persons. Alternatively, one or more of the parties may be companies. The second party may be a directory service, for example. This directory service would normally only accept contact information for a party if it receives this contact information directly from the party or its PSRP. With the method of Fig. 1 plus the use of a directory service, the first party (Bob) can make himself publicly reachable, but still easily distinguish between directory referrals and friend referrals. A company or organization that offers a PRSP service might also offer such a directory service.

[0081] Contact information may be transmitted and encoded as W3C Verifiable Credential, an IRMA Attribute-Based Credential, a Hyperledger Indy Anonymous Credential (a.k.a. AnonCred), an IETF Authentic Chained Data Containers (ACDC), or other credential format, for example. Contact information may be serialised in JSON, JSON-LD, XML, JWT, RDF, TURTLE or other data-model syntaxes, for example. Contact information may be shared via the Internet, e.g. as part of a vCard (.vcf file), or via short-range digital communication like QR, NFC, Bluetooth, Wifi, acoustic, infra-red or other, for example.

[0082] Contact information may be attached to an email, or may be part of a Gmail Plus Address, for example. Contact information may be attached to a phone call using DTMF signalling (analogue), user-to-user signalling (ISDN), or as SDP attribute (SIP signalling for voice / video over IP), for example. Contact information may be attached to a parcel as a scannable QR code or bar code, for example. Contact information may be included in HTTP requests and responses, or other Internet protocols, for example. Contact information may be appended to a URL, e.g. RESTful or as a query string, for example.

[0083] Contact information may also be included in a new message field, e.g. a field call “cit_info”. If a sender sends a message to multiple recipients, contact information of the multiple recipients may be automatically included in this message in this new message field. This may be done when the sender composes a new message or replies to another message, for example. This allows the multiple recipients to establish a communication relationship with each other. For example, if Alice sends a message to Carol and David, this message may then comprise contact information for contacting Carol created specifically by Alice for David and / or contact information for contacting David specifically created by Alice for Carol in the “cit_info” field.

[0084] This is especially helpful when a message is sent to multiple recipients at the same time but the sender intends that only a couple of the recipients are contacted through this message. Then, for the persons that are intended to be contacted, based on this message, the contact information can be shared with all other recipients via the “cit_info” field. A message server of a recipient may be configured to remove contact information in the “cit_info” field that has not specifically been created for this recipient or hide this contact information from the recipient. This is especially beneficial if a message has more than two recipients. For example, if Alice sends a message to Carol, David, and Frank, this message may then comprise, in the “cit_info” field, contact information for contacting Carol created specifically by Alice for Frank, contact information for contacting David specifically created by Alice for Frank, contact information for contacting Carol specifically created by Alice for David, contact information for contacting Frank specifically created by Alice for David, contact information for contacting Carol specifically created by Alice for Frank, and contact information for contacting David specifically created by Alice for Frank.

[0085] Carol would then only see contact information for contacting David specifically created by Alice for Carol and contact information for contacting Frank specifically created by Alice for Carol. David would then only see contact information for contacting Carol created specifically by Alice for David and contact information for contacting Frank specifically created by Alice for David. Frank would then only see contact information for contacting Carol created specifically by Alice for Frank and contact information for contacting David specifically created by Alice for Frank.

[0086] If the message server of the recipient is configured to hide, from the recipient, contact information in a message’s “cit_info” field that has not specifically been created for this recipient, this contact information may be retained in other messages sent by the recipient in reply to this message. Alternatively, the recipient may derive new contact information from the contact information included in the message received by the recipient and include the derived contact information in the reply.

[0087] An address-book application (e.g. email client, phone client, dedicated smartphone app) may store contact information (e.g. the first contact information, the second contact information) which has been shared with another party in association with this other party, e.g. as additional field(s) for that party / contact. This address-book application may share derived contact information as a newly-generated .vcf vCard, for example.

[0088] The method may further comprise transmitting communication information to the third party (Carol) if the communication relationship is established (e.g. as part of step 115 or after step 115; not shown in Fig. 1), e.g. transmit the response specified in the DID Exchange Protocol or the first cryptographic information and the second cryptographic information described in the patent application titled “Privacy Routing System” (European patent application EP22184205.77).

[0089] In the latter case, the first cryptographic information comprises a receiver identifier encrypted with a cryptographic key associated with a PRSP. This receiver identifier is associated with the first party (Bob) and may be created by the first party (Bob) or by the PRSP specifically for the third party (Carol). The third party may then communicate normally with the first party (Bob) by transmitting, to the PRSP, a message which comprises third cryptographic information and fourth cryptographic information. The third cryptographic information comprises the receiver identifier encrypted with the cryptographic key associated with the PRSP. The fourth cryptographic information has been determined based on the second cryptographic information.

[0090] The PRSP can then decrypt the receiver identifier from the third cryptographic information with the cryptographic key or with a further cryptographic key corresponding to the cryptographic key, identify the first party (Bob) based on the decrypted receiver identifier, validate the fourth cryptographic information, and forward the message to the first party (Bob) based on a result of the validation of the fourth cryptographic information. The cryptographic key associated with the PRSP may be a public key, for example.

[0091] By creating different encrypted receiver identifiers for different parties, other parties may be prevented from being able to correlate messages addressed to the same recipient. By having a PRSP of the first party (Bob) use the fourth cryptographic information received from the third party (Carol) to determine whether the message from the first user should be forwarded or not, the first party (Bob) may block spam without enabling other parties to correlate messages addressed to the same recipient.

[0092] Cryptographic information may comprise a cryptographic key, data encrypted with a cryptographic key, and / or other cryptographic information. The third cryptographic information may be the same as the first cryptographic information, but may alternatively be different, e.g. comprise a re-randomization of the received encrypted receiver identifier. If the third cryptographic information is different from the first cryptographic information, it should at least be derived from the first cryptographic information. Similarly, the fourth cryptographic information may be the same as the second cryptographic information, but may alternatively be different.

[0093] The method may further comprise informing the third party that the communication relationship cannot be established if the communication relationship is not established (not shown in Fig. 1), e.g. by transmitting the DIDcomm “request not accepted” rejection specified in the DID Exchange Protocol.

[0094] The method of Fig. 1 may be extended to involve further parties and include creation and / or derivation of further contact information. For example, more than one item of first-order contact information may be created, more than one item of second-order contact information may be derived, and contact information of an order higher than two may be derived.

[0095] Fig. 2 illustrates an embodiment of the method in which a one-way cryptographic algorithm is used. In this embodiment, second-order contact information 52, e.g. the second contact information of Fig. 1, is derived from first-order contact information 51, e.g. the first contact information of Fig. 1, in step 107 by applying a one-way cryptographic algorithm 59 to at least part of the first-order contact information 51. In this embodiment, third-order contact information 53 is derived from the second-order contact information 52, e.g. the second contact information of Fig. 1, by applying the one-way cryptographic algorithm 59 to at least part of the second-order contact information 52.

[0096] The purpose of the one-way algorithm is to prevent that the third party (Carol) is able to obtain the first contact information based on the second contact information, while making it possible, e.g. for the first party (Bob), to verify the validity of the second contact information received from the third party (Carol) based on the first contact information. It may also prevent the modification or removal of the identifier of the second party (Alice) from second contact information by either the second party (Alice) or the third party (Carol).

[0097] In the example of Fig. 2, the one-way cryptographic algorithm 59 is applied to contact information, or a part thereof, and to a subindex. Each first-order contact information 51 created by the system associated with the first party (Bob), including the first contact information of Fig. 1, is created by applying the one-way cryptographic algorithm 59 to a different index, e.g. a different value of x. The created second-order contact information 52 may also be referred to as CIx. This system may use the index x=l for Alice, for example.

[0098] Each second-order contact information 52, including the second contact information of Fig. 1, derived by the system of the second party (Alice) from the first-order contact information 51 (CIx), e.g. the first contact information of Fig. 1, is derived with a different subindex 56, e.g. a different value of y. The current index (x) and the sub index 56

[0099] (y) jointly form a new index (x.y). The derived second-order contact information 52 may also be referred to as Clx.y. This system may use the subindex y=l for Carol, for example.

[0100] Each third -order contact information 53 derived by the system of the third party (Carol) from the second-order contact information 52 (Clx.y), e.g. the second contact information of Fig. 1, is derived by applying the one-way cryptographic algorithm 59 to a different subindex 57, e.g. a different value of z. The current index (x.y) and the subindex 57

[0101] (z) jointly form a new index (x.y.z). The derived third-order contact information 53 may also be referred to as Clx.y. z. This system may use the subindex z=l for Dave, for example. Further k-order contact information may be derived in the same way. The use of indices and subindices provides versatility and flexibility in applying sharing policies to individual parties or groups of parties. For example, Bob may be able to block messages from Carol (e.g. index=1.3.2) without needing to block Alice (e.g. index=1.3) or any other friends of Alice (e.g. index= 1.3.x, x^2). Bob may also be able to block whole branches of the contact-information tree (e.g. index=1.3.2.y), or only accept messages up to three levels deep.

[0102] By using indices and subindices as described in relation to Fig. 2, a contact information tree may be formed. Fig. 3 shows a first example of such a contact information tree. Fig. 3 shows a forest with three contact information trees. First contact information 61 and second contact information 62 are part of a first contact information tree. First contact information 61 is at a higher hierarchical level in the contact information tree than the second contact information 62. The first contact information tree has four hierarchical levels 93-96. The hierarchical level 93 comprises the first-order contact information 51 of Fig. 2. The hierarchical level 94 comprises the second-order contact information 52 of Fig. 2.

[0103] Fig. 4 shows a second example of a contact information tree: contact information tree 90. A root secret 91 is at the root of contact information tree 90. The root secret may be generated at the system associated with the first party (Bob). The root secret may be a random number, for example. The first-order contact information is derived from the root secret. In the example of Fig. 4, the first-order contact information comprise the first contact information 61 , third contact information 261 for contacting the first party, and fourth contact information 271 for contacting the first party.

[0104] The third contact information 261 is specific for a fourth party and the fourth contact information 271 is specific for a fifth party. The first contact information 61, the third contact information 261, and the fourth contact information 271 are at the same hierarchical level 93 in the contact information tree 90. Each first-order contact information created by the system associated with the first party (Bob) may be created by applying the one-way cryptographic algorithm 59 of Fig. 2 to a different index, as described in relation to Fig. 2.

[0105] HD wallets (see e.g. https: / / en.bitcoin.it / wiki / BIP_0032) are also created from root secrets / seeds. An HD wallet contains cryptographic keys in a tree structure, in which parent keys can produce children keys, which can produce grandchildren keys, and so on, infinitely. The cryptocurrency holder can use the tree structure to organize transactions by type of transaction or by entity involved, such as departments or subsidiaries. HD wallets are created from a single master root seed. The benefit of this is that incoming payments cannot be correlated to the same entity, and for keeping track of incoming payments through a dedicated bitcoin address per invoice or payment request. Moreover, HD wallets also offer the option of creating sub-public keys without having to access the corresponding private keys. This means they can be used on insecure servers or in a receive-only mode. A similar advanced configuration may also be used for the contact information tree.

[0106] Fig. 5 illustrates an embodiment of the method in which the derivation operation 79 uses a hash function. A hash function is an embodiment of the one-way cryptographic algorithm 59 of Fig. 2. In the embodiment illustrated with Fig. 5, first contact information 71 comprises an index 203 in the contact information tree (with value 1 in the example of Fig. 5) and a hash value 205. The second contact information 72, which is derived by the system of the second party, comprises an identifier 207 of the second party. The identifier 207 is a new index (1.2 in the example of Fig. 5) created by appending subindex 77 (with value 2 in the example of Fig. 5) to the original index 203, including a dot (“.”) as separator, i.e. index=index & & subindex.

[0107] The second contact information 72 further comprises a result of applying the hash function to both the value 205 and the subindex 77. The hash function may be SHA- 256, MD5, CRC-32, Keccak-512, or Shake-256, for example. In an alternative embodiment, a different one-way cryptographic algorithm may be used. The new hash value 209 is calculated by taking the hash function of the original hash value 205 with the new subindex 77 appended, i.e. hash= HASH(hash & subindex). The root of this algorithm, i.e. the root secret, may be a random number generated by the system associated with the first party (Bob).

[0108] The first contact information 71 and the second contact information 72 further comprise a communication identifier 201 of the first party (Bob) or a communication identifier of a privacy routing service provider. In the example of Fig. 5, the communication identifier 201 is Bob’s e-mail address (e.g. bob@kpn.com), which is just copied in derivation operation 79. Alternatively, the communication identifier may be a postal address, a phone number, an IP address, a domain name, a TOR onion address, a decentralised identifier (DID), a SIP address, or something else. To achieve backwards compatibility, the method may be used to extend current communication identifiers while messages without this extension can still be received.

[0109] If a communication identifier of the PRSP (e.g. “PRSP-service@kpn.com”) is included in the contact information instead of the communication identifier of the first party (Bob), this may be signaled in the contact information. Based on this signaling, the PRSP may take the root secrets of all its customers and try to reconstruct the received hash value based on these root secrets and the received index to determine for which customer the message was intended. As hash collisions are vanishingly rare, this would result in a unique anonymous customer identification. This has as benefit that the first party (Bob) may be able to keep his own communication identifier private (no correlation by eavesdroppers).

[0110] The contact information may also signal that some index values (e.g. odd indices) are leaves of a contact-information tree, and that they can only be used to contact the first party (Bob), but not for further derivation (e.g. “odd=leaf ’). In this case, the contact information may also signal that other index values (e.g. even ones) can only be used for further derivation / b ranching (e.g. “even=branch_only”). The contact information may also signal that the depth of branching is limited or unlimited (e.g. “max_branching=5”, or “max_branching=unlimited”) .

[0111] Fig. 6 illustrates an embodiment of the method in which a public key encryption algorithm is used. A public key encryption algorithm is an embodiment of the one-way cryptographic algorithm 59 of Fig. 2. In the embodiment illustrated with Fig. 6, the first contact information 81 comprises a public key 211 of the first party (Bob) or of a PRSP and encrypted information (enc) 213 encrypted with the public key 211. The encrypted information 213 comprises an index in the contact information tree (with value 1 in the example of Fig. 6). The second contact information 82 comprises a result 215 (enc) of encrypting a combination of the encrypted information 213 and a subindex 87 (with value 2 in the example of Fig. 6) of the index with the public key 211 in derivation operation 89, i.e. enc= ENC(enc & subindex). The result 215 comprises the identifier of the second party (Alice). The identifier of the second party (Alice) comprises the index and the subindex 87.

[0112] In the embodiment illustrated with Fig. 6, each derivation includes an encryption step with this public key 211. These encryption steps are analogous to the layers of an onion. When the system associated with the first party (Bob) receives a message, it can decrypt and unpeel this onion to verify that the received contact information is genuine. By decrypting the first encrypted information 213 from the result / further encrypted information 215 and decrypting the initial encrypted information, e.g. the root secret, from the first encrypted information 213, the system associated with the first party (Bob) may verify that the contact information was genuine and apply the sharing policy associated with the identifier obtained by unpeeling the onion.

[0113] In the embodiment illustrated with Fig. 6, the (initial) index is not updated; the initial index and each of the one or more subindices are stored in separate encryption steps / layers and not as a single index like in the embodiment illustrated with Fig. 5. However, like in the embodiment of Fig. 5, the initial index and each of the one or more subindices (one subindex if the derived contact information is second-order contact information) jointly form the identifier of the party that derived the contact information. A benefit of the embodiment illustrated with Fig. 6 is that the depth of the contact information tree is hidden to other parties, including to Alice and Carol. The public key may be based on RSA, Elliptic Curve, or El-Gamal public-key cryptography, for example.

[0114] The first contact information 81 and the second contact information 82 further comprise a communication identifier 201 of the first party (Bob) or a communication identifier of a PRSP. In the example of Fig. 6, the communication identifier 201 is Bob’s e- mail address.

[0115] In another example, Bob has outsourced the verification of incoming messages to a PRSP. In this case, the above-mentioned public key may be a public key of the PRSP. This allows Bob’s communication identifier to be hidden in the encrypted onion, and only become visible to the PRSP. This has as benefit that the unpeeling decryption would need to be executed only once per message, and not for all customers of the PRSP, like in the embodiment illustrated with Fig. 5 (which uses hashes).

[0116] If Bob has outsourced the verification of incoming messages to a PRSP, cryptographic accumulators may be used to enable the PRSP to enforce the whitelisting and / or blacklisting while keeping the contents of the whitelist and / or blacklist private. In this case, proof-of-being-whitelisted and / or proof-of-not-being-blacklisted may need to be provided. Such proof may be a zero-knowledge proof (ZKP), for example.

[0117] The first embodiment of the method of creating and deriving contact information and establishing a communication relationship of Fig. 1 comprises a first embodiment of the method of deriving contact information, which comprises steps 105, 107 and 121, and a first embodiment of the method of establishing a communication relationship, which comprises steps 101, 103, 127, 113, and 115.

[0118] A second embodiment of the method of establishing a communication relationship is shown in Fig. 7. A step 151 comprises receiving a message from the system of the third party (Carol), e.g. a message requesting a communication relationship to be established. The message comprises second contact information for contacting the first party (Bob). The second contact information has been derived from first contact information for contacting the first party (Bob). The first contact information is specific for the second party (Alice). The second contact information is specific for the third party (Carol) and comprises an identifier of the second party (Alice).

[0119] In the embodiment of Fig. 7, step 151 comprises receiving the second contact information 72 of Fig. 5. The second contact information 72 comprises a communication identifier 201, an index 207, and a hash value 209. A step 153 comprises performing a hash function to calculate a hash value based on the root secret of the first party (Bob) and the index 207. In an alternative embodiment, no root secret is used and the hash value is calculated based on the initial hash value associated with (and provided to) the party whose number is included as initial index in the received contact information (e.g. the value of x in index x.y.z).

[0120] A step 155 comprises determining whether the hash value 209 received in step 151 and the hash value calculated in step 153 match. If it is determined in step 155 that the two hash values match, then step 113 is performed next. If it is determined in step 155 that the two hash values do not match, i.e. that the received contact information is not genuine, then a step 161 is performed next. Step 161 comprises ignoring / deleting the message received in step 151, and optionally returning an error message to the system of the third party (Carol).

[0121] Step 113 comprises obtaining the sharing policy associated with the identifier of the second party (Alice), i.e. associated with the index included in the contact information received in step 151. A step 157 comprises checking the policy obtained in step 113.

[0122] If it is determined in step 157 that the message received in step 151 should be accepted, then a step 163 is performed in which the message is automatically accepted. If it is determined in step 157 that the message received in step 151 should be stored, then a step 164 is performed in which the message is stored. If the message is stored, the first party may later select the message and accept the message manually. In both cases, a communication relationship is established between the first party (Bob) and the third party (Carol).

[0123] If it is determined in step 157 that the message received in step 151 should be blocked, then a step 166 is performed in which the message is blocked. If it is determined in step 157 that the message received in step 151 should be rejected, then a step 167 is performed in which the message is rejected. For example, the first party (Bob) could immediately read referrals from party A, he could ignore / block referrals from party B, and he could store referrals from party C to read later. Step 167 comprises transmitting a rejection message to the system of the third party (Carol). If the step 166 is performed, no rejection message is transmitted. Step 166 may be similar to step 161.

[0124] The first party would typically configure a policy for direct contacts, for whom the system associated with the first party creates first-order contact information, as well as for other contacts, for whom contact information is derived by other parties. Typically, the same policy would initially be used for all of the other contacts and the first party would then change the policy for one of these other contacts based on the messages its receives with contact information derived by this other contact.

[0125] The first party would normally know the identity of the direct contacts, so for a direct contact, the first party may configure a policy before receiving any message with contact information derived by this direct contact. For example, if Alice, Frank, and a directory service are all direct contacts, Bob could configure his policy to immediately read referrals from trusted Alice, ignore / block referrals from flaky Frank, and store referrals from the directory service to read later.

[0126] A second embodiment of the method of deriving contact information is shown in Fig. 8. A step 171 comprises receiving contact information for contacting a certain party, e.g. the first party (Bob). The contact information is specific for the party who receives the contact information in step 171, e.g. the second party (Alice). In the embodiment of Fig. 8, the contact information comprises a referral limit which specifies how often contact information may be derived from the first contact information, i.e. the contact information created by the certain party. This referral limit limits potential abuse. For example, “maxreferrals=3” in the contact information would indicate that only three referrals are allowed to be made from the first contact information, “x.l”, “x.2” and “x.3”.

[0127] The number of referrals may be limited per time unit. For example, the contact information may specify “maxreferralsperday=20”. In an alternative embodiment, the contact information may further comprise metadata that limits through what means derived contact information may be shared, e.g. limiting to in-person sharing with short-range digital communication, but not via the Internet.

[0128] A step 173 comprises verifying whether the referral limit specified in the contact information received in step 171 has been reached. This may be verified, for example, based on the number of subindices in the received index, see e.g. the example of Fig. 5, or based on the number of subindice s / encryption steps in the received encrypted information, see e.g. the example of Fig. 6. If it is determined in step 173 that this the referral limit has not been reached, step 107 is performed. This may be enforced with a secure hardware module, for example. The integrity of this field may be protected with the help of encryption, for example.

[0129] Step 107 comprises deriving, from the contact information received in step 171, new contact information for contacting the certain party, e.g. the first party (Bob). The new contact information is specific for the party to which the new contact information will be transmitted, e.g. the third party (Carol), and comprises an identifier of the party that is deriving the new contact information, e.g. the second party (Alice). The new contact information may be derived from the received contact information by applying a one-way cryptographic algorithm to at least part of the received contact information.

[0130] Step 121 comprises transmitting the new contact information to a system of the party for which the new contact information was derived in step 107, e.g. the third party (Carol). A step 175 comprises transmitting a notification to a system associated with the certain party, e.g. the first party (Bob). This notification may be transmitted by an addressbook application of the party that derives the new contact information, for example. Instead of transmitting a separate notification message, the notification may be transmitted with the help of a new recipient field. For example, a field “cit” may be introduced in addition to the conventional e-mail recipient fields “to”, “cc”, and “bcc”.

[0131] For instance, when Alice wants to share the derived contact information for contacting Bob with Carol, Alice sends a message “to” Carol with “cit” to Bob. Carol then receives the message from Alice with the derived contact information for contacting Bob, whereas Bob receives a notification that Alice has referred Carol to him. It may be configurable whether such notification will always be sent, or never or decided by the user on a case-by-case basis. In an alternative embodiment, step 175 is omitted or step 173 is omitted. In the latter case, step 105 of Fig. 5 does not need to be implemented by step 171.

[0132] The derived contact information may further comprise encrypted information relating to a context in which the contact information is derived, e.g. a time stamp, a GPS location, and / or a picture. The derived contact information may include further metadata added by the party that derives the new contact information, e.g. the second party (Alice) (e.g. “I derived this third contact information for Carol to contact Bob”). This party may electronically sign the metadata with their private key, and / or encrypt parts of the metadata for either themselves or for another party higher in the contact information tree with, respectively, their public key or the public key of this other party.

[0133] Optionally, when subindices are used in the different iterations of step 107, as described in relation to Figs. 4 to 6, subindices might not be generated in order but, for example, at random or deterministically based on an identifier of the party for which the new contact information is derived. This masks at what time the party derived the new contact information as well as the number of times the party derived new contact information from the received contact information. This may be done to provide some anonymity to the party that derives the new contact information, e.g. the second party (Alice). This might lead to collisions, but the chance is low, and collisions do not have big ramifications.

[0134] In an alternative embodiment, when subindices are used in the different iterations of step 107, as described in relation to Figs. 4 to 6, the party that receives the contact information may in an additional step, derive, from the received contact information, one or more items of new contact information for its own use. This party can then use this new contact information instead of the received contact information to establish a communication relationship. For example, instead of using CI Ito establish the communication relationship with Bob, Alice may derive and use CI 1.3 and CI 1.4.

[0135] In this alternative embodiment or in a different alternative embodiment, the party that receives the contact information may derive further new contact information from the new contact information, and possibly even other new contact information from the further new contact information, etcetera. This may be done to mask the referral depth / path and give some anonymity to the party that receives the contact information, e.g. the second party (Alice). For example, Alice could refer multiple times to herself by repeatedly applying the contact information derivation process, optionally choosing a random index in every derivation step. The final new contact information may be derived for another party and transmitted to this other party or may be derived for the party’s own use. As an example of the latter, Alice may generate a very high order derivation, which masks how she has actually been referred to. This may be useful if Alice received the contact information, or might have received the contact information, from a criminal or a dubious journalist, for example.

[0136] First embodiments of the system for establishing a communication relationship and the system for deriving contact information are shown in Fig. 9. The system 11 of the first party (Bob) establishes the communication relationship. The system 1 of the second party (Alice) derives the contact information. The system 21 of the third part (Carol) uses the derived contact information to request the system 1 to establish the communication relationship between the third party (Carol) and the first party (Bob). Systems 1, 11, and 21 are part of a communication system 10.

[0137] The system 11 of the first party (Bob) comprises a receiver 13, a transmitter 14, a processor 15, and a memory 17. The processor 15 is configured to receive a message from the system 21 of the third party (Carol). The message comprises second contact information for contacting the first party (Bob). The second contact information has been derived from first contact information for contacting the first party (Bob). The first contact information is specific for the second party (Alice). The second contact information is specific for the third party (Carol) and comprises an identifier of the second party (Alice).

[0138] The processor 15 is further configured to obtain a sharing policy associated with the identifier of the second party (Alice) and establish the communication relationship between the first party (Bob) and the third party (Carol) in dependence on the sharing policy. In the embodiment of Fig. 9, the processor 15 is further configured to create the first contact information and transmit the first contact information to the system 1 of the second party (Alice).

[0139] The system 1 of the second party (Alice) comprises a receiver 3, a transmitter 4, a processor 5, and a memory 7. The processor 5 is configured to receive the first contact information from system 11 of the first party (Bob), derive, from the first contact information, second contact information for contacting the first party (Bob), and transmit the second contact information to the system 21 of the third party (Carol). The second contact information is specific for the third party (Carol) and comprises an identifier of the second party (Alice).

[0140] A second embodiment of the system for establishing a communication relationship is shown in Fig. 10. While in the embodiment of Fig. 9, the sharing policy is obtained, and the communication relationship is established, at the system 11 of the first party (Bob), in the embodiment of Fig. 10, the sharing policy is obtained, and the communication relationship is established, at a system 31 of a PRSP. The system 31 is associated with at least the first party, i.e. it provides a privacy routing service to at least the first party. The system 31 of the PRSP is different from the system 41 of the first party (Bob). Systems 1, 21, 31, and 41 are part of a communication system 40.

[0141] The system 31 of the PRSP comprises a receiver 33, a transmitter 34, a processor 35, and a memory 37. The processor 35 is configured to receive a message from the system 21 of the third party (Carol). The message comprises second contact information for contacting the first party (Bob). The second contact information has been derived from first contact information for contacting the first party (Bob). The first contact information is specific for the second party (Alice). The second contact information is specific for the third party (Carol) and comprises an identifier of the second party (Alice).

[0142] The processor 35 is further configured to obtain a sharing policy associated with the identifier of the second party (Alice) and establish the communication relationship between the first party (Bob) and the third party (Carol) in dependence on the sharing policy. In the embodiment of Fig. 10, the processor 35 is further configured to create the first contact information and transmit the first contact information to the system 1 of the second party (Alice). In an alternative embodiment, the system 41 of the first party (Bob) is configured to create the first contact information.

[0143] The processor 5 of the system 1 is configured to receive the first contact information from system 31 of the PRSP, derive, from the first contact information, second contact information for contacting the first party (Bob), and transmit the second contact information to the system 21 of the third party (Carol). The second contact information is specific for the third party (Carol) and comprises an identifier of the second party (Alice).

[0144] In the embodiments shown in Figs. 9 and 10, the systems 1, 11, and 31 comprise one processor 5, one processor 15, and one processor 35, respectively. In an alternative embodiment, one or more of the systems 1, 11, and 31 comprise multiple processors. The processors 5, 15, and 35 may be general-purpose processors, e.g., ARM, Qualcomm, AMD, or Intel processors, or application-specific processors. The processors 5, 15, and 35 may run Google Android, Apple iOS, a Unix-based operating system or Windows as operating system, for example. The receivers 3, 13, and 33 and the transmitters 4, 14, and 34 of the systems 1, 11, and 31, respectively, may use one or more wired or wireless communication technologies such as Ethernet, Wi-Fi, LTE, and / or 5G New Radio to communicate with other devices on the Internet via an access point / base station, or they may use in-person communication like Bluetooth, Wi-Fi direct, QR-code, or a dead drop solution to communicate with other devices. The receiver and the transmitter of a system may be combined in a transceiver. The systems 1, 11, and 31 may comprise other components typical for a digital device.

[0145] Fig. 11 illustrates an embodiment of the method in which hierarchic deterministic cryptography is applied to form a contact information tree. In this embodiment, a public-key encryption system is used with function cp: S -> P that can create a public key p (in the space of public keys P) from a secret (private) key s (from the space of secret keys S). This private key s is comparable to the root secret 91 of Fig. 4 in terms of its position in the contact information tree 90.

[0146] The function cp may be the key-derivation function in DSA, EC-DSA, El- Gamal signatures, Schnorr signatures, or EdDsa, for example. Function <p may have the form <p(s) = gs, for example, where g is a generator of some group and secret key s an integer. Due to the group structure, the following property holds: <p(s + 1) = gsgf.

[0147] In this embodiment, a function f: P x I -> P is used to create a new public key from the tuple which consists of the current public key x and the index i. The function f may make use of a hash function H (e.g. SHA-256, MD5, CRC-32, Keccak-512, or Shake-256, as mentioned before). Function f may have the form f(x, t) = forexample.

[0148] The function f may be used in step 101 of Fig. 1 to derive a new public key xi from the public key p. This new public key xi is included in the first contact information 71 of Fig. 5 instead of the hash value 205. The function f may be used in step 107 of Fig. 1 to derive a new public key X2 from the public key xi . This new public key X2 is included in the second contact information 72 of Fig. 5 instead of the hash value 209.

[0149] Given cp and f, a suitable function h: S x I -> S can be found such that the diagram in Fig. 11 is commuting. With the above-mentioned functions <p(s) and f(x, i), a suitable function h is: h(x, i) = x H(<p(x), i). In this case, the commutation relation holds:

[0150] The functions g and h and the secret (private) key s are known only to the first party and / or its PRSP. The function f is known to all parties. Upon receipt of the second contact information from the system of the third party in step 127 of Fig. 1, the system of the first party or its PRSP verifies, based on the public key public key X2 and the index included in the second contact information, whether the public key X2 has been correctly derived and thus whether the second contact information is genuine, like in step 153 of Fig. 7.

[0151] Moreover, since the first party knows the functions g and cp and the secret (private) key s, the system of the third party could send a challenge to the system associated with the first party to verify that this system is indeed associated with the party with which the third party wishes to establish a communication relationship. An example of such a challenge is: decrypt this encrypted message (which I have encrypted with public key X2) and send me the decrypted message. If the system associated with the first party is able to send this decrypted message, the third party knows that it has transmitted its request to establish a communication relationship to the right system.

[0152] Fig. 12 depicts a block diagram illustrating an exemplary data processing system that may perform the method as described with reference to Figs. 1, 7, and 8.

[0153] As shown in Fig. 12, the data processing system 300 may include at least one processor 302 coupled to memory elements 304 through a system bus 306. As such, the data processing system may store program code within memory elements 304. Further, the processor 302 may execute the program code accessed from the memory elements 304 via a system bus 306. In one aspect, the data processing system may be implemented as a computer that is suitable for storing and / or executing program code. It should be appreciated, however, that the data processing system 300 may be implemented in the form of any system including a processor and a memory that is capable of performing the functions described within this specification.

[0154] The memory elements 304 may include one or more physical memory devices such as, for example, local memory 308 and one or more bulk storage devices 310. The local memory may refer to random access memory or other non-persistent memory device(s) generally used during actual execution of the program code. A bulk storage device may be implemented as a hard drive or other persistent data storage device. The processing system 300 may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code must be retrieved from the bulk storage device 310 during execution.

[0155] Input / output (I / O) devices depicted as an input device 312 and an output device 314 optionally can be coupled to the data processing system. Examples of input devices may include, but are not limited to, a keyboard, a pointing device such as a mouse, a camera, or the like. Examples of output devices may include, but are not limited to, a monitor or a display, speakers, or the like. Input and / or output devices may be coupled to the data processing system either directly or through intervening I / O controllers. In an embodiment, the input and the output devices may be implemented as a combined input / output device (illustrated in Fig. 12 with a dashed line surrounding the input device 312 and the output device 314). An example of such a combined device is a touch sensitive display, also sometimes referred to as a “touch screen display” or simply “touch screen”. In such an embodiment, input to the device may be provided by a movement of a physical object, such as e.g. a stylus or a finger of a user, on or near the touch screen display.

[0156] A network adapter 316 may also be coupled to the data processing system to enable it to become coupled to other systems, computer systems, remote network devices, and / or remote storage devices through intervening private or public networks. The network adapter may comprise a data receiver for receiving data that is transmitted by said systems, devices and / or networks to the data processing system 300, and a data transmitter for transmitting data from the data processing system 300 to said systems, devices and / or networks. Modems, cable modems, and Ethernet cards are examples of different types of network adapter that may be used with the data processing system 300.

[0157] The network adapter 316 may allow the data processing system to connect to the Internet, e.g. via Wi-Fi or Ethernet, and / or directly to nearby devices, e.g. via Bluetooth, Wi-Fi-Direct or Ultrasound. Data may also be exchanged between other devices and the data processing system in another way, e.g. by enabling the data processing system to scan a QR code displayed on another device and / or by enabling the data processing system to display a QR code for scanning by another device.

[0158] As pictured in Fig. 12, the memory elements 304 may store an application 318. In various embodiments, the application 318 may be stored in the local memory 308, he one or more bulk storage devices 310, or separate from the local memory and the bulk storage devices. It should be appreciated that the data processing system 300 may further execute an operating system (not shown in Fig. 12) that can facilitate execution of the application 318. The application 318, being implemented in the form of executable program code, can be executed by the data processing system 300, e.g., by the processor 302. Responsive to executing the application, the data processing system 300 may be configured to perform one or more operations or method steps described herein.

[0159] Various embodiments of the invention may be implemented as a program product for use with a computer system, where the program(s) of the program product define functions of the embodiments (including the methods described herein). In one embodiment, the program(s) can be contained on a variety of non-transitory computer-readable storage media, where, as used herein, the expression “non-transitory computer readable storage media” comprises all computer-readable media, with the sole exception being a transitory, propagating signal. In another embodiment, the program(s) can be contained on a variety of transitory computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information is permanently stored; and (ii) writable storage media (e.g., flash memory, floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory) on which alterable information is stored. The computer program may be run on the processor 302 described herein.

[0160] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0161] The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the implementations in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the present invention. The embodiments were chosen and described in order to best explain the principles and some practical applications of the present invention, and to enable others of ordinary skill in the art to understand the present invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

CLAIMS:

1. A method of creating and deriving contact information and establishing a communication relationship, the method comprising:- creating (101) first contact information for contacting a first party, the first contact information being specific for a second party;- transmitting (103) the first contact information to a system of the second party;- deriving (107), at the system of the second party, from the first contact information, second contact information for contacting the first party, the second contact information being specific for a third party and comprising an identifier of the second party;- transmitting (109) the second contact information from the system of the second party to a system of the third party;- transmitting (111) a message from the system of the third party to a system associated with the first party, the message including the second contact information;- obtaining (113) a sharing policy associated with the identifier of the second party; and- establishing (115) the communication relationship between the first party and the third party in dependence on the sharing policy.

2. A method as claimed in claim 1, wherein the second contact information (52) is derived from the first contact information by applying a one-way cryptographic algorithm (59) to at least part of the first contact information (51).

3. A method as claimed in claim 1 or 2, wherein the first contact information (61) and the second contact information (62) are part of a contact information tree (90), the first contact information (61) being at a higher hierarchical level (93) in the contact information tree (90) than the second contact information (62).

4. A method as claimed in claim 3, further comprising:- generating a root secret (91),- determining the first contact information (61) by deriving the first contact information (61) from the root secret (91), and- deriving, at the system of the first party, third contact information (261) for contacting the first party from the root secret (91), the third contact information (261) being specific for a fourth party, the first contact information (61) and the third contact information (261) being at the same hierarchical level (93) in the contact information tree (90).

5. A method as claimed in claim 3 or 4, wherein the first contact information (71) comprises an index (203) in the contact information tree and a value (205), the identifier (207) of the second party comprises the index (203) and a subindex (77) of the index (203), and the second contact information (72) further comprises a result (209) of applying a oneway cryptographic algorithm to both the value (205) and the subindex (77).

6. A method as claimed in claim 3 or 4, wherein the first contact information (81) comprises a public key (211) of the first party or of a privacy routing service provider and encrypted information (213) encrypted with the public key (211), the encrypted information comprising an index in the contact information tree, the second contact information (82) comprises a result (215) of encrypting a combination of the encrypted information (213) and a subindex (87) of the index with the public key (211), the result comprising, in encrypted form, the identifier of the second party, and the identifier of the second party comprises the index and the subindex (87).

7. A method as claimed in any one of the preceding claims, wherein the sharing policy is obtained, and the communication relationship is established, at a system (11) of the first party or at a system (31) of a privacy routing service provider.

8. A method as claimed in any one of the preceding claims, wherein the first contact information and the second contact information comprise a communication identifier (201) of the first party or a communication identifier of a privacy routing service provider.

9. A method as claimed in any one of the preceding claims, wherein the first contact information comprises a referral limit, the referral limit specifying how often contact information may be derived from the first contact information, and the method further comprises verifying (173), at the system of the second party, that the referral limit has not been reached before deriving (107) the second contact information from the first contact information.

10. A method as claimed in any one of the preceding claims, further comprising transmitting (175) a notification from the system of the second party to the system associated with the first party upon deriving (107) the second contact information and transmitting (121) the second contact information to the system of the third party.

11. A method as claimed in any one of the preceding claims, wherein the second contact information further comprises encrypted information relating to a context in which the second contact information is derived.

12. A method of deriving contact information, the method comprising:- deriving (107), from first contact information for contacting a first party, second contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party; and- transmitting (121) the second contact information to a system of the third party.

13. A method of establishing a communication relationship, the method comprising:- receiving (127) a message from a system of a third party, the message comprising second contact information for contacting a first party, the second contact information being derived from first contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party;- obtaining (113) a sharing policy associated with the identifier of the second party; and- establishing (115) the communication relationship between the first party and the third party in dependence on the sharing policy.

14. A method as claimed in claim 13, further comprising:- creating (101) the first contact information; and- transmitting (103) the first contact information to a system of the second party.

15. A computer program or suite of computer programs comprising at least one software code portion or a computer program product storing at least one software codeportion, the software code portion, when run on a computer system, being configured for performing any one of the methods of claims 1 to 14.

16. A system (1) for deriving contact information, the system (1) comprising at least one processor (5) configured to:- derive, from first contact information for contacting a first party, second contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party, and- transmit the second contact information to a system of the third party.

17. A system (11,31) for establishing a communication relationship, the system comprising at least one processor (15,35) configured to:- receive a message from a system of a third party, the message comprising second contact information for contacting a first party, the second contact information being derived from first contact information for contacting the first party, the first contact information being specific for a second party, the second contact information being specific for a third party and comprising an identifier of the second party,- obtain a sharing policy associated with the identifier of the second party, and- establish the communication relationship between the first party and the third party in dependence on the sharing policy.

18. A system (11,31) as claimed in claim 17, where the at least one processor (15,35) is further configured to:- create the first contact information, and- transmit the first contact information to a system of the second party.

19. A system (10,40) for deriving contact information and establishing a communication relationship, the system (10,40) comprising the system (1) for deriving contact information of claim 16 and the system (11,31) for establishing a communication relationship of claim 17 or claim 18.

Images