-
Notifications
You must be signed in to change notification settings - Fork 53
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
11 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,6 @@ | ||
--- | ||
tip: ? | ||
title: IOTA DID Method Specification | ||
title: IOTA DID Method Specification v2.0 | ||
description: Specifies how DID are stored in the IOTA ledger | ||
author: | ||
Eike Haß (@eike-hass) <[email protected]>, Abdulrahim Al Methiab (@abdulmth) <[email protected]>, Enrico Marconi (@UMR1352) <[email protected]> | ||
|
@@ -227,7 +227,7 @@ Temporarily deactivating a DID can be done by deleting the `Metadata Entry` corr | |
|
||
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. | ||
|
||
Note: since retrieving the history of an Account is unpractical, any Account Output lacking a `Metadata Entry` with a `did:iota` Key is considered a deactivated DID. The same applies for Account Outputs lacking the Metadata Feature. | ||
Since retrieving the history of an Account to detect if an Account ever was a DID is unpractical, any Account Output lacking a `Metadata Entry` with a `did:iota` Key is considered a deactivated DID. The same applies for Account Outputs lacking the Metadata Feature. | ||
|
||
#### Destroy | ||
|
||
|
@@ -241,7 +241,15 @@ The `did:iota` method is implemented in the [IOTA Identity framework](https://gi | |
|
||
### Revocation | ||
|
||
todo: irrelevant for iota 2.0 | ||
Revocation of verifiable credentials and signatures can be achieved using the Revocation Bitmap 2022 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 | ||
|
||
## Migration | ||
|
||
|