DID decentralized digital identity

Posted by autumn on Sat, 18 Dec 2021 14:04:25 +0100

DID decentralized digital identity

identity

The International Electronic Technology Commission defines "identity" as "a set of attributes associated with an entity". The entities here are not only people, but also machines or objects. Even virtual things in the network can also be entities and have identities.

Digital identity

With the emergence and popularization of the Internet, traditional identity has another form of expression, that is, digital identity. It is generally believed that the evolution of digital identity has experienced four stages: centralized identity, alliance identity, user-centered identity and self sovereignty identity.

Centralized identity is managed and controlled by a single authority. Now most identities on the Internet are still centralized identity.
The emergence of alliance identity solves the disadvantage of fragmented and chaotic identity data in centralized identity. This identity is managed and controlled by multiple institutions or alliances. The user's identity data has a certain degree of portability. For example, when allowing users to log in to a website, they can use the account information of other websites, similar to QQ Cross platform login of wechat or microblog.
User centered identity will focus on decentralization and share identity data through authorization and licensing, such as OpenID.
Self sovereignty identity is truly decentralized and completely owned and controlled by individuals.

PKI system

The abbreviation of Public Key Infrastructure is translated as Public Key Infrastructure, Its main function is to bind the identity of the certificate holder and related key pairs (by issuing digital certificates for public keys and related user identity information), provide users with convenient ways of certificate application, certificate cancellation, certificate acquisition and certificate status query, and make use of digital certificates and related services (certificate publishing, blacklist publishing, timestamp service, etc.) realize the identity authentication, integrity, non repudiation and confidentiality of each entity in the communication. The center of the PKI system is the CA server, which must be secure and trusted. The main carrier is the certificate file in X509 format. You can refer to the PKI system https://blog.csdn.net/lk2684753/article/details/100160856

DID

Decentralized IDentity decentralized identity, referred to as DID, compared with the traditional PKI based identity system, the DID digital identity system based on blockchain has the characteristics of ensuring data authenticity, protecting user privacy and security, and strong portability. Its advantages are:

Decentralization: Based on blockchain, identity data is prevented from being controlled by a single centralized authority.
Self controllable identity: Based on DPKI (distributed public key infrastructure), the identity of each user is not controlled by a trusted third party, but by its owner. Individuals can independently manage their own identity.
Trusted data exchange: identity related data is anchored on the blockchain, and the authentication process does not need to rely on the application providing the identity.

DID identification

DID identification is a string in a specific format, which is used to represent the digital identity of an entity, where the entity can be human, machine and object. The format of DID identification is:

Prefix did: is fixed, indicating that this string is a did identification string.
The middle example is called DID method, which is used to indicate which scheme (method) is used to define and operate the DID ID. this DID method can be customized and registered on the W3C website( https://w3c.github.io/did-spec-registries/#did-methods).
The last part is the unique identification string under the DID method. For example, we have built a DID system. Let's call the method cid. If we want to do the ID card information of Chinese citizens, my DID logo is:
did:cid:411424**************0
Here we use the ID number as the only identification under the DID method of cid.

DID document

Each DID ID corresponds to a DID Document. This document is a JSON string, which generally contains the following information:

DID document content
describe
DID topic
The DID identifier itself, that is, the DID described in the DID document. Due to the globally unique nature of DID, there can only be one DID in a DID document.
Public key
Public key is used for digital signature and other encryption operations, which are the basis for authentication and establishing secure communication with service endpoints. If the public key does not exist in the DID document, it must be assumed that the key has been revoked or invalid, and the revocation information of the key (for example, revocation list) must be included or referenced.
Authentication
The process of authentication is the process by which DID topics prove their association with DID by encryption.
to grant authorization
Authorization means that others perform operations on behalf of the DID subject. For example, when the key is lost, they can authorize others to update the DID document to assist in recovering the key.
Service Endpoint
In addition to publishing authentication and authorization mechanisms, another main purpose of DID documents is to discover service endpoints for topics. Service endpoints can represent any type of service that the subject wants to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction.
time stamp
Document creation time and update time

The above information is not required, but we generally recommend including it. Let's take a specific DID document example:

{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
// DID identification corresponding to this DID document
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
//Public key information corresponding to this DID
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}],
"service": [{
// Obtain the service interface of the VC corresponding to this DID
"id":"did:example:123456789abcdefghi#vcs",
"type": "VerifiableCredentialService",
"serviceEndpoint": "https://example.com/vc/"
}]
}

The most important thing in the DID document is the public key information, which is the basis for our next VC and VP verification.

We generally take the DID ID as the Key and store the DID document as the Value in the blockchain. We can quickly access and obtain trusted data during authentication by using the characteristics of tamper proof and shared data access of the blockchain.

Verifiable certificate / verifiable statement (VC)

(Verifiable Claims or Verifiable Credentials, hereinafter referred to as VC) is a descriptive statement issued by a DID endorsing some attributes of another DID and attaching its own digital signature to prove the authenticity of these attributes, which can be regarded as a digital certificate.
The traditional PKI digital certificate system requires CA to issue, and DID is also divided into issuer, holder, verifier and DID registration system (i.e. blockchain). The specific relationship is shown in the figure:

Issuer is the certificate issuing organization. For example, the ID card is issued by the public security organ, and the graduation certificate is issued by the University.
Holder is the holder of the certificate, just us ordinary people.
The Verifier is the person or organization that checks our certificate when we use it. For example, when we stay in a hotel, the front desk needs to verify our ID card, so the front desk of the hotel is the Verifier; For another example, when we join a new company, we need to provide a university diploma, and the HR of the new company is the Verifier.
The DID registration system Verifiable Data Registry is where we store the DID ID and DID documents. The corresponding DID documents can be queried through the DID ID.

When the public security organ issued me an ID card, in DID, this ID card is VC. A VC is also a JSON string, which contains the following information:

VC metadata mainly refers to the issuer, release date, declaration type and other information.
Declaration, one or more descriptions of the subject. For example, as a VC issued to me by the public security organ, the ID card will contain: name, gender, date of birth, nationality, address and other information in the statement.
Proof, usually the issuer's digital signature, ensures that the VC can be verified, prevents the VC content from being tampered with and verifies the issuer of the VC.

The following is a specific example of VC officially given:

{
  // JSON-LD standard followed by VC content
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // The unique ID of this VC, that is, the certificate ID
  "id": "http://example.edu/credentials/1872",
  // Format of VC content
  "type": ["VerifiableCredential", "AlumniCredential"],
  // Issuer of this VC
  "issuer": "https://example.edu/issuers/565049",
  // Date of issuance of this VC
  "issuanceDate": "2010-01-01T19:73:24Z",
  // Specific contents of VC statement
  "credentialSubject": {
    // DID of the declared person
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    // Declared assertion content
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  // Proof of this VC
  "proof": {
    // signature algorithm 
    "type": "RsaSignature2018",
    // Signature creation time
    "created": "2017-06-18T21:19:10Z",
    // Purpose of this certificate
    "proofPurpose": "assertionMethod",
    // The ID of the public key that verifies this signature
    "verificationMethod": "https://example.edu/issuers/keys/1",
    // Contents of digital signature
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

Because VC has the user's privacy information, VC is generally stored in private storage, such as the user's own mobile phone or the network address that needs authorization. In addition to the data given in the previous example, our VC can also have an expiration date. For example, our ID card is generally valid for 10 years. After expiration, we need to re apply to the issuer for a new VC.

Verifiable expression (VP)

Verifiable presentation is referred to as VP for short. Verifiable expression is the data that the VC holder lists his own identity to the verifier. Generally, we can show the full text of the VC directly, but in some cases, for the sake of privacy protection, we do not need to show the complete VC content. We only want to selectively disclose some attributes, or do not disclose any attributes, and only need to prove a certain assertion.

Name ID number and name of a registered office building, but our VC also contains information about nationality and address. Our job seekers do not want to expose their address to security. Therefore, the VP provided to security personnel should only be selectively disclosed ID number and name, and other information will not be disclosed.
For another example, we stipulate that a consumer must be at least 18 years old before he is eligible to buy cigarettes, so a consumer must prove that he is at least 18 years old when buying cigarettes, but showing his ID card directly to the cashier will expose too much private information. Even if the birthday attribute is selectively disclosed, the cashier will know the specific age and birthday date of the consumer, In this case, consumers only want to prove that they are over 18 years old in the VP, and no other information can be exposed.

The format of VP is:

VP metadata mainly includes version, type of this JSON object and other information
VC list, the content of VC to be displayed to the public. If it is selective disclosure or privacy protection, it may not contain any VC.
Proof mainly refers to the signature information of the holder on this VP

The following is an official example of a specific VP:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  // VC content included in this VP
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://example.edu/credentials/1872",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "issuer": "https://example.edu/issuers/565049",
    "issuanceDate": "2010-01-01T19:73:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": [{
          "value": "Example University",
          "lang": "en"
        }, {
          "value": "Exemple d'Université",
          "lang": "fr"
        }]
      }
    },
    "proof": {
      "type": "RsaSignature2018",
      "created": "2017-06-18T21:19:10Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "https://example.edu/issuers/keys/1",
      "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
        sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
        X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
        PAYuNzVBAh4vGHSrQyHUdBBPM"
    }
  }],
  // Holder's signature information on this VP
  "proof": {
    "type": "RsaSignature2018",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
    // challenge and domain are designed to prevent replay attacks
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
  }
}

Use process of DiD

Scene description

Xiaoming is a fresh graduate who has just graduated from university. On the day of graduation, the school issued the graduation certificate to Xiaoming's corresponding digital identity. Xiaoming went to the company for employment the next day after he got the graduation certificate. In one link, the company's HR required to verify Xiaoming's academic information. After verification, Xiaoming was successful in employment.

Generally, the school will issue graduation certificate and degree certificate. For simplicity, let's ignore the degree certificate

Step 1: Xiao Ming generates DID identification and DID document

Xiao Ming must have his own did if he wants to obtain the graduation certificate issued by the school, so he first downloads a digital identity mobile app and then creates an account. The process of creating an account is to generate a random private key and the corresponding public key in the mobile phone. Here we assume that our DID identification rule is "did:cid: ID number", so Xiaoming entered its ID number in APP, and produced a DID logo:

did:cid:511112200001010015

A DID document will also be generated as follows:

{
"@context": "https://w3id.org/did/v1",
"id": "did:cid:511112200001010015",
"version": 1,
"created": "2020-12-08T16:02:20Z",
"updated": "2020-12-08T16:02:20Z",
"publicKey": [
{
"id": "did:cid:511112200001010015#keys-1", "type": "Secp256k1", "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71" },
{ "id": "did:cid:511112200001010015#keys-2", "type": "Secp256k1", "publicKeyHex": "e3080168ee293053ba33b235d7116a3263d29f1450936b71" } ],
"authentication": ["did:cid:511112200001010015#key-1"],
"recovery": ["did:cid:511112200001010015#key-2"],
"service": [
{
"id": "did:cid:511112200001010015#resolver", "type": "DIDResolve", "serviceEndpoint": "https://did.studyzydemo.com" } ],
"proof": {
"type": "Secp256k1", "creator": "did:cid:511112200001010015#keys-1", "signatureValue": "QNB13Y7Q9...1tzjn4w==" } }

Here, we set two public keys for the DID. One is Xiaoming's own, which is used for authentication and signature. Key2 is hosted by the system. It is used to help Xiaoming retrieve his DID and bind it into a new public key when the mobile phone is lost or the user's private key is lost due to system crash.

The proof part is Xiaoming's signature of the DID document with the private key in his APP. If we want to further enhance security, we can change the proof part to be signed by the public security organ.

After the DID document is generated, the APP will chain the DID and document to the blockchain for certificate storage. Once the chain is completed, everyone can query Xiaoming's DID and document. The block chain here is usually a chain of alliances, and it is not arbitrary data that can be written at random. Therefore, Xiao Ming must use his ID number to verify that he is really on the chain before he can prevent others from using the ID number of Xiao Ming.

Step 2: issuer school issues graduation certificate VC to Xiao Ming

The school also has its own DID. Because the school is a DID issued by the education system, the rules are different from Xiao Ming's DID rules as a Chinese citizen. For example, the school's DID logo is:

did:cedu:uestc

This DID is not signed by the school itself, but by the Ministry of Education (the DID of the Ministry of education is did:corg:moe). We can find the DID document corresponding to this DID in the blockchain as follows:

{
"@context": "https://w3id.org/did/v1",
"id": "did:cedu:uestc",
"version": 1,
"created": "2020-12-08T16:02:20Z",
"updated": "2020-12-08T16:02:20Z",
"publicKey": [
{
"id": "did:cedu:uestc#keys-1", "type": "Secp256k1", "publicKeyHex": "3053ba33b235d7116a3e3080168ee293053ba33b235d7116a33053ba33b235d7116a3" },
{ "id": "did:cedu:uestc#keys-2", "type": "Secp256k1", "publicKeyHex": "e293053ba3053ba33b235d7116a3263d29fe293053ba" } ],
"authentication": ["did:cedu:uestc#key-1"],
"recovery": ["did:cedu:uestc#key-2"],
"service": [
{
"id": "did:cedu:uestc#resolver", "type": "DIDResolve", "serviceEndpoint": "https://did.studyzydemo.com" } ],
"proof": {
"type": "Secp256k1", "creator": "did:corg:moe#keys-1", "signatureValue": "QNB13Y7Q9...1tzjn4w==" } }

The DID of all certified colleges and universities is created by the did:corg:moe, so it is equivalent to the traditional root CA. we only need to trust the DID created by the DID to be considered a regular college.

Going back to the issuance of graduation certificate VC, the school generates VC according to Xiaoming's learning situation (enrollment time, graduation time, major, completion or not) and Xiaoming's own DID submitted by Xiaoming as follows:

{
  // JSON-LD standard followed by VC content
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // The unique ID of this VC, that is, the certificate ID
  "id": "uestc/alumni/12345",
  // Format of VC content
  "type": ["VerifiableCredential", "AlumniCredential"],
  // Issuer of this VC
  "issuer": "did:cedu:uestc",
  // Date of issuance of this VC
  "issuanceDate": "2010-07-01T19:73:24Z",
  // Specific contents of VC statement
  "credentialSubject": {
    // DID of the declared person
    "id": "did:cid:511112200001010015",
    // Statement content: graduation institution, major, degree, etc
    "name":"Xiao Ming",
    "alumniOf": {
      "id": "did:cedu:uestc",
      "name": [{
        "value": "University of Electronic Science and technology",
        "lang": "cn"
      }]
    },
    "degree":"Master's degree",
    "degreeType":"engineering course",
    "college":"school of computing"
  },
  // Proof of this VC
  "proof": {
    "creator": "did:cedu:uestc#keys-1",
    "type": "Secp256k1",
    "signatureValue": "3044022051757c2de7032a0c887c3fcef02ca3812fede7ca748254771b9513d8e2bb"
  }
}

The most important thing here is the content of the credentialSubject certificate and the certificate given by the project issuing school. After the VC is generated, it will be transmitted to Xiaoming. Xiaoming can choose to store this content in his mobile APP or in the cloud, and then read it when he needs to use it in the future.

Step 3: holder Xiaoming submits the academic certificate VP to the HR of Verifier company

Next, Xiao Ming comes to the new company for employment. On the day of employment, he needs to submit the academic certificate to the HR of the company. Therefore, Xiao Ming encapsulates the VC generated in the previous step to generate a VP. The contents of the VP are as follows:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  // VC content included in this VP
  "verifiableCredential": [{
    "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "uestc/alumni/12345",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "did:cedu:uestc",
  "issuanceDate": "2010-07-01T19:73:24Z",
  "credentialSubject": {
    "id": "did:cid:511112200001010015",
    "name":"Xiao Ming",
    "alumniOf": {
      "id": "did:cedu:uestc",
      "name": [{
        "value": "University of Electronic Science and technology",
        "lang": "cn"
      }]
    },
    "degree":"Master's degree",
    "degreeType":"engineering course",
    "college":"school of computing"
  },
  "proof": {
    "creator": "did:cedu:uestc#keys-1",
    "type": "Secp256k1",
    "signatureValue": "3044022051757c2de7032a0c887c3fcef02ca3812fede7ca748254771b9513d8e2bb"
  }
  }],
  // Holder Xiaoming's signature information on this VP
  "proof": {
    "type": "Secp256k1",
    "created": "2010-07-02T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:cid:511112200001010015#keys-1",
    // challenge and domain are designed to prevent replay attacks
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
  }
}

It's simple here. It's just to submit all the contents of the whole graduation certificate, so you only need to check in the VC in the VP. At the end of the proof, Xiaoming signs with the private key in his APP. The table name VP is generated by Xiaoming himself. After the VP is generated, Xiao Ming needs to submit the contents of the whole VP to the HR of the new company.

Step4: HR of verifier company has passed Xiaoming's VP verification

HR of the company, as the verifier, first verifies the Proof field after receiving the VP submitted by Xiaoming to ensure that the VP is submitted by Xiaoming and has not been tampered with. Next, extract the VC content and verify the VC. The verification process is as follows:

Get the issuer's DID: DID: CED: UESTC from the creator of proof
Query the document of the DID through the blockchain, and there is a list of its creator and public key in the document, in which we take the public key corresponding to keys-1.
The creator is did:corg:moe, which is a trusted DID, so the DID it creates is trusted.
We further use did:corg:moe to read the DID document from the blockchain and obtain the public key. We use the public key to verify the signature of the document corresponding to DID: CEO: UESTC to ensure that it has not been tampered with.
After the verification is passed, we use the public key of did: CEO: UESTC to verify the signature of the VC submitted by Xiao Ming. If the verification is passed, it indicates that the certificate is indeed issued by a trusted UESTC.
HR checks whether the content provided in VC is consistent with the resume submitted by Xiao Ming. After the check is completed, HR will go through the next entry formalities.

In the above verification process, we need to verify the signature at least three times. The verification VP is submitted by Xiao Ming, the verification VC is issued by UESTC, the verification DID of UESTC is created by MOE, and the MOE is in the trusted list of the verifier's system, so the whole system ensures the credibility of the certificate submitted by Xiao Ming.

Selective disclosure of user attributes

We have issued the VC with the simplest generation of DID, and verified the VP flow to introduce the usage of DID. But in real life, we do not always want to see the whole certificate VC directly to the verifier. For example, when we go to a hotel, we need to register the name and ID number, but if we directly give the ID card to the front desk staff, The front desk staff can see our nationality, address and other information. For ordinary people, we may think it's nothing. If stars and public figures go to stay in the hotel, the front desk staff may secretly write down the address information or leak it to the Internet for various reasons, which will bring all kinds of trouble to the license's own life. So what can we do? Selective disclosure of user attributes can reduce risk.

We obtained the identity card VC from xiaoming from the public security organ, and then only showed the name, photo and ID number when staying in the hotel. Instead of exposing the nationality and address (because the ID card number already had a birthday, so we ignored the birth date attribute), for example, we explained the process of selective disclosure of user attributes.

Preparatory knowledge 1: Merkel tree

The purpose of Merkel tree is to form a short fingerprint of all transactions in a block (Merkel root, hash value) and put this fingerprint in the block header. Any tampering with the transaction will lead to the fingerprint change. The reason why we use Merkel tree instead of directly hashing all transactions in the block is because we want to carry out fast simple payment verification (SPV).

We take the Merkel tree composed of four transactions as an example. To verify whether Data2 is included in the block, we only need to give:

Raw data to validate: Data2
The location index of the data to be verified: 1 (the index starts with 0, so the index of Data2 is 1)
Verification path: [Hash1,Hash34]
MerkleRoot

Through these four parameters, we can confirm whether Data2 is included in the tree.

Preparatory knowledge 2: infinite sequence based on Seed

Based on the Merkel tree and Merkel authentication mentioned above, we can calculate the Merkel tree by taking the user's attributes as the Data part. For example, we want to build a Merkel tree for the attributes on the ID card:

Based on the above Merkel tree, we can only expose the birthday without exposing other fields, and then give the verification path to prove the authenticity of the birthday data. However, there is a potential privacy leakage problem here, that is, we will expose Hash1, and the attacker can exhaust all ethnic data, calculate the Hash of each ethnic group, and then compare it, so as to get the "ethnic" attribute I don't want to expose. So what? The simplest way is to add "salt" to each field.

Before generating Merkel tree, users need to create a random seed and save the seed data, Then, N sequences are generated based on this seed (N depends on the number of leaf nodes of our Merkel tree). Because our seed is generated randomly, we can think that this sequence is also random. The simplest way is to use the Hash function to Hash the previous data continuously to get the next data. The following is my sequence generation function

func GenerateSequence256(seed []byte, count int) [][]byte {
    result := [][]byte{}
    current := seed
    for i := 0; i < count; i++ {
        current = getHash(current)
        result = append(result, current)
    }
    return result
}

func getHash(input []byte) []byte {
    h := sha256.New()
    h.Write(input)
    return h.Sum(nil)
}

With this infinite random sequence, we can add salt to each Merkel tree leaf node, as shown in the figure below:

Now our Hash values are calculated after adding salt, so it is impossible to collide with the original data.

step1: generate VC

Based on the above two knowledge points, when preparing VC data, in addition to giving each attribute in the certificate, we also need to give: random seed, Merkel root, and the signature of the license issuing authority to Merkel root. Taking the ID card as an example, the ID card VC issued to us by the public security organ is as follows:

{
  // JSON-LD standard followed by VC content
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://studyzyexamples.com/identity/v1"
  ],
  // The unique ID of this VC, that is, the certificate ID
  "id": "vc511112200001010015",
  // Format of VC content
  "type": ["VerifiableCredential", "Identity"],
  // Issuer of this VC
  "issuer": "did:police ID",
  // Date of issuance of this VC
  "issuanceDate": "2010-07-01T19:73:24Z",
  // Specific contents of VC statement
  "credentialSubject": {
    // DID of the declared person
    "id": "did:cid:511112200001010015",
    // Statement content: name, gender, birthday, nationality, address, etc
    "name":"Xiao Ming",
    "gender":"male",
    "birthdate":"2000-01-01",
    "nation":"Chinese",
    "address":"A province B city C area D street xxx number",
    //Next is the number of seeds, Merkel root and the signature of public security
    "seed":"23523865082340324",
    "merkleRoot":"ea59a369466be42d1a4783f09ae0721a5a157d6dba9c4b053d407b5a4b9af145",
    "rootSignature":"3066022051757c2de7032a0c887c3fcef02ca3812fede7ca748254771b9513d8e266",
    "signer":"did:police ID#keys-1"
  },
  // Proof of this VC
  "proof": {
    "creator": "did:police ID#keys-1",
    "type": "Secp256k1",
    "signatureValue": "3044022051757c2de7032a0c887c3fcef02ca3812fede7ca748254771b9513d8e2bb"
  }
}

We should note that the signature of Merkel root is not in the proof field, but in the credentialSubject. The signature in the proof is the signature of the entire VC data, and the rootSignature is the signature of the public security organ on the root hash of the constructed Merkel tree.

Step 2: generate VP

Next, if Xiao Ming wants to participate in an activity of giving free gifts on his birthday, the activity party needs to verify Xiao Ming's date of birth, so Xiao Ming can generate the corresponding VP according to the VC in the previous step, in which only the birthday field is exposed and other identity attributes are not exposed. An example is as follows:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://studyzyexamples.com/identity/v1"
  ],
  "type": "VerifiablePresentation",
  // VC content included in this VP
  "verifiableCredential": [{
    "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://studyzyexamples.com/identity/v1"
  ],
  "id": "vc511112200001010015",
  "type": ["VerifiableCredential", "Identity"],
  "issuer": "did:police ID",
  "issuanceDate": "2010-07-01T19:73:24Z",
  "credentialSubject": {
    "id": "did:cid:511112200001010015",
    //The following are the contents to be selectively disclosed
    "birthdate":"2000-01-01",
    //The following is the data to verify the validity of the disclosure field
    //Index of data in Merkel tree
    "dataIndex":2,
    //The value of salt added in this data
    "salt":"6b264354ed367ced527a86d38f75f9c3888bd3939f548cc48d93af435890b84a",
    //Merkel verification path
    "merklesibling":"34b64151443c3124620bf4ff69a05e97d580f0878b374b8343c6a5c3d8223435 9d2b5b35ccb5bf18747c1f5dc05771c68ce613e6eb0c5f5ef77cec8ba3e9da67 bb82c63d4e21525125bf66a6724fbb4dcbded26aae2baa2633235dc12730016e",
    //Merkel Gen hash
    "merkleRoot":"ea59a369466be42d1a4783f09ae0721a5a157d6dba9c4b053d407b5a4b9af145",
    //Signature of public security organs to Merkel root
    "rootSignature":"3066022051757c2de7032a0c887c3fcef02ca3812fede7ca748254771b9513d8e266",
    //Which Key of the public security organ was used to sign
    "signer":"did:police ID#keys-1"
  },
  
  }],
  // Holder Xiaoming's signature information on this VP
  "proof": {
    "type": "Secp256k1",
    "created": "2010-07-02T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:cid:511112200001010015#keys-1",
    // challenge and domain are designed to prevent replay attacks
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
  }
}

Here, we give the field birthdate selected for disclosure, and then give several essential fields to be verified by Merkel:

"birthdate": "2000-01-01", the original data to be disclosed.
dataIndex, the index of the disclosure field on the leaf Festival when constructing Merkel tree, because we sort here by name, gender, birthday, nationality and address, so the index value of birthday is 2
Salt, the salt added to the birthdate field. Xiaoming can calculate the data according to the seed and dataIndex in his VC.
Merklesabling is the path required for Merkel's verification. Take the four Data mentioned above as examples. If we want to calculate the verification path of Data2, it is Hash1 and Hash34.
merkleRoot Merkel, this will not be repeated.
rootSignature and signer are used to verify Merkel's legitimacy. If merkleRoot, rootSignature and signer are verified, it means that Merkel root has been certified by the Ministry of public security.

step3: validate VP

After receiving the VP submitted by the user, the merchant needs to carry out step-by-step verification, mainly including the following steps:

1. Obtain Xiaoming's DID document from the blockchain according to Xiaoming's DID, obtain the public key from it, and verify that the VP signature is true and valid.

2. According to the issuer in VC, obtain the DID document of the public security organ from the blockchain, obtain the public key from the document, and verify that the DID is a trusted DID.

3. Verify whether Merkel's signature is correct according to the public key of the public security department.

4. Merkel shall verify the disclosure fields, Dataindex, Salt, merklebanking, MerkleRoot, etc. to ensure that the disclosure fields have been certified by the public security organ.

5. All the above steps pass the verification, and the credible disclosure content is displayed: "birthdate": "2000-01-01".

The merchant verified Xiaoming's date of birth, but did not obtain other identity information except the date of birth, so as to realize selective disclosure.

Application of DID

Secure login without password

This usage scenario should be familiar to everyone. It is similar to wechat code scanning login. When we want to register or log in to a website, we don't need to fill in information such as user name, password and email. We just need to scan the QR code of the login page with the digital identity APP in our mobile phone, then pop up the information after code scanning in the APP, and select confirm login. The difference between the APP using DID and the traditional wechat code scanning login is that the user's identity information in DID is mastered by the user, while the identity information of wechat code scanning login is mastered by Tencent. If Tencent blocks your wechat account one day, you will not be able to log in to all the websites you used to log in with wechat. And DID won't have this problem, because no one can ban your DID. The process of realizing password free login using DID is as follows:

The user opens the website to log in, and the website server generates a QR code containing the randomly assigned ID, website DID and website server URL.
The user unlocks the DID APP in the mobile phone and scans the QR code on the website.
APP obtains the ID in the QR code and the URL submitted by the server, generates a login request, uses the website DID to query the DID document in the blockchain, obtains the public key of the website server, encrypts the request data with the public key and sends it to the website server.
The website server decrypts the login request with the private key, queries the DID document corresponding to the DID in the blockchain, obtains the public key, and verifies the signature with the public key to ensure that the DID is the corresponding user.
The website server passes the authentication, and the login page is refreshed to login status.

From the whole process, we can see that the server does not know the user's password and cannot obtain any information other than the user's DID and DID documents, so as to ensure the security of the user's private data. From now on, there is no need to worry about the leakage of user information of XX website or the fact that the password is hit by hackers, logging in to other websites and stealing useful information.

identity authentication

In a large number of networks involving value, especially those of financial products, KYC and AML are required to be done well. KYC, in particular, needs to obtain some identity information of users, and every time you register a financial website, you need to authenticate. The identity information is very complex. Using DID for identity authentication can simplify this process. Take an internet financial APP as an example. If a new user wants to invest in it, he needs to provide mobile phone verification code, ID card photo verification, face recognition verification, video recording and other procedures. If the user goes to another Internet Finance APP, he has to verify it again, which is very troublesome. If it is based on DID, the procedures of identity authentication can be greatly simplified. Of course, the premise of identity authentication is that public security organs, universities and other identity information and certificate issuing institutions have generated VC and concurrent it to users. Users store VC in their own cloud space or their own mobile phone.

After the user logs in to the APP without password, the process of real name authentication is as follows:

The user logs in to the website or APP or the merchant and clicks the authentication button.
The server generates a request for information requiring authentication according to business requirements, and sends the request to the user DID APP in QR code or other ways.
After receiving the authentication request, the DID APP queries whether the DID has a VC that meets the requirements, whether there are corresponding fields, etc. if the requirements are met, the authentication content is displayed, and requests the user to unlock the private key through fingerprint or password for signature to generate VP.
After confirming that the information is correct, the user unlocks the private key, generates a VP, and sends the VP to the merchant server in the form of QR code or direct return to the merchant server.
After receiving the VP, the merchant server verifies that the VP signature is correct, meets the verification requirements, and displays that the verification is passed. The merchant server saves the VP and associates it with the user DID.

In addition to the KYC required by the financial scenario, we also cited earlier examples of companies that need to verify their academic qualifications when entering the company, verify their identity when staying in the hotel, verify that they are older than 18 when buying cigarettes and alcohol, verify their student identity when buying tickets to scenic spots, and enjoy student discounts

electronic signature

In the traditional electronic signature scheme, the user needs to prefabricate a U shield, which contains the private key assigned to the user and the certificate issued to the user. Each signature needs to insert the U shield and install the plug-in before it can be used normally. The electronic signature scheme based on U shield has the following problems:

1. It takes a long time to prepare the U shield (production certificate), so you can't apply immediately and use it immediately.

2. The U-shield must be carried with you. Generally, users only have the habit of carrying their mobile phone with them, and do not have the habit of carrying the U-shield with them.

3. After signing for the first time, the signatory can modify the original document and then re sign it, and it still passes the verification

The electronic signature scheme based on digital identity DID can solve the three problems mentioned above. Its application process is as follows:

After the user has created a DID through his mobile phone, he first sends a request to the trusted Licensor to obtain the VC, and stores the VC in the client. The VC is equivalent to the certificate file of the traditional PKI system.
After reviewing the document and confirming that there is no problem, the user calculates the document Hash and sends the document Hash and other summary information to the DID APP through QR code or other methods.
The DID APP requests the user to unlock the private key, sign the document Hash with the private key, and chain the DID, document Hash and signature value at the same time.
The PC side retrieves the blockchain, obtains the DID, signature value and other information of the chain in the previous step, passes the verification, and displays the signature results in the document.

In the above steps, because the generation and download of VC are realized by software, there is no need to wait for u shield production for a long time; Moreover, the private key is saved to the mobile phone through encryption, and there is no need to carry a U shield alone; The signature results are directly linked to prevent tampering, and prevent the signer from signing multiple versions of the same document

Personal privacy protection

Selective disclosure of user identity attributes and zero knowledge proof, users only disclose the information required by the verifier when displaying the certificate, and will not expose all the information of the whole certificate, so as to achieve the purpose of personal privacy protection

In addition, there is a further scheme called PDC (personal data center). Personal data are encrypted and stored in the personal data center and associated with the personal DID. Each person is responsible for his own data. When he needs to obtain some private data of the user, he needs the authorization of the DID to decrypt and access.

Internet of things identification

The above-mentioned application scenarios are aimed at people's identity. In fact, IOT can also be closely combined with DID. We assign each IOT device its unique IDD and build it based on Internet of things + blockchain + DID: Commodity traceability, Internet of vehicles, intelligent manufacturing, smart city and other application scenarios.

Take manufacturing machines in the manufacturing industry as an example. Each machine has a DID. The DID is generated by the machine manufacturer and given to each machine. When the machine is running, a large amount of production data will be generated. The machine will sign the data and link the non sensitive production data, signature results and DID. The manufacturer of the machine can know the operation of the machine according to the data on the chain, so as to facilitate better after-sales maintenance service. When an enterprise needs a loan, the bank can judge the production and operation of the enterprise and evaluate the loan risk according to the production data on the blockchain and the endorsement of the machine manufacturer.

We take the Internet of things anti-counterfeiting traceability of high-value commodities as an example. When each commodity is manufactured, the merchant produces a private key for its IOT equipment and creates a unique DID. Because the private key cannot be copied and exported, only the goods registered with DID on the blockchain are authentic. Moreover, the DID of goods can map the corresponding non-homogeneous pass, and show the circulation process of goods in the form of digitization.

Take a U-shield with you; The signature results are directly linked to prevent tampering, and prevent the signer from signing multiple versions of the same document

Personal privacy protection

Internet of things identification

Topics: Blockchain

Programmer Think

DID decentralized digital identity

DID decentralized digital identity

identity

Digital identity

PKI system

DID

DID identification

DID document

Verifiable certificate / verifiable statement (VC)

Verifiable expression (VP)

Use process of DiD

Scene description

Step 1: Xiao Ming generates DID identification and DID document

Step 2: issuer school issues graduation certificate VC to Xiao Ming

Step 3: holder Xiaoming submits the academic certificate VP to the HR of Verifier company

Step4: HR of verifier company has passed Xiaoming's VP verification

Selective disclosure of user attributes

Preparatory knowledge 1: Merkel tree

Preparatory knowledge 2: infinite sequence based on Seed

step1: generate VC

Step 2: generate VP

step3: validate VP

Application of DID

Secure login without password

identity authentication

electronic signature

Personal privacy protection

Internet of things identification

Personal privacy protection

Internet of things identification

Hot Topics