Background of DID

As we’ve discussed in the previous article, until the advent of blockchain technology, DIDs did not develop that quickly. The emergence of blockchain has solved the biggest problem of DID. As the blockchain technology is tamper-proof, and with the characteristics of the hash, it enabled the establishment of an identity system that is identification unique, credible, and decentralized.

Nowadays, compared with the popular concepts of blockchain technologies such as scaling, cross-chain, and DeFi, DID is not a research hot spot. Up to now, only a few teams have released their DID projects. The decentralized identifier standard developed by the World Wide Web Consortium (W3C) is becoming the standard for decentralized identity (DID) technology implementation, with companies or projects such as PlatON, Microsoft, ArcBlock, uPort, and lifeID currently submitting their own DID protocol methods.

The following article will introduce the PDID project built by PlatON, which will contain some specification information about the standard DID.

Pldentity DID

PDID is a collection of tools and protocols for building user-centric decentralized applications. The PlatON network registers digital identities on the Internet to protect user privacy and data security.

Decentralized Identifier (DID) is a new type of identifier that is globally unique, highly available, resolvable, and password verifiable. DIDs are typically linked to cryptographic materials (e.g., public keys) and service endpoints to establish secure communication channels. DIDs are useful for any application that benefits from self-managed, password-verifiable identifiers such as personal identifiers, organizational identifiers, and IoT scenario identifiers. For example, current commercial deployments of W3C’s verifiable credentials make extensive use of DIDs to identify people, organizations, and things, and to enable the assurance of many security and privacy protections.

PDID Specification

Instruction:

The prefix did is constant and identifies this string URL as a did identification string. The pdid identifier in the middle is defined and handled using PlatON’s systematic scheme. The scheme will automatically define and register to the official W3C website. The last part is the unique identification string of the DID method. It is the address corresponding to the private key in the PlatON network system, which is used to represent the unique address of the user.

PDID Document

PDID infrastructure uses PlatON network system for data hosting, and its storage method can be understood as simple key-value pair storage, with the DID identifier being the key and the DID document the value.

Each DID identifier corresponds to a DID Document, which is a JSON text containing the following information:

• DID identifier
• A set of cryptographic materials like the public key
• A set of cryptographic protocols
• A set of service endpoints
• Timestamps
• An optional JSON-LD signature to prove that this DID document is legitimate;

PDID document sample:

{
 “@context”: “https://PIdentity.platon.com/did/v1",
 “id”: “did:pid:atp1s4u4p9j95lh72a2c0ttj48ntd58s45resjgtza”,
 “created”: “2017–09–24T17:00:00Z”,
 “updated”: “2018–09–24T02:41:00Z”,
 “status”: “deactivation”,
 “publicKey”: [{
 “id”: “did:pid:atp1s4u4p9j95lh72a2c0ttj48ntd58s45resjgtza#keys-2”,
 “type”: “Secp256k1VerificationKey2018”,
 “controller”: “did:pid:atp1s4u4p9j95lh72a2c0ttj48ntd58s45resjgtza”,
 “publicKeyHex”: “02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71”
 }],
 “authentication”: [
 “did:pid:atp1s4u4p9j95lh72a2c0ttj48ntd58s45resjgtza#keys-1”
 ],
 “service”: [
 {
 “id”: “did:pid:lax1s4u4p9j95lh72a2c0ttj48ntd58s45resjgtza#some-service”,
 “type”: “SomeServiceType”,
 “serviceEndpint”: “https://PIdentity.platon.com/some-service/v1"
 }
 ],
 }

In PDID, the DID identifier and document are stored in the blockchain as Key and Value, which realizes fast authentication and fast access to credible data with the blockchain’s features of tamper-proof and shared data access.

Verifiable Credentials

Verifiable Claims (VC) or Verifiable Credentials, VC for short, are descriptive statements issued by a DID to credibly endorse certain attributes of another DID, while attaching its own digital signature to prove the authenticity of these attributes, which can be understood as a digital certificate. CA is needed to issue the traditional PKI digital certificate system, of course, the DID also has issuers, holders, verifiers, and DID data registry (blockchain).

Activity relationship chart of DID:

In it:

• Issuer: the issuing agency of the certificate, for example, the public security organ is the issuer of the ID card, the school is the issuer of the graduation certificate.
• Holder: the holder of a certificate, for example, a citizen with an ID card, and a graduate with a diploma.
• Verifier: the user of the certificate, or the person or organization that needs to verify the certificate. For example, the hotel reception that examines the ID when checking in is a verifier.
• Verifiable Data Registry: where DID identifier and the DID document are stored, the corresponding document can be accessed by the DID identifier.

Here we use the issuance of ID cards by the public security organs as an example. The issuance of an ID card by the public security organ is like a VC generated by the DID, with VC being the ID card. A VC is also a JSON formatted text, which mainly contains metadata, claim data, proof data, and other information.

• Metadata: Mainly record information about the issuer, the date of issue, and the type of claim;
• Claim: One or more descriptions of the subject. For example, the claim of the above-mentioned ID card (VC) issued by the public security organ should include: name, gender, date of birth, ethnicity, and other information; Proof: generally the digital signature of the issuer, which can guarantee that this VC can be verified, prevent the content from being tampered with, as well as verify the issuer of the VC;

Sample of VC:

{
 “@content”: “https://PIdentity.platon.com/credential/v1",
 “id”: “ca4ab2f56d106dac92e891b6f7fc4d9546fdf2eb94a364208fa65a9996b03ba0”, // UUID
 “type”: [“VerifiableCredential”, “AlumniCredential”], // Credential type for declaring what data should be included in the credential
 “issuer”: “did:pid:ATP2423refddj95lh72a2c0tt2323e3e3dweweewew”,
 “issuanceDate”: “2010–01–01T21:19:10Z”,
 “expirationDate”: “2020–01–01T19：23：24Z”,
 “holder”: “did:pid:lax1s4u4p9j95lh72a2c0ttj48ntd58s45resjgtza”,
 “version”: “v1.0”,
 “claimMeta”: {
 “pctId”: 110,
 “currentStatus”: “Revoked”,
 “statusReason”: “Disciplinary action”
 },
 “claimData”: {
 “name”: “Zhang San”,
 “gender”: “male”,
 “birth”: “1989–06–06–18T21:19:10Z”,
 “address”: “Haikou”,
 “MonthlySalary”: 3000.00
 },
 “proof”: {
 “type”: “RsaVerificationKey2018”,
 “created”: “2016–06–18T21:19:10Z”,
 “verificationMethod”: “did:pid:atp2423refddj95lh72a2c0tt2323e3e3dweweewew#keys-2”,
 “salt”: {
 “name”: “122”,
 “gender”: “342”,
 “birth”: “err”,
 “address”: “4545”,
 “MonthlySalary”: “rgee”
 },
 “jws”: “BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCu
 }

Verifiable Presentation

Verifiable Presentation (VP) is the data by which the holder of a VC identifies himself to the verifier. Usually, the holder can achieve valid proof by directly presenting the full VC data. However, in some cases, for privacy reasons, the holder does not need to show the full VC but certain attributes, or only need to prove an assertion without disclosing any attributes.

Scenario 1: When entering a high-end office building, the visitor needs to provide his name and ID number, but the VC also contains the ethnicity, address, and other information. Providing VC directly will expose other data, and the visitor does not want to expose the address. For this time, the visitor can provide selected VP data to the security guard, i.e., ID number and name, without showing any other information.

Scenario 2 (Assertion): Only those who are at least 18 years old can enter an Internet cafe, so when a consumer wants to go to an Internet cafe, he must prove that he is at least 18 years old, but showing their ID card directly to the staff will reveal too much private information, and even if he chooses to disclose his birthday attributes, it will still reveal the consumer’s birth date. In this case, the customer has to prove in the VP that he is at least 18 years old without disclosing any other information, and this is called assertion proof.

Form of VP:

In it,

• VP metadata: contains mainly the version, type of JSON object, and other information.
• VC set: the content of VC that needs to be shown and may not contain VC if it is selective disclosure or privacy protection.
• Proof: The holder’s signature information for this VP.

Sample of VP:

{
 “@context”: [“https://pidentity.platon.com/presentation/v1"],
 “type”: [“VerifiablePresentation”],
 “verifiableCredential”: [
 {
 “@content”: “https://PIdentity.platon.com/credential/v1",
 “id”: “ca4ab2f56d106dac92e891b6f7fc4d9546fdf2eb94a364208fa65a9996b03ba0”,
 “type”: [“VerifiableCredential”, “AlumniCredential”],
 “issuer”: “did:pid:lax2423refddj95lh72a2c0tt2323e3e3dweweewew”,
 “issuanceDate”: “2010–01–01T21:19:10Z”,
 “expirationDate”: “2020–01–01T19：23：24Z”,
 “holder”: “did:pid:lax1s4u4p9j95lh72a2c0ttj48ntd58s45resjgtza”,
 “version”: “v1.0”,
 “claimMeta”: {
 “pctId”: 110,
 “currentStatus”: “Revoked”,
 “statusReason”: “Disciplinary action”
 },
 “claimData”: {
 “name”: “Zhang San”,
 “gender”: “male”,
 “birth”: “1989–06–06–18T21:19:10Z”,
 “address”: “Haikou”,
 “MonthlySalary”: 3000.00
 },
 “revocation”: {
 “id”: “did:pid:lax2423refddj95lh72a2c0tt2323e3e3dweweewew”,
 “type”: “SimpleRevocationList2017”
 },
 “proof”: {
 “type”: “RsaVerificationKey2018”,
 “created”: “2016–06–18T21:19:10Z”,
 “verificationMethod”: “did:pid:lax2423refddj95lh72a2c0tt2323e3e3dweweewew#keys-2”,
 “salt”: {
 “name”: “122”,
 “gender”: “342”,
 “birth”: “err”,
 “address”: “4545”,
 “MonthlySalary”: “rgee”
 },
 “jws”: “BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0Ufqz
 }
 ],
 “proof”: [{
 “type”: “RsaVerificationKey2018”,
 “created”: “2016–06–18T21:19:10Z”,
 “verificationMethod”: “did:pid:lax1s4u4p9j95lh72a2c0ttj48ntd58s45resjgtza#keys-3”,
 “challenge”: “598c63d6”,
 “jws”: “JBMvvFAIC00nSGB6Tn0XKbbF9XrsaJZREWvR2aONYTQQxnyXirtXnlewJMBBn2h9hfcGZrvnC1b6PgWmukzFJ1IiH1
 }
 ]
 }

Analysis and Summary

The novelty digital identifier of DID is verifiable and self-sovereign, enabling identity data to always be under the control of the end-user, while personal identity information is not stored on the blockchain (with the signed hash as the only evidence), allowing the user to be the sole owner of the identity, and freed them from the control of the centralized registration service, identity provider and certificate issuer. To protect privacy, the DID typically uses zero-knowledge proof to keep the exposure of vital information to a minimum.

The experience and usage of decentralized identities enabled by DID technology are entirely different from traditional digital identities. First of all, each entity has not only one DID, but countless different DIDs for the different needs of identity occasions. Each DID give you a separate encrypted lifelong private channel to interact and communicate with other individuals, organizations, or things, so you can better choose your identity to communicate and better protect privacy, and “doxing” previously existed on the Internet will never happen again. PDID will be used to prove identity and exchange verifiable digital certificates, as each DID is registered directly on the blockchain or distributed network, eliminating the need to apply to a centralized registry.