Skip to content

Commit

Permalink
Content for create did, replit improvements (#372)
Browse files Browse the repository at this point in the history
* Content for create did, replit improvements

* md

* Improved phrasing based on suggestions
  • Loading branch information
Jelle Femmo Millenaar authored Sep 8, 2021
1 parent 76e3b0f commit b755a40
Show file tree
Hide file tree
Showing 6 changed files with 75 additions and 41 deletions.
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
title: Creating a Decentralized Identity
sidebar_label: Create and Publish
description: DID Documents and publishing them to the Tangle
image: /img/Identity_icon.png
keywords:
- Documents
- DID
- Tangle
- Publish
---

When someone or something wants to benefit from Self-Sovereign Identity, they must first create a Decentralized Identity. This identity consists of many parts that have different functions. This page will cover both the basics and the details about identity creation, storage, and publishing to the Tangle.

The example below utilizes the high-level account module of the IOTA Identity framework to create an identity. The account is the easiest method of using IOTA Identity. It is recommended to use the account for your use cases, a lower-level API is also available, providing more flexibility at the cost of more complexity.

### Creating an Identity using the Account

:::tip Using Replit

Select your programming language of choice and press the green play button to execute the example.

:::

import CodeSnippet from '../../../src/components/CodeSnippetComponent'

<CodeSnippet nodeReplitLink="https://repl.it/@abdulmth/Create-did?lite=true"
rustReplitLink="https://replit.com/@JelleMillenaar1/accountbasic?lite=true"></CodeSnippet>

The first step in this example is the creation of an account. This acts as a stateful object that manages one or more identities. The account provides an interface to execute high-level operations on identities, such as creating, updating, and storing them.

Next, the identity is created and published to the IOTA Tangle. This operation will generate a private key, storing it in the account, generating a DID, DID Document, and publishing it to the Tangle. Once it is uploaded to the Tangle, it becomes immutable, meaning that this version of the identity can never be altered or removed. The only way to update or delete an identity is by publishing a new version, which we will discuss in the next section. This immutability is what makes a Decentralized Identity solution based on Distributed Ledger Technology (DLT) trustworthy. The public keys inside the DID Document can never be changed without having access to the private key, allowing the users to completely control their own identities. The rest of the example shows how to retrieve (resolve) the identity from the Tangle and how it can be deleted.

### Identity Generation Process

The generation of an identity starts with a randomly generated asymmetric key pair. This can be generated by the IOTA Identity framework or can be provided as a parameter during the creation process. The public key is hashed using the `Blake2b-256` algorithm. This hash becomes the DID, creating a permanent and provable link between the initial keypair and the DID. The public key is then embedded into the initial DID Document and is used for verifying signatures created with the corresponding private key. This process can be observed and manipulated in depth by using the low-level API available for the IOTA Identity framework. This low-level API can be found here (TODO: Link) and is only recommended for complex use cases that require maximum flexibility in the framework.

This file was deleted.

Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
---
title: Secure DIDs
sidebar_label: Secure
---

TODO: Stronghold
Original file line number Diff line number Diff line change
@@ -1,4 +1,6 @@
---
title: DID Introduction
sidebar_label: Introduction
description: The Decentralized Identifiers (DID) standard from W3C is the fundamental standard that supports the concept of a decentralized digital identity. Explore the basic aspects of the DID standard.
image: /img/Identity_icon.png
keywords:
Expand All @@ -13,64 +15,64 @@ keywords:

The Decentralized Identifiers (DID) standard from W3C is the fundamental standard that supports the concept of a decentralized digital identity. A DID is a unique identifier that contains information that can be resolved to a DID Document. This document contains data such as public keys, enabling the holder to prove ownership over their personal data, but also URIs that link to public information about the identity. This implementation complies to the [DID specifications v1.0 Working](https://www.w3.org/TR/did-core//).

In the IOTA Identity framework, we have implemented the DID standard according to the `iota` [DID Method Specification](./specs/iota_did_method_spec.md). We recommend seeing the `iota` DID Method Specification as the golden standard for DID on IOTA. Other implementations of DID on IOTA are recommended to follow the `iota` DID Method Specification. However, it is not necassary to implement a novel Method implementation for every project, so feel free to utilize this framework directly.
In the IOTA Identity framework, we have implemented the DID standard according to the `iota` [DID Method Specification](./specs/iota_did_method_spec.md). We recommend seeing the `iota` DID Method Specification as the golden standard for DID on IOTA. Other implementations of DID on IOTA are recommended to follow the `iota` DID Method Specification. However, it is not necessary to implement a novel Method implementation for every project, so feel free to utilize this framework directly.

An example of DID conforming to the `iota` method specification:
An example of a DID conforming to the `iota` method specification:
`did:iota:8dQAzVbbf6FLW9ckwyCBnKmcMGcUV9LYJoXtgQkHcNQy`

## Chapter Overview

In this chapter we will explain the basic aspects of the DID standard. We will explore the how and why of DID Documents and why IOTA is a very suitable technology to host the DID Documents and the rest of a Self Sovereign Identity Framework.
In this chapter, we will explain the basic aspects of the DID standard. We will explore the how and why of DID Documents and why IOTA is a very suitable technology to host the DID Documents and the rest of a Self-Sovereign Identity Framework.

## Decentralized Identifiers

A Decentralized Identifier, or DID, is a unique identifier that is tied to a subject. This subject can be anything, like a person, an organization, an IoT device or even an object. The identifier can be used by the subject to identify themselves through a digital format, providing a basis for online identification. The identifier looks like a set of random characters that includes some prefixes to determine which standard and implementation is used:
A Decentralized Identifier, or DID, is a unique identifier that is tied to a subject. This subject can be anything, like a person, an organization, an IoT device, or even an object. The identifier can be used by the subject to identify themselves through a digital format, providing a basis for online identification. The identifier looks like a set of random characters that includes some prefixes to determine which standard and implementation is used:

`did:iota:8dQAzVbbf6FLW9ckwyCBnKmcMGcUV9LYJoXtgQkHcNQy`

The World Wide Web Consortium (W3C) is a well-known standardization body that has standardized how DIDs should look like and work. This provides a basis for different technologies that implement the DID standard to achieve interoperability. A full list of all implementations can be found [here.](https://www.w3.org/TR/did-spec-registries/#did-methods) Please keep in mind that unfortuanetly most of these methods are outdated and not maintained.
The World Wide Web Consortium (W3C) is a well-known standardization body that has standardized how DIDs should look and work. This provides a basis for different technologies that implement the DID standard to achieve interoperability. A full list of all implementations can be found [here.](https://www.w3.org/TR/did-spec-registries/#did-methods) Please keep in mind that unfortunately most of these methods are outdated and not maintained.

## DID Documents

The purpose of a DID is to help navigate to a DID Document, which is a document containing more information regarding the identity subject. This document contains data such as public keys, enabling the subject to prove ownership over their personal data, but also URIs that link to public information about the identity.

The identifier contains all information to resolve a DID, providing the latest DID Document. The first three characters `did` indicate that the DID standard from W3C must be used to resolve the identifier. It is followed by a unique method name, in our case `iota`, to indicate that the IOTA method is used. The IOTA method is a specific implementation that follows the following [method spec](../../specs/iota_did_method_spec.md). This provides unique rules for the protocol to follow in order to result in the latest DID Document. In our case it describes how DID Documents are uploaded and queried to and from the IOTA Tangle. Lastly, a DID contains a set of random characters that are unique per identity, this makes the identity unique and makes sure every identity resolves to a unique DID Document.
The identifier contains all information to resolve a DID, providing the latest DID Document. The first three characters `did` indicate that the DID standard from W3C must be used to resolve the identifier. It is followed by a unique method name, in our case `iota`, to indicate that the IOTA method is used. The IOTA method is a specific implementation that follows the following [method spec](../../specs/iota_did_method_spec.md). This provides unique rules for the protocol to follow to result in the latest DID Document. In our case, it describes how DID Documents are uploaded and queried to and from the IOTA Tangle. Lastly, a DID contains a set of random characters that are unique per identity, this makes the identity unique and makes sure every identity resolves to a unique DID Document.

:::tip Requires basic knowledge of Assymtric Encryption
:::tip Requires basic knowledge of Asymmetric Encryption

The following and later sections require some basic knowledge of Assymetric Encryption. Please read or view some materials in the subject before continuing.
The following and later sections require some basic knowledge of Asymmetric Encryption. Please read or view some materials on the subject before continuing.

:::

A DID Document mostly contains two important pieces of data: public keys and services. The public keys can be used to prove ownership over the identity, by cryptographically signing something with the associated private key. The public key can be used to verify that the identity subject signed the data and therefore controls the private key. Ownership over the private keys therefore prove ownership over the identity. This also means that it is very important to keep the private keys safe and secure. In addition, the public keys allow users to send encrypted data to the identity, using their public key, that only the identity owner can decrypt.
A DID Document mostly contains two important pieces of data: public keys and services. The public keys can be used to prove ownership over the identity, by cryptographically signing something with the associated private key. The public key can be used to verify that the identity subject signed the data and therefore controls the private key. Ownership over the private keys, therefore, proves ownership over the identity. This also means that it is very important to keep the private keys safe and secure. In addition, the public keys allow users to send encrypted data to the identity, using their public key, that only the identity owner can decrypt.

:::caution

Never share your private keys, seeds, passphrases with anyone. Not even IOTA Foundation members. This may lead to loss of IOTA funds or control over your own digital identity.

:::

Services are URIs that point to more information about the identity. This could be something as simple as a website for a organizational identity. These services are publicly avaliable for all to read and should therefore not contain Personal Identifiable Information (PII) in the case of human identities.
Services are URIs that point to more information about the identity. This could be something as simple as a website for an organizational identity. These services are publicly available for all to read and should therefore not contain Personal Identifiable Information (PII) in the case of human identities.

## Why use DIDs?

DIDs have some limited use cases. It allows any subject to have a unique identifier, that they can prove ownership off and at the same time provide a way to send them encrypted messages. The Identity is Self Sovereign, meaning the subject is control of when the identity is created, but also destroyed.
DIDs have some limited use cases. It allows any subject to have a unique identifier, that they can prove ownership of and at the same time provide a way to send them encrypted messages. The Identity is Self Sovereign, meaning the subject is in control of when the identity is created but also destroyed.

DIDs become really interesting in combination with Verifiable Credentials, that will be covered in a later section. In essence, Verifiable Credentials (VCs) are signed statements by trusted third parties about a certain identity. The signer, or Issuer, is referenced by DID and so is the subject, often called the Holder. The Holder can control a copy of this statement and share this with other parties, the Verifiers, that can verify the statement and check which party gave out the statement, without having to ask the Issuer. Instead, they can verify the signature of the Issuer by checking the Issuers DID Document. This whole set up puts Holders back into control over their own data, but also makes the data much more trustworthy as it has become verifiable.
DIDs become interesting in combination with Verifiable Credentials, which will be covered in a later section. In essence, Verifiable Credentials (VCs) are signed statements by trusted third parties about a certain identity. The signer, or Issuer, is referenced by the DID and so is the subject, often called the Holder. The Holder controls a copy of this statement and share it with other parties, the Verifiers, that can verify the statement and check which party made the statement, without having to ask the Issuer. Instead, they can verify the signature of the Issuer by checking the Issuers DID Document. This whole setup puts Holders back in control over their own data, but also makes the data much more trustworthy as it has become verifiable.

## Why use IOTA Identity over other implementations?

IOTA Identity is a framework to implement Self Sovereign Identities on IOTA. Inherently, IOTA provides some unique features that have a major impact on the usability of the framework.
IOTA Identity is a framework to implement Self-Sovereign Identities on IOTA. Inherently, IOTA provides some unique features that have a major impact on the usability of the framework.

### Feeless

IOTA is a feeless Distributed Ledger Technology, that means that messages can immutably be stored inside the Tangle at no-cost, nor a requirements of holding any cryptocurrency tokens. That means that SSI applications can directly deploy towards the main network without any problems, as compared to most other SSI solutions running on a test network or having cryptocurrency requirements. This doesn't just make IOTA Identity have predictable costs and prevent issues around cryptocurrency holding taxes and legislation, it also makes it a fair network as anyone would be able to create one or more identities at no costs. The wealth of someone is irrelevant, making it the most inclusive SSI solution.
IOTA is a feeless Distributed Ledger Technology, which means that messages can immutably be stored inside the Tangle at no cost, nor a requirement of holding any cryptocurrency tokens. That means that SSI applications can directly deploy towards the main network without any problems, as compared to most other SSI solutions running on a test network or having cryptocurrency requirements. This doesn't just make IOTA Identity have predictable costs and prevent issues around cryptocurrency holding taxes and legislation, it also makes it a fair network as anyone would be able to create one or more identities at no cost. The wealth of someone is irrelevant, making it the most inclusive SSI solution.

### Ease-of-use

Without the need for a token, IOTA Identity can directly be used on the main network without having to purchase and manage a cryptocurrency token. In addition, the framework provides easy-to-use APIs that allow both standardized behavior or flexible, yet more complex access. Lastly, IOTA Identity provides a Stronghold solution for managing secrets in a secure manner, without requiring developers to reinvent the security wheel.
Without the need for a token, IOTA Identity can directly be used on the main network without having to purchase and manage a cryptocurrency token. In addition, the framework provides easy-to-use APIs that allow both standardized behavior or flexible, yet more complex access. Lastly, IOTA Identity provides a Stronghold solution for managing secrets securely, without requiring developers to reinvent the security wheel.

### General Purpose DLT

IOTA is a general purpose DLT as compared to some for-purpose DLTs with restricted use cases. That means that SSI can easily be combined with other DLT features such as payments, data streams, smart contracts and access control. It will no longer be needed to utilize multiple DLT projects alongside each other.
IOTA is a general-purpose DLT as compared to some for-purpose DLTs with restricted use cases. That means that SSI can easily be combined with other DLT features such as payments, data streams, smart contracts, and access control. It will no longer be needed to utilize multiple DLT projects alongside each other.

1 change: 1 addition & 0 deletions documentation/sidebars.js
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,7 @@ module.exports = {
'getting-started/decentralized_identifiers/create',
'getting-started/decentralized_identifiers/resolve',
'getting-started/decentralized_identifiers/update',
'getting-started/decentralized_identifiers/manage',
'getting-started/decentralized_identifiers/merkle_key_collection',
],
},
Expand Down
Loading

0 comments on commit b755a40

Please sign in to comment.