METALIFE™ IDENTITY

Identity is one of the cornerstones for social trust. As a decentralized social platform, MetaLife uses DID (Decentralized Identity) technology to build a trust framework. In additional, to address the colorful and multi-dimensional existence in metaverse, MetaLife identity will embrace diversity and inclusiveness. In order to reflect differences and compatible with social networking and application scenarios, we created five types of social DIDs:

1. Trusted social user identity (including Pub) – provides users with decentralized authentication of identity authenticity (DID basic function)

2. Value NFT – Items with creative value and uniqueness, such as artwork, music, and article copyright, physical or virtual can all be tagged with identity and proof of authenticity to generate derivative value, just as in the physical world, where precious collectables like jade, jewely, limited wine production all come with anti-counterfeiting certificates and collection value.

3. DAO – Although social DAO is a loose structure in the MetaLife ecosystem, it is an indispensable real existence in interaction. DAO's behavior also needs trust endorsement, and DAO and DAO also need to be interactively verified to prevent Collusion and fraud.

4. Metaverse virtual character – Different from traditional social interaction, the social objects in the meta-universe may be characters in the game, artificial intelligence robots, virtual avatars of stars, etc., as the trust endorsement of brand value, giving the characters emotions and emotions. Interactive experience.

5. Pan-social IoT device – Personalized IoT devices owned by users (such as body monitoring sensors, security monitoring sensors, etc.) are tagged with ID to provide private data to relevant agencies in the form of authorized access for applications like telemedicine, remote alert and other interactive and personalized services.

Framework for Social DID

The social DID framework includes mainly social DID theme, DID controller, DID (DID URL), DID document, authenticity registration and authentication (blockchain, social platform), external resources (external credentials, cloud and edge storage).

Social DID Basic Framework and Relationship

Single Control Mode

Group Control Mode

DID and DID URL – A decentralized identifier or DID is a simple text string that consists of three parts: (1) the URL scheme identifier (did), (2) the identifier for the DID method, and (3) the DID method-specific identifier. MetaLife DID will be designed according to W3C DID framework.

DID Subject – The entity identified by a DID and described by a DID document. It may also be a DID controller, individual, group, organization, physical, digital or logical thing, and concepts can all be themes. In this solution, it refers to the five themes of social classification.

DID Document – A set of data describing the DID subject, including mechanisms such as cryptographic public keys that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID.

DID Controller – An entity (person, organization, or autonomous software) that has the capability (as defined by the DID method) to make changes to a DID document. A DID might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that a DID controller might be the DID subject.

Verifiable Data Registration – A system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents. MetaLife chain and MetaLife social platform is the underlying network to record, and parse DID into DID documents.

External Resources – refer to vendors that provide device certificates to DID, and cloud and edge servers that provide storage services for DID.

Use Cases and Process Flow

The use case and process of DID application in the social platform based on composition of the above framework and the overall relationship is shown as follow:

The actors in the process flow are as follow:

Issuer – the task of issuing DID is to be completed by the DID controller, which can be a user or a related social DAO.

Holder – the holder refers to the owner of DID, which could be one of the five types of social DID described above.

Verifier – An individual or organization that has access to social DID related information when using DID.

DID registration system – A place where DID identification and DID documents are stored, and DID documents can be queried through DID identification.

Use Case 1 – User social DID Registration and Process

Description: Alice is a MetaLife user and is willing to register for an DID as a trusted member of the platform so that she can participate in various activities organized by the platform and third party (e.g., a game DApp). While accessing one of DApp, the DApp requests for verification of Alice's registration. Upon completion of verification, incentive is issued to Alice so that she can participate in the game to start earning.

The process is as follow:

1. Alice uses metaLife App to generate a DID and DID document

2. MetaLife App uploads Alice’s DID and DID document to MetaLife blockchain for certification (send to MetaLife platform at the same time)

3. MetaLife platform generates the Verifiable Credential (VC) based on Alice's DID and registration information, and sends it to Alice (also distributes MLT to Alice as incentive to getting her identity registered)

4. Alice submits VC to the requestor (e.g., 3rd party game DApp)) for verification

   1. Obtain Issuer’s DID of the issuer from the creator of proof and confirm that it is the platform

   2. Query DID document on the blockchain

   3. Verify whether it is a trusted DID, a valid signature, and whether it is consistent with VC

   4. Verification passed, token issued to Alice and she is allowed entrance to the game and start play-to-earn

Use Case 2 – NFT DID Registration and Process

Description: Charlie is a painter; he has created a new digital artwork and wishes to tokenize it into an NFT for trading or stake (fragmented). For copyright and anti-counterfeiting considerations Charlie registers a DID for this artwork. Prospective purchasers can check for authenticity using the DID prior to purchase.

The process is as follows:

1. Charlie creates an artwork and generates a DID and DID document for it

2. Charlie mints a NFT for his artwork and uses its DID as one of the attributes in NFT

3. Charlie uploads the DID and DID document to MetaLife blockchain for certification (send to the platform at the same time)

4. The platform generates VC based on NFT's DID and registration information, and sends it to Charlie

5. Charlie sends VC to prospective purchaser Jenny for verification

6. Verification is passed and transaction is completed

Use Case 3 – Pan-social Internet of Things Device Registration and Process

Description: Bob is an elderly person with mobility impairment. He installs a smart detection device in his room to regularly measure his body state (body temperature, blood pressure, etc.). In order to receive remote medical assistance, Bob registers an DID for the smart device and authorizes medical authority to access data for health diagnosis.

The process is as follows:

1. Bob obtains verifiable credential (VC) of the monitoring device from its equipment manufacturer (external source), and use MetaLife App to generate a DID and DID document for the device (VC is added in the DID document)

2. Bob uploads DID of the monitoring device to MetaLife blockchain for storage and uploads DID document to cloud service for storage. Data from the monitoring device is uploaded regularly to the cloud server and accessibility is authorized by DID (authorization mechanism is defined in smart contract)

3. Medical authority registers the DID on blockchain to call the operation of processing Bob’s DID device data and save it to the platform at the same time

4. The medical institution requests access to Bob's monitoring data. Bob authorizes the medical institution to access the device DID document URL in the smart contract to obtain the data access token. The medical institution accesses the detection data stored in the cloud server and provides remote medical services.

Classification Storage Mechanism for DID

According to the above use cases and the nature and voluminous number of identities, two storage mechanisms are used. DIDs and documents related to entity identities are stored on the MetaLife blockchain for inquiry and verification by verifiers. DIDs for devices are stored on blockchain and the corresponding DID documents and collected data are stored on cloud and edge storage servers, and the two are associated and interactively accessed through smart contracts.