EP4315744A1

EP4315744A1 - Method and apparatus for providing and using a virtual representation of a user

Info

Publication number: EP4315744A1
Application number: EP22707374.9A
Authority: EP
Inventors: Rik CLAESEN
Original assignee: Sony Group Corp; Sony Europe BV
Current assignee: Sony Group Corp; Sony Europe BV
Priority date: 2021-03-31
Filing date: 2022-02-04
Publication date: 2024-02-07
Also published as: WO2022207164A1

Abstract

The present disclosure relates to a network node associated with a virtual representation of a user. The network node comprises memory configured to store a decentralized identifier, DID, of the virtual representation, a DID document whereto the DID resolves, and a private key of an asymmetric key pair associated with the DID. The DID document indicates at least one attribute assigned to the virtual representation by the user and a public key of the asymmetric key pair. The network node further comprises a first interface configured to send the private key to a network node associated with the user.

Description

METHOD AND APPARATUS FOR PROVIDING AND USING A VIRTUAL REPRESENTATION OF A USER

Field

Examples of the present disclosure relate to a network node associated with a virtual repre sentation of a user in the context of Decentralized Identifiers. Examples of the present disclo sure may also relate to a method for providing a virtual representation of a user and a method for using the virtual representation of the user for performing data transactions on behalf of the user.

Background

An increasing number of activities of private individuals have transitioned from offline mo dalities to online or partly online modalities. For example, a private individual may perform transactions entirely or partly online, including financial activities (shopping, banking, etc.), social activities (posting, commenting, etc.), or leisure activities (online gaming, etc.). Such activities require a certain degree of disclosure of personal data about the private individual. Therefore, the private individual may create avatars virtually representing the private individ ual with different degrees of disclosure. Such avatars may perform the activities on behalf of the private individual without entirely revealing the true identity of the private individual.

A user usually creates avatars on an online platform, such as a banking website, a gaming platform, or a social network like Facebook or Twitter, where the avatars are linked to an account of the user. The avatars are displayed publicly to all users of the online forum, web site, or online forum and as such can be contacted to chat or send an email to. The platform provider is in control of the avatars, implying that the user of the online platform is dependent on a good handling of his/her avatars on the part of the platform provider. The user can barely prevent the platform provider from, for example, deleting or modifying the avatars, or ex tracting and demanding more personal data than the user seeks to convey. Furthermore, avatars are usually bound to the online platform they were created on. Thus, they cannot be transferred to other online platforms. The user needs to create avatars specifi cally for every online platform the user wants to perform transactions with. An avatar may only exist as long as a corresponding user account exists. For other users and companies, it is difficult to decide how to contact a user via an avatar because there might exist many avatars of one and the same user on different websites. It is also difficult for the online platform to verify the veracity of data associated with avatars or for users to proof an ownership of ava tars. Consequently, avatars can be tampered with or faked.

Today’s avatars, as described above, may have various limitations and shortcomings:

Avatars are not managed by a user that is represented by the avatars.

Avatars are linked to user accounts, so, when a corresponding user account on a web site is removed, the avatar is removed, too.

Avatars are only known to the website the user accounts were created in.

Avatars need to be recreated on different websites over and over again.

- For other parties, it is difficult to contact a user via an avatar because there might exist many copies on different website.

It is difficult to create an avatar across multiple websites.

The user is not able to claim ownership of the avatar.

Imposters can create similar looking avatars on other websites and pretend to be the user behind the “original” avatar.

A decentralized global registration mechanism for avatars is lacking.

The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one exemplary technology area where some embodiments de scribed herein may be practiced.

Summary

A need for improvement is addressed by the subject matter of the independent claims. Further, possibly advantageous embodiments are addressed by the dependent claims. According to a first aspect of the present disclosure, it is provided a network node associated with a virtual representation of a user. The network node associated with the virtual represen tation comprises memory configured to store a decentralized identifier, DID, of the virtual representation, a DID document whereto the DID resolves, and a private key of an asymmetric key pair associated with the DID. The DID document indicates at least one attribute assigned to the virtual representation by the user and a public key of the asymmetric key pair. The network node associated with the virtual representation further comprises a first interface configured to send the private key to a network node associated with the user.

According to a second aspect of the present disclosure, it is provided a method for providing a virtual representation of a user. The method comprises storing a DID, a DID document, and a private key of an asymmetric key pair on a memory associated with the virtual representa tion. The DID is associated with the virtual representation and resolves to the DID document. The DID document indicates at least one attribute assigned to the virtual representation by the user and a public key of the asymmetric key pair. The method further comprises sending the private key to a network node associated with the user.

Brief description of the Figures

Some examples of apparatuses and/or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which

Fig. 1 illustrates a basic architecture for Decentralized Identifiers (DIDs);

Fig. 2 illustrates a network node associated with a virtual representation of a user, comprising a first interface;

Fig. 3 illustrates the network node with a second interface;

Fig. 4 illustrates a concept for providing a proof-of-possession;

Fig. 5 illustrates the network node with a third interface; Fig. 6 illustrates a concept for establishing a secure communication channel.

Detailed Description

Some examples are now described in more detail with reference to the enclosed figures. How ever, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain ex amples should not be restrictive of further possible examples.

Throughout the description of the figures same or similar reference numerals refer to same or similar elements and/or features, which may be identical or implemented in a modified form while providing the same or a similar function. The thickness of lines, layers and/or areas in the figures may also be exaggerated for clarification.

When two elements A and B are combined using an 'or', this is to be understood as disclosing all possible combinations, i.e., only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the same combinations, "at least one of A and B" or "A and/or B" may be used. This applies equivalently to combinations of more than two elements.

If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the same function. If a function is described below as implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. It is further understood that the terms "include", "in cluding", "comprise" and/or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and/or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and/or a group thereof. An objective of the present disclosure may be providing “public self-sovereign identity ava tars” for users of online platforms. An avatar may be a virtual representation of the user.

Embodiments disclosed herein are related to a network node associated with a virtual repre sentation of a user. The user may be any entity that could benefit from a virtual representation. For example, the user may be one or more human beings. The user may alternatively be a machine, a software, a device, a subpart of a machine, system or device, or a collection or combination of the previously mentioned. For instance, a device could be a printed circuit board and could integrate an executable software component, e.g., an artificial intelligence. Thus, the user may be any reasonable entity, human or non-human, that is capable of creating and using a virtual representation.

A virtual representation of a user may comprise computer-implemented software, for exam ple, to perform data transactions on an online platform on behalf of the user. The virtual rep resentation may also comprise processing circuitry to execute the software and data storage, for example, to store any data useful to perform the transactions. Such a virtual representation may be viewed by other users of the online platform. The virtual representation may be an “avatar” or “online alias” representing the user in the virtual world. The virtual representation may be used to interact with the virtual or real world. The virtual representation may be cre ated by the user and perform data transactions on behalf of the user, for example, in a context of an account of an online platform. More than one virtual representation may belong to the same user and may, for example, differ in the level of disclosure of private information or in an application environment, such as business or private environment. An account of an online platform may be a process to authenticate a user and/or to allow a user to access services provided by the online platform.

A network node associated with the virtual representation may be part of a computer system. A computer system may be distributed over a computer network and may include multiple constituent computer systems. Computer systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computer systems, datacenters, or even devices that have not traditionally been considered a computer system, such as wearables. The network node may comprise an interface to a computer network. As used herein, the term “computer network” may comprise any infrastructure to exchange data, such as data associated with the data transactions, between multiple computer systems or network nodes. Such infrastructure may comprise servers, network cables, fibre optic ca bles, routers, etc. The computer network may include any electronic communication means which incorporates both hardware and software of such communication among parties. Com munication may be accomplished through any suitable communication channels, such as a telephone network, an extranet, an intranet, Internet, point of interaction device, online com munications, offline communications, wireless communications, transponder communica tions, Local Area Network, Wide Area Network, networked or linked devices, or alike. The data may be exchanged in accordance with communication protocols, such as TCP/IP, Ap pletalk, IP-6, NetBIOS, OSI or any number of existing or future protocols. A computer system may have one or more network nodes, in other words a computer system may have one or more interfaces to the computer network. Likewise, a user may use his/her virtual represen tation, for example, to send messages to a third party via a network node associated with the virtual representation. Data transactions may comprise any information provided by the vir tual representation of the user.

The network node associated with the virtual representation may comprise a so-called digital agent. The digital agent may be an electronic device, an online service, or a software program configured to handle a digital identity of the virtual representation. The digital identity of the virtual representation may comprise information on the virtual representation used by com puter systems to allow for assessment and authentication of the virtual representation when interacting with a third party or other entities without the involvement of human operators. The virtual representation may be in control of the digital agent, i.e., the virtual representation may be authorized to configure the digital agent. The digital identity of the virtual represen tation may comprise attributes assigned to the virtual representation by the user. The attributes may be inherited from (user) attributes of a digital identity of the user or may be created by the user or other entities. Attributes may be changeable and/or configurable by the user. Non limiting examples of attributes may be name, associated images, date of birth, etc. of the vir tual representation. Some attributes may be required to be verified by other entities and/or inherited from other entities, such as recommendations, accreditations, etc. Some attributes may be partially configurable and/or changeable only within predetermined and/or calculated ranges. Some attributes may be marked as private and/or null or otherwise not shown or available through the virtual representation. Interaction with a third party or other entities may be automated and/or regulated according to account characteristics.

The digital identity of the virtual representation may, for example, allow access to parts of computer systems and to services provided by the computer systems to be automated. For this purpose, the digital agent administers one or more digital identifiers. Such a digital identifier may be a code, sign, or token that, for example, comprises a string of characters which may be unique among all digital identifiers used for a certain purpose. The digital identifier “la bels” the digital identity of the virtual representation, for example, according to a certain scheme. It may inherently carry metadata along with it. The digital agent may operate a so- called digital wallet which may be a data storage solely controlled by the digital agent. The digital agent may store the digital identity of the virtual representation, corresponding digital identifiers, and methods for using those in the digital wallet.

Conventional digital identifiers used for identification of entities throughout computer net works may depend on a centralized identity management system controlled by a third party, such as a company or organization providing identity management services. A centralized identity management system may be a centralized information system used to manage the issued digital identifiers and the authentication, authorization, roles, and privileges of the cor responding digital identities. For example, the centralized identity management system may use a PKI (Public Key Infrastructure) which is a set of roles, policies, and procedures needed to create, manage, distribute, use, store and revoke digital identifiers and manage public key encryption. Centralized identity management systems have been deemed as secure since they often use professionally maintained hardware and software. Finally, when an entity needs to verify another entity’s digital identity, the verifying entity often needs to go through the cen tralized identity management system to obtain information verifying and/or authenticating the other entity’s digital identity. For instance, a traditional digital identifier may be a password allowing a user (entity) to perform certain transactions with a website, such as an internet forum. The password may be issued by an external authority operating the website or being commissioned by the website provider. The external authority may decide who or what the password identifies and when a usage of the password can be revoked. The password may be useful only in certain contexts and recognized only by certain bodies not of the user’s choos ing. The password might disappear or cease to be valid with a failure of the website provider. The password or metadata of the password might unnecessarily reveal personal information. In some cases, the password can be fraudulently replicated and asserted by a malicious third party, which is more commonly known as “identity theft”.

A decentralized identifier (DID) may be an alternative approach to conventional digital iden tifiers. DIDs may be a new type of digital identifier independent from any centralized registry, identity provider, or certificate authority. DIDs may be based on a self-sovereign identity (SSI) paradigm, meaning they may be designed to enable entities to generate their own digital identifiers and to “own” and control their personal data in the digital space. Thus, DIDs may be implemented independently of any centralized registry. A DID may be a simple text string comprising three parts: 1) a DID URL (Uniform Resource Locators) scheme identifier, 2) an identifier for a DID method, and 3) a DID method-specific identifier. DID methods may be a mechanism by which a particular type of DID and its associated DID document are created, resolved, updated, and deactivated according to a DID method specification. A simple exam ple of a DID may be did:example:123456789abcdefghi, wherein “did” may be the DID URL scheme identifier, “example” may be an identifier for a DID method, and “123456789abcdefghi” may be a DID method-specific identifier.

DIDs may be distinguished between private and public DIDs. Private individuals may usually use private DIDs (also known as peer, pairwise, pseudonymous, or pairwise-pseudonymous DIDs) that may be kept on their personal digital wallet. Private DIDs may be exchanged be tween the private individual and a third party to create a secure (end-to-end-encrypted) com munication channel that no third party is privy to. The secure communication channel does not rely on any central authority. The private individual may create as many separate private DIDs for as many separate secure communication channels as he/she sees fit to prevent cor relation of personal data. Otherwise, public DIDs may be used for when an entity wants to be publicly identifiable, e.g., in the case of companies or online platforms. Public DIDs may also be used for a virtual representation of a user according to some embodiments of the present disclosure. Such public DIDs may be stored on a public distributed ledger to provide access to the DID to any entity that may perform data transactions with the owner of the DID.

Fig. 1 illustrates a basic architecture 100 for DIDs. A DID 110 refers to any entity (DID subject 120) that a controller of the DID 110 (DID controller 130) decides that it refers to. In the context of the present disclosure, a virtual representation of a user may have a Self-Sov ereign Identity (SSI) and may be the DID controller 130. The user may also have an SSI which differs from the SSI of the virtual representation. The user may control his/her user DIDs which differ from the DID 110.

A DID 110 can use DID URLs 140 to associate the DID 110 with a DID document 150, extending the syntax of a basic DID 110 to incorporate other standard URL components such as path, query, and fragment in order to locate a particular resource, for example, a crypto graphic public key inside a DID document 150, or a resource external to the DID document 150. In the same manner URLs in the web may resolve to an IP-address (Internet Protocol), a DID URL 140 resolves to a DID document 150. DIDs 110 may allow trustable interactions associated with the DID subject 120 as the DID 110 as well as the DID document 150 may be recorded on a verifiable data registry 160. Non-limiting examples for a verifiable data registry 160 are distributed ledgers, decentralized file systems, decentralized databases of any kind, peer-to-peer networks, blockchains, and other forms of trusted data storage. For exam ple, if the DID subject 120 is a private individual, the DID 110 and DID document 150 may rather be recorded on a non-public verifiable data registry, such as a peer-to-peer network which may comprise a digital wallet of the DID controller 130 and/or a digital wallet of an other entity involved in a data transaction with the DID controller 130. If the DID controller 130 is a virtual representation of a user, some DID 110 and DID document 150 may be stored on a public verifiable data registry, thus, the virtual representation may be found by a third party by accessing the public verifiable data registry. In many cases, DID controller 130 and DID subject 120 may belong to the same entity. Since the generation and assertion of DIDs 110 is entity-controlled, each entity can have as many DIDs 110 as to maintain a desired separation of digital identities, digital personas, and interactions. The use of DIDs 110 can be scoped appropriately to different contexts. DIDs 110 may support interactions with other en tities via computer systems, when the interactions require a digital identification, and provide control over how much personal data should be revealed.

The DID document 150 may express a set of data, including attributes, describing the DID subject 120 as well as cryptographic material, verification methods, or service endpoints (core properties), which provide a set of mechanisms enabling a DID controller 130 to prove control of the DID 110 to the other entity. The cryptographic material may be used to prove certain aspects or attributes of a digital identity of the DID subject 120 by using a digital signature. A simple example of a DID document, that the above-mentioned example of DID may resolve to, may be:

{

"@context" : "https://www.example.did",

"id" : "did:example: 123456789abcdefghi",

"verificationMethod": [{

"id" : "did:example: 123#_QqOUL2Fq651QOFjd6TvnYE-faHiOpRlPVQcY_-tA4A", "type": "JsonWebKey2020",

"controller" : "did:example: 123 ",

"publicKeyJwk" : {

"crv": "Ed25519",

"x" : " VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQa03FxVeQ",

"kty": "OKP",

"kid" : "_QqOUL2Fq651 QOFj d6TvnYE-faHiOpRlP VQcY_-tA4 A"

}

}],

"credentialSubject": {

"id": "did:example:123",

"givenName": "JOHN",

"familyName": "SMITH",

"gender": "Male",

"image": "data:image/png",

"birthCountry": "Bahamas",

"birthDate": "1958-08-17"

},

}

In the example shown above, the DID document may comprise verification material. Verifi cation material is any information that is used by a process that applies a verification method. The type of a verification method may be expected to be used to determine its compatibility with such processes. The shown example uses publicKeyJwk as verification method type which may correspond to an IETF (Internet Engineering Task Force) specification. A verification suite may be responsible for specifying the verification method type and its asso ciated verification material. The publicKeyJwk may represent a public key as JSON (JavaS cript Object Notation) Web Key with an “Ed25519” curve. The curve’s “x” coordinates and key type parameter “kty” may be base64url-encoded values as shown. The verification method that uses JSON Web Keys may use the value of “kid” as key fragment identifier. Other types of verification methods may be used in other examples. Embodiments may not be restricted to a certain syntax or to certain properties of DID document.

A DID document may indicate a public key, as shown in the example above. The public key may be part of an asymmetric key pair according to public key cryptography, or asymmetric cryptography. The asymmetric key pair may comprise the public key which may be known to others, and private keys which may not be known by any except the owner. Effective se curity may require keeping the private key secret; the public key can be openly distributed without compromising security. Such asymmetric key pairs may be generated based on cryp tographic algorithms which may belong to mathematical problems termed one-way functions. A one-way function may be a function that is easy to compute on every input, but hard to invert given the image of a random input. Here, “easy” and “hard” may be understood in the sense of computational complexity theory, specifically the theory of polynomial time prob lems.

Public key algorithms may be fundamental security primitives in modern cryptosystems, in cluding applications and protocols which offer assurance of the confidentiality, authenticity and non-repudiability of electronic communications and data storage. Such cryptosystems may underpin numerous Internet standards, such as Transport Layer Security (TLS), S/MIME, PGP, and GPG. Some public key algorithms may provide key distribution and se crecy, e.g., Diffie-Hellman key exchange, some may provide digital signatures, e.g., Digital Signature Algorithm, and some may provide both, e.g., RSA.

In the example shown above, the DID document may also comprise attributes, such as “givenName”, “familyName”, “gender”. The attributes may belong to a DID subject, such as a virtual representation of a user. In this case, the attributes are part of a credential. The at tributes may be inherited from the user. In other embodiments, attributes may be created by the user, or created by a third party, or inherited from a third party. Fig. 2 illustrates a network node 200 associated with a virtual representation of a user accord ing to embodiments of the present disclosure. The network node 200 comprises memory 210 configured to store a decentralized identifier, DID, 110 of the virtual representation, a DID document 150 whereto the DID 110 resolves, and a private key 212 of an asymmetric key pair associated with the DID 110, the DID document 150 indicating at least one attribute 250 assigned to the virtual representation by the user and a public key 252 of the asymmetric key pair. The network node 200 further comprises a first interface 220 configured to send the private key 212 to a network node 230 associated with the user.

The memory 210 may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Digital storage devices may use semiconductor-based integrated circuit chips. Data may be stored in metal -oxide-semiconductor (MOS) memory cells. Digital stor age devices chip may comprise volatile memory (e.g., RAM), nonvolatile memory (e.g., ROM, PCMCIA cards, and so forth), or a combination thereof. An operating system may be resident in the memory. The first interface 220 may relate to software, computer hardware, peripheral electronic devices, and combinations thereof which may provide a shared boundary across which two or more computer systems or separate components of a computer system exchange information.

The network node 200 may comprise a digital agent which may handle a digital identity of the virtual representation. The digital identity may comprise the attributes 250 of the virtual representation assigned by the user. The user may assign the attributes 250 when the virtual representation is created and/or may change the attributes 250 or assign more attributes to his/her liking. The network node 200 associated with the virtual representation may be con trolled by the network node 230 associated with the user and may perform data transactions on behalf of the user. The DID 110 may be a kind of digital identifier. The DID 110 may label the digital identity of the virtual representation. The private key 212 and the public key 252 may belong to a cryptosystem for asymmetric cryptography. The first interface 220 may send the private key 212 to the network node 230 associated with the user when the virtual repre sentation is created or when requested by the user. The network node 200 of the virtual rep resentation may copy the private key 212 and the first interface 220 may communicate the copy via a (secure) communication channel to the network node 230 associated with the user. The network node 230 associated with the user may comprise memory to store the private key 212. The private key 212 may be used for proving an ownership of the virtual represen tation. In this manner, the user may use the virtual representation as anonymous identity with out directly exposing his/her digital identity. The user may use the virtual representation to create and manage accounts on online platforms. The creation of the accounts may be auto mated, optionally according to a configuration made by the user. The accounts may incorpo rate the attributes 250, some of the attributes 250 or data derived from the attributes 250.

Fig. 3 illustrates other embodiments of a network node 200 associated with a virtual repre sentation of a user. The network node 200 may further comprise a second interface 310 con figured to register the DID 110 and the DID document 150 on a distributed ledger 320. The DID 110 may be unique among a plurality of DIDs stored on the distributed ledger 320. This may be advantageous as the network node 200 may then be unambiguously identified by the DID 110.

The distributed ledger 320 may be any distributed data registry, e.g., ablockchain, decentral ized file systems, decentralized databases of any kind, peer-to-peer networks, or trusted data storage. The distributed ledger 320 may comprise sections or blocks 322, 324, 326, etc., which may comprise a record, such as the DID 110 and the DID document 150. The distributed ledger 320 may represent a growing list of sections. The distributed ledger 320 may be veri fiable in a way that if a section of ledger is altered, all subsequent sections of ledger are al tered. In the case of a blockchain, a section may comprise the DID 110 and the DID document 150, a 32-bit whole number called a nonce, and a 256-bit number (a hash) wedded to the nonce. The nonce is randomly generated when a section is created, which then generates a section header hash. In a blockchain, every section may have its own unique nonce and hash, but also references the hash of the previous section in the chain. So, mining a section (creating a new section) may be time-consuming, especially on large blockchains. Mining may require special software to solve the complex mathematical task of finding a nonce that generates an accepted hash. When the length of the nonce is 32 bits and the length of the hash is 256 bits, there may be roughly four billion possible nonce-hash combinations that may be mined before a suitable combination is found. Making a change to any section earlier in the blockchain may require “re-mining” not only the one block, but also the subsequent blocks. The network node 200 may therefore comprise special software to register the DID 110 and DID document 150 on the distributed ledger 320 according to requirements of the distributed ledger 320. If the distributed ledger 320 is publicly reachable, the virtual representation may be reachable for other entities having access to the distributed ledger 320.

According to embodiments of the present disclosure, the first interface 230 of the network node 200 may further be configured to provide a proof-of-possession of the virtual represen tation to the network node 230 associated with the user, the proof-of-possession indicating that the network node 230 associated with the user has the private key 212. The proof-of- possession may prove the ownership of the virtual representation. The proof-of-possession may be a credential issued by the network node 200 of the virtual representation. The network node 230 associated with the user may receive and store the proof-of-possession and may use it to present it to a third party when requested. The proof-of-possession may be a set of data created by the network node 200 of the virtual representation.

Fig. 4 illustrates a concept for providing a proof-of-possession. A first interface 220 of a net work node 200 associated with a virtual representation of a user may be configured to provide a random challenge 410 to a network node 230 associated with the user. The random challenge 410 may comprise a randomly produced string. The first interface 220 may further be config ured to encrypt the random challenge 410 by applying the public key 252, yielding an en crypted challenge 420. The first interface 220 may further be configured to send the encrypted challenge 420 to the network node 230 associated with the user and receive a decrypted chal lenge 430 from the network node associated with the user. The decrypted challenge 420 may be the encrypted challenge 420 decrypted by applying the private key 212. The first interface 220 may further be configured to compare the decrypted challenge 430 with the random chal lenge 410. The first interface 220 may further be configured to generate a proof-of-possession 440 if the random challenge 410 matches the decrypted challenge 430. The network node 200 associated with the virtual representation may therefore comprise software suitable for en crypting the random challenge 410 based on the public key 252.

Fig. 5 illustrates a network node 200 of a virtual representation of a user according to other embodiments of the present disclosure. The network node 200 may further comprise a third interface 510 configured to send the DID 110 to a network node 520 associated with a third party. The third party may be any entity the network node 200 of the virtual representation seeks to perform data transactions with. The third party may be, for example, an online plat form, a website, a social network, a company, another user, a virtual representation of another user.

For instance, by sending the DID 110 to the network node 520 associated with an online platform the virtual representation may create an account on the online platform. The network node 520 of the online platform may therefore look up on a distributed ledger, such as dis tributed ledger 320, a DID document 150 corresponding to the DID 110. The DID document 150 may indicate attributes 250 assigned to the virtual representation. The attributes 250 may be (partially) disclosed to the network node 520 associated with the online platform to create the account and to authenticate the virtual representation when the virtual representation pre forms data transactions on the online platform on behalf of the user.

Alternatively, when the third party may be another user or a virtual representation of the other user, the network node 200 of the virtual representation may selectively disclose attributes 250, such as a communication endpoint, which enable the other user or the virtual represen tation of the other user to establish a communication channel between the network node 200 and the network node 520. Alternatively or additionally, the network node 200 may further send to the network node 520 associated with the third party the DID document 150, for ex ample, if the DID document 150 was not registered on the distributed ledger 320, e.g., to keep the DID document 150 private. Alternatively or additionally, the third interface 510 may be configured to send messages from the network node 230 associated with the user to the net work node 520 associated with the third party and/or messages from the network node 520 associated with the third party to the network node 230 associated with the user. Therefore, the third interface 510 may receive messages from the network node 230 associated with the user and forward the messages to the network 520 associated with the third party, and vice versa. In this manner, the user may be able to anonymously send messages via his/her virtual representation to the third party and the third party may be able to contact the user without knowing his/her digital or real identity. Alternatively or additionally, the third interface 510 may be configured to send a proof-of-possession of the virtual representation to the network node 520 associated with the third party, the proof-of-possession indicating that the network node 230 associated with the user has the private key 212. For instance, upon a request of the network node 520 associated with the third party, the user may prove that he/she “owns” the virtual representation. The proof-of-possession may therefore comprise a digital signature of the virtual representation and a user DID or other data authenticating the user. Alternatively or additionally, the third interface 510 may be configured to send at least one user attribute associated with a user DID to the network node 520 associated with the third party. The user DID may be associated with the network node 230 of the user. For instance, the network node 200 associated with the virtual representation of the user may disclose user attributes, such as the user’s name or age, to the network node 520 associated with the third party.

Alternatively or additionally, the third interface 510 may be configured to prove an authen ticity of the at least one user attribute by providing a zero-knowledge-proof to the network node 520 associated with the third party, the zero-knowledge-proof indicating that the net work node 200 associated with the virtual representation knows a credential associated with the user DID, the credential proving an authenticity of the at least one user attribute. For instance, a (digital) credential of the user’s passport issued by a governmental authority may be coupled to the user DID. If the user does not allow disclosing his/her user DID, the zero- knowledge-proof may still prove the authenticity of the user attribute, such as name of the user, confirmed by the credential. A zero-knowledge-proof may be a computer-implemented protocol. The protocol may response to an interactive input of the network node 520 associ ated with the third party which may want to verify the user attribute. The interactive input may comprise one or more challenges such that the protocol may convince the network node 520 that the user attribute is authentic, i.e., the network node 200 associated with the virtual representation knows the credential proving the user attribute.

Alternatively or additionally, the third interface 510 may be configured to send a credential associated with the user DID to the network node 520 associated with the third party, the credential being verified by an issuer. The issuer may be a trusted entity, such as a govern mental authority. The credential may be verified by the issuer with a digital signature of the issuer. The issuer may provide the credential to the network node 230 associated with the user which may send the credential to the network node 200 associated with the virtual represen tation. The issuer may, additionally or alternatively, provide the credential directly to the net work node 200 associated with the virtual representation if the network node 230 associated with the user provides a proof-of-possession of the virtual representation to the issuer.

Optionally, the network node 200 shown in fig. 5 may further comprise a second interface as shown in fig. 3 or fig. 4. For sending the DID 110, messages, user attributes, etc. to the network node 520 associated with the third party, the network node 200 associated with the virtual representation may use a secure communication channel according to an approach shown in fig. 6. Fig. 6 illustrates a concept for establishing a secure communication channel. For example, a network node 520 associated with a third party may have stored a DID 610 associated with the third party and a corresponding DID document 620 in a section 326 of a distributed ledger 320. A network node 200 associated with the virtual representation may retrieve the DID 610 associated with the third party, for example, from a website of the third party and look up the corresponding DID document 620 in the section 326 of the distributed ledger 320. The DID document 620 may comprise an endpoint of the network node 520 and a public key 622 of an asymmetric key pair of the network node 520. The network node 200 may store the DID document 620 on a computer data storage. The network node 200 may then encrypt a data packet comprising public key 252 of the network node 200, an endpoint of the network node 200, and data, such as the DID 110, messages, user attributes, etc., based on the public key 622. The network node 200 may then send the encrypted data packet to the endpoint of the network node 520. As the network node 520 associated with the third party has a private key 624 corresponding to the public key 622, the network node 520 may be able to decrypt the data packet and re trieve the public key 252, the endpoint of the network node 200 and the data. The network node 520 may use the endpoint and the public key 252 of the network node 200 to encrypt and send a response to the network node 200. The network node 520 may store the data packet on a computer data storage for future data transactions. In this manner, the network node 200 associated with the virtual representation and the network node 520 associated with the third party may establish an end-to-end encrypted secure communication channel. The network node 200 associated with the virtual representation may only disclose as many attributes or user attributes according to the user’s permission/configuration.

Optionally, the concept of fig. 6 may likewise be used for a secure communication channel between the network node 200 associated with the virtual representation and the network node 230 associated with the user.

To summarize, a virtual representation of a user, also designated as “Public Self-Sovereign Identity Avatar”, may be managed by a self-sovereign identity of the user. It may be looked up publicly without revealing the self-sovereign identity of the user. The user may prove the ownership of the avatar. The “Public Self-Sovereign Identity Avatar” may meet the following requirements:

They can be looked up publicly: they have a public DID.

They may not be able to reveal private information about the self-sovereign identity of the user, but may be able to disclose information about the self-sovereign identity of the user, retrieved from credentials in the possession of the self-sovereign identity of the user.

They may function as “real” self-sovereign identities in the SSI ecosystem, i.e., they may act independently of the self-sovereign identity of the user, so, they may be thought of “alter egos” of the self-sovereign identity of the user.

They are owned by a legitimate self-sovereign identity who can prove ownership with out revealing private information.

“Public self-sovereign identity avatars” can be used and owned by self-sovereign iden tities with public or private DIDs.

A self-sovereign identity can own and use one or more “Public Self-Sovereign Identity Avatars”.

A “Public Self-Sovereign Identity Avatar” may be created by registering a public DID and DID document on a distributed ledger and associating it with one or more public keys. A copy of corresponding private key(s) may be in the possession of the self-sovereign identity of the user. A “Public Self-Sovereign Identity Avatar” can issue an ownership credential to the self sovereign identity of the user. By doing so, the self-sovereign identity of the user can now proof that the user may be the person behind the avatar. By using this credential, the self sovereign identity of the user may generate a zero-knowledge proof and selectively disclose user attributes to his liking, hence, expose an identity of the user to the degree of the user’s liking. A “Public Self-Sovereign Identity Avatar” cannot buy or obtain verifiable credentials that do require personal information of the self-sovereign identity of the user because that may reveal the self-sovereign identity. However, a self-sovereign identity of the user may request a verifiable credential on behalf of the avatar as the self-sovereign identity of the user can proof ownership of the avatar. Such verifiable credentials can be used by the “Public Self- Sovereign Identity Avatar” to create certain proofs while still deciding on the degree of se lectively disclosing (user) attributes of the user’s self-sovereign identity.

Possible advantages of the invention: Current websites can deal with the “Public Self-Sovereign Identity Avatar” the same way they do for conventional self-sovereign identities.

A self-sovereign identity can have multiple “Public Self-Sovereign Identity Avatars”. “Public Self-Sovereign Identity Avatars” may facilitate creating anonymous digital identities.

A “Public Self-Sovereign Identity Avatar” can relay messages and data back to the self-sovereign identity of the user in privacy. The other way round, may also be pos sible.

“Public Self-Sovereign Identity Avatars” may be unique and publicly reachable. “Public Self-Sovereign Identity Avatars” can be used in situations where conventional avatars may be used today but they may not be restricted or bound to a specific web site.

“Public Self-Sovereign Identity Avatars” may especially be useful for gamers. “Public Self-Sovereign Identity Avatars” may act as “alter ego” of the user, i.e., it may stand on its own and may be considered as own self-sovereign identity.

Note that the present technology can also be configured as described below.

(1) A network node associated with a virtual representation of a user, comprising: memory configured to store a decentralized identifier, DID, of the virtual rep resentation, a DID document whereto the DID resolves, and a private key of an asym metric key pair associated with the DID, the DID document indicating at least one attribute assigned to the virtual representation by the user and a public key of the asymmetric key pair; a first interface configured to send the private key to a network node associated with the user.

(2) The network node of (1), further comprising a second interface configured to register the DID and the DID document on a distributed ledger.

(3) The network node of (2), the DID being unique among a plurality of DIDs stored on the distributed ledger. (4) The network node of one of (1) to (3), the first interface further being configured to provide a proof-of-possession of the virtual representation to the network node asso ciated with the user, the proof-of-possession indicating that the network node associ ated with the user has the private key.

(5) The network node of (4), the first interface further being configured to provide a random challenge to the network node associated with the user, the random challenge comprising a randomly produced string; encrypt the random challenge by applying the public key, yielding an en crypted challenge; send the encrypted challenge to the network node associated with the user; receive a decrypted challenge from the network node associated with the user, the decrypted challenge being the encrypted challenge decrypted by applying the pri vate key; compare the decrypted challenge with the random challenge; and generate the proof-of-possession if the random challenge matches the de crypted challenge.

(6) The network node of one of the previous examples, further comprising a third interface configured to send the DID to a network node associated with a third party.

(7) The network node of (6), the third party being at least one of an online platform, a website, a social network, a company, another user, a virtual representation of another user.

(8) The network node of one of (6) or (7), the third interface further being configured to send messages from the network node associated with the user to the network node associated with the third party and/or messages from the network node associated with the third party to the network node associated with the user.

(9) The network node of one of (6) to (8), the third interface further being configured to send a proof-of-possession of the virtual representation to the network node associated with the third party, the proof-of-possession indicating that the network node associ ated with the user has the private key.

(10) The network node of one of (6) to (9), the third interface further being configured to send at least one user attribute associated with a user DID to the network node associated with the third party, the user DID being associated with the network node of the user; provide a zero-knowledge-proof to the network node associated with the third party, the zero-knowledge-proof proving an authenticity of the at least one user attrib ute.

(11) The network node of (10), the third interface further being configured to send a cre dential associated with the user DID to the network node associated with the third party, the credential being verified by an issuer.

(12) Method for providing a virtual representation of a user, the method comprising: storing a DID, a DID document, and a private key of an asymmetric key pair on a memory associated with the virtual representation, the DID being associated with the virtual representation and resolving to the DID document, the DID document in dicating at least one attribute assigned to the virtual representation by the user and a public key of the asymmetric key pair; and sending the private key to a network node associated with the user.

(13) Method for using a virtual representation of a user provided by the method according to (12) for performing data transactions on behalf of the user.

The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example. Examples may further be or relate to a (computer) program including a program code to exe cute one or more of the above methods when the program is executed on a computer, proces sor or other programmable hardware component. Thus, steps, operations or processes of dif ferent ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or com puter-readable and encode and/or contain machine-executable, processor-executable or com puter-executable programs and instructions. Program storage devices may include or be dig ital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPEi), ap plication-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

It is further understood that the disclosure of several steps, processes, operations or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execu tion of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process or operation may include and/or be broken up into several sub-steps, - functions, -processes or -operations.

If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.

The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not intended. Further more, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

(2) The network node of claim (1), further comprising a second interface configured to register the DID and the DID document on a distributed ledger.

(3) The network node of claim (2), the DID being unique among a plurality of DIDs stored on the distributed ledger.

(4) The network node of claim (1), the first interface further being configured to provide a proof-of-possession of the virtual representation to the network node associated with the user, the proof-of-possession indicating that the network node associated with the user has the private key.

(5) The network node of claim (4), the first interface further being configured to provide a random challenge to the network node associated with the user, the random challenge comprising a randomly produced string; encrypt the random challenge by applying the public key, yielding an en crypted challenge; send the encrypted challenge to the network node associated with the user; receive a decrypted challenge from the network node associated with the user, the decrypted challenge being the encrypted challenge decrypted by applying the pri vate key; compare the decrypted challenge with the random challenge; and generate the proof-of-possession if the random challenge matches the de crypted challenge.

(6) The network node of claim (1), further comprising a third interface configured to send the DID to a network node associated with a third party.

(7) The network node of claim (6), the third party being at least one of an online platform, a website, a social network, a company, another user, a virtual representation of an other user.

(8) The network node of claim (6), the third interface further being configured to send messages from the network node associated with the user to the network node associ ated with the third party and/or messages from the network node associated with the third party to the network node associated with the user.

(9) The network node of claim (6), the third interface further being configured to send a proof-of-possession of the virtual representation to the network node associated with the third party, the proof-of-possession indicating that the network node associated with the user has the private key.

(10) The network node of claim (6), the third interface further being configured to send at least one user attribute associated with a user DID to the network node associated with the third party, the user DID being associated with the network node of the user; provide a zero-knowledge-proof to the network node associated with the third party, the zero-knowledge-proof proving an authenticity of the at least one user attrib ute.

(11) The network node of claim (10), the third interface further being configured to send a credential associated with the user DID to the network node associated with the third party, the credential being verified by an issuer.

(12) Method for providing a virtual representation of a user, the method comprising: storing a DID, a DID document, and a private key of an asymmetric key pair on a memory associated with the virtual representation, the DID being associated with the virtual representation and resolving to the DID document, the DID document indicat ing at least one attribute assigned to the virtual representation by the user and a public key of the asymmetric key pair; and sending the private key to a network node associated with the user.

(13) Method for using a virtual representation of a user provided by the method according to claim (12) for performing data transactions on behalf of the user.