Crate did

DID Pallet

Provides W3C-compliant DID functionalities. A DID identifier is derived from a KILT address and must be verifiable, i.e., must be able to generate digital signatures that can be verified starting from a raw payload, its signature, and the signer identifier. Currently, the DID pallet supports the following types of keys: Ed25519, Sr25519, and Ecdsa for signing keys, and X25519 for encryption keys.

• Config
• Call
• Origin
• Pallet

Terminology

Each DID identifier is mapped to a set of keys, which in KILT are used for different purposes.

• One authentication key: used to sign and authorise DID-management operations (e.g., the update of some keys or the deletion of the whole DID). This is required to always be present as otherwise the DID becomes unusable since no operation signature can be verified anymore.

• Zero or more key agreement keys: used by other parties that want to interact with the DID subject to perform ECDH and encrypt information addressed to the DID subject.

• Zero or one delegation key: used to sign and authorise the creation of new delegation nodes on the KILT blockchain. In case no delegation key is present, the DID subject cannot write new delegations on the KILT blockchain. For more info, check the delegation pallet.

• Zero or one attestation key: used to sign and authorise the creation of new attested claims on the KILT blockchain. In case no attestation key is present, the DID subject cannot write new attested claims on the KILT blockchain. For more info, check the attestation pallet.

• A set of public keys: includes at least the previous keys in addition to any past attestation key that has been rotated but not entirely revoked.

• A set of service endpoints: pointing to the description of the services the DID subject exposes. For more information, check the W3C DID Core specification.

• A transaction counter: acts as a nonce to avoid replay or signature forgery attacks. Each time a DID-signed transaction is executed, the counter is incremented.

Assumptions

• The maximum number of new key agreement keys that can be specified in a creation or update operation is bounded by MaxNewKeyAgreementKeys.
• After it is generated and signed by a client, a DID-authorised operation can be submitted for evaluation anytime between the time the operation is created and Config::MaxBlocksTxValidity blocks after that. After this time has elapsed, the operation is considered invalid.

Re-exports

• pub use crate::default_weights::WeightInfo;
• pub use crate::did_details::DeriveDidCallAuthorizationVerificationKeyRelationship;
• pub use crate::did_details::DeriveDidCallKeyRelationshipResult;
• pub use crate::did_details::DidAuthorizedCallOperationWithVerificationRelationship;
• pub use crate::did_details::DidSignature;
• pub use crate::did_details::DidVerificationKeyRelationship;
• pub use crate::did_details::RelationshipDeriveError;
• pub use crate::origin::DidRawOrigin;
• pub use crate::origin::EnsureDidOrigin;
• pub use crate::pallet::*;

Modules

• benchmarking
• default_weights
  Autogenerated weights for did
• did_details
• errors
• migrations
• mock_utils
• origin
• pallet
  The pallet module in each FRAME pallet hosts the most important items needed to construct this pallet.
• service_endpoints

Structs

• DidSignatureVerify