+
+### 2. Create the content for the DID Document
+
+As a bare minimum, a [DID document](../../explanations/decentralized-identifiers.mdx) needs at least one verification method.
+
+At this point, the DID itself is unknown since the `Identity` object is not published yet and thus there's no `ID` for it.
+
+:::tip
+
+You can use a placeholder `did:iota:0x0000000000000000000000000000000000000000000000000000000000000000` to reference
+the DID inside the document.
+
+:::
+
+
+
+### 3. Construct an `Identity` Object
+
+Next, you need to construct a new [Identity Object](../../explanations/about-identity-objects.mdx) that contains the just created
+DID Document.
+The created `Identity` contains an encoded version of the DID Document, and has a single controller that is represented by a newly
+created `ControllerCap`.
+
+:::info Controller Capability
+When a new `Identity` is created the transaction's sender is assumed to be its controller and thus a `ControllerCap` is sent to its address.
+:::
+
+
+
+## Full Example Code
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/examples/0_basic/0_create_did.rs
+```
+
+
+
+
+## Running Examples Locally
+
+In order to run the examples, you will need to run an IOTA network locally.
+
+If you want to use something different, you will need to modify the API and faucet endpoints in the examples to match your
+setup.
diff --git a/docs/content/iota-identity/how-tos/decentralized-identifiers/delete.mdx b/docs/content/iota-identity/how-tos/decentralized-identifiers/delete.mdx
new file mode 100644
index 00000000000..9424433a6e4
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/decentralized-identifiers/delete.mdx
@@ -0,0 +1,87 @@
+---
+title: Delete an IOTA Identity
+sidebar_label: Delete
+description: How to deactivate or destroy an IOTA Identity
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+ - did
+---
+
+
+There are two approaches to delete an IOTA Identity, with different implications:
+
+- [Deactivate](#deactivate)
+- [Destroy](#destroy)
+
+## Deactivate
+
+As detailed in the [IOTA DID Method Specification](
+../../../references/iota-identity/iota-did-method-spec.mdx#deactivate),
+a controller of an IOTA Identity may [deactivate](https://www.w3.org/TR/did-core/#did-document-metadata) it by executing an update that either:
+
+- deletes the contents of the DID Document entirely, leaving the state metadata empty, OR
+- sets the `deactivated` field in the DID Document metadata to `true`.
+
+In both cases, the DID Document will be marked as `deactivated` when resolved.
+
+:::tip Reversible
+
+The identity can be reactivated at any time, by publishing an update restoring the DID Document's contents,
+or unsetting the `deactivated` field in the metadata respectively, depending on how it was initially deactivated.
+
+:::
+
+### Example
+
+The following example demonstrates deactivating and reactivating an IOTA DID Document.
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/examples/0_basic/3_deactivate_did.rs
+```
+
+
+
+
+## Destroy
+
+Alternatively, you can [destroy](../../../references/iota-identity/iota-did-method-spec.mdx#destroy) an IOTA Identity permanently.
+
+:::warning Irreversible
+
+Destroying an IOTA Identity is permanent and irreversible.
+
+:::
+
+This may be achieved by a DID controller by executing the `Identity::execute_delete` API.
+
+Any coins and tokens owned by the destroyed `Identity` are reclaimed and must be sent to another address.
+
+:::warning
+
+Note that historical versions may still be stored off-ledger, or on a permanode,
+so sensitive or Personal Identifiable Information (PII) should NEVER be stored in a DID Document.
+
+:::
+
+Even with a previous version available, a destroyed DID can never be restored.
+
+{/*
+### Example
+
+The following example demonstrates how a controller destroys an IOTA Identity.
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/examples/0_basic/4_delete_did.rs
+```
+
+
+
+*/}
\ No newline at end of file
diff --git a/docs/content/iota-identity/how-tos/decentralized-identifiers/resolve.mdx b/docs/content/iota-identity/how-tos/decentralized-identifiers/resolve.mdx
new file mode 100644
index 00000000000..3f5bb7a23dd
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/decentralized-identifiers/resolve.mdx
@@ -0,0 +1,148 @@
+---
+title: Resolve an IOTA Identity
+sidebar_label: Resolve
+description: Explain how resolving works including arguments
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+ - did
+---
+
+
+DID resolution is the process of fetching and decoding a [DID Document](https://www.w3.org/TR/did-core/#dfn-did-documents) corresponding to a given [DID](https://www.w3.org/TR/did-core/#dfn-decentralized-identifiers).
+The [IOTA Identity framework](https://github.com/iotaledger/identity.rs) supports resolving DID Documents that are
+stored on an IOTA network and enables users to plug in handlers for additional methods.
+
+This is similar to, but not to be confused with,
+the [W3C DID Resolution specification](https://w3c-ccg.github.io/did-resolution/),
+which defines function signatures for resolution in the context of web or REST APIs,
+whereas the IOTA Identity framework provides strongly-typed resolution for a better developer experience.
+
+This functionality is primarily provided by the `Resolver`, which can:
+
+- [Resolve IOTA DID Documents](#resolving-an-iota-did).
+- [Resolve DID Documents from multiple DID methods](#resolving-multiple-did-methods).
+- Resolve the DID Documents referenced in a verifiable presentation or credential.
+
+## Resolving an IOTA DID
+
+The following examples demonstrate how to resolve an IOTA DID Document from its DID.
+
+### Resolver
+
+Once you have configured a `Resolver` with a `Client`, it will resolve
+IOTA DID Documents according to the read procedure defined in the [IOTA DID Method Specification](../../../references/iota-identity/iota-did-method-spec.mdx#read).
+It fetches the `Identity` from the network specified in the DID (see [DID Format](../../../references/iota-identity/iota-did-method-spec.mdx#did-format)),
+then extracts and validates the DID Document from it.
+
+
+
+
+```rust
+use examples::create_did_document;
+use examples::get_client_and_create_account;
+
+use examples::get_memstorage;
+use identity_iota::iota::IotaDocument;
+use identity_iota::prelude::Resolver;
+
+/// Demonstrates how to resolve an existing DID
+#[tokio::main]
+async fn main() -> anyhow::Result<()> {
+ // create new client to interact with chain and get funded account with keys
+ let storage = get_memstorage()?;
+ let identity_client = get_client_and_create_account(&storage).await?;
+ // create new DID document and publish it
+ let (document, _) = create_did_document(&identity_client, &storage).await?;
+
+ let did = document.id().clone();
+
+ // We will be using a `Resolver` to resolve the DID Document.
+ let mut resolver = Resolver::::new();
+
+ // We need to register a handler that can resolve IOTA DIDs.
+ // This convenience method only requires us to provide a client.
+ resolver.attach_kinesis_iota_handler((*identity_client).clone());
+
+ let resolver_document: IotaDocument = resolver.resolve(&did).await.unwrap();
+
+ // Client and Resolver resolve to the same document.
+ assert_eq!(client_document, resolver_document);
+
+ Ok(())
+}
+```
+
+
+
+
+### Client
+
+You can also use the `Client` directly to resolve individual DIDs from its configured network.
+
+
+
+
+```rust
+use examples::create_did_document;
+use examples::get_client_and_create_account;
+use examples::get_memstorage;
+
+use identity_iota::iota::IotaDocument;
+
+#[tokio::main]
+async fn main() -> anyhow::Result<()>{
+ let storage = get_memstorage()?;
+ let identity_client = get_client_and_create_account(&storage).await?;
+ // create new DID document and publish it
+ let (document, _) = create_did_document(&identity_client, &storage).await?;
+
+ let did = document.id().clone();
+
+ // We can resolve a `IotaDID` to bytes via client.
+ // Resolve the associated `Identity Object` and extract the DID document from it.
+ let client_document: IotaDocument = identity_client.resolve_did(&did).await?;
+ println!("Client resolved DID Document: {client_document:#}");
+}
+```
+
+
+
+
+## Advanced Resolver Configuration
+
+You can configure the `Resolver` to support many use cases by attaching custom resolution handlers.
+This enables the `Resolver` to resolve multiple DID methods, as well as customizing how
+a particular DID method (such as the IOTA method) gets resolved.
+
+This feature is mainly intended to be used together with the Resolver's convenience methods for
+handling [verifiable presentations](../verifiable-presentations/create-and-validate.mdx)
+and [credentials](./../../explanations/verifiable-credentials.mdx).
+
+### Resolving Multiple DID Methods
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/examples/1_advanced/5_custom_resolution.rs
+```
+
+
+
+
+## Resolution for Verifiable Presentations
+
+When validating [verifiable presentations](./../verifiable-presentations/create-and-validate.mdx), you need to
+resolve the DID Documents of the [verifiable credential](./../../explanations/verifiable-credentials.mdx) issuers
+and presentation holder to verify their signatures.
+
+Resolving the necessary DID Documents is
+[performed automatically when verifying presentations via the `Resolver`](../verifiable-presentations/create-and-validate.mdx#example-code)
+
+When direct access to these DID Documents is desired, the `Resolver` also provides standalone methods to:
+
+- Resolve a presentation holder's DID Document.
+- Resolve the DID Documents of the issuers of the credentials in a verifiable presentation.
+- Resolve the issuer's DID Document for a given verifiable credential.
diff --git a/docs/content/iota-identity/how-tos/decentralized-identifiers/update.mdx b/docs/content/iota-identity/how-tos/decentralized-identifiers/update.mdx
new file mode 100644
index 00000000000..e1c50866955
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/decentralized-identifiers/update.mdx
@@ -0,0 +1,380 @@
+---
+sidebar_label: Update
+description: How DID Documents can be manipulated and how updates should be published
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+ - did
+---
+
+
+# Update DID Documents
+
+You can extend DID Documents by adding [verification methods](#verification-methods), [services](#services) and custom properties.
+A verification method adds public keys, which can be used to digitally sign things like a DID message or a verifiable credential,
+while a service can provide metadata around the identity via URIs.
+
+## Verification Methods
+
+As demonstrated by the [example](#full-example-code) below, the IOTA Identity framework offers easy-to-use methods for adding
+[verification methods](https://www.w3.org/TR/did-core/#verification-methods).
+
+### Properties
+
+You can specify the following properties for a verification method:
+
+- **id**: A [DID URL](https://www.w3.org/TR/did-core/#did-url-syntax) for the verification method. You can specify it by setting the [fragment](https://www.w3.org/TR/did-core/#fragment).
+- **type**: Specifies the type of the verification method. The framework supports `Ed25519` and `X25519` key types. This property is automatically filled by the framework when specifying the verification material.
+- **publicKeyMultibase**: A multi-base encoded public key which concludes the [verification material](https://www.w3.org/TR/did-core/#verification-material). This can be automatically generated by the framework or manually provided by users.
+
+## Verification Relationships
+
+[Verification relationships](https://www.w3.org/TR/did-core/#verification-relationships) express the relationship between the DID subject and the verification method.
+You can use it to specify the purpose of the verification method.
+
+### Relationships
+
+The Identity Framework supports the following relationships:
+
+- **[Authentication](https://www.w3.org/TR/did-core/#authentication)**: Used to specify authentication methods for the DID subject.
+- **[Assertion](https://www.w3.org/TR/did-core/#assertion)**: Used to verify verifiable credentials.
+- **[Key Agreement](https://www.w3.org/TR/did-core/#assertion)**: Used for establishing secure communication channels.
+- **[Capability Invocation](https://www.w3.org/TR/did-core/#capability-invocation)**: Can be used to authorize updates to the DID Document.
+- **[Capability Delegation](https://www.w3.org/TR/did-core/#capability-delegation)**: A mechanism to delegate cryptographic capability to another party.
+
+Verification methods can be either [embedded or referenced](https://www.w3.org/TR/did-core/#referring-to-verification-methods). Referencing verification
+methods allows them to be used by more than one verification relationship.
+When you create a verification method using the Identity Framework, specifying the `MethodScope` option will result in an embedded verification method.
+Leaving that option unset will create the verification method as a map entry of the `verificationMethod` property.
+You can also add verification relationships afterward using references.
+
+:::note
+
+Updates to the DID Document are done through the invocation of `Identity::execute_update` API by an `Identity`'s controller.
+The public key or address of the controller does not need to be a verification method in the DID Document,
+since the controller is authenticated through possession of a `ControllerCap` token.
+
+:::
+
+## Services
+
+[Services](https://www.w3.org/TR/did-core/#services) allow you to add other ways of communicating with the DID subject.
+An endpoint included in the DID Document can offer a way of reaching services for different purposes
+like authentication, communicating, and discovery.
+
+### Properties
+
+You can specify the following properties for a service:
+
+- **id**: A [DID URL](https://www.w3.org/TR/did-core/#did-url-syntax) for referencing the service in the DID document. You can specify it by setting the [fragment](https://www.w3.org/TR/did-core/#fragment).
+- **type**: A string used to maximize interoperability between services. The framework does not perform any checks on the content of this string.
+- **serviceEndpoint**: A URL that points to the service endpoint.
+
+## Create Identity
+
+Before you can update anything, you will need to [create an Identity](./create.mdx).
+
+
+
+
+```rust
+ // Create a new client to interact with the IOTA ledger.
+ // create new client to interact with chain and get funded account with keys
+ let storage = get_memstorage()?;
+ let identity_client = get_client_and_create_account(&storage).await?;
+ // create new DID document and publish it
+ let (document, vm_fragment_1) = create_did_document(&identity_client, &storage).await?;
+ let did: IotaDID = document.id().clone();
+```
+
+
+
+
+This creates and publishes an Identity object containing a DID Document with one verification method.
+
+```json
+{
+ "doc": {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "verificationMethod": [
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#HZ11e0XacuODQw5FcoMHtcdxl8oXHbSnIhQMUgVzWBE",
+ "controller": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "type": "JsonWebKey",
+ "publicKeyJwk": {
+ "kty": "OKP",
+ "alg": "EdDSA",
+ "kid": "HZ11e0XacuODQw5FcoMHtcdxl8oXHbSnIhQMUgVzWBE",
+ "crv": "Ed25519",
+ "x": "475CGLtezvySFMCHhx6hE9S97MIYMLb4B-pbVEHaCtY"
+ }
+ }
+ ]
+ },
+ "meta": {
+ "created": "2023-11-16T20:40:03Z",
+ "updated": "2023-11-16T20:40:03Z",
+ }
+}
+```
+
+## Add a Verification Method
+
+
+
+
+```rust
+ // Insert a new Ed25519 verification method in the DID document.
+ let fragment_2: String = document
+ .generate_method(
+ &storage,
+ JwkMemStore::ED25519_KEY_TYPE,
+ JwsAlgorithm::EdDSA,
+ None,
+ MethodScope::VerificationMethod,
+ )
+ .await?;
+```
+
+
+
+
+This creates a new verification method that includes a newly generated Ed25519 public key.
+
+```json
+{
+ "doc": {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "verificationMethod": [
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#HZ11e0XacuODQw5FcoMHtcdxl8oXHbSnIhQMUgVzWBE",
+ "controller": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "type": "JsonWebKey",
+ "publicKeyJwk": {
+ "kty": "OKP",
+ "alg": "EdDSA",
+ "kid": "HZ11e0XacuODQw5FcoMHtcdxl8oXHbSnIhQMUgVzWBE",
+ "crv": "Ed25519",
+ "x": "475CGLtezvySFMCHhx6hE9S97MIYMLb4B-pbVEHaCtY"
+ }
+ },
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE",
+ "controller": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "type": "JsonWebKey",
+ "publicKeyJwk": {
+ "kty": "OKP",
+ "alg": "EdDSA",
+ "kid": "yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE",
+ "crv": "Ed25519",
+ "x": "h8ndZ4_Urmzf4xN4emqS8r5q4pAQvAh0k2YHq5JLBBo"
+ }
+ }
+ ]
+ },
+ "meta": {
+ "created": "2023-11-16T20:40:03Z",
+ "updated": "2023-11-16T20:40:03Z",
+ }
+}
+```
+
+## Add Verification Relationships
+
+You can attach verification relationships to a verification method by referencing its fragment.
+
+
+
+
+```rust
+// Attach a new method relationship to the inserted method.
+document.attach_method_relationship(
+ &document.id().to_url().join(format!("#{fragment_2}"))?,
+ MethodRelationship::Authentication,
+)?;
+```
+
+
+
+
+This will add `Authentication` relationship to the verification method with the fragment `key-1`.
+Note that `Authentication` references the already included `key-2` verification method:
+
+```json {12,19}
+{
+ "doc": {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "verificationMethod": [
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#HZ11e0XacuODQw5FcoMHtcdxl8oXHbSnIhQMUgVzWBE",
+ "controller": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "type": "JsonWebKey",
+ "publicKeyJwk": {
+ "kty": "OKP",
+ "alg": "EdDSA",
+ "kid": "HZ11e0XacuODQw5FcoMHtcdxl8oXHbSnIhQMUgVzWBE",
+ "crv": "Ed25519",
+ "x": "475CGLtezvySFMCHhx6hE9S97MIYMLb4B-pbVEHaCtY"
+ }
+ },
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE",
+ "controller": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "type": "JsonWebKey",
+ "publicKeyJwk": {
+ "kty": "OKP",
+ "alg": "EdDSA",
+ "kid": "yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE",
+ "crv": "Ed25519",
+ "x": "h8ndZ4_Urmzf4xN4emqS8r5q4pAQvAh0k2YHq5JLBBo"
+ }
+ }
+ ],
+ "authentication": [
+ "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE"
+ ]
+ },
+ "meta": {
+ "created": "2023-11-16T20:40:03Z",
+ "updated": "2023-11-16T20:40:03Z",
+ }
+}
+```
+
+## Add a Service
+
+You can also add custom properties can to a service by setting `properties`:
+
+
+
+
+```rust
+ // Add a new Service.
+ let service: Service = Service::from_json_value(json!({
+ "id": document.id().to_url().join("#linked-domain")?,
+ "type": "LinkedDomains",
+ "serviceEndpoint": "https://iota.org/"
+ }))?;
+ assert!(document.insert_service(service).is_ok());
+ document.metadata.updated = Some(Timestamp::now_utc());
+```
+
+
+
+
+The updated Document with the newly created service looks as follows.
+
+```json {21-27}
+{
+ "doc": {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "verificationMethod": [
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#HZ11e0XacuODQw5FcoMHtcdxl8oXHbSnIhQMUgVzWBE",
+ "controller": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "type": "JsonWebKey",
+ "publicKeyJwk": {
+ "kty": "OKP",
+ "alg": "EdDSA",
+ "kid": "HZ11e0XacuODQw5FcoMHtcdxl8oXHbSnIhQMUgVzWBE",
+ "crv": "Ed25519",
+ "x": "475CGLtezvySFMCHhx6hE9S97MIYMLb4B-pbVEHaCtY"
+ }
+ },
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE",
+ "controller": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "type": "JsonWebKey",
+ "publicKeyJwk": {
+ "kty": "OKP",
+ "alg": "EdDSA",
+ "kid": "yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE",
+ "crv": "Ed25519",
+ "x": "h8ndZ4_Urmzf4xN4emqS8r5q4pAQvAh0k2YHq5JLBBo"
+ }
+ }
+ ],
+ "authentication": [
+ "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE"
+ ],
+ "service": [
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#linked-domain",
+ "type": "LinkedDomains",
+ "serviceEndpoint": "https://iota.org/"
+ }
+ ]
+ },
+ "meta": {
+ "created": "2023-11-16T20:40:03Z",
+ "updated": "2023-11-16T20:40:08Z",
+ }
+}
+```
+
+## Remove a Verification Method
+
+You can also remove verification methods at any time using the following snippet:
+
+
+
+
+```rust
+// Remove a verification method.
+let original_method: DIDUrl = document.resolve_method(fragment_1.as_str(), None).unwrap().id().clone();
+document.purge_method(&storage, &original_method).await.unwrap();
+```
+
+
+
+
+This removes the original verification method with the fragment `key-1`.
+
+```json
+{
+ "doc": {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "verificationMethod": [
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE",
+ "controller": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a",
+ "type": "JsonWebKey",
+ "publicKeyJwk": {
+ "kty": "OKP",
+ "alg": "EdDSA",
+ "kid": "yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE",
+ "crv": "Ed25519",
+ "x": "h8ndZ4_Urmzf4xN4emqS8r5q4pAQvAh0k2YHq5JLBBo"
+ }
+ }
+ ],
+ "authentication": [
+ "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#yJz-sPlCmd432JKqK_hkiPml2kj22Jv0aAFy_2jJ8nE"
+ ],
+ "service": [
+ {
+ "id": "did:iota:tst:0x19ed80fbd2a644fc2347e27e46e09d42b89df9b1ba09ae41832a9d47d686776a#linked-domain",
+ "type": "LinkedDomains",
+ "serviceEndpoint": "https://iota.org/"
+ }
+ ]
+ },
+ "meta": {
+ "created": "2023-11-16T20:40:03Z",
+ "updated": "2023-11-16T20:40:08Z",
+ }
+}
+```
+
+## Full Example Code
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/examples/0_basic/1_update_did.rs
+```
+
+
+
diff --git a/docs/content/iota-identity/how-tos/domain-linkage/create-and-verify.mdx b/docs/content/iota-identity/how-tos/domain-linkage/create-and-verify.mdx
new file mode 100644
index 00000000000..34b437cda69
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/domain-linkage/create-and-verify.mdx
@@ -0,0 +1,167 @@
+---
+description: How to link a domain and a DID
+sidebar_label: Create and Verify
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+---
+
+# Domain Linkage
+
+:::info
+To use Domain Linkage in Rust you have to enable the `domain-linkage` feature.
+:::
+
+## Overview
+
+Domain Linkage can provide proof for a connection between a DID and a domain being controlled by the same entity.
+This linkage can transfer trust from a domain to a DID and vice versa.
+For instance, if an entity trusts a domain, it can also trust the linked DID and all documents signed by
+the verification methods included in the DID Document.
+
+A use case could be a verifier that trusts `www.example.com`, and receives a verifiable presentation issued by `did:foo:abc`.
+If `did:foo:abc` is linked to `www.example.com`, the verifier can trust that the verifiable presentation is issued by
+the same entity controlling `www.example.com`.
+The DIF has approved a [Well Known DID Configuration](https://identity.foundation/.well-known/resources/did-configuration/) draft to standardize this connection by introducing
+the [DID Configuration Resource](https://identity.foundation/.well-known/resources/did-configuration/#did-configuration-resource) and the [Linked Domain Service Endpoint](https://identity.foundation/.well-known/resources/did-configuration/#linked-domain-service-endpoint).
+
+![Identity getting started](/img/iota-identity/domain-linkage-diagram.png)
+
+### DID Configuration Resource
+
+Suppose that a DID `did:foo:example` with the following DID Document only contains one `verificationMethod`, `key-1`:
+
+```json {5}
+{
+ "id": "did:foo:abc",
+ "verificationMethod": [
+ {
+ "id": "did:foo:abc#key-1",
+ "controller": "did:foo:abc",
+ "type": "Ed25519VerificationKey2018",
+ "publicKeyMultibase": "zDShpHKXkcHKHcF8CnGAA1UqyyuEPRNz1XFEuggbWJQSq"
+ }
+ ]
+ },
+```
+
+The domain `https://www.example.com` represents the same entity and needs to be linked to increase trust in the DID.
+
+To establish this link, you must create a [DID Configuration Resource](https://identity.foundation/.well-known/resources/did-configuration/#did-configuration-resource),
+and make it available on the [DID Configuration URL](https://identity.foundation/.well-known/resources/did-configuration/#did-configuration-uri).
+In this case it's `https://example.com/.well-known/did-configuration.json`.
+
+The [DID Configuration Resource](https://identity.foundation/.well-known/resources/did-configuration/#did-configuration-resource) is a JSON-LD object containing verifiable credentials called `Domain Linkage Credentials`.
+Each credential represents a linkage to a single DID.
+
+:::note
+
+Note that one `DID Configuration Resource` can include multiple `Domain Linkage Credentials`,
+effectively linking the same domain to multiple DIDs.
+
+:::
+
+In this example, the domain `https://www.example.com` needs to be linked to the DID `did:foo:abc`.
+This means that the `DID Configuration Resource` will have one `Domain Linkage Credential`.
+This credential must have the following properties:
+
+- Its `type` includes `DomainLinkageCredential`.
+- It includes the DID Configuration context.
+- The `credentialSubject` must be the DID `did:foo:abc` and references the domain `https://www.example.com`.
+- The issuer is the DID itself `did:foo:abc`.
+- It is signed by a key material included in the DID Document, in this case `did:foo:abc#key-1`.
+
+```json
+{
+ "@context": "https://identity.foundation/.well-known/did-configuration/v1",
+ "linked_dids": [
+ {
+ "@context": [
+ "https://www.w3.org/2018/credentials/v1",
+ "https://identity.foundation/.well-known/did-configuration/v1"
+ ],
+ "type": ["VerifiableCredential", "DomainLinkageCredential"],
+ "credentialSubject": {
+ "id": "did:foo:abc",
+ "origin": "https://www.example.com/"
+ },
+ "issuer": "did:foo:abc",
+ "issuanceDate": "2023-02-09T22:14:15Z",
+ "expirationDate": "2024-02-09T22:14:15Z",
+ "proof": {
+ "type": "JcsEd25519Signature2020",
+ "verificationMethod": "did:foo:abc#key-1",
+ "signatureValue": "4SvYqo3YoArfW7r7qKfN7RUJdZnBteb166KE4UkX8MNdbp5UW6YbykneAzvjyRmf5EVQ9bnP9cS5sbEPUn2uaAcB"
+ }
+ }
+ ]
+}
+```
+
+Now this `DID Configuration Resource` must be made available on `https://example.com/.well-known/did-configuration.json`,
+which establishes the linkage.
+
+### Linked Domain Service Endpoint
+
+By having a domain, one can discover what DIDs are linked to it by fetching the `DID Configuration Resource` and
+investigating the `Domain Linkage Credentials`.
+
+If you want to enable discovery from the other direction, that is, if you have a DID and want to discover which
+domains are linked to it, you can add a [Linked Domain Service Endpoint](https://identity.foundation/.well-known/resources/did-configuration/#linked-domain-service-endpoint) to the DID Document.
+The DID Document from this example will be extended as follows to enable discovery of `https://www.example.com`:
+
+```json {11-17}
+{
+ "id": "did:foo:abc",
+ "verificationMethod": [
+ {
+ "id": "did:foo:abc#key-1",
+ "controller": "did:foo:abc",
+ "type": "Ed25519VerificationKey2018",
+ "publicKeyMultibase": "zDShpHKXkcHKHcF8CnGAA1UqyyuEPRNz1XFEuggbWJQSq"
+ }
+ ],
+ "service": [
+ {
+ "id": "did:foo:abc#domain-linkage",
+ "type": "LinkedDomains",
+ "serviceEndpoint": "https://www.example.com/"
+ }
+ ]
+}
+```
+
+:::note
+Note that a DID Document can have multiple `Linked Domain Services` and each service can link to multiple domains.
+:::
+
+### Verifying a DID and Domain Linkage
+
+As mentioned above, you can discover the Domain Linkage from either direction.
+However, verifying the linkage in both cases involves only verifying the DID Configuration Resource.
+The process is as follows:
+
+1. Fetch `DID Configuration Resource` from `https://www.example.com/.well-known/did-configuration.json`.
+2. Resolve the DID Document of `did:foo:abc`.
+3. Verify the `DID Configuration Resource` and its `Domain Linkage Credential` that references `did:foo:abc`.
+
+
+:::tip About DID Configuration Resource Verification
+
+You can learn more
+[about DID Configuration Resource Verification on the Identity Foundation website](https://identity.foundation/.well-known/resources/did-configuration/#did-configuration-resource-verification).
+
+:::
+
+## Example Code
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/examples/1_advanced/6_domain_linkage.rs
+```
+
+
+
diff --git a/docs/content/iota-identity/how-tos/key-storage.mdx b/docs/content/iota-identity/how-tos/key-storage.mdx
new file mode 100644
index 00000000000..2116166089c
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/key-storage.mdx
@@ -0,0 +1,133 @@
+---
+title: Key Storage
+sidebar_label: Key Storage
+description: Explain the use of the storage interfaces and how they can be implemented
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+---
+
+
+## Introduction
+
+The `JwkDocumentExt` API allows you to modify a DID document, for example, adding new verification methods.
+It enables storing the secrets that verification methods represent securely.
+It does so using the two storage interfaces, the `JwkStorage` and `KeyIdStorage`.
+We refer to both of these as the **key storage**.
+
+The main idea behind the key storage is strongly inspired by the architecture of key management systems (KMS)
+or secure enclaves: once private keys are entered into the system, they can never be retrieved again.
+Instead, all operations using the key will have to go through that system.
+
+This approach allows the key storage to be architected more securely than simply storing and loading private keys from
+a regular database.
+Of course, security is directly dependent on the concrete implementation,
+which is why we provide [Stronghold](https://github.com/iotaledger/stronghold.rs/), a best-effort in-software enclave, by default.
+
+However, there are cases where one cannot use `Stronghold`,
+or may want to integrate key management of identities into their own KMS or similar,
+which is why the key storage is an abstraction over such systems.
+Any implementation of a key storage can be used by the `JwkDocumentExt` API.
+
+The two interfaces making up the key storage have two respective responsibilities.
+
+:::info
+
+Even though there are two separate interfaces, you can implement them using the same backing storage.
+
+:::
+
+## Function Overview
+
+A brief overview of those functions:
+
+- `JwkStorage`: CRUD and signing operations on [JSON Web Keys](https://www.rfc-editor.org/rfc/rfc7517).
+ - `generate`: Generate a new key represented as a JSON Web Key.
+ - `insert`: Insert an existing JSON Web Key into the storage.
+ - `sign`: Signs the provided data using the stored private key.
+ - `delete`: Permanently deletes a key.
+ - `exists`: Returns whether a key exists.
+- `KeyIdStorage`: Stores the mappings from verification methods to their corresponding key identifier in the `JwkStorage`.
+ - `insert_key_id`: Inserts a mapping from a verification method identifier to a key identifier.
+ - `get_key_id`: Returns the key identifier for a given verification method identifier.
+ - `delete_key_id`: Deletes a mapping.
+
+## Key Identifier
+
+A `JwkStorage` stores and operates on keys, so they must be identified.
+In general, Key Management Systems use some form of an identifier for their keys.
+To abstract over those, the `JwkStorage` interface has a general-purpose `KeyId` type,
+which is effectively a wrapper around a string.
+
+A `KeyIdStorage` is needed to store the key id that represents the private key for a given verification method.
+To that end, a verification method itself must be identified.
+
+While within a document, each fragment must be unique, the same is not true given multiple documents,
+so we cannot rely only on fragments if we don't want to partition the `KeyIdStorage` by DID.
+The solution to this is using a `MethodDigest`, a hash over a verification method.
+
+When following best security practices, each verification method has its own associated key and, thus, a unique public key.
+That, plus the fragment of a method, ensures the `MethodDigest` is unique.
+
+So, in essence, a `JwkStorage` stores a `KeyId -> JWK` mapping while a `KeyIdStorage` stores a `MethodDigest -> KeyId` mapping.
+
+:::caution
+
+Given the construction and limitations of the method digest,
+no two documents should contain a method that shares both the same fragment and public key.
+This should not happen under typical circumstances, but it is good to keep it in mind.
+
+:::
+
+## Key Types
+
+To express what key types a given `JwkStorage` implementation supports, you should use the `KeyType`,
+which is another simple wrapper around a string.
+
+The reason for this design might seem odd in Rust, given the existence of associated types.
+This more simplistic design is necessary to accommodate implementing the interface via the bindings to the library.
+
+Implementations are expected to export constants of the key types they support,
+so users have an easy way to discover the supported types.
+In general, storage implementations are free to support any [JSON Web Algorithm](https://www.rfc-editor.org/rfc/rfc7518.html)-compatible key.
+However, the recommended default used by IOTA Identity is the `EdDSA` algorithm with curve `Ed25519`.
+
+## Implementation
+
+The IOTA Identity library ships two implementations of key storage.
+The `JwkMemStore` and `KeyIdMemstore` are insecure in-memory implementations
+intended as example implementations and for testing.
+
+The default key storage implementation is `Stronghold`,
+which is an example of a storage that implements both storage interfaces simultaneously.
+[`Stronghold`](https://github.com/iotaledger/stronghold.rs/) may be interesting for implementers to look at,
+as it needs to deal with some challenges the in-memory version does not have to deal with. Note that the `Stronghold` implementation is only available in Rust.
+
+## Examples
+
+This section shows the Rust `Memstore` implementation.
+
+### `JwkMemStore`
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/identity_storage/src/key_storage/memstore.rs
+```
+
+
+
+
+### `KeyIdMemstore`
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/identity_storage/src/key_id_storage/memstore.rs
+```
+
+
+
diff --git a/docs/content/iota-identity/how-tos/verifiable-credentials/create.mdx b/docs/content/iota-identity/how-tos/verifiable-credentials/create.mdx
new file mode 100644
index 00000000000..3862af479cb
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/verifiable-credentials/create.mdx
@@ -0,0 +1,117 @@
+---
+title: Create a Verifiable Credential
+sidebar_label: Create and Sign
+description: Explain how a VC is created and verified
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+ - verifiable-credentials
+---
+
+A [Verifiable Credential (VC)](./../../explanations/verifiable-credentials.mdx) can represent all
+information that a physical credential represents, such as a passport or university
+degree. However, by allowing other parties to cryptographically verify the authorship
+and integrity of the claims, verifiable credentials can be seen as more tamper-evident
+and more trustworthy than their physical counterparts.
+
+## Verifiable Credential Properties
+
+In the IOTA Identity Framework, you can create a Verifiable Credential with the following properties:
+
+- [**Context**](https://www.w3.org/TR/vc-data-model/#contexts): List of JSON-LD context URIs. Includes `"https://www.w3.org/2018/credentials/v1"` by default.
+- [**Types**](https://www.w3.org/TR/vc-data-model/#types): List of types describing the credential. Includes `"VerifiableCredential"` by default.
+- [**Subject**](https://www.w3.org/TR/vc-data-model/#credential-subject): The issuer's claims; a set of objects that contain one or more properties that are each related to a subject.
+- [**Issuer**](https://www.w3.org/TR/vc-data-model/#issuer): The identifier of the issuer, typically their [DID](../../explanations/decentralized-identifiers.mdx).
+- [**ID**](https://www.w3.org/TR/vc-data-model/#identifiers): Optional URI identifier for the credential.
+- [**Issuance Date**](https://www.w3.org/TR/vc-data-model/#issuance-date): Timestamp for expressing the date and time when a credential becomes valid.
+- [**Expiration Date**](https://www.w3.org/TR/vc-data-model/#expiration): Optional timestamp for expressing the date and time when a credential ceases to be valid.
+- [**Status**](https://www.w3.org/TR/vc-data-model/#status): Optional information used to determine the current status of a credential, i.e. whether or not it has been [revoked](./revocation.mdx).
+- [**Schema**](https://www.w3.org/TR/vc-data-model/#data-schemas): Optional list of objects specifying the schema that the data must conform to.
+- [**Refresh Service**](https://www.w3.org/TR/vc-data-model/#refreshing): Optional link to a service where the recipient may refresh the included credentials.
+- [**Terms of Use**](https://www.w3.org/TR/vc-data-model/#terms-of-use): Optional list of policies defining obligations, prohibitions, or permissions of the presentation recipient.
+- [**Evidence**](https://www.w3.org/TR/vc-data-model/#evidence): Optional list of objects that can be used by the issuer to provide the verifier with additional supporting information in a verifiable credential.
+- [**Non-Transferable**](https://www.w3.org/TR/vc-data-model/#nontransferable-property): Optional flag that indicates that a verifiable credential must only be encapsulated in a [verifiable presentation](./../../explanations/verifiable-presentations.mdx) whose proof was issued by the credential subject.
+
+
+
+
+## Signing
+
+After preparing the verifiable credential, the issuer creates a signed JWT containing VC in the claims using one of their private keys. This is what allows verifiers to validate the credential independently using the corresponding public key from the issuer's DID Document.
+
+## Validation
+
+Verifiers should ensure certain credential properties are valid when receiving one or more in a [verifiable presentation](./../../explanations/verifiable-presentations.mdx). Both issuers and holders may also wish to validate their credentials, particularly directly after creating or receiving one. Validation may be performed at any point in time and can be a useful way of checking whether a credential has expired or been revoked.
+
+### Validation Checks
+
+The IOTA Identity Framework supports the following checks during credential validation:
+
+- **Semantic structure**: Ensures the credential adheres to the specification.
+- **Signature**: Verifies the JWS against the issuer's DID Document.
+- **Optional validations**: Additional checks on credential properties, and the signature can be configured by specifying [Validation Options](#validation-options).
+
+### Validation Options
+
+These options specify conditions that specific properties in a credential must satisfy.
+
+- **Expiration Date**: Check that the [`expirationDate`](https://www.w3.org/TR/vc-data-model/#expiration) property, if present, is not before a specific date-time. Defaults to the current datetime if unset.
+- **Issuance Date**: Check that [`issuanceDate`](https://www.w3.org/TR/vc-data-model/#issuance-date) property, if present, is not after a specific date-time. Defaults to the current datetime if unset.
+- **Verifier Options**: Validates aspects of the credential signature.
+
+## Sharing Verifiable Credentials
+
+A [verifiable presentation](./../../explanations/verifiable-presentations.mdx) is the recommended data format for sharing one or more verifiable credentials,
+as it provides cryptographic means of proving the DID of the holder presenting them,
+and for enforcing [subject-holder relationships](https://www.w3.org/TR/vc-data-model/#subject-holder-relationships).
+
+## Example
+
+The following code showcases how an issuer can [create, sign](#create-and-sign-a-vc),
+and [validate](#validate-a-vc) a verifiable credential.
+In this example, the issuer signs a `UniversityDegreeCredential` with Alice's name and DID.
+
+### Create and Sign a VC
+
+
+
+
+This Verifiable Credential can be [verified by anyone](./../../explanations/verifiable-presentations.mdx),
+allowing Alice to take control of it and share it with anyone.
+
+### Full Example Code
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/examples/0_basic/5_create_vc.rs
+```
+
+
+
diff --git a/docs/content/iota-identity/how-tos/verifiable-credentials/revocation.mdx b/docs/content/iota-identity/how-tos/verifiable-credentials/revocation.mdx
new file mode 100644
index 00000000000..05e69cfdc62
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/verifiable-credentials/revocation.mdx
@@ -0,0 +1,174 @@
+---
+sidebar_label: Revoke
+description: Explain how a VC can be revoked
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+ - verifiable-credentials
+---
+
+
+# Revoke a Verifiable Credential
+
+The [example](#full-example-code) below demonstrates two methods that an issuer can use to revoke a verifiable credential
+using the IOTA Identity Framework:
+
+1. By using the [`credentialStatus`](https://www.w3.org/TR/vc-data-model/#status) field in a credential and linking
+ to a [revocation method](#revocation-methods).
+2. By [removing the verification method](#removing-the-verification-method) that signed the credential.
+ This invalidates all credentials that were signed with that verification method.
+
+## Revocation methods
+
+The IOTA Identity Framework supports two different revocation methods: `RevocationBitmap2022` and `StatusList2021`.
+
+### Revocation Bitmap
+
+[RevocationBitmap2022](../../../references/iota-identity/revocation-bitmap-2022.mdx) is the default credential revocation method used in the IOTA Identity Framework. It allows
+issuers to control whether a credential is _valid_ or _revoked_. To do so, a revocation list (represented
+as a bitmap) is stored in the issuer's DID document.
+When a credential is issued, a unique index from the issuer's revocation list
+is chosen, linking the credential's status to the value of the list entry. To change the status of a credential, the issuer
+simply updates the corresponding entry in its revocation list.
+
+With `RevocationBitmap2022` the `identity.rs` library completely handles the processes required to handle credentials revocation;
+from creation and storage of the revocation list to its lookup.
+This makes `RevocationBitmap2022` the preferred way for users to handle credential revocation, but it requires sufficient
+funds to rent out the required on-tangle space.
+
+:::note
+
+DLT's size constraints limit the size of the revocation list. With the assumption of only one such revocation list
+per the issuer's DID document, one may expect to be able to handle roughly 50k entries.
+
+:::
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-alpha/examples/0_basic/7_revoke_vc.rs#L132
+```
+
+
+
+
+If the binary value of the index in the bitmap is 1 (one), the verifiable credential is revoked,
+if it is 0 (zero) it is not revoked.
+
+For example, with this approach the issuer adds an index to a credential in the `credentialStatus` field, such as `"5"`.
+This part of the credential might then look like this:
+
+```json
+"credentialStatus": {
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#revocation",
+ "type": "RevocationBitmap2022",
+ "revocationBitmapIndex": "5"
+},
+```
+
+The verifier uses the `id` field (`did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#revocation`) to look up the
+service in the issuer's DID document:
+
+```json
+{
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#revocation",
+ "type": "RevocationBitmap2022",
+ "serviceEndpoint": "data:application/octet-stream;base64,ZUp5ek1tQmdZR1NBQUFFZ1ptVUFBQWZPQUlF"
+}
+```
+
+During verification, the verifier decodes the revocation bitmap embedded in the `data` URL.
+This bitmap written as a bitstring looks like this: `000001`.
+Here, the 5th bit is set, which means the credential with that index is revoked,
+while all other credentials aren't revoked.
+
+### StatusList2021
+
+[StatusList2021](https://www.w3.org/TR/2023/WD-vc-status-list-20230427) offers similar functionalities to `RevocationBitmap2022`
+but in a more flexible and scalable way.
+The main difference is that `StatusList2021` is completely agnostic in regards to how the issuer's status list
+is stored and fetched, as long as its location can be encoded through a URL. For instance, the status list
+can be made available over HTTP (e.g. `https://example.com/credentials/status`) or through the
+Interplanetary File System (e.g. `ipfs://QmXDWGdVBhbDoXXzKNMhJk5ejnZgxpMBVzW4EhQaHPD3Mi`).
+
+This flexibility, although it requires the issuer to manually fetch and update its status list, allows for an arbitrary number of
+entries in the status list, in contrast with `RevocationBitmap2022`, where the length of the list is limited by the DLT's constraints.
+
+Furthermore, `StatusList2021` introduces a new credential state: _suspended_. Suspended credentials are credentials that a validator will not accept as _valid_, but that might become valid again in the future. Instead, _revoked_ credentials **cannot** ever
+be valid again, as the _revoked_ state is irreversible.
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-alpha/examples/1_advanced/8_status_list_2021.rs#L57-L61
+```
+
+
+
+
+First, an issuer creates a credential that encodes a certain status list, specifying its purpose (either `revocation` or `suspension`)
+and the location at which it will be available (`https://example.com/credentials/status` in this case). After creation, the issuer
+must make the credential available at the chosen URL so that verifiers can fetch it.
+
+Upon issuing a credential, to revoke it or suspend it later, the issuer sets the `credentialStatus` field, linking
+to an entry in its status list. The snippet below shows what `credentialStatus` would look like when linking to the previously created
+status list credential.
+
+```json
+{
+ "id": "https://example.com/credentials/status#94567",
+ "type": "StatusList2021Entry",
+ "statusPurpose": "revocation",
+ "statusListIndex": "94567",
+ "statusListCredential": "https://example.com/credentials/status"
+}
+```
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-alpha/examples/1_advanced/8_status_list_2021.rs#L144
+```
+
+
+
+
+To set the status of a credential, the issuer retrieves the status list credential and sets the value of the chosen entry index.
+
+## Removing the Verification Method
+
+A less efficient alternative is to remove the verification method that signed the credential from the DID Document of
+the issuer.
+This means the VC can no longer be validated.
+
+However, this will also invalidate every VC signed with that verification method,
+meaning that the issuer will have to sign every VC with a different key to retain
+precise control over which credential is revoked.
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-alpha/examples/0_basic/7_revoke_vc.rs#L159-L166
+```
+
+
+
+
+## Full Example Code
+
+The following code exemplifies how you can revoke a [Verifiable Credential (VC)](../../explanations/verifiable-credentials.mdx).
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-alpha/examples/0_basic/7_revoke_vc.rs
+```
+
+
+
diff --git a/docs/content/iota-identity/how-tos/verifiable-credentials/selective-disclosure.mdx b/docs/content/iota-identity/how-tos/verifiable-credentials/selective-disclosure.mdx
new file mode 100644
index 00000000000..9236270d117
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/verifiable-credentials/selective-disclosure.mdx
@@ -0,0 +1,131 @@
+---
+sidebar_label: Selective Disclosure
+description: Explain VC with selective disclosure.
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+ - verifiable-credentials
+---
+
+
+# Selective Disclosure (SD-JWT)
+
+
+Holders of verifiable credentials may prefer to keep all the information contained within the credential private from a verifier. Instead, they may opt only to share a specific subset of the properties included in the VC. The identity library implements the [IETF Specifications](https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-07.html), which outlines a mechanism to enable the selective disclosure of individual properties within the JSON object of JWT claims.
+
+## Concept
+
+### Issuance
+
+During the issuance process, the issuer replaces a subset of the fields in a credential with digests of their salted values and creates a signed JWT. Next, JWT, alongside the plain text disclosures and the salt used for digest creation are sent to the holder.
+
+### Presentation
+
+At this stage, the holder can selectively choose which fields to disclose to the verifier. The disclosures are sent in plain text, with the JWT containing the digests to the verifier.
+
+:::note
+Only values replaced by digests through the issuer can be selectively disclosed. The holder **can not** conceal values provided in plain text in the JWT claims.
+:::
+
+
+### Validation
+
+With these values and a valid signature, the verifier is able to reconstruct a Verified Credential (VC) that exclusively contains the information the holder intended to disclose.
+
+## How It Works
+
+A SD JWT can be constructed from the following JWT claim of an address credential in accordance with the [VC Data Model v1.1](https://www.w3.org/TR/vc-data-model/#json-web-token):
+
+
+```json
+{
+ "iss": "did:iota:tst:0x899d07a766f93c2af1a19a3f4583ad338fc94c5d84b6afcadf49b197e1cb693e",
+ "jti": "https://example.com/credentials/3732",
+ "nbf": 1705925652,
+ "sub": "did:iota:tst:0x6c045e1f658197b432cfc7c66350b8781dca50f820e9de0fcdf0029b4b384355",
+ "vc": {
+ "@context": "https://www.w3.org/2018/credentials/v1",
+ "credentialSubject": {
+ "address": {
+ "country": "DE",
+ "locality": "Maxstadt",
+ "postal_code": "12344",
+ "street_address": "Weidenstraße 22"
+ },
+ "name": "Alice"
+ },
+ "type": [
+ "VerifiableCredential",
+ "AddressCredential"
+ ]
+ }
+}
+
+```
+
+The issuer makes the values of "locality", "postal_code", and "street_address" selectively disclosable, giving the holder the freedom to select what details of the address to be disclosed and presented.
+
+```json
+{
+ "_sd_alg": "sha-256",
+ "iss": "did:iota:tst:0x899d07a766f93c2af1a19a3f4583ad338fc94c5d84b6afcadf49b197e1cb693e",
+ "jti": "https://example.com/credentials/3732",
+ "nbf": 1705925652,
+ "sub": "did:iota:tst:0x6c045e1f658197b432cfc7c66350b8781dca50f820e9de0fcdf0029b4b384355",
+ "vc": {
+ "@context": "https://www.w3.org/2018/credentials/v1",
+ "credentialSubject": {
+ "address": {
+ "_sd": [
+ "8Dai0-GMZgkzmdryGzjYufUaRFkiNWzVsJJdWucwu84",
+ "jemTNaG_wiHauwmwWiWREsirAlr91qugPds4MA8e2xo",
+ "iakC9Dfe2r9fGnOaAr_pGg1b7CwITBjcwE7-O7WlMnY"
+ ],
+ "country": "DE"
+ },
+ "name": "Alice"
+ },
+ "type": [
+ "VerifiableCredential",
+ "AddressCredential"
+ ]
+ }
+}
+```
+
+:::note
+The digests are contained in the `_sd` property in `address`. This allows both keys and values to be concealed.
+:::
+
+For further details, see the [example](#full-example-code) below and the [sd-jwt-payload crate](https://github.com/iotaledger/sd-jwt-payload).
+
+## Presentation format
+
+The SD-JWT is presented in the following [format](https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-07.html#section-5):
+
+> `~~~...~~`
+
+## Key Binding JWT
+
+When a verifier receives an SD-JWT, it may be desirable to verify that the presenter's identity matches the holder of the Credential. For that purpose, a [Key Binding JWT (KB-JWT)](https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-07.html#section-4.3) can be used.
+
+
+- The verifier sends a nonce to the holder.
+- The holder creates a JWT containing the nonce and the digest of the issuer-signed JWT and the disclosures 1→N.
+- The holder sends the KB-JWT to the verifier as a part of the presentation.
+- By verifying the KB-JWT, the verifier ensures the identity of the holder, the integrity of the data, the freshness of the signature, and the intended audience.
+
+
+
+## Full Example Code
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/examples/1_advanced/7_sd_jwt.rs
+```
+
+
+
diff --git a/docs/content/iota-identity/how-tos/verifiable-credentials/zero-knowledge-selective-disclosure.mdx b/docs/content/iota-identity/how-tos/verifiable-credentials/zero-knowledge-selective-disclosure.mdx
new file mode 100644
index 00000000000..c18ceb0eac3
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/verifiable-credentials/zero-knowledge-selective-disclosure.mdx
@@ -0,0 +1,121 @@
+---
+sidebar_label: Zero Knowledge Selective Disclosure
+description: Zero Knowledge selectively disclosable VCs.
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+ - verifiable-credentials
+ - zk
+---
+
+
+# Zero Knowledge Selective Disclosure (ZK-SD-VCs)
+ZK-SD-VCs allow holders to verify their VCs without having to disclose the entire VC's claim set to verifiers.
+This is done through the creation of a Zero Knowledge Proof (ZKP) that guarantees the integrity and authenticity
+of the VC, even when only partially disclosed to the verifier.
+
+:::note
+Although ZK-SD-VCs offer similar functionalities to [SD-JWT VCs](selective-disclosure.mdx) - at least on a high level - they rely on completely different
+concepts and security concerns. For a user, the most notable difference is the shifted capability of choosing which fields can
+be concealed from a verifier. For ZK-SD-VCs it's the holder that has total control over which parts of the credential can be
+undisclosed, whereas for SD-JWT VCs it's the issuer that decides which fields may be concealed by the holder.
+:::
+
+## Concepts
+### Issuance
+The issuer of a ZK-SD-VC creates the credential, signs it using the [BBS+](https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-05.html) signature scheme
+and sends both the credential and the signature to the holder. To facilitate this process, the credential is first encoded
+as a [JSON Proof Token](https://www.ietf.org/archive/id/draft-ietf-jose-json-proof-token-02.html) (JPT), which is then used as the payload of a
+[JSON Web Proof](https://www.ietf.org/archive/id/draft-ietf-jose-json-web-proof-02.html) (JWP) and sent to the holder as JPT.
+:::note
+JWPs and JPTs can be reasoned about as the Zero Knowledge (ZK) based counterparts of JWSs and JWTs.
+:::
+In code, this process would look like the following snippet:
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-alpha/examples/1_advanced/9_zkp.rs#L95-L122
+```
+
+
+
+
+
+Note how the VC issuer makes no prescription whatsoever regarding the disclosability of the VC's fields.
+
+### Holder presentation
+
+Once the holder receives a presentation challenge from a verifier, they construct a selective disclosure presentation for the requested credential
+and send it back for verification. For this process the JWP in possession of the holder undergoes a transformation that allows the holder
+to conceal any fields from the credentials claims through the creation of a Zero Knowledge Proof (ZKP) of the issuer's signature and becomes a _presented JWP_.
+The proof value depends on the selected [JSON Proof Algorithm](https://www.ietf.org/archive/id/draft-ietf-jose-json-proof-algorithms-02.html) (JPA).
+
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-alpha/examples/1_advanced/9_zkp.rs#L177-L203
+```
+
+
+
+
+Here's an example presented JWP in its JPT JSON serialization format where the undisclosed values are replaced by `null`:
+```
+{
+ "payloads": [
+ null,
+ "IkpheSI",
+ null,
+ "NDI"
+ ],
+ "issuer": "eyJpc3MiOiJodHRwczovL2lzc3Vlci50bGQiLCJjbGFpbXMiOlsiZmFt
+ aWx5X25hbWUiLCJnaXZlbl9uYW1lIiwiZW1haWwiLCJhZ2UiXSwidHlwIjoiSlBUIiw
+ icHJvb2ZfandrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiLCJ4IjoiYWNiSVFpdU
+ 1zM2k4X3VzekVqSjJ0cFR0Uk00RVUzeXo5MVBINkNkSDJWMCIsInkiOiJfS2N5TGo5d
+ ldNcHRubUt0bTQ2R3FEejh3Zjc0STVMS2dybDJHekgzblNFIn0sInByZXNlbnRhdGlv
+ bl9qd2siOnsiY3J2IjoiUC0yNTYiLCJrdHkiOiJFQyIsIngiOiJvQjFUUHJFX1FKSUw
+ 2MWZVT09LNURwS2dkOGoyemJaSnRxcElMRFRKWDZJIiwieSI6IjNKcW5ya3VjTG9ia2
+ RSdU9xWlhPUDlNTWxiRnllbkZPTHlHbEctRlBBQ00ifSwiYWxnIjoiU1UtRVMyNTYif
+ Q",
+ "proof": "LJMiN6caEqShMJ5jPNts8OescqNq5vKSqkfAdSuGJA1GyJyyrfjkpAG0c
+ DJKZoUgomHu5MzYhTUsa0YRXVBnMB91RjonrnWVsakfXtfm2h7gHxA_8G1wkB09x09k
+ on2eK9gTv4iKw4GP6Rh02PEIAVAvnhtuiShMnPqVw1tCBdhweWzjyxJbG86J7Y8MDt2
+ H9f5hhHIwmSLwXYzCbD37WmvUEQ2_6whgAYB5ugSQN3BjXEviCA__VX3lbhH1RVc27E
+ YkRHdRgGQwWNtuExKz7OmwH8oWizplEtjWJ5WIlJpee79gQ9HTa2QIOT9bUDvjjkkO-
+ jK_zuDjZwh5MkrcaQ",
+ "presentation": "eyJub25jZSI6InVURUIzNzFsMXB6V0psN2FmQjB3aTBIV1VOaz
+ FMZS1iQ29tRkx4YThLLXMifQ"
+}
+```
+
+### Verification
+
+The verifier decodes the received JPT presentation and asserts the validity of the ZKP it contains, thus proving the
+authenticity and integrity of the presented credential, without knowledge of any of the undisclosed fields and of the issuer signature.
+
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-alpha/examples/1_advanced/9_zkp.rs#L225-L237
+```
+
+
+
+
+## Full Example Code
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/tree/v1.6.0-alpha/examples/1_advanced/9_zkp.rs
+```
+
+
+
diff --git a/docs/content/iota-identity/how-tos/verifiable-presentations/create-and-validate.mdx b/docs/content/iota-identity/how-tos/verifiable-presentations/create-and-validate.mdx
new file mode 100644
index 00000000000..7aff05427ca
--- /dev/null
+++ b/docs/content/iota-identity/how-tos/verifiable-presentations/create-and-validate.mdx
@@ -0,0 +1,107 @@
+---
+sidebar_label: Create and Validate
+description: Explain how a VP is created and verified
+image: /img/identity/icon.png
+tags:
+ - how-to
+ - identity
+---
+
+# Create and Validate Verifiable Presentations
+
+The IOTA Identity Framework enables holders to easily construct
+[verifiable presentations](./../../explanations/verifiable-presentations.mdx).
+As demonstrated in the [example](#example-code),
+holders only need to pass in their credentials to create a JWT presentation.
+
+## Properties
+
+You can specify the following properties in a presentation:
+
+- [**ID**](https://www.w3.org/TR/vc-data-model/#identifiers): Optional URI identifier for the presentation.
+- [**Context**](https://www.w3.org/TR/vc-data-model/#contexts): List of JSON-LD context URIs. Includes `"https://www.w3.org/2018/credentials/v1"` by default.
+- [**Types**](https://www.w3.org/TR/vc-data-model/#types): List of types describing the presentation. Includes `"VerifiablePresentation"` by default.
+- [**Credentials**](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials): List of verifiable credentials to present.
+- [**Holder**](https://www.w3.org/TR/vc-data-model/#dfn-holders): Optional URI, typically a DID, of the entity that generated the presentation.
+- [**Refresh Service**](https://www.w3.org/TR/vc-data-model/#refreshing): Optional link to a service where the recipient may refresh the included credentials.
+- [**Terms of Use**](https://www.w3.org/TR/vc-data-model/#terms-of-use): Optional list of policies defining obligations, prohibitions, or permissions of the presentation recipient.
+
+Of the above, **only the list of credentials is required** when creating a presentation using the framework.
+However, the holder property should be included to satisfy [subject-holder relationship](#subject-holder-relationship) checks during validation.
+
+After creation, the holder signs the verifiable presentation using a private key linked to one of the verification
+methods in their DID Document and transmits it to a verifier for validation.
+
+## Creation and Validation
+
+A Verifiable Presentation can be issued as a JWT that provides data integrity,
+and also proves the [DID](../../explanations/decentralized-identifiers.mdx) of the holder.
+
+:::note
+
+Verifiers should always send a challenge
+to [mitigate replay attacks](./../../explanations/verifiable-presentations.mdx#security-considerations).
+:::
+
+
+The IOTA Identity Framework provides several options for verifiers to validate various sections of a verifiable presentation.
+See the [example](#example-code) for a demonstration of how to validate a presentation.
+
+The framework checks:
+
+- **Semantic structure**: Ensures the presentation and its credentials adhere to the specification.
+- **Presentation proof**: Verifies the presentation signature against the holder's DID document.
+- **Credential proofs**: Verifies the credential signatures against the DID Documents of their respective issuers.
+
+
+Currently, the following are **not** checked automatically:
+
+- **Data schemas**: Credentials that specify a [schema](https://www.w3.org/TR/vc-data-model/#data-schemas) property
+should be examined to ensure conformance.
+- **Fitness for purpose**: Whether the credentials in a presentation and the data within them are acceptable and
+valid depends on the context in which they are used. Verifiers should ensure that the credential types, subjects,
+and schemas sent by a holder match what was requested.
+- **Issuer trustworthiness**: Verifiers must check that they trust the issuer on each individual credential in a
+presentation. The framework only verifies that the issuer's signature on each credential is current and valid
+against the given options.
+
+The default validation behavior may be modified by the following options.
+
+## Subject-Holder Relationship
+
+Specifies the expected relationship between the holder that signed the verifiable presentation and the subject
+specified in each [verifiable credential](./../../explanations/verifiable-credentials.mdx).
+This can be restricted by the [`nonTransferable`](https://www.w3.org/TR/vc-data-model/#nontransferable-property) property,
+which indicates that a verifiable credential must only be encapsulated into a verifiable presentation whose holder matches the credential subject.
+
+By default, the framework always enforces that the holder matches the subject.
+
+The following options are available to modify that behavior:
+
+- **`AlwaysSubject` (default)**: The holder DID that signed the presentation must match the [`credentialSubject` `id`](https://www.w3.org/TR/vc-data-model/#credential-subject) field in each of the attached credentials. This is the safest option which ensures holders may only present credentials that were directly issued to their DID. An error is thrown on a mismatch or if no subject `id` is present.
+- **`SubjectOnNonTransferable`**: The holder DID must match the subject only for credentials where the [`nonTransferable`](https://www.w3.org/TR/vc-data-model/#nontransferable-property) property is `true`. This is appropriate for accepting [bearer credentials](https://www.w3.org/TR/vc-data-model/#bearer-credentials) while still adhering to the specification.
+- **`Any`**: The holder DID is not required to have any kind of relationship to any credential subject. This option performs no checks and ignores the [`nonTransferable`](https://www.w3.org/TR/vc-data-model/#nontransferable-property) property.
+
+:::note
+
+See the [Verifiable Credentials Data Model Specification](https://www.w3.org/TR/vc-data-model/#subject-holder-relationships)
+for further discussion on the different subject-holder relationships.
+
+:::
+
+
+## Example Code
+
+The following code demonstrates how to use the IOTA Identity Framework end-to-end to create and sign a verifiable
+presentation as a holder, serialize it to JSON for transmission, deserialize it on the receiving side as a verifier,
+and finally validate it with various options.
+
+
+
+
+```rust reference
+https://github.com/iotaledger/identity.rs/blob/v1.6.0-alpha/examples/0_basic/6_create_vp.rs
+```
+
+
+
diff --git a/docs/content/iota-identity/index.mdx b/docs/content/iota-identity/index.mdx
new file mode 100644
index 00000000000..80da6184998
--- /dev/null
+++ b/docs/content/iota-identity/index.mdx
@@ -0,0 +1,79 @@
+---
+description: The most important concepts that developers will need to know to utilize IOTA Identity to its full potential.
+image: /img/identity/icon.png
+tags:
+ - reference
+ - identity
+---
+# IOTA Identity Framework
+
+![IOTA Identity](/img/banner/banner_identity.svg)
+
+The IOTA Identity framework implements the most common standards and patterns for Decentralized Identity in both a DLT agnostic and `iota` method-specific manner.
+It is designed to work for Identity for [People](#identity-for-people), [Organizations](#identity-for-organizations),
+[Things, and Objects](#identity-for-things) acting as a unifying layer of trust between everyone and everything.
+
+## Introduction to Decentralized Identity
+
+Decentralized or Self-Sovereign Identity (SSI) gives individuals full control over their online identity,
+offering a remedy for database breaches, lack of digital trust, and stringent privacy laws like GDPR.
+Digital identity bridges the gap between online pseudonyms and real-world personas, enabling true verifiable identities. This gives individuals the power to choose which data to share and with whom.
+
+### Identity for People
+
+:::info Privacy
+
+IOTA Identity builds a new internet, without usernames, passwords, endless repeated forums, or uncontrolled data harvesting.
+
+:::
+
+Information about anyone's life is spread across many locations. Most people have numerous unorganized important documents at home, hundreds of online accounts, and many more online footprints. Through statistical predictive analysis, computer programs can harvest unverified online information sources and create a reasonably accurate profile about our lives. These profiles are accurate enough for targeted advertising and personalized content but lack the proof and trust for them to be used in business. This results in an antiquated customer experience where we have to submit our age and address for every purchase we make and every account we create. It also inhibits our ability to do many online tasks like requesting and extending licenses or taking out a mortgage.
+
+Self-Sovereign Identity is about returning autonomy and privacy to the individual, while also improving our online experience. Some movements focus on data privacy, preventing companies from using our information altogether, but with the IOTA Identity framework you control which part of the information you want to reveal. The user can create a single online profile containing all our personal information. They can decide who they share what information with, and a verifier checks if the information is correct, making the data trustworthy. This moves their online profile from a statistical estimation by corporate entities to an accurate and verifiable profile under their own control.
+
+IOTA Identity allows a new internet without usernames, passwords, endlessly repeated forms or data harvesting. Users have ultimate control and can choose to supply service providers with their personal data, who in return provide personalized experiences. Data will still flow, and perhaps even more than before, but it will always be in the individual's interest instead of a corporation's. People will gain additional benefits in sharing their data, either in monetary value or improved customer experience. This system is impossible in non-neutral environments such as permissioned or fee-based ledgers.
+
+Governmental mechanisms for building _digital identities_ are currently being established throughout Europe and Asia, with demand increasing around the globe. However, they are managed by single entities and restricted to the governments that created them. By decentralizing a framework for these standards to adapt to, we have a system for intergovernmental verification of individuals and devices. A person’s digital identification will be transferable across borders like a passport. However, it will no longer require the trust of the issuing government due to the digital trust established by the open and auditable system.
+
+### Identity for Organizations
+
+:::info GDPR
+
+IOTA Identity allows organizations to comply with GDPR in a cost-efficient and privacy-enabling manner
+
+:::
+
+Corporations are associated with greed and abuse of power. This reputation stems from the role some have chosen to take within society. Corporations are trusted with our data, but often do not act responsibly; vulnerability, fix, patch, repeat. In software and systems, we have seen this cycle repeat. Headlines on data leaks are now an ever-present feature in the news.
+
+IOTA Identity presents an opportunity for companies to embrace a new role in the ecosystem. Traditional approaches do not provide cost-efficient solutions to new legislation like GDPR. IOTA Identity enables organizations to change their processes to comply with the new regulations in a cost-efficient and privacy-enabling manner. Features of “Data Protection and Privacy by Design” shift responsibility over Personal Identifiable Information (PII) from organization to customer, and organizations no longer need to store that data. The relationship between customer and organization is also tightened as communication via a third-party Identity provider like Google or Facebook is no longer needed.
+
+Due to Know-Your-Customer (KYC) and Anti-Money Laundering (AML) obligations, companies can be certain who their customers are. These services also provide unique insight into their customers’ data. These insights can be combined and translated into verifiable credentials, providing a new “Trust Anchor” service with the potential for new business models. KYC and AML credentials would return the autonomy of personal data to the customer. Once companies accept other companies' KYC and AML credentials, the enrollment time for new customers is significantly reduced, as are the costs. With the personal data secured by the customer, companies can afford to store less data in their databases, reducing risk and responsibility and fulfilling the goals of legislation such as GDPR.
+
+Organizations that have their own decentralized identities can also combat fraud and increase control over their online brand. Companies can sign invoices and agreements using their decentralized identities. While interacting with the customers, they will also be able to reliably identify themselves.
+
+### Identity for Things
+
+:::info TRUST
+
+IOTA Identity adds the missing key ingredient for the "Economy of Things": Trust.
+
+:::
+
+With Identity of Things (IDoT), devices are provided with a unique global identity that are able to prove many attributes, including their capabilities, specifications, and authenticity. People, organizations, and other devices will only pay for devices that can prove their ability to fulfill the required task. This basis of trust prevents fraudulent activity. Additionally, using the IOTA ledger, the task's progress can be immutably logged. Combining the IOTA protocol and the IOTA Identity framework, we can automate the entire interaction between all parties without requiring predefined trust. The [Industry Marketplace](https://industry.iota.org/) provides a perfect example of how this framework and level of autonomy work.
+
+There is a growth in applications that generate Digital Twins for physical devices or objects, such as the Asset Administration Shell (AAS) developed for our Industry Marketplace. Digital twins are online profiles representing a device or object. They provide a virtual state that mirrors reality by emulating the device or object’s physical state through data input sources like sensors. A digital twin is often used to monitor states and execute actions based on the information. Digital twins are only rarely shared outside the associated application and organization due to the complexities in sharing and matching profiles. However, empowered with a digital identity, digital twin sharing would become possible. Once data is verifiable and trusted, digital twins can form the basis for the digital representation of physical devices and objects. This allows other identities to interact with them automatically and provide services such as predictive maintenance.
+
+Security is a major barrier to advancing technologies that use IoT. Whether it is the smart devices in our homes or at a larger scale, the critical infrastructure of organizations and cities, security must be at the core. It is central to any globally unifying identity solution. By integrating advanced research in cryptography and digital ledgers and combining it with a scalable access and management system, security will become a core functionality of the systems we build. By using scalable device DIDs, integrating verification and reputation schemes, and allowing for transparent tamper-proof accountability, we begin to understand how we can future-proof the security of our systems, allowing us to start trusting the process and not the patch.
+
+### One Framework. Any Identity
+
+The IOTA Identity framework serves as a ubiquitous layer of trust for the internet. Whether it's people, organizations, or things, the framework enables the creation of digital identities, fosters trust-building through verifiable credentials, and ensures seamless interaction among different entities.
+
+### Why IOTA?
+
+IOTA stands apart as a scalable Distributed Ledger Technology (DLT), suitable for a universal identity solution. Some features of IOTA include:
+
+* **Cost-effectiveness**: Creating Identities on IOTA incurs minimal fees and deposits for occupied ledger space can be reclaimed at any time.
+* **High availability**: Identities are always available on all network nodes - for holders, issuers, and verifiers.
+* **Security**: Write access to identities is secured through multi-level control structures with key rotation capabilities, allowing for backup access and recoverability.
+* **Integrity**: Updates go through the same mechanisms that secure the IOTA network, guaranteeing consistent state and history of all identities.
diff --git a/docs/content/references/iota-identity/iota-did-method-spec.mdx b/docs/content/references/iota-identity/iota-did-method-spec.mdx
new file mode 100644
index 00000000000..bdd13a83ac7
--- /dev/null
+++ b/docs/content/references/iota-identity/iota-did-method-spec.mdx
@@ -0,0 +1,226 @@
+---
+title: IOTA DID Method Specification v2.0
+sidebar_label: DID Method
+description: How IOTA Identity implements the Decentralized Identifiers Standard on the IOTA Tangle.
+image: /img/identity/icon.png
+tags:
+ - reference
+ - identity
+ - did
+---
+
+# IOTA DID Method Specification v2.0
+
+2024-08-23
+
+## Abstract
+
+The IOTA DID Method Specification describes a method of implementing the [Decentralized Identifiers](https://www.w3.org/TR/did-core/) (DID) standard on [IOTA](https://iota.org), a Distributed Ledger Technology (DLT). It conforms to the [DID specification v1.0](https://www.w3.org/TR/did-core/) and describes how to perform Create, Read, Update and Delete (CRUD) operations for IOTA DID Documents using shared Move objects on the IOTA network.
+
+## Introduction
+
+{/*
+### Move-based DLT
+
+:::warning
+We might want to borrow text for this section from other parts of the wiki that deal with this in more details!
+:::
+*/}
+
+### Identity Object
+
+`Identity` is a **shared** _Move_ object that contains a DID document along other metadata used for access-control.
+
+Although `Identity`'s instances are **shared**, and therefore publicly accessible by anyone, only a well-defined per-instance set of
+actors - called **controllers** - are allowed to make changes to an `Identity`.
+
+### Ledger and DID
+
+Storing DID Documents in the ledger state means they inherently benefit from the guarantees the ledger provides.
+
+1. Conflicts among nodes are resolved and dealt with by the ledger.
+2. Replay attacks are mitigated since transactions need to be confirmed by the ledger.
+3. Through the `State Index` a linear history for updates of a DID Document is provided.
+
+## DID Method Name
+
+The `method-name` to identify this DID method is: `iota`.
+
+A DID that uses this method MUST begin with the following prefix: `did:iota`. Following the generic DID specification, this string MUST be lowercase.
+
+## DID Format
+
+The DIDs that follow this method have the following ABNF syntax. It uses the syntax in [RFC5234](https://www.rfc-editor.org/rfc/rfc5234) and the corresponding definition for `digit`.
+
+```
+iota-did = "did:iota:" iota-specific-idstring
+iota-specific-idstring = [ iota-network ":" ] iota-tag
+iota-network = 8lowercase-hex
+iota-tag = "0x" 64lowercase-hex
+lowercase-hex = digit / "a" / "b" / "c" / "d" / "e" / "f"
+```
+
+It starts with the string "did:iota:", followed by an optional network name (8 lowercase hexadecimal digits) and a colon, then the tag.
+The tag starts with "0x" followed by a lowercase hex-encoded `Object ID`.
+
+### IOTA-Network
+
+The iota-network is an identifier of the network where the DID is stored. This network must be an IOTA Ledger, but can either be a public or private network, permissionless or permissioned.
+
+When no IOTA network is specified, it is assumed that the DID is located on IOTA main network, having id **PUT IOTA CHAIN ID HERE**. This means that the following DIDs will resolve to the same DID Document:
+
+```
+did:iota:IOTA CHAIN ID:0xe4edef97da1257e83cbeb49159cfdd2da6ac971ac447f233f8439cf29376ebfe
+did:iota:0xe4edef97da1257e83cbeb49159cfdd2da6ac971ac447f233f8439cf29376ebfe
+```
+
+### IOTA-Tag
+
+An IOTA-tag is a lowercase hex-encoded `Object ID`. The `Object ID` itself is a unique identifier for _Move_ objects and is derived from the digest of the trasanction that created the object it identifies.
+This tag identifies the `Identity` where the DID Document is stored, and it will not be known before the generation of the DID since it will be assigned when the `Identity` object is created.
+
+### Anatomy of the encoded DID Document
+
+The DID Document stored within an `Identity` must be encoded as the payload of a byte packed structure with fields as follows:
+
+| Name | Type | Description |
+| ------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Document Type | ByteArray[3] | Set to value **DID** to denote a DID Document. |
+| Version | uint8 | Set value **1** to denote the version number of this method |
+| Encoding | uint8 | Set to value to **0** to denote JSON encoding without compression. |
+| Payload | (uint16)ByteArray | A DID Document and its metadata, where every occurrence of the DID in the document is replaced by `did:0:0`. It must be encoded according to `Encoding`. |
+
+The types are defined in [TIP-21](https://github.com/iotaledger/tips/blob/main/tips/TIP-0021/tip-0021.md).
+
+#### Payload
+
+The payload must contain the following fields:
+
+- `meta`: contains metadata about the DID Document. For example, `created` to indicate the time of
+ creation, and `updated` to indicate the time of the last update to the document. It may also include other properties.
+- `doc`: contains the DID Document. In the example below, the document only contains one verification method. The `id` and `controller` is specified by `did:0:0` which references the DID of the document itself, since the DID is unknown at the time of publishing. It also deduplicates the DID of the document to reduce the size of the state metadata, in turn reducing the required storage deposit.
+
+Example State Metadata Document:
+
+```json
+{
+ "doc": {
+ "id": "did:0:0",
+ "verificationMethod": [
+ {
+ "id": "did:0:0#jkGOGVO3Te7ADpvlplr47eP9ucLt41zm",
+ "controller": "did:0:0",
+ "type": "JsonWebKey",
+ "publicKeyJwk": {
+ "kty": "OKP",
+ "alg": "EdDSA",
+ "kid": "jkGOGVO3Te7ADpvlplr47eP9ucLt41zm",
+ "crv": "Ed25519",
+ "x": "D5w8vG6tKEnpBAia5J4vNgLID8k0BspHz-cVMBCC3RQ"
+ }
+ }
+ ],
+ "authentication": ["did:0:0#jkGOGVO3Te7ADpvlplr47eP9ucLt41zm"]
+ },
+ "meta": {
+ "created": "2023-08-28T14:49:37Z",
+ "updated": "2023-08-28T14:50:27Z"
+ }
+}
+```
+
+## Multiple _controllers_ and _voting power_
+
+An `Identity` may be owned by more than one controller and each controller may have a different **voting power** - i.e. a quantificable level of control over a given `Identity` represented with an unsigned integer.
+Whenever control over an `Identity` is shared among multiple controllers an access control (AC) policy - in the form of an unsigned positive integer **threshold** - must be defined. Any operation a controller performs that might modify the interested `Identity` isn't carried out right away. Instead, a **proposal** to perform such an operation is created, and controllers are required to approve it, before it may be executed. The number of approvals needed in order to execute the proposal depends on the threshold and controllers' voting power.
+
+## CRUD Operations
+
+Create, Read, Update and Delete (CRUD) operations that change the DID Documents are performed by invoking `Identity`'s APIs in a transaction.
+
+**These operations require funds to cover the gas cost. Transactions must be carefully done in order to avoid fund loss** - e.g. executing a transaction that is bound to fail wastefully consumes funds for gas. Additionally, private keys of controllers must be stored securely.
+
+### Create
+
+In order to create a simple self controlled DID two things are required:
+
+1. An Address for which the private key is available.
+2. Enough funds to cover for the creation of a new `Identity` object.
+
+Creation steps:
+
+1. Create the content of the DID Document like verification methods, services, etc.
+2. Create the payload and the headers as described in the [Anatomy of the encoded DID document](#anatomy-of-the-encoded-did-document).
+3. Execute `Identity::new` in a transaction, providing the encoded DID document as its parameter.
+
+Once the transaction is confirmed, the DID is published and can be formatted by using the `Object ID` as the tag in [DID Format](#did-format).
+
+### Read
+
+The following steps can be used to read the latest DID Document associated with a DID.
+
+1. Obtain the `Object ID` from the DID by extracting the `iota-tag` from the DID, see [DID Format](#did-format).
+2. Obtain the network of the DID by extracting the `iota-network` from the DID, see [DID Format](#did-format).
+3. Query the Object corresponding to the `Object ID` using a node running the indexer, asserting that the network the node is connected to matches the previously extracted network ID.
+4. Assert that the `Object ID` of the returned Object matches the `Object ID` extracted from the DID. Return an error otherwise.
+5. Parse the retrieved object into an `Identity` object.
+6. Decode the DID Document from its byte packed encoding stored in the `Identity` Object.
+7. Replace the placeholder `did:0:0` with the DID given as input.
+
+### Update
+
+Updating a DID Document can be achieved by invoking the `Identity::propose_update` API passing the updated encoded DID Document as its parameter, followed by executing the generated proposal after enough approvals from the `Identity`'s controllers are obtained.
+In a more detailed step-by-step description:
+
+1. Create a copy of the encoded DID document with the `Object ID` set explicitly.
+2. Pack the updated DID Document, as described in the [Anatomy of the encoded DID Document](#anatomy-of-the-encoded-did-document), and use it as the parameter to a call to `Identity::propose_update` API.
+3. Query the generated `Proposal` object, and check if the threshold has been reached. If that's not the case wait for enough controllers to approve the proposal.
+4. Execute the approved proposal by invoking `Identity::execute_update`.
+
+### Delete
+
+#### Deactivate
+
+Temporarily deactivating a DID can be done by deleting the contents of the encoded DID Document in the `Identity` object, setting it to an empty byte array, and publishing an [update](#update).
+
+Another option is to [update](#update) the DID Document and set the `deactivated` property in its `metadata` to true. In both cases, the deactivated DID Document will be marked as `deactivated` when resolved.
+
+#### Destroy
+
+To permanently destroy a DID Document controllers need to go through a process similar to that of [updating](#update) the document. First, a proposal for destroying the corresponding `Identity` is created, which can be executed after the AC policy has been met.
+
+Note that this operation irreversibly and irrecoverably deletes the DID. This is because the `Object ID` from which an IOTA DID is derived (see [IOTA-Tag](#iota-tag)) is generated from the hash of the input transaction that created it, which cannot generally be replicated.
+
+## IOTA Identity standards
+
+The `did:iota` method is implemented in the [IOTA Identity framework](https://github.com/iotaledger/identity.rs). This framework supports a number of operations that are standardized, some are standardized across the SSI community, and some are the invention of the IOTA Foundation.
+
+### Revocation
+
+Revocation of verifiable credentials and signatures can be achieved using the [Revocation Bitmap 2022](./revocation-bitmap-2022.mdx) where issuers store a bitmap of indices in the DID Document. These indices correspond to verifiable credentials they have issued. If the binary value of the index in the bitmap is 1 (one), the verifiable credential is revoked, if it is 0 (zero) it is not revoked.
+
+### Standardized Services
+
+The IOTA Identity framework also standardized certain `services` that are embedded in the DID Document. It is RECOMMENDED to implement these when implementing the `did:iota` method.
+
+Currently standardized `services`:
+
+- [Revocation Bitmap Service](./revocation-bitmap-2022.mdx#revocation-bitmap-service)
+
+## Security Considerations
+
+### Private Key Management
+
+All private keys or seeds used for the `did:iota` method should be equally well protected by the users. Private keys of the state controller and the governor are especially important as they control how keys are added or removed, providing full control over the identity.
+
+## Privacy Considerations
+
+### Personal Identifiable Information
+
+IOTA networks are immutable. This means that once something is included, it can never be completely removed. For example, destroying an `Identity` will remove it from the ledger state, but it can still be stored in permanodes or by any party that records historical ledger states.
+
+That directly conflicts with certain privacy laws such as GDPR, which have a 'right-to-be-forgotten' for Personal Identifiable Information (PII). As such, users should NEVER upload any PII, including inside DID Documents. While verifiable credentials can be made public, this should only be utilized by Identity for Organisations and Identity for Things.
+
+### Correlation Risks
+
+As with any DID method, identities can be linked if they are used too often and their usage somehow becomes public. See [DID Correlation Risks](https://www.w3.org/TR/did-core/#did-correlation-risks). Additionally, a DID can be correlated with funds if the Alias Output used to store the DID Document or any of its controllers is used for holding, transferring or controlling coins or NFTs.
diff --git a/docs/content/references/iota-identity/overview.mdx b/docs/content/references/iota-identity/overview.mdx
new file mode 100644
index 00000000000..db1b1da3510
--- /dev/null
+++ b/docs/content/references/iota-identity/overview.mdx
@@ -0,0 +1,17 @@
+---
+title: Specifications Overview
+sidebar_label: Overview
+description: Provide overview of the specifications
+image: /img/identity/icon.png
+tags:
+ - reference
+ - identity
+---
+
+While IOTA Identity implements many existing standards, it also adds some additional features we would like to standardize ourselves. This section covers these features and how they work in great detail. These are not light reads and can be skipped.
+
+The current specifications are:
+
+- [IOTA DID](iota-did-method-spec.mdx): The specification for the IOTA DID Method implemented on the IOTA network.
+- [Revocation Bitmap 2022](revocation-bitmap-2022.mdx): The specification for an on-chain credential revocation mechanism.
+- [Revocation Timeframe 2024](revocation-timeframe-2024.mdx): The specification for a privacy-enhanced on-chain credential revocation mechanism.
\ No newline at end of file
diff --git a/docs/content/references/iota-identity/revocation-bitmap-2022.mdx b/docs/content/references/iota-identity/revocation-bitmap-2022.mdx
new file mode 100644
index 00000000000..0a373d8c5b9
--- /dev/null
+++ b/docs/content/references/iota-identity/revocation-bitmap-2022.mdx
@@ -0,0 +1,199 @@
+---
+title: Revocation Bitmap
+sidebar_label: Revocation Bitmap
+description: The specification for the embedded revocation bitmap.
+image: /img/identity/icon.png
+tags:
+ - reference
+ - identity
+ - did
+---
+
+# Revocation Bitmap 2022
+
+## Abstract
+
+This specification describes a mechanism for publishing the revocation status of [verifiable credentials](../../iota-identity/explanations/verifiable-credentials.mdx) embedded in an issuer's DID document.
+
+## Introduction
+
+Revocation gives an issuer the capability to invalidate a credential they issued before its natural expiration date. To achieve this, issuers can embed an identifier in the `credentialStatus` field of a credential. Verifiers can then lookup that identifier in a separate list, to check whether the credential is still valid. This document specifies a mechanism of embedding such a list, in form of a bitmap, in the DID document of the issuer, where each bitmap index corresponds to a credential they have issued. This mechanism is space-efficient and enables a verifier to check a credential's status in a privacy-preserving manner and without requiring additional lookups or external resources.
+
+## Revocation Bitmap Concept
+
+The revocation status of a verifiable credential is expressed as a binary value. The issuer keeps a bitmap of indices corresponding to verifiable credentials they have issued. If the binary value of the index in the bitmap is 1 (one), the verifiable credential is revoked, if it is 0 (zero) it is not revoked.
+
+## Data Model
+
+### Revocation Bitmap Status
+
+For an issuer to enable verifiers to check the status of a verifiable credential, the [`credentialStatus`](https://www.w3.org/TR/vc-data-model/#status) property MUST be specified with the following properties:
+
+| Property | Description |
+| :---------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `id` | The constraints on the `id` property are listed in the [Verifiable Credentials Data Model specification](https://www.w3.org/TR/vc-data-model/). The `id` MUST be a [DID URL](https://www.w3.org/TR/did-core/#did-url-syntax) that is the URL to a [Revocation Bitmap Service](#revocation-bitmap-service) in the DID Document of the issuer. It SHOULD include an `index` query set to the same value as `revocationBitmapIndex`, to uniquely identify the `credentialStatus`. If the `index` query is present, implementations SHOULD reject statuses where the `index` query's value does not match `revocationBitmapIndex`. |
+| `type` | The `type` property MUST be `"RevocationBitmap2022"`. |
+| `revocationBitmapIndex` | The `revocationBitmapIndex` property MUST be an unsigned, 32-bit integer expressed as a string. This is the index of the credential in the issuer's revocation bitmap. Each index SHOULD be unique among all credentials linking to the same [Revocation Bitmap Service](#revocation-bitmap-service). |
+
+#### Example
+
+An example of a verifiable credential with a `credentialStatus` of type `RevocationBitmap2022`.
+
+```json
+{
+ "@context": "https://www.w3.org/2018/credentials/v1",
+ "id": "https://example.edu/credentials/3732",
+ "type": ["VerifiableCredential", "UniversityDegreeCredential"],
+ "credentialSubject": {
+ "id": "did:iota:B8DucnzULJ9E8cmaReYoePU2b7UKE9WKxyEVov8tQA7H",
+ "GPA": "4.0",
+ "degree": "Bachelor of Science and Arts",
+ "name": "Alice"
+ },
+ "issuer": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw",
+ "issuanceDate": "2022-06-13T08:04:36Z",
+ "credentialStatus": {
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw?index=5#revocation",
+ "type": "RevocationBitmap2022",
+ "revocationBitmapIndex": "5"
+ },
+ "proof": {
+ "type": "JcsEd25519Signature2020",
+ "verificationMethod": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#key-1",
+ "signatureValue": "2eHdbDumMrer4pNVkaiYMqsVqVp2adq7bRcgTJZiw17Zeghk2ZT49YHwLwCCg35YKganBhxP6YSbzYoBK1AuCUv"
+ }
+}
+```
+
+### Revocation Bitmap Service
+
+To allow verifiers to check the status of a [Revocation Bitmap Status](#revocation-bitmap-status), the DID document of the credential issuer MUST contain a [service](https://www.w3.org/TR/did-core/#services) with the following properties:
+
+| Property | Description |
+| :---------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `id` | The constraints on the `id` property are listed in the [DID Core service specification](https://www.w3.org/TR/did-core/#services). The `id` property MUST be a DID URL uniquely identifying the revocation bitmap. |
+| `type` | The `type` property MUST be `"RevocationBitmap2022"`. |
+| `serviceEndpoint` | The `serviceEndpoint` MUST be generated according to the [service endpoint generation algorithm](#service-endpoint-generation-algorithm). |
+
+#### Example
+
+An example of an issuer's DID document where credential `"5"` in the `#revocation` service is revoked:
+
+```json
+{
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw",
+ "verificationMethod": [
+ {
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#key-1",
+ "controller": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw",
+ "type": "Ed25519VerificationKey2018",
+ "publicKeyMultibase": "z3hgM9fNkhwgT5mECbj1HdKoFNZgpffwQYEV8WBVHphXq"
+ }
+ ],
+ "capabilityInvocation": [
+ {
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#sign-0",
+ "controller": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw",
+ "type": "Ed25519VerificationKey2018",
+ "publicKeyMultibase": "z83F6zbD3KqaxvQhqo25LvSXzoDdpZmp3EpPVonSVACwZ"
+ }
+ ],
+ "service": [
+ {
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#revocation",
+ "type": "RevocationBitmap2022",
+ "serviceEndpoint": "data:application/octet-stream;base64,ZUp5ek1tQmdZR1NBQUFFZ1ptVUFBQWZPQUlF"
+ }
+ ]
+}
+```
+
+## Algorithms
+
+The following algorithms define how to generate, expand and validate revocation bitmaps.
+
+### Service Endpoint Generation Algorithm
+
+The following process MUST be followed when producing a `RevocationBitmap2022` to embed in a service endpoint:
+
+1. Let **bitmap** be a [_roaring bitmap_](https://roaringbitmap.org/) where each bit is initialized to 0.
+2. For each revoked credential with an **index** not exceeding an unsigned, 32-bit integer, set the corresponding bit in **bitmap** at **index** to 1.
+3. Generate the **bitmap serialization** according to the [roaring bitmap serialization format](https://github.com/RoaringBitmap/RoaringFormatSpec/) using the **bitmap** as input.
+4. Generate a **compressed bitmap** by using the ZLIB compression algorithm [[RFC 1950](https://datatracker.ietf.org/doc/html/rfc1950)] on the **bitmap serialization** and base64-encoding [[RFC4648](https://datatracker.ietf.org/doc/html/rfc4648)] the result.
+5. Create the **service endpoint** by embedding the **compressed bitmap** in a data URL [[RFC2397](https://datatracker.ietf.org/doc/html/rfc2397)]. On the data url, the `` MUST be `application/octet-stream` and the `base64` attribute MUST be set.
+6. Return the **service endpoint**.
+
+### Service Endpoint Expansion Algorithm
+
+The following process MUST be followed when expanding the endpoint from a service of type `RevocationBitmap2022`:
+
+1. Let **service endpoint** be a data url generated using the [service endpoint generation algorithm](#service-endpoint-generation-algorithm).
+2. The `` of the **service endpoint** MUST be `application/octet-stream` and the `base64` attribute MUST be set, return an error otherwise. Let **compressed bitmap** be the `` part of the data url.
+3. Generate an **uncompressed bitmap** by base64-decoding [[RFC4648](https://datatracker.ietf.org/doc/html/rfc4648)] the **compressed bitmap** and then decompressing the result using ZLIB [[RFC 1950](https://datatracker.ietf.org/doc/html/rfc1950)].
+4. Generate the **bitmap** by deserializing the **uncompressed bitmap** according to the [roaring bitmap serialization format](https://github.com/RoaringBitmap/RoaringFormatSpec/).
+5. Return the **bitmap**.
+
+### Validation Algorithm
+
+The following steps MUST be followed when checking whether a verifiable credential is revoked:
+
+1. Let **credential** be a verifiable credential containing a `credentialStatus` whose `type` is `RevocationBitmap2022`.
+2. Let **revocation bitmap URL** be the `id` field of the **credential**'s `credentialStatus`.
+3. Resolve the **revocation bitmap URL** to a **revocation bitmap service** in the issuer's DID document, and verify that the service `type` is `RevocationBitmap2022`. Return an error otherwise.
+4. Expand the endpoint of the **revocation bitmap service** into a **revocation bitmap** according to the [service endpoint expansion algorithm](#service-endpoint-expansion-algorithm).
+5. Let **revocation index** be the integer value of the `revocationBitmapIndex` property contained in the `credentialStatus` of the **credential**.
+6. Let **revoked** be the value of the bit at index **revocation index** in the **revocation bitmap**.
+7. Return `true` if **revoked** is 1, `false` otherwise.
+
+## Test Vectors
+
+This section provides test vectors to validate implementations against.
+
+### Test Vector 1
+
+The following data URL decodes to a bitmap of length 0 where no index is revoked:
+
+`"data:application/octet-stream;base64,ZUp5ek1tQUFBd0FES0FCcg=="`
+
+### Test Vector 2
+
+The following data URL decodes to a bitmap of length 3 where indices `5`, `398`, and `67000` are revoked:
+
+`"data:application/octet-stream;base64,ZUp5ek1tQmdZR0lBQVVZZ1pHQ1FBR0laSUdabDZHUGN3UW9BRXVvQjlB"`.
+
+### Test Vector 3
+
+The following data URL decodes to a bitmap of length 16384 where all indices are revoked:
+
+`"data:application/octet-stream;base64,ZUp6dHhERVJBQ0FNQkxESEFWS1lXZkN2Q3E0MmFESmtyMlNrM0ROckFLQ2RBQUFBQUFBQTMzbGhHZm9q"`
+
+## Rationale
+
+This section describes the rationale behind some of the design decisions of this specification.
+
+### Compression and maximum size
+
+Considering that messages published to the Tangle cannot exceed [32 KiB](https://github.com/iotaledger/tips/blob/main/tips/TIP-0006/tip-0006.md#message-validation) in size, and that larger messages have increased requirements, the use of compression was assessed.
+The precise size of a serialized bitmap varies based on the number and distribution of revoked indices. When indices are revoked uniformly randomly, roughly 100,000 - 200,000 can be achieved in a DID Document with compression, and significantly more if consecutive indices are revoked.
+
+ZLIB [[RFC 1950](https://datatracker.ietf.org/doc/html/rfc1950)] was chosen for having a free and open source software licence and being one of the most widely used compression schemes, which enhances the accessibility of this specification. Some other assessed algorithms produced only marginally better compression ratios but had far fewer existing implementations across different programming languages.
+
+### Compressed Bitstring vs. Roaring Bitmap
+
+Because of its space efficiency, a roaring bitmap is preferred for representing a bitmap in-memory. To avoid the dependency on roaring bitmap, we considered using a compressed bitstring as the serialization format. However, serialization of such a bitstring was 2-3x slower compared to roaring's serialization format, which becomes an issue on resource-constrained devices (e.g. smartphones) or in web browsers.
+
+### Comparison to `RevocationList2020` and `StatusList2021`
+
+The [RevocationList2020 specification](https://w3c-ccg.github.io/vc-status-rl-2020/) and [StatusList2021 specification](https://w3c-ccg.github.io/vc-status-list-2021/) both describe a similar revocation mechanism using a verifiable credential that contains a bitmap, similar to the `RevocationBitmap2022` approach. The credential is hosted outside of the DID document and the verifier thus needs to fetch it from an external resource, likely one controlled by the issuer. This has privacy implications as the issuer can track where a fetch request for the credential came from and potentially infer who the credential was verified by and for what purpose. The issuer can also potentially infer which credential was checked. Because `RevocationBitmap2022` is embedded in the issuer's DID document, which can be obtained without the their knowledge, this approach does not suffer from these privacy shortcomings. See also the [privacy considerations](#privacy-considerations).
+
+A downside of embedding the revocation list in the DID document is that storage in a distributed ledger (DLT) is usually more expensive than other storage hosting solutions. The DLT might also impose message size limitations, capping the total number of revocations that can be done (see also [compression](#compression-and-maximum-size)).
+
+Another difference is that `RevocationList2020` specifies a minimum initial size of 131,072 for its bitstring, to mitigate the potential for correlating individuals when few credentials have been issued. `RevocationBitmap2022` uses a roaring bitmap instead of a bitstring, so the maximum size is not fixed (apart from the upper bound of an unsigned 32-bit integer). This means the bitmap cannot be used to correlate small populations without more information not present in the bitmap itself. However, both schemes still reveal publicly how many credentials have been revoked, which could be used to infer other information if more knowledge about how an issuer assigns credential revocation indexes is known.
+
+`StatusList2021` allows for explicitly stating the purpose of the list, currently either _revocation_ or _suspension_. This specification does not mandate that revoked credentials cannot be unrevoked, which means a `RevocationBitmap2022` can effectively also be used as a suspension list.
+
+### Privacy Considerations
+
+Because the revocation bitmap is embedded in the DID document, and thus available without contacting the issuer directly, the issuer cannot correlate how a holder uses their credential.
+
+An observer finding a service of type `RevocationBitmap2022` in a DID document can infer that this DID belongs to an issuer. However, DIDs of issuers tend to be publicly known, in contrast to DIDs of other entities, so this is unlikely to present an issue. External observers can monitor the frequency of revocations and potentially the total number of issued credentials, depending on how the issuer assigns credential indices (e.g. starting from 0 and incrementing the index for each issued credential).
\ No newline at end of file
diff --git a/docs/content/references/iota-identity/revocation-timeframe-2024.mdx b/docs/content/references/iota-identity/revocation-timeframe-2024.mdx
new file mode 100644
index 00000000000..c4f7fb84ed7
--- /dev/null
+++ b/docs/content/references/iota-identity/revocation-timeframe-2024.mdx
@@ -0,0 +1,148 @@
+---
+title: Revocation Timeframe 2024
+sidebar_label: Revocation Timeframe 2024
+description: The specification for an embeddable time-based revocation method - `RevocationTimeframe2024`.
+image: /img/identity/icon.png
+tags:
+ - reference
+ - identity
+ - did
+---
+
+# Revocation Timeframe 2024
+
+## Abstract
+
+This specification describes a new revocation mechanism - `RevocationTimeframe2024` - that extends [`RevocationBitmap2022`](./revocation-bitmap-2022.mdx)
+to address its linkability security concerns, at least when used in combination with selectively disclosable (SD-able) VCs.
+
+## Introduction
+
+`RevocationBitmap2022` allows for a simple and straightforward way for an issuer to invalidate an issued VC before its expiration. While this method prevents the analysis of usage by the issuer through hosting the revocation information on-chain
+it comes with a high risk of linkability by colluding verifiers as they can store the bitmap index and use it to identify users. Additionally, verifiers can monitor the revocation information and at a later point, outside of any interaction, check the revocation status.
+To address this privacy concern, `RevocationTimeframe2024` was designed as an extension that builds on top of `RevocationBitmap2022`, therefore sharing
+most of its logic.
+
+## Concepts
+`RevocationTimeframe2024` should be used together with selectively disclosable credentials - either [SD-JWT](../../iota-identity/how-tos/verifiable-credentials/selective-disclosure)
+or [ZK-SD](../../iota-identity/how-tos/verifiable-credentials/zero-knowledge-selective-disclosure) - in order to conceal to the verifier
+the credential's index in the issuer's revocation bitmap to avoid linkability.
+
+### Validity Timeframe
+
+If the revocation index is concealed from the verifier how can it assert the validity of the presented credential?
+To solve this issue `RevocationTimeframe2024` introduces the concept of a _validity timeframe_, i.e. a limited time span
+in which the credential is guaranteed to be non-revoked. By having a validity timeframe embedded in the credential's status
+the verifier can prove the credential's validity by verifying the credential's signature.
+
+The downside of this mechanism is that the credential holder using `RevocationTimeframe2024` has to contact the credential's issuer
+to update the signature - i.e. re-issue the credential - at the end of the credentials validity timeframe. Furthermore,
+given how a credentials validity timeframe proves the validity of the credential itself, the updates made by the issuer to the credential's status -
+i.e., revoking or un-revoking it - won't be reflected on the credential until a new validity timeframe starts. For this reason,
+issuers should choose a validity timeframe length with respect to how frequently they expect to change the credential's status;
+frequent updates deem shorter validity timeframes.
+
+:::note
+A credential holder does not need to have its credential re-issued at the end of every validity timeframe, but only when
+they need to present the credential to a verifier and its validity timeframe has expired.
+:::
+
+## Data Model
+
+### Revocation Timeframe Status
+
+For an issuer to enable verifiers to check the status of a verifiable credential, the [`credentialStatus`](https://www.w3.org/TR/vc-data-model/#status) property MUST be specified with the following properties:
+
+| Property | Description |
+| :---------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `id` | The constraints on the `id` property are listed in the [Verifiable Credentials Data Model specification](https://www.w3.org/TR/vc-data-model/). The `id` MUST be a [DID URL](https://www.w3.org/TR/did-core/#did-url-syntax) that is the URL to a [Revocation Timeframe Service](#revocation-timeframe-service) in the DID Document of the issuer. |
+| `type` | The `type` property MUST be `"RevocationTimeframe2024"`. |
+| `revocationBitmapIndex` | The `revocationBitmapIndex` property MUST be an unsigned, 32-bit integer expressed as a string. This is the index of the credential in the issuers revocation bitmap. Each index SHOULD be unique among all credentials linking to the same [Revocation Timeframe Service](#revocation-timeframe-service). To ensure user unlinkability, this value MUST NOT be disclosed to the verifier (this is done by default). |
+| `startValidityTimeframe`| The `startValidityTimeframe` property MUST be a [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339)-compliant timestamp. |
+| `endValidityTimeframe`| The `endValidityTimeframe` property MUST be a [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339)-compliant timestamp. |
+
+#### Example
+
+An example of a verifiable credential with a `credentialStatus` of type `RevocationTimeframe2024`.
+
+```json
+{
+ "@context": "https://www.w3.org/2018/credentials/v1",
+ "id": "https://example.edu/credentials/3732",
+ "type": ["VerifiableCredential", "UniversityDegreeCredential"],
+ "credentialSubject": {
+ "id": "did:iota:B8DucnzULJ9E8cmaReYoePU2b7UKE9WKxyEVov8tQA7H",
+ "GPA": "4.0",
+ "degree": "Bachelor of Science and Arts",
+ "name": "Alice"
+ },
+ "issuer": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw",
+ "issuanceDate": "2022-06-13T08:04:36Z",
+ "credentialStatus": {
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#my-revocation-service",
+ "type": "RevocationTimeframe2024",
+ "revocationBitmapIndex": "5"
+ "startValidityTimeframe": "2024-05-03T08:00:00Z",
+ "endValidityTimeframe": "2024-05-03T08:05:00Z",
+ },
+}
+```
+
+### Revocation Timeframe Service
+
+To allow verifiers to check the status of a [Revocation Timeframe Status](#revocation-timeframe-status), the DID document of the credential issuer MUST contain a [service](https://www.w3.org/TR/did-core/#services) with the following properties:
+
+| Property | Description |
+| :---------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `id` | The constraints on the `id` property are listed in the [DID Core service specification](https://www.w3.org/TR/did-core/#services). The `id` property MUST be a DID URL uniquely identifying the revocation bitmap. |
+| `type` | The `type` property MUST be `"RevocationTimeframe2024"`. |
+| `serviceEndpoint` | The `serviceEndpoint` MUST be generated according to the service endpoint generation algorithm described in [`RevocationBitmap2022`](./revocation-bitmap-2022.mdx#service-endpoint-generation-algorithm). |
+
+#### Example
+
+An example of an issuers DID document where credential `"5"` in the `#revocation` service is revoked:
+
+```json
+{
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw",
+ "verificationMethod": [
+ {
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#key-1",
+ "controller": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw",
+ "type": "Ed25519VerificationKey2018",
+ "publicKeyMultibase": "z3hgM9fNkhwgT5mECbj1HdKoFNZgpffwQYEV8WBVHphXq"
+ }
+ ],
+ "capabilityInvocation": [
+ {
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#sign-0",
+ "controller": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw",
+ "type": "Ed25519VerificationKey2018",
+ "publicKeyMultibase": "z83F6zbD3KqaxvQhqo25LvSXzoDdpZmp3EpPVonSVACwZ"
+ }
+ ],
+ "service": [
+ {
+ "id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#revocation",
+ "type": "RevocationTimeframe2024",
+ "serviceEndpoint": "data:application/octet-stream;base64,ZUp5ek1tQmdZR1NBQUFFZ1ptVUFBQWZPQUlF"
+ }
+ ]
+}
+```
+
+## Algorithms
+
+For generation and expansion of the service endpoint see [`RevocationBitmap2022`](./revocation-bitmap-2022.mdx#algorithms).
+
+### Validation Algorithm
+
+The following steps MUST be followed when checking whether a verifiable credential is revoked:
+
+1. Let **credential** be a verifiable credential containing a `credentialStatus` whose `type` is `RevocationTimeframe2024`.
+2. Let **now** be the string serialization of the RFC3339 timestamp representing the current UTC time.
+3. Let **start validity timeframe** and **end validity timeframe** be the RFC3339 timestamps of the `startValidityTimeframe` and `endValidityTimeframe` (respectively) properties contained in the `credentialStatus` of the **credential**.
+4. Return `true` if `startValidityTimeframe <= now < endValidityTimeframe`, `false` otherwise.
+
+## Test Vectors
+See [`RevocationBitmap2022`](./revocation-bitmap-2022.mdx#test-vectors).
\ No newline at end of file
diff --git a/docs/content/sidebars/developer.js b/docs/content/sidebars/developer.js
index 32192dd666b..e8ac1eb1bb5 100644
--- a/docs/content/sidebars/developer.js
+++ b/docs/content/sidebars/developer.js
@@ -212,7 +212,7 @@ const developer = [
{
type: 'category',
label: 'NFT',
- items: ['developer/iota-101/nft/create-nft', 'developer/iota-101/nft/rent-nft'],
+ items: ['developer/iota-101/nft/create-nft', 'developer/iota-101/nft/rent-nft', 'developer/iota-101/nft/marketplace'],
},
{
type: 'category',
diff --git a/docs/content/sidebars/identity.js b/docs/content/sidebars/identity.js
new file mode 100644
index 00000000000..ceba6878c5e
--- /dev/null
+++ b/docs/content/sidebars/identity.js
@@ -0,0 +1,90 @@
+// Copyright (c) Mysten Labs, Inc.
+// Modifications Copyright (c) 2024 IOTA Stiftung
+// SPDX-License-Identifier: Apache-2.0
+const identity = [
+ 'iota-identity/index',
+ {
+ type: 'category',
+ label: 'Getting Started',
+ collapsed: false,
+ items: ['iota-identity/getting-started/rust'],
+ },
+ {
+ type: 'category',
+ label: 'Explanations',
+ items: [
+ 'iota-identity/explanations/decentralized-identifiers',
+ 'iota-identity/explanations/verifiable-credentials',
+ 'iota-identity/explanations/verifiable-presentations',
+ 'iota-identity/explanations/about-identity-objects',
+ ],
+ },
+ {
+ type: 'category',
+ label: 'How To',
+ items: [
+ {
+ type: 'category',
+ label: 'Decentralized Identifiers (DID)',
+ items: [
+ 'iota-identity/how-tos/decentralized-identifiers/create',
+ 'iota-identity/how-tos/decentralized-identifiers/update',
+ 'iota-identity/how-tos/decentralized-identifiers/resolve',
+ 'iota-identity/how-tos/decentralized-identifiers/delete',
+ ],
+ },
+ {
+ type: 'category',
+ label: 'Verifiable Credentials',
+ items: [
+ 'iota-identity/how-tos/verifiable-credentials/create',
+ 'iota-identity/how-tos/verifiable-credentials/revocation',
+ 'iota-identity/how-tos/verifiable-credentials/selective-disclosure',
+ 'iota-identity/how-tos/verifiable-credentials/zero-knowledge-selective-disclosure',
+ ],
+ },
+ {
+ type: 'category',
+ label: 'Verifiable Presentations',
+ items: ['iota-identity/how-tos/verifiable-presentations/create-and-validate'],
+ },
+ {
+ type: 'category',
+ label: 'Domain Linkage',
+ items: ['iota-identity/how-tos/domain-linkage/create-and-verify'],
+ },
+ 'iota-identity/how-tos/key-storage',
+ ],
+ },
+ {
+ type: 'category',
+ label: 'References',
+ collapsed: true,
+ items: [
+ {
+ type: 'category',
+ label: 'API',
+ items: [
+ {
+ type: 'link',
+ label: 'Rust',
+ href: 'https://docs.rs/identity_iota/latest/identity_iota/index.html',
+ },
+ ],
+ },
+ {
+ type: 'category',
+ label: 'Specifications',
+ items: [
+ 'references/iota-identity/overview',
+ 'references/iota-identity/iota-did-method-spec',
+ 'references/iota-identity/revocation-bitmap-2022',
+ 'references/iota-identity/revocation-timeframe-2024',
+ ],
+ },
+ ],
+ },
+ 'iota-identity/contribute',
+];
+
+module.exports = identity;
diff --git a/docs/content/sidebars/ts-sdk.js b/docs/content/sidebars/ts-sdk.js
index 3ce2111226e..6951b07e0f4 100644
--- a/docs/content/sidebars/ts-sdk.js
+++ b/docs/content/sidebars/ts-sdk.js
@@ -3,7 +3,7 @@
// SPDX-License-Identifier: Apache-2.0
import typedocSidebar from '../references/ts-sdk/api/typedoc-sidebar.cjs';
-const references = [
+const tsSDK = [
{
type: 'category',
label: 'Typescript SDK',
@@ -133,4 +133,4 @@ const references = [
},
];
-module.exports = references;
+module.exports = tsSDK;
diff --git a/docs/examples/move/nft_marketplace/README.md b/docs/examples/move/nft_marketplace/README.md
index 42cb414ab65..80b330362ff 100644
--- a/docs/examples/move/nft_marketplace/README.md
+++ b/docs/examples/move/nft_marketplace/README.md
@@ -1,4 +1,4 @@
-# Marketplace Guide
+# Marketplace Extension Usage
## Modules
diff --git a/docs/site/configs/preContent.tsx b/docs/site/configs/preContent.tsx
new file mode 100644
index 00000000000..a7f9798b920
--- /dev/null
+++ b/docs/site/configs/preContent.tsx
@@ -0,0 +1,9 @@
+// Copyright (c) 2024 IOTA Stiftung
+// SPDX-License-Identifier: Apache-2.0
+
+import React from 'react';
+import Admonition from '@theme/Admonition';
+
+export default {
+ '/iota-identity*': IOTA Identity for Rebased is currently in alpha and may still be subject to significant changes,
+};
diff --git a/docs/site/docusaurus.config.js b/docs/site/docusaurus.config.js
index 3edac2ca385..bdb717867cb 100644
--- a/docs/site/docusaurus.config.js
+++ b/docs/site/docusaurus.config.js
@@ -186,7 +186,8 @@ const config = {
type: "text/css",
},
],
- themes: ["@docusaurus/theme-live-codeblock", "@docusaurus/theme-mermaid", 'docusaurus-theme-search-typesense'],
+ themes: ["@docusaurus/theme-live-codeblock", "@docusaurus/theme-mermaid", 'docusaurus-theme-search-typesense',
+ '@saucelabs/theme-github-codeblock'],
themeConfig:
/** @type {import('@docusaurus/preset-classic').ThemeConfig} */
({
@@ -241,10 +242,6 @@ const config = {
label: "Developers",
to: "developer",
},
- {
- label: "TS SDK",
- to: "references/ts-sdk/typescript/",
- },
{
label: "Node Operators",
to: "operator",
@@ -253,6 +250,14 @@ const config = {
label: "References",
to: "references",
},
+ {
+ label: "TS SDK",
+ to: "references/ts-sdk/typescript/",
+ },
+ {
+ label: "IOTA Identity",
+ to: "iota-identity",
+ },
],
},
footer: {
diff --git a/docs/site/package.json b/docs/site/package.json
index 28d0b5926e7..5f0f7503310 100644
--- a/docs/site/package.json
+++ b/docs/site/package.json
@@ -36,6 +36,7 @@
"@iota/iota-sdk": "workspace:*",
"@mdx-js/react": "^3.0.1",
"@mui/material": "^5.15.19",
+ "@saucelabs/theme-github-codeblock": "^0.3.0",
"@tanstack/react-query": "^5.50.1",
"autoprefixer": "^10.4.19",
"axios": "^1.7.4",
diff --git a/docs/site/sidebars.js b/docs/site/sidebars.js
index 0207505a354..88001f36f83 100644
--- a/docs/site/sidebars.js
+++ b/docs/site/sidebars.js
@@ -8,6 +8,7 @@ const aboutIota = require("../content/sidebars/about-iota.js");
const operator = require("../content/sidebars/operator.js");
const references = require("../content/sidebars/references.js");
const tsSDK = require("../content/sidebars/ts-sdk.js")
+const identity = require("../content/sidebars/identity.js")
const sidebars = {
//whyIOTASidebar: why_iota,
@@ -16,6 +17,7 @@ const sidebars = {
aboutIotaSidebar: aboutIota,
referencesSidebar: references,
tsSDK: tsSDK,
+ identity: identity,
};
module.exports = sidebars;
diff --git a/docs/site/src/theme/DocItem/index.tsx b/docs/site/src/theme/DocItem/index.tsx
new file mode 100644
index 00000000000..03b5768679f
--- /dev/null
+++ b/docs/site/src/theme/DocItem/index.tsx
@@ -0,0 +1,26 @@
+/**
+ * SWIZZLED VERSION: 3.5.2
+ * REASONS:
+ * - Add option to allow custom components before the DocItem
+ */
+import React from 'react';
+import DocItem from '@theme-original/DocItem';
+import type DocItemType from '@theme/DocItem';
+import type {WrapperProps} from '@docusaurus/types';
+import { useLocation } from '@docusaurus/router';
+
+import preMDXComponents from '../../../configs/preContent';
+
+type Props = WrapperProps;
+
+export default function DocItemWrapper(props: Props): JSX.Element {
+ const { pathname } = useLocation();
+ const matchingKey = Object.keys(preMDXComponents).find((key) => new RegExp(key).test(pathname));
+
+ return (
+ <>
+ {preMDXComponents[matchingKey]}
+
+ >
+ );
+}
diff --git a/docs/site/src/theme/MDXContent/index.tsx b/docs/site/src/theme/MDXContent/index.tsx
index f2d505c0bb0..a94a55e771d 100644
--- a/docs/site/src/theme/MDXContent/index.tsx
+++ b/docs/site/src/theme/MDXContent/index.tsx
@@ -2,6 +2,7 @@
* SWIZZLED VERSION: 3.5.2
* REASONS:
* - Add default components
+ * - Add FeedbackForm component
*/
import React from 'react';
import { MDXProvider } from '@mdx-js/react';
diff --git a/iota-execution/latest/iota-adapter/src/programmable_transactions/context.rs b/iota-execution/latest/iota-adapter/src/programmable_transactions/context.rs
index d8d20638fc6..cfe7ff20ee5 100644
--- a/iota-execution/latest/iota-adapter/src/programmable_transactions/context.rs
+++ b/iota-execution/latest/iota-adapter/src/programmable_transactions/context.rs
@@ -1019,7 +1019,7 @@ mod checked {
}
}
- impl<'vm, 'state, 'a> TypeTagResolver for ExecutionContext<'vm, 'state, 'a> {
+ impl TypeTagResolver for ExecutionContext<'_, '_, '_> {
/// Retrieves the `TypeTag` corresponding to the provided `Type` by
/// querying the Move VM runtime.
fn get_type_tag(&self, type_: &Type) -> Result {
@@ -1464,7 +1464,7 @@ mod checked {
// TODO: `DataStore` will be reworked and this is likely to disappear.
// Leaving this comment around until then as testament to better days to
// come...
- impl<'state, 'a> DataStore for IotaDataStore<'state, 'a> {
+ impl DataStore for IotaDataStore<'_, '_> {
fn link_context(&self) -> AccountAddress {
self.linkage_view.link_context()
}
diff --git a/iota-execution/latest/iota-adapter/src/programmable_transactions/execution.rs b/iota-execution/latest/iota-adapter/src/programmable_transactions/execution.rs
index cc70099dc59..b382a447ffc 100644
--- a/iota-execution/latest/iota-adapter/src/programmable_transactions/execution.rs
+++ b/iota-execution/latest/iota-adapter/src/programmable_transactions/execution.rs
@@ -1659,7 +1659,7 @@ mod checked {
struct VectorElementVisitor<'a>(&'a PrimitiveArgumentLayout);
- impl<'d, 'a> serde::de::Visitor<'d> for VectorElementVisitor<'a> {
+ impl<'d> serde::de::Visitor<'d> for VectorElementVisitor<'_> {
type Value = ();
fn expecting(&self, formatter: &mut fmt::Formatter<'_>) -> fmt::Result {
@@ -1677,7 +1677,7 @@ mod checked {
struct OptionElementVisitor<'a>(&'a PrimitiveArgumentLayout);
- impl<'d, 'a> serde::de::Visitor<'d> for OptionElementVisitor<'a> {
+ impl<'d> serde::de::Visitor<'d> for OptionElementVisitor<'_> {
type Value = ();
fn expecting(&self, formatter: &mut fmt::Formatter<'_>) -> fmt::Result {
diff --git a/iota-execution/latest/iota-adapter/src/programmable_transactions/linkage_view.rs b/iota-execution/latest/iota-adapter/src/programmable_transactions/linkage_view.rs
index 40a0270c3fe..b3bdf7948a8 100644
--- a/iota-execution/latest/iota-adapter/src/programmable_transactions/linkage_view.rs
+++ b/iota-execution/latest/iota-adapter/src/programmable_transactions/linkage_view.rs
@@ -303,7 +303,7 @@ impl From<&MovePackage> for LinkageInfo {
}
}
-impl<'state> LinkageResolver for LinkageView<'state> {
+impl LinkageResolver for LinkageView<'_> {
type Error = IotaError;
fn link_context(&self) -> AccountAddress {
@@ -325,7 +325,7 @@ impl<'state> LinkageResolver for LinkageView<'state> {
/// Remaining implementations delegated to state_view ************************
-impl<'state> ResourceResolver for LinkageView<'state> {
+impl ResourceResolver for LinkageView<'_> {
type Error = IotaError;
fn get_resource(
@@ -337,7 +337,7 @@ impl<'state> ResourceResolver for LinkageView<'state> {
}
}
-impl<'state> ModuleResolver for LinkageView<'state> {
+impl ModuleResolver for LinkageView<'_> {
type Error = IotaError;
fn get_module(&self, id: &ModuleId) -> Result