From 188b90cd259ab5c831b33045d41f0b71d642ec77 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Tue, 2 Apr 2024 16:42:41 +0200 Subject: [PATCH 01/16] Change web3name Signed-off-by: Chris Chinchilla --- .../src/core_features/getting_started/03_fetch_did.ts | 4 ++-- .../src/core_features/getting_started/index.ts | 2 +- .../sdk_examples/src/core_features/web3names/index.ts | 6 +++--- docs/develop/01_sdk/01_quickstart.md | 8 ++++---- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/code_examples/sdk_examples/src/core_features/getting_started/03_fetch_did.ts b/code_examples/sdk_examples/src/core_features/getting_started/03_fetch_did.ts index 4e8dcea33..497c2e06a 100644 --- a/code_examples/sdk_examples/src/core_features/getting_started/03_fetch_did.ts +++ b/code_examples/sdk_examples/src/core_features/getting_started/03_fetch_did.ts @@ -4,13 +4,13 @@ import * as Kilt from '@kiltprotocol/sdk-js' export async function main(): Promise { let apiConfig = Kilt.ConfigService.get('api') const encodedJohnDoeDetails = - await apiConfig.call.did.queryByWeb3Name('john_doe') + await apiConfig.call.did.queryByWeb3Name('kiltnerd123') // This function will throw if johnDoeOwner does not exist const { document: { uri } } = Kilt.Did.linkedInfoFromChain(encodedJohnDoeDetails) - console.log(`My name is john_doe and this is my DID: "${uri}"`) + console.log(`My name is kiltnerd123 and this is my DID: "${uri}"`) return uri } diff --git a/code_examples/sdk_examples/src/core_features/getting_started/index.ts b/code_examples/sdk_examples/src/core_features/getting_started/index.ts index 87c1ec93b..54da74d03 100644 --- a/code_examples/sdk_examples/src/core_features/getting_started/index.ts +++ b/code_examples/sdk_examples/src/core_features/getting_started/index.ts @@ -12,7 +12,7 @@ import { main as verifyCredential } from './06_verify_credential' async function fetchDidAndCredential() { const johnDoeDid = await fetchJohnDoeDid() if (!johnDoeDid) - throw new Error('"john_doe" is not associated to any DID on Spiritnet') + throw new Error('"kiltnerd123" is not associated to any DID on Spiritnet') const endpoints = await fetchJohnDoeEndpoints(johnDoeDid) if (!endpoints || !endpoints.length) throw new Error(`DID doesn't include services`) diff --git a/code_examples/sdk_examples/src/core_features/web3names/index.ts b/code_examples/sdk_examples/src/core_features/web3names/index.ts index 66764f2ef..1a49ae271 100644 --- a/code_examples/sdk_examples/src/core_features/web3names/index.ts +++ b/code_examples/sdk_examples/src/core_features/web3names/index.ts @@ -45,13 +45,13 @@ export async function runAll( throw new Error('web3name is registered for a wrong DID') } - console.log('3 w3n) Query credentials for "john_doe" web3name') + console.log('3 w3n) Query credentials for "kiltnerd123" web3name') try { - await queryPublishedCredentials('john_doe') + await queryPublishedCredentials('kiltnerd123') } catch (e) { if (e instanceof FetchError) { console.log( - 'Query credentials for "john_doe" web3name failed because of bad IPFS gateway. Ignoring this.' + 'Query credentials for "kiltnerd123" web3name failed because of bad IPFS gateway. Ignoring this.' ) } else { // This one should not have happened. diff --git a/docs/develop/01_sdk/01_quickstart.md b/docs/develop/01_sdk/01_quickstart.md index e1c043217..fc914acaa 100644 --- a/docs/develop/01_sdk/01_quickstart.md +++ b/docs/develop/01_sdk/01_quickstart.md @@ -160,7 +160,7 @@ The next step is to start querying data from the blockchain. ## Query a KILT Identity -The following code queries information related to a **web3name** (`john_doe`) and uses it to retrieve the **KILT DID** linked to it. +The following code queries information related to a **web3name** (`kiltnerd123`) and uses it to retrieve the **KILT DID** linked to it. Between the `Kilt.connect()` and `Kilt.disconnect()` lines, add the following code: @@ -173,8 +173,8 @@ dropTail="1" Try running the code and check the result. -Did you get the DID? You now have `john_doe`'s DID. -The next step is to see if `john_doe` has any publicly linked KILT credentials to retrieve and verify. +Did you get the DID? You now have `kiltnerd123`'s DID. +The next step is to see if `kiltnerd123` has any publicly linked KILT credentials to retrieve and verify. ## Retrieve and Verify a Credential @@ -184,7 +184,7 @@ A **KILT DID** can expose services that allow external resources to be linked to You can retrieve the **services** attached to John Doe's DID and see if they link to any public credentials to **query** and **verify**. Add the following code after the code you added in the previous step but before the `await Kilt.disconnect()`. -It retrieves the services exposed by the DID found for `john_doe`: +It retrieves the services exposed by the DID found for `kiltnerd123`: Date: Thu, 2 May 2024 15:20:29 +0200 Subject: [PATCH 02/16] Update index and footer Signed-off-by: Chris Chinchilla --- docusaurus.config.js | 4 ---- src/pages/index.js | 6 +++--- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/docusaurus.config.js b/docusaurus.config.js index d6053c3df..8ae6ee9ba 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -149,10 +149,6 @@ module.exports = { label: 'Discord', href: 'https://discord.gg/hX4pc8rdHS', }, - { - label: 'Telegram', - href: 'https://t.me/KILTProtocolChat', - }, { label: 'Twitter', href: 'https://twitter.com/Kiltprotocol', diff --git a/src/pages/index.js b/src/pages/index.js index c287dafec..956f63eea 100644 --- a/src/pages/index.js +++ b/src/pages/index.js @@ -15,7 +15,7 @@ const featureRows = [ link: 'docs/concepts/what-is-kilt', description: ( <> - Learn about KILT identity components and why they matter. Read on KILT + Learn about KILT identity components and why they matter. Read about KILT credentials and what they provide. ), @@ -27,8 +27,8 @@ const featureRows = [ link: 'docs/develop/sdk/quickstart', description: ( <> - Start building with KILT. Issue and verify your first credential or - set up an app. + Start building with KILT to issue and verify your first credential. + Use the KILT SDK with your app. ), }, From 499dbd928c3bf5f7a0a04ef047d58d9dd3f53df8 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Tue, 7 May 2024 10:08:11 +0200 Subject: [PATCH 03/16] Draft Signed-off-by: Chris Chinchilla --- docs/concepts/01_what_is_kilt.md | 18 +++++----- docs/concepts/02_did.md | 56 +++++++++++++++++++++----------- 2 files changed, 46 insertions(+), 28 deletions(-) diff --git a/docs/concepts/01_what_is_kilt.md b/docs/concepts/01_what_is_kilt.md index 226304b9e..401a4c289 100644 --- a/docs/concepts/01_what_is_kilt.md +++ b/docs/concepts/01_what_is_kilt.md @@ -10,12 +10,12 @@ The core component of KILT is a digital identity protocol for: 1. Generating and managing [**decentralized identifiers (DIDs)**](./10_glossary.md#Decentralized-Identifiers-(DID)) 2. Issuing and presenting digital [**verifiable credentials (VCs)**](./10_glossary.md#verifiable-credentials). -In contrast to other centralized alternatives, KILT features self-sovereign data as well as revocable [credentials](./10_glossary.md#credential) anchored to the KILT blockchain. +In contrast to other centralized alternatives, KILT features self-sovereign data and revocable [credentials](./10_glossary.md#credential) anchored to the KILT blockchain. KILT was built to be a business enabler, not only for the software industry but also for any entity. Such entities can establish a business model based on the trust infrastructure KILT provides, which is an essential building block of Web 3.0. -## What KILT Provides +## What KILT provides In particular, KILT provides: @@ -26,22 +26,22 @@ In particular, KILT provides: KILT's main goal is to generate a level playing field for companies to explore new business models related to trust relationships and data sovereignty. KILT enables businesses and governments to rely on a common standard owned by everyone participating and not by a single company or set thereof. -## The Problem +## The problem In the beginning, identity and trust between entities were organized in a fully decentralized way. Individuals created trust relationships directly between them based on their observations. Of course, this had major drawbacks: * The size of the personal social network is limited -* It is not trivial to judge the trustworthiness of an individual -* It is hard to prove one's own identity to outsiders +* It's not trivial to judge the trustworthiness of an individual +* It's hard to prove one's own identity to outsiders When people started to organize themselves in bigger groups, founding villages and cities, those drawbacks were amplified and people needed to address them. People introduced mechanisms to create trust relationships between groups by issuing some form of attestation. -In this way, people who do not know the individual directly but who trusted the group that gave the attestation, for example, a carpenter's guild, a monastery or a Scottish clan, could verify certain properties about another individual. +In this way, people who don't know the individual directly but who trusted the group that gave the attestation. For example, a carpenter's guild, a monastery or a Scottish clan could verify certain properties about another individual. When the organizational structures grew further and large bureaucratic nations emerged, the authorities issuing those attestations and the scope of the trust relationships also grew. -Though we can now see a more and more centralized way of organizing trust, the actual information that makes up an identity is still handed out directly to the individual, who is still responsible for their data. +While there is now a more centralized way of organizing trust, the actual information that makes up an identity is still handed out directly to the individual, who is still responsible for their data. Take official personal documents like passports as an example. Trusted entities issue them and hand them out to the holder. That holder then has full control of their credential (their passport) and can use it wherever needed. @@ -54,10 +54,10 @@ Every time users log into any service, they generate new data points which are t KILT Protocol aims to change that and give users back control over their data. -## The Solution +## The solution KILT provides a protocol and the tools for people to manage their own data, and to build a [digital identity](./10_glossary.md#digital-identity) by collecting credentials issued by trusted entities. -Such credentials are not publicly available but stay within the user's control. +Such credentials aren't publicly available but stay within the user's control. This is similar to the approach used for centuries before big corporations monetized our data. The core ideas are: diff --git a/docs/concepts/02_did.md b/docs/concepts/02_did.md index 3a47ac9d7..6f408c051 100644 --- a/docs/concepts/02_did.md +++ b/docs/concepts/02_did.md @@ -4,12 +4,18 @@ title: KILT Decentralized Identifiers (DIDs) --- A KILT decentralized identifier (DID) is a string of letters and numbers uniquely identifying each KILT user. -A DID can be thought of as a container of different keys that are all under the control of the same DID subject. -For the official W3C DID spec, please visit the [DID Core spec page](https://www.w3.org/TR/did-core/); for the official KILT DID method specification, see the [KILT DID spec page](https://github.com/KILTprotocol/spec-kilt-did). -The simplest type of KILT DID is called a **light DID**, because it can be generated and used offline without any internet connection (hence any connection with the KILT blockchain at all). -Although very cheap, light DIDs are not very flexible and are only suitable for low-security use cases. -In more complex use cases, an on-chain **full DID** is required, which allows the subject to store several different keys (and key types) and replace them over time, with the support of the KILT blockchain. +Think of a DID as a container of different keys all under the control of the same DID subject. + +:::info DID spec + +For the official W3C DID spec, read the [DID Core spec page](https://www.w3.org/TR/did-core/); for the official KILT DID method specification, read the [KILT DID spec page](https://github.com/KILTprotocol/spec-kilt-did). + +::: + +The simplest type of KILT DID is a **[light DID](#light-dids)**, because you can generate and use it offline and no connection with the KILT blockchain. +Although cheap, light DIDs aren't flexible and are only suitable for low-security use cases. +In more complex use cases, you need an on-chain **[full DID](#full-dids)**, which allow the subject to store different keys and key types and replace them over time by using the KILT blockchain. ## Light DIDs @@ -19,9 +25,11 @@ The following is an example of a light KILT DID: did:kilt:light:014nv4phaKc4EcwENdRERuMF79ZSSB5xvnAk3zNySSbVbXhSwS ``` -Beyond the standard prefix `did:kilt:`, the `light:` component indicates that this DID is a light DID, hence it can be resolved and utilized offline. +Beyond the standard prefix `did:kilt:`, the `light:` component indicates that this DID is a light DID, hence it can be resolved and used offline. + + -Light DIDs optionally support the specification of an **encryption key** (of one of the supported key types) and services, which are both serialized, encoded and added at the end of the DID, like the following: +Light DIDs optionally support the specification of an **encryption key** (of one of the supported key types) and services, which are both serialized, encoded, and added at the end of the DID, like the following: ``` did:kilt:light:014nv4phaKc4EcwENdRERuMF79ZSSB5xvnAk3zNySSbVbXhSwS:z1ERkVVjngcarMbJn6YssB1PYULescQneSSEfCTJwYbzT2aK8fzH5WPsp3G4UVuLWWfsTayketnFV74YCnyboHBUvqEs6J8jdYY5dK2XeqCCs653Sf9XVH4RN2WvPrDFZXzzKf3KigvcaE7kkaEwLZvcas3U1M2ZDZCajDG71winwaRNrDtcqkJL9V6Q5yKNWRacw7hJ58d @@ -29,8 +37,8 @@ did:kilt:light:014nv4phaKc4EcwENdRERuMF79ZSSB5xvnAk3zNySSbVbXhSwS:z1ERkVVjngcarM ## Full DIDs -As mentioned above, the creation of a full DID requires interaction with the KILT blockchain. -Therefore, the DID creation operation must be submitted by a KILT address with enough funds to pay the transaction fees and the required deposit. +The creation of a full DID requires interaction with the KILT blockchain. +Therefore, a KILT address with enough funds to pay the transaction fees and the required deposit must submit the DID creation operation. The following is an example of a full KILT DID: @@ -38,29 +46,39 @@ The following is an example of a full KILT DID: did:kilt:4rp4rcDHP71YrBNvDhcH5iRoM3YzVoQVnCZvQPwPom9bjo2e ``` -Here, there is no `light:` component, which indicates that the DID is a full DID and that the keys associated with it must not be derived from the DID identifier, but must be retrieved from the KILT blockchain. +Above, there is no `light:` component. This indicates that the DID is a full DID and that you can't derive the keys associated with it from the DID identifier, but retrieve them from the KILT blockchain. -Along with an authentication key, an encryption key, and services, a full DID also supports an **attestation key**, which must be used to write CTypes and attestations on the blockchain, and a **delegation key**, which must be used to write delegations on the blockchain. +Along with an authentication key, encryption key, and services, a full DID also supports an **attestation key**, which you must use to write CTypes and attestations on the blockchain, and a **delegation key** to write delegations on the blockchain. -## Migrating a Light DID to a Full DID +## Migrating a light DID to a full DID The **migration** of a DID means that a light, off-chain DID is anchored to the KILT blockchain, supporting all the features that full DIDs provide. In the current version (v1) of the KILT DID protocol, a light DID of the form `did:kilt:light:014nv4phaKc4EcwENdRERuMF79ZSSB5xvnAk3zNySSbVbXhSwS` would become a full DID of the form `did:kilt:4nv4phaKc4EcwENdRERuMF79ZSSB5xvnAk3zNySSbVbXhSwS`. -Note that the identifier of the two DIDs, apart from the initial `01` sequence of the light DID, are the same since both DIDs are derived from the same seed. -**Once a light DID is migrated, all the credentials collected by the light DID can only be presented using the migrated on-chain DID.** -This is by design, as it is assumed that the user had valid reasons to migrate the DID, and as on-chain DIDs offer greater security guarantees. -KILT will thus reject light DID signatures even if the original claim in the credential was generated with that off-chain DID. +:::note + +The identifier of the two DIDs, apart from the initial `01` sequence of the light DID, are the same since both DIDs are derived from the same seed. + +::: + +**Once you migrate a light DID, you can only present all the credentials collected by the light DID using the migrated on-chain full DID.** + +This restriction is by design, as it's assumed that the user had valid reasons to migrate the DID, as on-chain DIDs offer greater security guarantees. +KILT thus rejects light DID signatures even if the original claim in the credential was generated with that off-chain DID. + +:::tip + +For a detailed developer-oriented guide to KILT DIDs, read the [DID Cookbook section](../develop/01_sdk/02_cookbook/01_dids/01_light_did_creation.md). -For a detailed developer-oriented guide to KILT DIDs, see our [DID Cookbook section](../develop/01_sdk/02_cookbook/01_dids/01_light_did_creation.md). +::: ## Storing a DID -Storing a DID in the blockchain requires a deposit, consisting of a base deposit and an additional fee. The base deposit is a fixed amount of 4 KILT, while the additional fee is 0.05 KILT. +Storing a DID on the KILT blockchain requires a deposit, consisting of a base deposit and an additional fee. The base deposit is a fixed amount of 4 KILT, while the additional fee is 0.05 KILT. In addition to the base deposit and fee, the total deposit increases based on the storage space used by the DID. Each byte of storage occupied by the DID requires a deposit of 50 micro KILT (0.000005 KILT). The overall size of the DID is determined by the inclusion of services and keys. The more services and keys in the DID, the larger the storage space required and, consequently, the higher the additional deposit. When updating the DID, the deposit is automatically adjusted to match the updated size. This ensures that the deposit accurately reflects the current storage requirements of the DID, whether they increase or decrease. -The deposit can be reclaimed when the DID is deleted from the blockchain, allowing users to retrieve the deposited amount. However, please note that the additional fee cannot be refunded once it has been paid. +You can reclaim the deposit when the DID is deleted from the blockchain, allowing users to retrieve the deposited amount. However, the additional fee can't be refunded once paid. \ No newline at end of file From aa528fee21c265ee2f84f90d44e040aadc25cd8c Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Tue, 7 May 2024 13:46:18 +0200 Subject: [PATCH 04/16] Draft Signed-off-by: Chris Chinchilla --- docs/concepts/02_did.md | 3 +- docs/concepts/03_web3names.md | 54 ++++++++++++++++++++-------------- docs/concepts/04_asset_dids.md | 44 +++++++++++++-------------- 3 files changed, 55 insertions(+), 46 deletions(-) diff --git a/docs/concepts/02_did.md b/docs/concepts/02_did.md index 6f408c051..427864763 100644 --- a/docs/concepts/02_did.md +++ b/docs/concepts/02_did.md @@ -77,7 +77,8 @@ For a detailed developer-oriented guide to KILT DIDs, read the [DID Cookbook sec Storing a DID on the KILT blockchain requires a deposit, consisting of a base deposit and an additional fee. The base deposit is a fixed amount of 4 KILT, while the additional fee is 0.05 KILT. In addition to the base deposit and fee, the total deposit increases based on the storage space used by the DID. Each byte of storage occupied by the DID requires a deposit of 50 micro KILT (0.000005 KILT). -The overall size of the DID is determined by the inclusion of services and keys. The more services and keys in the DID, the larger the storage space required and, consequently, the higher the additional deposit. + +The inclusion of services and keys determines the overall size of the DID. The more services and keys in the DID, the larger the storage space required and, consequently, the higher the additional deposit. When updating the DID, the deposit is automatically adjusted to match the updated size. This ensures that the deposit accurately reflects the current storage requirements of the DID, whether they increase or decrease. diff --git a/docs/concepts/03_web3names.md b/docs/concepts/03_web3names.md index 4a88a9085..50bca80d2 100644 --- a/docs/concepts/03_web3names.md +++ b/docs/concepts/03_web3names.md @@ -5,19 +5,20 @@ title: web3names import ThemedImage from '@theme/ThemedImage'; -In short, web3names are user-friendly aliases for KILT DIDs. -They serve the same purpose that domain names do for IP addresses: who knows the IP address under the `kilt.io` domain name? 🤷🏽‍♀️ +web3names are user-friendly aliases for KILT DIDs. +They serve the same purpose as domain names for IP addresses. Do you know the IP address for the "kilt.io" domain name? 🤷🏽‍♀️ There is a one-to-one relationship between DIDs and web3names. -This means that a KILT DID can be linked to only one web3name, and a web3name can be claimed only by one DID. +This means that you can link a KILT DID to only one web3name, and a web3name can only claim one DID. + +Each web3name is globally unique within the KILT blockchain and consists of a sequence of a minimum of 3 to a maximum of 32 characters taken from a specific character set to enhance human readability and reduce the chances of *two web3names looking the same, despite being different*. -Each web3name is globally unique within the KILT space, and is composed of a sequence of a minimum of 3 to a maximum of 32 characters taken from a specific character set to enhance human readability and reduce the chances of *two web3names looking the same, despite being different*. The character set includes only: - *lowercase letters*, from `a` to `z` - *digits* from `0` to `9` - the symbols `-` and `_` -A regex that would match all and only the allowed web3names would be the following: +A regex that matches all and only the allowed web3names is the following: ``` ^[a-z0-9_-]{3,32}$ @@ -26,13 +27,13 @@ A regex that would match all and only the allowed web3names would be the followi In the global URI space, web3names are prefixed with the `w3n:` URI namespace. For example, the full URI for the web3name `example-web3name` is `w3n:example-web3name`. -### Linking Multiple Accounts to a web3name +### Linking multiple accounts to a web3name -Beyond linking a web3name, KILT allows DID owners to link multiple accounts to a single DID. -These accounts are not specific to the KILT blockchain; they can reference any chain within the Polkadot ecosystem. -Each account to DID link requires the payment of a small deposit. +Beyond linking a web3name, KILT lets DID owners link multiple accounts to a single DID. +These accounts aren't specific to the KILT blockchain. They can reference any chain within the Polkadot ecosystem. +Each account to DID link requires paying a small deposit. -For DIDs that have also claimed a web3name, the linking feature opens up the way to a host of possibilities, e.g., showing the web3name of a collator's account on the [KILT Stakeboard](https://stakeboard.kilt.io/). +For DIDs that have also claimed a web3name, the linking feature opens the way to a host of possibilities. For example, showing the web3name of a collator's account on the [KILT Stakeboard](https://stakeboard.kilt.io/). -For a detailed developer-oriented guide to web3names and account linking, see our [web3name Cookbook section](../develop/01_sdk/02_cookbook/02_web3names/01_claim.md) and our [account linking Cookbook section](../develop/01_sdk/02_cookbook/03_account_linking/01_link.md). +For a detailed developer-oriented guide to web3names and account linking, read the [web3name Cookbook section](../develop/01_sdk/02_cookbook/02_web3names/01_claim.md) and the [account linking Cookbook section](../develop/01_sdk/02_cookbook/03_account_linking/01_link.md). + +## KILT DIDs vs. KILT accounts + +While you can link multiple accounts to a DID, it's important to notice the difference between the two. + +KILT *accounts* are classical blockchain accounts, that can hold and send KILT tokens, and sign and submit transactions. + +KILT *DIDs* are a higher level construct derived from KILT accounts, but are completely separated from them. + +This means that **KILT DIDs can't hold any KILT tokens**. + +You use DIDs to authorize (sign) some operations, but you must submit the resulting signature to the KILT blockchain with a KILT account, which must pay for the transaction fees. + +Don't consider a DID `did:kilt:4rp4rcDHP71YrBNvDhcH5iRoM3YzVoQVnCZvQPwPom9bjo2e` the same as the account `4rp4rcDHP71YrBNvDhcH5iRoM3YzVoQVnCZvQPwPom9bjo2e`, although they share the same identifier. :::caution -While multiple accounts can be linked to a DID, it is important to notice the difference between the two. -KILT *accounts* are classical blockchain accounts, that can be used to hold and send KILT tokens, as well as to sign and submit transactions. -On the other hand, KILT *DIDs* are a higher level construct which are derived from KILT accounts, but are completely separated from them. -This means that **KILT DIDs cannot hold any KILT tokens**. -DIDs are used to authorize (sign) some operations, but the resulting signature must then be submitted to the blockchain by a KILT account, which must pay for the transaction fees. +There's no (immediate) relationship between the two, so you should consider a DID **only as a DID** and never as an account. +If instructed to "*send some funds to the DID by using the account after the `did:kilt` prefix*". Ignore the advice, as without the required technical expertise, sending funds to a DID can result in loss of those funds. -A DID `did:kilt:4rp4rcDHP71YrBNvDhcH5iRoM3YzVoQVnCZvQPwPom9bjo2e` is not to be considered the same as the account `4rp4rcDHP71YrBNvDhcH5iRoM3YzVoQVnCZvQPwPom9bjo2e`, although they share the same identifier. -There is no (immediate) relationship between the two, thus the DID should always be considered a DID and never used as an account. -Therefore, if instructed to "*send some funds to the DID by using the account after the `did:kilt` prefix*", please ignore the advice, as without the required technical expertise, sending funds to a DID can result in those funds being lost. ::: -### Storing web3name +### The cost for storing a web3name -Storing a web3name in the blockchain requires providing a constant deposit, which is currently around 0.11 KILT. The deposit amount is calculated based on the worst-case scenario for a web3name, which is when a user provides a name with 32 characters. The deposit serves -as a security measure to ensure the integrity of the blockchain and incentivize users to manage their web3names responsibly. By requiring a deposit, it discourages spamming or unnecessary creation of web3names. The deposit can be reclaimed by the user by deleting their web3name. +Storing a web3name on the KILT blockchain requires providing a constant deposit, which is currently around 0.11 KILT. The deposit amount is calculated based on the worst-case scenario for a web3name, which is when a user provides a name with 32 characters. +The deposit serves as a security measure to ensure the integrity of the KILT blockchain and incentivize users to manage their web3names responsibly. +A deposit discourages spamming or unnecessary creation of web3names. You can reclaim the deposit can by deleting a web3name. diff --git a/docs/concepts/04_asset_dids.md b/docs/concepts/04_asset_dids.md index b252d3c6a..f0c6ef493 100644 --- a/docs/concepts/04_asset_dids.md +++ b/docs/concepts/04_asset_dids.md @@ -5,45 +5,43 @@ title: AssetDIDs import ThemedImage from '@theme/ThemedImage'; -KILT DIDs are suitable for those use cases that involve so-called "active" participants, i.e., entities that can act out of their will (a person, an organization, a DAO). +KILT DIDs are suitable for use cases that involve "active" participants. For example, entities that can act of their will (a person, an organization, a DAO). -There are classes of entities that represent "passive" participants, i.e., they can be "used" by active participants within a given use case. -We define these class of participants **assets**. -As with traditional KILT users, assets also need to be uniquely identified. +There are classes of entities that represent "passive" participants. That is, they can be "used" by active participants within a given use case. +KILT defines these class of participants as **assets**. +As with traditional KILT users, assets also need to be uniquely identified, with an *AssetDID*. -This is what an *AssetDID*, of which KILT is the ideator and initial editor, does. An example of a valid AssetDID is the following: `did:asset:eip155:1.erc721:0xb47e3cd837ddf8e4c57f05d70ab865de6e193bbb`. This AssetDID refers to the [CryptoPunks NFT collection][cryptopunks-nft]. ## AssetDID structure -An AssetDID is a *generative* identifier, meaning that it does not depend nor rely on any information stored anywhere. -Rather, given the asset that needs to be identified, it is **always** possible to generate its AssetDID (hence the term generative). -The reverse is also true: given an AssetDID, it is always possible to dereference it into its building components which, together, uniquely identified a given asset. +An AssetDID is a *generative* identifier, meaning that it doesn't depend nor rely on any information stored anywhere. +Rather, given the asset to identify, it's **always** possible to generate its AssetDID. +The reverse is also true. Given an AssetDID, it's always possible to dereference it into its components which, together, uniquely identified a given asset. AssetDIDs always start with the `did:asset` prefix, and then contain a *chain* component (namespace + reference) and an *asset* component (namespace + reference + identifier). -### Chain Namespace and Chain Reference +### Chain namespace and reference + +Together, the namespace and reference identify the (blockchain) network on which the asset lives. -Together, they identify the (blockchain) network on which the asset lives. +In the case of NFTs, this represents the blockchain on which the smart contract is deployed. +Different deployments of the same network have the same chain namespace but a different reference. +For instance, both the Ethereum mainnet and the Goerli testnet have a chain namespace of `eip155`, but the former is identified by the reference `1` (as the mainnet), while the Goerli testnet is identified by the reference `5`. -In the case of NFTs, this would represent the blockchain on which the smart contract is deployed. -Different deployments of the same network will have the same chain namespace but a different reference. -For instance, both the Ethereum mainnet and the Goerli testnet have a chain namespace of `eip155`, but the former is identified by the reference `1` (being the mainnet), while the Goerli testnet is identified by the reference `5`. +### Asset namespace, reference and identifier -A list of Ethereum chain IDs (which are used as reference) can be found on [chainlist.org][chainlist]. - -### Asset Namespace, Asset Reference and Asset Identifier - -Similarly to their chain counterparts, asset *namespaces* are used to distinguish among different asset classes that might live within the same environment. -In the case of NFTs for instance, a smart contract could support both ERC20 (fungible) and ERC721 (non-fungible) tokens, hence the namespace is used to distinguish between the two token types. +Similar to their chain counterparts, you use asset *namespaces* to distinguish among different asset classes within the same environment. +In the case of NFTs, a smart contract could support both ERC20 (fungible) and ERC721 (non-fungible) tokens, hence the namespace distinguishes between the two token types. Each asset namespace defines the semantics and the meaning of asset references and asset identifiers within that namespace. -In the example of Ethereum-based NFTs, the asset *reference* identifies the smart contract address on which the NFT is stored. -**Hence, the combination of asset namespace + asset reference is sufficient to identify an NFT collection on a given network.** +In the example of Ethereum-based NFTs, the asset *reference* identifies the smart contract address that stores the NFT. + +**The combination of asset namespace + asset reference is sufficient to identify an NFT collection on a given network.** -For some assets, for instance NFTs, it is possible to specify an asset *identifier*, which is used to refer to a single item within the collection. -In the example of the CryptoPunks collection above, the AssetDID could be extended with an additional `:1005` to now refer to the [CryptoPunk piece #1005][cryptopunk-1005] rather than to the CryptoPunks collection as a whole. +For some assets, for instance NFTs, it's possible to specify an asset *identifier*, used to refer to a single item within the collection. +In the example of the CryptoPunks collection, the AssetDID could be extended with an additional `:1005` to now refer to the [CryptoPunk piece #1005][cryptopunk-1005] rather than to the CryptoPunks collection as a whole. ![][cryptopunk-1005-image] From 867f0d6e7d5605bfe0f5296af9f55b9fff37de34 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 10:21:48 +0200 Subject: [PATCH 05/16] Draft Signed-off-by: Chris Chinchilla --- docs/concepts/06_distributed_trust.md | 49 +++++++++++---------------- docs/concepts/08_messaging.md | 20 +++++------ 2 files changed, 29 insertions(+), 40 deletions(-) diff --git a/docs/concepts/06_distributed_trust.md b/docs/concepts/06_distributed_trust.md index 8118060fb..751050c6e 100644 --- a/docs/concepts/06_distributed_trust.md +++ b/docs/concepts/06_distributed_trust.md @@ -5,22 +5,22 @@ title: Distributed Trust import ThemedImage from '@theme/ThemedImage'; -In some cases, Attesters are individuals that attest to the validity of claims made by Claimers. -Nevertheless, in most cases multiple Attesters group together to build up trust in a brand. -In this way, Verifiers no longer need to trust each and every Attester individually; they can put trust in the brand as a whole, which in return ensures that all Attesters working for this brand are credible. +Sometimes, Attesters are individuals that attest to the validity of claims made by Claimers. +However, usually multiple Attesters group together to build up trust in a brand. +In this way, Verifiers no longer need to trust each and every Attester individually. They can put trust in the brand as a whole, which in return ensures that all Attesters working for this brand are credible. Such a brand can be organized in many different ways. The KILT protocol provides mechanisms to form such brands on the blockchain. There are two ways for Attesters to create groups and build an organization. -The first is by creating a Delegation Hierarchy, which provides a very basic and traditional hierarchical structure. -The second option is a Virtual Credential Organization (VCO), which is not yet implemented in KILT. -Virtual Credential Organizations will be more flexible and will be able to support more decentralized use cases than Delegation Hierarchies. +The first is by creating a Delegation Hierarchy, which provides a basic and traditional hierarchical structure. +The second option is a Virtual Credential Organization (VCO), which isn't yet implemented in KILT. +VCOs will be more flexible and able to support more decentralized use cases than Delegation Hierarchies. -## Delegation Hierarchies +## Delegation hierarchies Delegation Hierarchies organize their members in a traditional hierarchical structure, and are modeled as a [Tree data structure](https://en.wikipedia.org/wiki/Tree_(data_structure)), also shown in the graph below. -Everyone in KILT can create a new hierarchy and immediately become the only member of the newly created organization. -Not only is the creator the only member of the organization, they are also the root of the hierarchy, meaning that the creator will have full control over the whole hierarchy. +Everyone can use KILT to create a new hierarchy and immediately become the only member of the newly created organization. +Not only is the creator the only member of the organization, they're also the root of the hierarchy. This means that the creator has full control over the whole hierarchy.
@@ -41,35 +41,24 @@ The graph above provides an example Delegation Hierarchy containing five Atteste **Attester 1** is the root (i.e., the creator) of the Delegation Hierarchy. At some point, Attester 1 has added two more Attesters, Attester 2 and Attester 3. **Attester 2** was given the right to both further delegate to other entities and to issue credentials on behalf of the organization. -**Attester 3**, on the other hand, was only given the right to add more Attesters to the Delegation Hierarchy, so they cannot issue any credentials. -This is useful in cases where someone should only have powers over the members, but is not authorized to do any work themselves. +**Attester 3**, on the other hand, was only given the right to add more Attesters to the Delegation Hierarchy, so they can't issue any credentials. +This is useful in cases where someone should only have powers over the members, but isn't authorized to do any work themselves. For example, in companies this could be someone who manages a team of Attesters. -**Attesters 4** and **Attester 5** were added by Attester 3 and were only given attestation permissions, meaning that they can issue new credentials, but cannot delegate any work to other Attesters. -In the company example, these would be employees that do the attestation work but have no authority to hire new staff. +**Attesters 4** and **Attester 5** were added by Attester 3 and were only given attestation permissions, meaning that they can issue new credentials, but can't delegate any work to other Attesters. +In the company example, these would be employees that attest the work but have no authority to hire new staff. ### Revocation -Delegation Hierarchies also limit who can change or remove permissions. +Delegation hierarchies limit who can change or remove permissions. For delegations, only the parents of a given Attester can change or remove the Attester's delegation itself or any of its children. -E.g., Attester 2 cannot change the delegation information for Attester 4, but Attester 1 and Attester 3 can both remove Attester 4 from the organization, or give them permission to also hire new people, which it cannot do right now. +E.g., Attester 2 can't change the delegation information for Attester 4, but Attester 1 and Attester 3 can both remove Attester 4 from the organization, or give them permission to also hire new people, which it can't do right now. -Credential revocation works similarly, with the difference that a credential can be revoked by any parent (as with delegations), or by the original Attester. -E.g., Attester 2 cannot revoke credentials issued by Attester 1, 3, 4 and 5, while Attester 1 can revoke credentials issued by any Attester since Attester 1 is, directly or indirectly, the parent of every other node. +Credential revocation works similarly, with the difference that any parent can revoke a credential (as with delegations), or by the original Attester. +E.g., Attester 2 can't revoke credentials issued by Attester 1, 3, 4 and 5, while Attester 1 can revoke credentials issued by any Attester since Attester 1 is, directly or indirectly, the parent of every other node. -## Virtual Credential Organizations - -
- -![Coming soon](@site/static/img/concepts/distributed_trust/coming-soon.png) - -[Credits to freepngimg.com.](https://freepngimg.com/png/11420-coming-soon-png-file) - -
- - -## Storing Delegation node +## Storing delegation node Adding a new node in the delegation hierarchies requires providing a constant deposit, which is currently 1 KILT. The deposit serves as a security measure to ensure the integrity of the blockchain and incentivize users to manage their nodes responsibly. By requiring a deposit, it discourages spamming or unnecessary creation of nodes. -The deposit can be reclaimed by the user by deleting their node. +When a user deletes their node, they can reclaim the deposit. \ No newline at end of file diff --git a/docs/concepts/08_messaging.md b/docs/concepts/08_messaging.md index 99899b375..1070ed633 100644 --- a/docs/concepts/08_messaging.md +++ b/docs/concepts/08_messaging.md @@ -7,27 +7,27 @@ import CodeBlock from '@theme/CodeBlock'; import encryptedMessage from '@site/scripts/out/encrypted-message.json.raw!=!raw-loader!@site/scripts/out/encrypted-message.json'; -Distributed trust on the internet only works if credentials and other information can be exchanged securely, and communicating parties can be confident that they are not being fooled or eavesdropped on by bad actors. -To help with that, KILT provides a **transport-agnostic messaging layer** that helps with securely exchanging data between the respective owners of two DIDs. +Distributed trust on the internet only works if credentials and other information can be exchanged securely, and communicating parties can be confident that bad actors aren't fooling or eavesdropping on them. +KILT provides a **transport-agnostic messaging layer** that helps with securely exchanging data between the respective owners of two DIDs. -This messaging layer provides **authenticated end-to-end encryption** – the gold standard in secure communication – in a way that hides the security of the technologies used for transporting the message over the internet – be it sending the encrypted messages via email, or posting them to and fetching them from a centralized or decentralized messaging service. +This messaging layer provides **authenticated end-to-end encryption**, the gold standard in secure communication, in a way that hides the security of the technologies used for transporting the message over the internet – be it sending the encrypted messages via email, or posting them to and fetching them from a centralized or decentralized messaging service. :::info -The messaging layer enables secure communication between two digital identities – DIDs. -A necessary condition for secure communication with a given person or organization is to make sure that the DID on the other side of the communication channel is really controlled by the other party in order to avoid attacks such as *Man in the Middle* (MitM) attacks. +The messaging layer enables secure communication between two digital identities, DIDs. +A necessary condition for secure communication with a given person or organization is to make sure that the DID on the other side of the communication channel is really controlled by the other party to avoid attacks such as *Man in the Middle* (MitM) attacks. ::: To be able to communicate, the two DIDs need to expose **key agreement public keys** for that purpose (a.k.a., an **encryption key**). -In order to send a message to the other party, a DID owner (let's call her **Alice**) looks up her peer's (let's call him **Bob**) encryption public key, which can be part of either a [full DID](./02_did.md#full-dids) or a [light DID](./02_did.md#light-dids). +To send a message to the other party, a DID owner (called **Alice**) looks up her peer's (called **Bob**) encryption public key, which can be part of either a [full DID](./02_did.md#full-dids) or a [light DID](./02_did.md#light-dids). Using this key in combination with her secret encryption key, **Alice** can now encrypt the message such that only she and **Bob** can decrypt it. A **nonce** introduces randomness and uniqueness into encryption operations, making it highly challenging for an attacker to predict or replicate the encryption process. Each message has a different **nonce**, resulting in the creation of a unique encryption context for every message. **Bob** can decrypt this message after looking up **Alice's** encryption key. An additional _message authentication code_ (MAC) added during encryption and verified on decryption protects against manipulation of the encrypted data. -As long as both parties keep their secret keys well protected, the combination of these measures allows **Bob** to be confident that if the message decrypts successfully, it could have only been encrypted by **Alice** and has not been read or tampered with by some malicious third party while in transport. +As long as both parties keep their secret keys well protected, the combination of these measures allows **Bob** to be confident that if the message decrypts successfully, only **Alice** could have encrypted it and that malicious third party hasn't read or tampered with it while in transport. While encrypted, the message travels in a compact and privacy-preserving envelope format that only exposes data that the recipient needs to be able to decrypt. @@ -35,10 +35,10 @@ While encrypted, the message travels in a compact and privacy-preserving envelop {encryptedMessage} -The encrypted message not only references the DIDs of sender and recipient, it also references the unique identifier of the keys that were used in encryption. +The encrypted message not only references the DIDs of sender and recipient, it also references the unique identifier of the keys that used in encryption. Therefore, this scheme still works if a DID should expose multiple encryption keys from which a message sender may choose. :::caution -While no one can read or change what is inside an encrypted message even if they intercept it while traveling on the network, a sophisticated attacker may try to guess what is inside and trick either side of the channel by resubmitting a copy of that message later. -For a detailed developer-oriented guide about how to protect against *replay attacks*, see our [Replay Protection Cookbook section](../develop/01_sdk/02_cookbook/06_messaging/02_replay_protection.md). +While no one can read or change what's inside an encrypted message even if they intercept it while traveling on the network, a sophisticated attacker may try to guess what's inside and trick either side of the channel by resubmitting a copy of that message later. +For a detailed developer-oriented guide about how to protect against *replay attacks*, read the [Replay Protection Cookbook section](../develop/01_sdk/02_cookbook/06_messaging/02_replay_protection.md). ::: From 0966b7aa200bb36c7de3e2ad3b532f87d6b5c017 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 13:21:54 +0200 Subject: [PATCH 06/16] Fix broken link Signed-off-by: Chris Chinchilla --- .../01_staking/02_advanced_collator_section/04_monitoring.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/participate/01_staking/02_advanced_collator_section/04_monitoring.md b/docs/participate/01_staking/02_advanced_collator_section/04_monitoring.md index 8b39bc3ab..89052ec0b 100644 --- a/docs/participate/01_staking/02_advanced_collator_section/04_monitoring.md +++ b/docs/participate/01_staking/02_advanced_collator_section/04_monitoring.md @@ -50,7 +50,7 @@ Install the latest version of docker-compose from the [official docker-compose i The configuration can be checked by visiting `https://localhost:3000` and authenticating with the username and password set in `.env` at step 3. ## Configuring Alert Notification Channel -Choose any of the supported notification channels and follow the [grafana documentation](https://grafana.com/docs/grafana/latest/alerting/old-alerting/notifications/) to receive alerts and notifications. +Choose any of the supported notification channels and follow the [grafana documentation](https://grafana.com/docs/grafana/latest/alerting/) to receive alerts and notifications. Overall, for monitoring we recommend the following stack: - Prometheus From 6a595697eb996cf5bd0ce6948084871735dcece7 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 16:29:55 +0200 Subject: [PATCH 07/16] Update docs/concepts/02_did.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/02_did.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/02_did.md b/docs/concepts/02_did.md index 427864763..3b3150966 100644 --- a/docs/concepts/02_did.md +++ b/docs/concepts/02_did.md @@ -46,7 +46,8 @@ The following is an example of a full KILT DID: did:kilt:4rp4rcDHP71YrBNvDhcH5iRoM3YzVoQVnCZvQPwPom9bjo2e ``` -Above, there is no `light:` component. This indicates that the DID is a full DID and that you can't derive the keys associated with it from the DID identifier, but retrieve them from the KILT blockchain. +Above, there is no `light:` component. +This indicates that the DID is a full DID and that you can't derive the keys associated with it from the DID identifier, but retrieve them from the KILT blockchain. Along with an authentication key, encryption key, and services, a full DID also supports an **attestation key**, which you must use to write CTypes and attestations on the blockchain, and a **delegation key** to write delegations on the blockchain. From 1c2ba8cfc627f1b63f63f5dbc25e241921d6a6f0 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 16:30:14 +0200 Subject: [PATCH 08/16] Update docs/concepts/03_web3names.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/03_web3names.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/03_web3names.md b/docs/concepts/03_web3names.md index 50bca80d2..6ae02b5eb 100644 --- a/docs/concepts/03_web3names.md +++ b/docs/concepts/03_web3names.md @@ -30,7 +30,8 @@ For example, the full URI for the web3name `example-web3name` is `w3n:example-we ### Linking multiple accounts to a web3name Beyond linking a web3name, KILT lets DID owners link multiple accounts to a single DID. -These accounts aren't specific to the KILT blockchain. They can reference any chain within the Polkadot ecosystem. +These accounts aren't specific to the KILT blockchain. +They can reference any chain within the Polkadot ecosystem. Each account to DID link requires paying a small deposit. For DIDs that have also claimed a web3name, the linking feature opens the way to a host of possibilities. For example, showing the web3name of a collator's account on the [KILT Stakeboard](https://stakeboard.kilt.io/). From 3a439fb2f3575fe0e70ac5fe422556438ebfa51c Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 16:30:26 +0200 Subject: [PATCH 09/16] Update docs/concepts/02_did.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/02_did.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/02_did.md b/docs/concepts/02_did.md index 3b3150966..3cb26bad7 100644 --- a/docs/concepts/02_did.md +++ b/docs/concepts/02_did.md @@ -79,7 +79,8 @@ Storing a DID on the KILT blockchain requires a deposit, consisting of a base de In addition to the base deposit and fee, the total deposit increases based on the storage space used by the DID. Each byte of storage occupied by the DID requires a deposit of 50 micro KILT (0.000005 KILT). -The inclusion of services and keys determines the overall size of the DID. The more services and keys in the DID, the larger the storage space required and, consequently, the higher the additional deposit. +The inclusion of services and keys determines the overall size of the DID. +The more services and keys in the DID, the larger the storage space required and, consequently, the higher the additional deposit. When updating the DID, the deposit is automatically adjusted to match the updated size. This ensures that the deposit accurately reflects the current storage requirements of the DID, whether they increase or decrease. From af8dd965483cd8ef19e94b65cf08c7d3ac9c81f4 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 16:31:01 +0200 Subject: [PATCH 10/16] Update docs/concepts/03_web3names.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/03_web3names.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/03_web3names.md b/docs/concepts/03_web3names.md index 6ae02b5eb..1e37e34ab 100644 --- a/docs/concepts/03_web3names.md +++ b/docs/concepts/03_web3names.md @@ -6,7 +6,8 @@ title: web3names import ThemedImage from '@theme/ThemedImage'; web3names are user-friendly aliases for KILT DIDs. -They serve the same purpose as domain names for IP addresses. Do you know the IP address for the "kilt.io" domain name? 🤷🏽‍♀️ +They serve the same purpose as domain names for IP addresses. +Do you know the IP address for the "kilt.io" domain name? 🤷🏽‍♀️ There is a one-to-one relationship between DIDs and web3names. This means that you can link a KILT DID to only one web3name, and a web3name can only claim one DID. From 0d4c2cd65e67c9df68ec04032a3b8574dad1870b Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 16:32:58 +0200 Subject: [PATCH 11/16] Update docs/concepts/03_web3names.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/03_web3names.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/03_web3names.md b/docs/concepts/03_web3names.md index 1e37e34ab..b2f54a1cc 100644 --- a/docs/concepts/03_web3names.md +++ b/docs/concepts/03_web3names.md @@ -35,7 +35,8 @@ These accounts aren't specific to the KILT blockchain. They can reference any chain within the Polkadot ecosystem. Each account to DID link requires paying a small deposit. -For DIDs that have also claimed a web3name, the linking feature opens the way to a host of possibilities. For example, showing the web3name of a collator's account on the [KILT Stakeboard](https://stakeboard.kilt.io/). +For DIDs that have also claimed a web3name, the linking feature opens the way to a host of possibilities. +For example, showing the web3name of a collator's account on the [KILT Stakeboard](https://stakeboard.kilt.io/). Date: Thu, 16 May 2024 16:35:30 +0200 Subject: [PATCH 12/16] Update docs/concepts/04_asset_dids.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/04_asset_dids.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/04_asset_dids.md b/docs/concepts/04_asset_dids.md index f0c6ef493..adfed5846 100644 --- a/docs/concepts/04_asset_dids.md +++ b/docs/concepts/04_asset_dids.md @@ -5,7 +5,8 @@ title: AssetDIDs import ThemedImage from '@theme/ThemedImage'; -KILT DIDs are suitable for use cases that involve "active" participants. For example, entities that can act of their will (a person, an organization, a DAO). +KILT DIDs are suitable for use cases that involve "active" participants. +For example, entities that can act of their will (a person, an organization, a DAO). There are classes of entities that represent "passive" participants. That is, they can be "used" by active participants within a given use case. KILT defines these class of participants as **assets**. From 540ddfb3ab5fc2f295dbeaf5164641e3bdc8b810 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 16:35:44 +0200 Subject: [PATCH 13/16] Update docs/concepts/04_asset_dids.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/04_asset_dids.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/04_asset_dids.md b/docs/concepts/04_asset_dids.md index adfed5846..f178f766e 100644 --- a/docs/concepts/04_asset_dids.md +++ b/docs/concepts/04_asset_dids.md @@ -8,7 +8,8 @@ import ThemedImage from '@theme/ThemedImage'; KILT DIDs are suitable for use cases that involve "active" participants. For example, entities that can act of their will (a person, an organization, a DAO). -There are classes of entities that represent "passive" participants. That is, they can be "used" by active participants within a given use case. +There are classes of entities that represent "passive" participants. +That is, they can be "used" by active participants within a given use case. KILT defines these class of participants as **assets**. As with traditional KILT users, assets also need to be uniquely identified, with an *AssetDID*. From 4d1f943374df5ae017785f3803c60974a6c89aef Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 16:35:54 +0200 Subject: [PATCH 14/16] Update docs/concepts/06_distributed_trust.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/06_distributed_trust.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/06_distributed_trust.md b/docs/concepts/06_distributed_trust.md index 751050c6e..968e5a863 100644 --- a/docs/concepts/06_distributed_trust.md +++ b/docs/concepts/06_distributed_trust.md @@ -7,7 +7,8 @@ import ThemedImage from '@theme/ThemedImage'; Sometimes, Attesters are individuals that attest to the validity of claims made by Claimers. However, usually multiple Attesters group together to build up trust in a brand. -In this way, Verifiers no longer need to trust each and every Attester individually. They can put trust in the brand as a whole, which in return ensures that all Attesters working for this brand are credible. +In this way, Verifiers no longer need to trust each and every Attester individually. +They can put trust in the brand as a whole, which in return ensures that all Attesters working for this brand are credible. Such a brand can be organized in many different ways. The KILT protocol provides mechanisms to form such brands on the blockchain. From e95f5e9e1041dde94743acffb890479e25d32bdc Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 16:40:10 +0200 Subject: [PATCH 15/16] Update docs/concepts/04_asset_dids.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/04_asset_dids.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/04_asset_dids.md b/docs/concepts/04_asset_dids.md index f178f766e..f0b3d8528 100644 --- a/docs/concepts/04_asset_dids.md +++ b/docs/concepts/04_asset_dids.md @@ -20,7 +20,7 @@ This AssetDID refers to the [CryptoPunks NFT collection][cryptopunks-nft]. An AssetDID is a *generative* identifier, meaning that it doesn't depend nor rely on any information stored anywhere. Rather, given the asset to identify, it's **always** possible to generate its AssetDID. -The reverse is also true. Given an AssetDID, it's always possible to dereference it into its components which, together, uniquely identified a given asset. +The reverse is also true. Given an AssetDID, it's always possible to dereference it into its components, which, together, uniquely identify a given asset. AssetDIDs always start with the `did:asset` prefix, and then contain a *chain* component (namespace + reference) and an *asset* component (namespace + reference + identifier). From ce9e6ff5a84f47538e9e4973e4a29160282757a3 Mon Sep 17 00:00:00 2001 From: Chris Chinchilla Date: Thu, 16 May 2024 16:41:02 +0200 Subject: [PATCH 16/16] Update docs/concepts/06_distributed_trust.md Co-authored-by: Skedley <48058984+Dudleyneedham@users.noreply.github.com> --- docs/concepts/06_distributed_trust.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/concepts/06_distributed_trust.md b/docs/concepts/06_distributed_trust.md index 968e5a863..261a38b77 100644 --- a/docs/concepts/06_distributed_trust.md +++ b/docs/concepts/06_distributed_trust.md @@ -21,7 +21,8 @@ VCOs will be more flexible and able to support more decentralized use cases than Delegation Hierarchies organize their members in a traditional hierarchical structure, and are modeled as a [Tree data structure](https://en.wikipedia.org/wiki/Tree_(data_structure)), also shown in the graph below. Everyone can use KILT to create a new hierarchy and immediately become the only member of the newly created organization. -Not only is the creator the only member of the organization, they're also the root of the hierarchy. This means that the creator has full control over the whole hierarchy. +Not only is the creator the only member of the organization, they're also the root of the hierarchy. +This means that the creator has full control over the whole hierarchy.