You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DID (Decentralized identity) is a trust framework in which identifiers such as usernames can be replaced with IDs that are self-owned, independent, and enable data exchange using blockchain technology, providing privacy and secure transactions. Our lives are increasingly linked to apps, devices and services, and we’re often subject to data breaches and privacy loss. Hence, a standards-based decentralized identity system can provide greater privacy and control over your data.
9
+
Rubix Network supports a lightweight and secure Decentralized Identity (DID) mechanism built using the **BIP39 standard**. This implementation allows users and systems to generate cryptographic identities that are:
10
10
11
-
Rubix Decentralized Identity (DID) project is an open standard enabling users to create self-owned identities, and use blockchain networks for getting decentralized tamper proof verifiable claims. The claims are 100% on-chain and publicly verifiable.
11
+
-**Self-owned** and **recoverable**
12
+
-**Verifiable** through cryptographic proofs
13
+
-**Tamper-proof** with on-chain claim registration
14
+
-**Privacy-preserving**, with optional selective disclosure
12
15
13
-
### Key features of Rubix DID
16
+
This guide covers the concepts behind DID, its significance, and how to create, register, and recover a BIP39-based DID on the Rubix Network.
14
17
15
-
1. Identities are self-created and self-owned allowing more control for user over his data i.e., no Certificate Authority (CA) is required for generating identity key pairs.
16
-
2. Information is immutable, once it is issued by using cryptographic proofs and object-oriented Distributed File System (DFS).
17
-
3. Real world DFS based on content-based addressing, preserves complete integrity over signed data.
18
-
4. Parallel scalable ledger allows asynchronous claims and verification.
19
-
5. Instant confirmation and finality.
20
-
6. Data confidentiality is preserved by encrypting the signed certificate using patented Non-Linear Secret Sharing (NLSS) method.
21
-
7. Selective disclosure property helps user to choose partial revealing of data for verification.
22
-
8. The information cannot be decrypted without the consent of the issuer and/or the certificate holder.
23
-
9. In Compliance with globally accepted standards like : <br>
24
-
a. IMS Open Badges<br>
25
-
b.W3C Verifiable Claims<br>
26
-
c.W3C Linked Data Signatures<br>
18
+
---
19
+
20
+
## What is a DID?
21
+
22
+
A **Decentralized Identifier (DID)** is a cryptographic, globally unique identifier that enables the creation of **self-sovereign identities**. Unlike centralized identities tied to usernames or email addresses, a DID:
23
+
24
+
- Is **generated by the user** (not issued)
25
+
-**Eliminates third-party trust dependencies**
26
+
- Enables **verifiable claims** without disclosing sensitive data
27
+
28
+
---
29
+
30
+
## Why BIP39-Based DID?
31
+
32
+
Rubix supports multiple DID types, but the recommended and default approach is **BIP39-based DID (Type 4)**. It offers:
33
+
34
+
- 24-word **mnemonic-based** identity recovery
35
+
- Secure **key pair generation** using `secp256k1` elliptic curve
36
+
- Compatibility with **Hierarchical Deterministic Wallet (HD Wallet)** specs
37
+
- No external Certificate Authorities (CA) required
38
+
39
+
---
40
+
41
+
## Verifiable Claims in Rubix
27
42
28
-
10. Follows digital preservation rules like GDPR, CCPA.
29
-
11. All transactions are on-chain, while also being cost effective.
30
-
12. Light weight infrastructure with support for multi architectural designs.
43
+
Verifiable claims allow identity holders to present cryptographically signed statements (e.g., “User1 graduated from XYZ University”) without relying on centralized servers.
31
44
32
-
<br>
45
+
- Claims are **100% on-chain**
46
+
- Can be selectively disclosed and verified
47
+
- Tamper-proof and immutable
48
+
- Aligned with **W3C Verifiable Credentials** and **Linked Data Signatures**
33
49
34
-
## DID creation
50
+
---
35
51
36
-
There are two common ways of DID creation in Rubix. The standard way is to generate a BIP39 standard HD master key and one child key (path zero) on curve secp256k1. This is faster , lighter and provides account recovery using mnemonics. The second day provides double layer security with addition of an MPC Non Linear Secret Sharing scheme on top of traditional pki system. This type is recommeneded for systems that require addtional security.
52
+
## DID Creation & Registration Workflow
37
53
38
-
### Type 4 : BIP39 DID generation and recovery
54
+
### 1. Start Rubix Node
39
55
40
-
To create a BIP based DID in rubix , use flag -didType 4 in createdid command. A random 24 word mnemonic will be created and used as seed to create BIP master key and child key at path zero. The mnemonic file will be stored in mnemonic.txt inside the DID folder. Please do not share the mnemonics and store them in safe place for recovery. The following command create BIP 39 keypair
56
+
Ensure your Rubix node is up and running on a port (e.g., `20000`):
41
57
58
+
```bash
59
+
./rubixgoplatform startnode -port <port_number>
42
60
```
43
-
./rubixgoplatform createdid -didType 4
61
+
62
+
---
63
+
64
+
### 2. Create a DID Using BIP39
65
+
66
+
Open a new terminal tab in the same build directory and run:
Inorder to recover DID and key pairs, backup the mnemonickeyfile in a seperate folder and call createdid with -didType 4 -mnemonicKeyFile /pathtomnemonickeyfile. This will create the same master key and key pairs
Every node joining the Rubix network must create a DID. There is an option for creation of DID after node setup. A CURL request is called when the user selects this option.
106
+
**Example:**
63
107
64
-
The creation process is a logic that combines a 256x256 image and a system generated hash value. The image chosen here is a standard image used for all DID creations across the network. The hash value on the other hand, is the hashed value of the peerID of the node, which is in turn generated during node setup by IPFS protocol. The combination of both is a hash value which is then used as a DID for the node.
The DID is further split into two parts, namely [Public Share](https://learn.rubix.net/public-share/) and [Private Share](https://learn.rubix.net/private-share/). These parts are used during various athentication and data transfer scenarios. More about this can be found on the above links.
112
+
---
67
113
114
+
### 5. Recover the DID (If Needed)
68
115
69
-
### Inner working of createDID method
116
+
To recover a lost DID using the mnemonic:
70
117
71
-
- When the createDID method is called along with the input parameter which is your .png file of 256x256
72
-
- This image is converted into binary.
73
-
- An input parameter String is given which can be any string as the user wishes,
74
-
- it can be any detail provided by the user such as name,address,phone number etc.
75
-
- This input string is hashed, then this hash is again hashed multiple times.
76
-
- This hash is embedded with the image binary.
77
-
- This embedded image file is then split to provide DID.png, PrivateShare.png, PublicShare.png and your corresponding DID, using our patented NLSS algorithm
A DID-oriented blockchain can be used for applications that are currently running on a centralised authentication mechanism. For example, a traditional food delivery app can be transitioned into a DID-oriented authentication system to provide for more user data privacy and security.
124
+
---
82
125
83
-
### Additional points to be noted by the developer
126
+
##Summary of Commands
84
127
85
-
- developer must look into the basics of ipfs protocol.
86
-
- The ipfs version which we follow is 0.6.0.
87
-
- Going through this doc will give you an idea about the working of the protocol.
88
-
<https://docs.ipfs.io/>
89
-
- You can find more about DID in our White Paper (Page 3)
The creation logic could be improved or made more effecient and still provide a similar level of functionality.
136
+
---
137
+
138
+
## Standards Compliance
139
+
140
+
Rubix DID implementation is aligned with:
95
141
96
-
<blockquoteclass="Rubix-tweet"><plang="en"dir="ltr">Crypto, public chains will transform the access management enormously for the better. In Rubix, every node/user gets #DID automatically assigned,can build verifiable claims around it,build DNS, build alternatives to #SAML & much more</p>— Rubix (@rubixchain) <ahref="https://twitter.com/RubixChain/status/1484763352966447104">January 22, 2022</a></blockquote> <scriptasyncsrc="https://platform.Rubix.com/widgets.js"charset="utf-8"></script>
142
+
- W3C Verifiable Credentials
143
+
- W3C Linked Data Signatures
144
+
- IMS Open Badges
145
+
- GDPR & CCPA regulations
146
+
147
+
---
97
148
98
-
If you have questions or feedback, please DM us at [@rubixchain](http://twitter.com/rubixChain).
149
+
## Closing Thoughts
150
+
151
+
The BIP39-based DID on Rubix is a **privacy-first**, **developer-friendly**, and **production-ready** identity primitive. It aligns with the principles of self-sovereignty, transparency, and decentralization empowering developers to build trust into the very fabric of their applications.
152
+
153
+
> Ready to integrate decentralized identity into your app?
154
+
> Start with `./rubixgoplatform createdid -didType 4 -port <port_number>` today.
DID (Decentralized identity) is a trust framework in which identifiers such as usernames can be replaced with IDs that are self-owned, independent, and enable data exchange using blockchain technology, providing privacy and secure transactions. Our lives are increasingly linked to apps, devices and services, and we’re often subject to data breaches and privacy loss. Hence, a standards-based decentralized identity system can provide greater privacy and control over your data.
10
+
11
+
Rubix Decentralized Identity (DID) project is an open standard enabling users to create self-owned identities, and use blockchain networks for getting decentralized tamper proof verifiable claims. The claims are 100% on-chain and publicly verifiable.
12
+
13
+
### Key features of Rubix DID
14
+
15
+
1. Identities are self-created and self-owned allowing more control for user over his data i.e., no Certificate Authority (CA) is required for generating identity key pairs.
16
+
2. Information is immutable, once it is issued by using cryptographic proofs and object-oriented Distributed File System (DFS).
17
+
3. Real world DFS based on content-based addressing, preserves complete integrity over signed data.
18
+
4. Parallel scalable ledger allows asynchronous claims and verification.
19
+
5. Instant confirmation and finality.
20
+
6. Data confidentiality is preserved by encrypting the signed certificate using patented Non-Linear Secret Sharing (NLSS) method.
21
+
7. Selective disclosure property helps user to choose partial revealing of data for verification.
22
+
8. The information cannot be decrypted without the consent of the issuer and/or the certificate holder.
23
+
9. In Compliance with globally accepted standards like : <br>
24
+
a. IMS Open Badges<br>
25
+
b.W3C Verifiable Claims<br>
26
+
c.W3C Linked Data Signatures<br>
27
+
28
+
10. Follows digital preservation rules like GDPR, CCPA.
29
+
11. All transactions are on-chain, while also being cost effective.
30
+
12. Light weight infrastructure with support for multi architectural designs.
31
+
32
+
<br>
33
+
34
+
## DID creation
35
+
36
+
There are two common ways of DID creation in Rubix. The standard way is to generate a BIP39 standard HD master key and one child key (path zero) on curve secp256k1. This is faster , lighter and provides account recovery using mnemonics. The second day provides double layer security with addition of an MPC Non Linear Secret Sharing scheme on top of traditional pki system. This type is recommeneded for systems that require addtional security.
37
+
38
+
### Type 4 : BIP39 DID generation and recovery
39
+
40
+
To create a BIP based DID in rubix , use flag -didType 4 in createdid command. A random 24 word mnemonic will be created and used as seed to create BIP master key and child key at path zero. The mnemonic file will be stored in mnemonic.txt inside the DID folder. Please do not share the mnemonics and store them in safe place for recovery. The following command create BIP 39 keypair
41
+
42
+
```
43
+
./rubixgoplatform createdid -didType 4
44
+
```
45
+
46
+
Inorder to recover DID and key pairs, backup the mnemonickeyfile in a seperate folder and call createdid with -didType 4 -mnemonicKeyFile /pathtomnemonickeyfile. This will create the same master key and key pairs
- Network is currently mining in `level 4` - reached on `5 th march 2022`
57
+
58
+
{{< / expand >}} -->
59
+
60
+
### Type 0 : PKI + NLSS DID generation and recovery
61
+
62
+
Every node joining the Rubix network must create a DID. There is an option for creation of DID after node setup. A CURL request is called when the user selects this option.
63
+
64
+
The creation process is a logic that combines a 256x256 image and a system generated hash value. The image chosen here is a standard image used for all DID creations across the network. The hash value on the other hand, is the hashed value of the peerID of the node, which is in turn generated during node setup by IPFS protocol. The combination of both is a hash value which is then used as a DID for the node.
65
+
66
+
The DID is further split into two parts, namely [Public Share](https://learn.rubix.net/public-share/) and [Private Share](https://learn.rubix.net/private-share/). These parts are used during various athentication and data transfer scenarios. More about this can be found on the above links.
67
+
68
+
69
+
### Inner working of createDID method
70
+
71
+
- When the createDID method is called along with the input parameter which is your .png file of 256x256
72
+
- This image is converted into binary.
73
+
- An input parameter String is given which can be any string as the user wishes,
74
+
- it can be any detail provided by the user such as name,address,phone number etc.
75
+
- This input string is hashed, then this hash is again hashed multiple times.
76
+
- This hash is embedded with the image binary.
77
+
- This embedded image file is then split to provide DID.png, PrivateShare.png, PublicShare.png and your corresponding DID, using our patented NLSS algorithm
78
+
79
+
### Use Cases
80
+
81
+
A DID-oriented blockchain can be used for applications that are currently running on a centralised authentication mechanism. For example, a traditional food delivery app can be transitioned into a DID-oriented authentication system to provide for more user data privacy and security.
82
+
83
+
### Additional points to be noted by the developer
84
+
85
+
- developer must look into the basics of ipfs protocol.
86
+
- The ipfs version which we follow is 0.6.0.
87
+
- Going through this doc will give you an idea about the working of the protocol.
88
+
<https://docs.ipfs.io/>
89
+
- You can find more about DID in our White Paper (Page 3)
The creation logic could be improved or made more effecient and still provide a similar level of functionality.
95
+
96
+
<blockquoteclass="Rubix-tweet"><plang="en"dir="ltr">Crypto, public chains will transform the access management enormously for the better. In Rubix, every node/user gets #DID automatically assigned,can build verifiable claims around it,build DNS, build alternatives to #SAML & much more</p>— Rubix (@rubixchain) <ahref="https://twitter.com/RubixChain/status/1484763352966447104">January 22, 2022</a></blockquote> <scriptasyncsrc="https://platform.Rubix.com/widgets.js"charset="utf-8"></script>
97
+
98
+
If you have questions or feedback, please DM us at [@rubixchain](http://twitter.com/rubixChain).
0 commit comments