Coder Social home page Coder Social logo

iotaledger / identity.rs Goto Github PK

View Code? Open in Web Editor NEW
298.0 28.0 83.0 17.07 MB

Implementation of the Decentralized Identity standards such as DID and Verifiable Credentials by W3C for the IOTA Tangle.

Home Page: https://www.iota.org

License: Apache License 2.0

Rust 87.58% JavaScript 0.78% TypeScript 11.59% Dockerfile 0.04% Shell 0.02%
self-sovereign-identity did verifiable-credentials decentralized-identity

identity.rs's Introduction

banner

StackExchange Discord Discord Apache 2.0 license Dependencies Coverage Status

IntroductionBindingsDocumentation & ResourcesGetting StartedExampleRoadmapContributing


Introduction

IOTA Identity is a Rust implementation of decentralized digital identity, also known as Self-Sovereign Identity (SSI). It implements the W3C Decentralized Identifiers (DID) and Verifiable Credentials specifications. This library can be used to create, resolve and authenticate digital identities and to create verifiable credentials and presentations in order to share information in a verifiable manner and establish trust in the digital world. It does so while supporting secure storage of cryptographic keys, which can be implemented for your preferred key management system. Many of the individual libraries (Rust crates) are agnostic over the concrete DID method, with the exception of some libraries dedicated to implement the IOTA DID method, which is an implementation of decentralized digital identity on the IOTA and Shimmer networks. Written in stable Rust, IOTA Identity has strong guarantees of memory safety and process integrity while maintaining exceptional performance.

Bindings

Foreign Function Interface (FFI) Bindings of this Rust library to other programming languages:

gRPC

We provide a collection of experimental gRPC services

Documentation and Resources

Prerequisites

Getting Started

If you want to include IOTA Identity in your project, simply add it as a dependency in your Cargo.toml:

[dependencies]
identity_iota = { version = "1.3.1" }

To try out the examples, you can also do this:

  1. Clone the repository, e.g. through git clone https://github.com/iotaledger/identity.rs
  2. Start IOTA Sandbox as described in the next section
  3. Run the example to create a DID using cargo run --release --example 0_create_did

Example: Creating an Identity

The following code creates and publishes a new IOTA DID Document to a locally running private network. See the instructions on running your own private network for development.

Cargo.toml

[package]
name = "iota_identity_example"
version = "1.0.0"
edition = "2021"

[dependencies]
identity_iota = { version = "1.3.1", features = ["memstore"] }
iota-sdk = { version = "1.0.2", default-features = true, features = ["tls", "client", "stronghold"] }
tokio = { version = "1", features = ["full"] }
anyhow = "1.0.62"
rand = "0.8.5"

main.rs

use identity_iota::core::ToJson;
use identity_iota::iota::IotaClientExt;
use identity_iota::iota::IotaDocument;
use identity_iota::iota::IotaIdentityClientExt;
use identity_iota::iota::NetworkName;
use identity_iota::storage::JwkDocumentExt;
use identity_iota::storage::JwkMemStore;
use identity_iota::storage::KeyIdMemstore;
use identity_iota::storage::Storage;
use identity_iota::verification::jws::JwsAlgorithm;
use identity_iota::verification::MethodScope;
use iota_sdk::client::api::GetAddressesOptions;
use iota_sdk::client::secret::stronghold::StrongholdSecretManager;
use iota_sdk::client::secret::SecretManager;
use iota_sdk::client::Client;
use iota_sdk::crypto::keys::bip39;
use iota_sdk::types::block::address::Bech32Address;
use iota_sdk::types::block::output::AliasOutput;
use iota_sdk::types::block::output::dto::AliasOutputDto;
use tokio::io::AsyncReadExt;

// The endpoint of the IOTA node to use.
static API_ENDPOINT: &str = "http://localhost";

/// Demonstrates how to create a DID Document and publish it in a new Alias Output.
#[tokio::main]
async fn main() -> anyhow::Result<()> {
  // Create a new client to interact with the IOTA ledger.
  let client: Client = Client::builder()
    .with_primary_node(API_ENDPOINT, None)?
    .finish()
    .await?;

  // Create a new Stronghold.
  let stronghold = StrongholdSecretManager::builder()
    .password("secure_password".to_owned())
    .build("./example-strong.hodl")?;

  // Generate a mnemonic and store it in the Stronghold.
  let random: [u8; 32] = rand::random();
  let mnemonic =
    bip39::wordlist::encode(random.as_ref(), &bip39::wordlist::ENGLISH).map_err(|err| anyhow::anyhow!("{err:?}"))?;
  stronghold.store_mnemonic(mnemonic).await?;

  // Create a new secret manager backed by the Stronghold.
  let secret_manager: SecretManager = SecretManager::Stronghold(stronghold);

  // Get the Bech32 human-readable part (HRP) of the network.
  let network_name: NetworkName = client.network_name().await?;

  // Get an address from the secret manager.
  let address: Bech32Address = secret_manager
  .generate_ed25519_addresses(
    GetAddressesOptions::default()
      .with_range(0..1)
      .with_bech32_hrp((&network_name).try_into()?),
  )
  .await?[0];

  println!("Your wallet address is: {}", address);
  println!("Please request funds from http://localhost/faucet/, wait for a couple of seconds and then press Enter.");
  tokio::io::stdin().read_u8().await?;

  // Create a new DID document with a placeholder DID.
  // The DID will be derived from the Alias Id of the Alias Output after publishing.
  let mut document: IotaDocument = IotaDocument::new(&network_name);

  // Insert a new Ed25519 verification method in the DID document.
  let storage: Storage<JwkMemStore, KeyIdMemstore> = Storage::new(JwkMemStore::new(), KeyIdMemstore::new());
  document
    .generate_method(
      &storage,
      JwkMemStore::ED25519_KEY_TYPE,
      JwsAlgorithm::EdDSA,
      None,
      MethodScope::VerificationMethod,
    )
    .await?;

  // Construct an Alias Output containing the DID document, with the wallet address
  // set as both the state controller and governor.
  let alias_output: AliasOutput = client.new_did_output(address.into(), document, None).await?;
  println!("Alias Output: {}", AliasOutputDto::from(&alias_output).to_json_pretty()?);

  // Publish the Alias Output and get the published DID document.
  let document: IotaDocument = client.publish_did_output(&secret_manager, alias_output).await?;
  println!("Published DID document: {:#}", document);

  Ok(())
}

Example output

{
  "doc": {
    "id": "did:iota:tst:0xa947df036e78c2eada8b16e019d517c9e38d4b19cb0c1fa066e752c3074b715d",
    "verificationMethod": [
      {
        "id": "did:iota:tst:0xa947df036e78c2eada8b16e019d517c9e38d4b19cb0c1fa066e752c3074b715d#9KdQCWcvR8kmGPLFOYnTzypsDWsoUIvR",
        "controller": "did:iota:tst:0xa947df036e78c2eada8b16e019d517c9e38d4b19cb0c1fa066e752c3074b715d",
        "type": "JsonWebKey",
        "publicKeyJwk": {
          "kty": "OKP",
          "alg": "EdDSA",
          "kid": "9KdQCWcvR8kmGPLFOYnTzypsDWsoUIvR",
          "crv": "Ed25519",
          "x": "JJoYoeFWU7jWvdQmOKDvM4nZJ2cUbP9yhWZzFgd044I"
        }
      }
    ]
  },
  "meta": {
    "created": "2023-08-29T14:47:26Z",
    "updated": "2023-08-29T14:47:26Z",
    "governorAddress": "tst1qqd7kyu8xadzx9vutznu72336npqpj92jtp27uyu2tj2sa5hx6n3k0vrzwv",
    "stateControllerAddress": "tst1qqd7kyu8xadzx9vutznu72336npqpj92jtp27uyu2tj2sa5hx6n3k0vrzwv"
  }
}

Roadmap and Milestones

For detailed development progress, see the IOTA Identity development kanban board.

Contributing

We would love to have you help us with the development of IOTA Identity. Each and every contribution is greatly valued!

Please review the contribution and workflow sections in the IOTA Wiki.

To contribute directly to the repository, simply fork the project, push your changes to your fork and create a pull request to get them included!

The best place to get involved in discussions about this library or to look for support at is the #identity channel on the IOTA Discord. You can also ask questions on our Stack Exchange.

identity.rs's People

Contributors

7opf avatar abdulmth avatar aconitin avatar charlesthompson3 avatar cycraig avatar dependabot[bot] avatar depplearning avatar dr-electron avatar egarciar avatar eike-hass avatar github-actions[bot] avatar henriquenogara avatar huhn511 avatar itsyaasir avatar l1h3r avatar l4rot avatar lucagiorgino avatar lucas-tortora avatar m-renaud avatar marcianos avatar nanderstabel avatar nothingismagick avatar omskremer avatar philippgackstatter avatar phyloiota avatar rajivshah3 avatar tensor-programming avatar thoralf-m avatar umr1352 avatar wulfraem avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

identity.rs's Issues

Optimize Tangle Document Size

Investigate storing the minimal amount of data needed to reconstruct a full DID Document on the Tangle. We currently store DID Documents as JSON objects and don't perform any optimizations.

  • Use a more space-efficient format
  • Remove constant values (eg. did:iota: for DIDs)

Add Public Credential support

Add support and standardize a service endpoint that links to a publicly available Verifiable Credential (VC), published to an IOTA address. This address can be resolved to retrieve a VC and can be verified. The public VC should also have its own type made available within the DID Document as filtering and searching for public credentials within a DID Document should be done with as few queries as possible.

This feature is targeted at Identity for Organization, Things, and Objects. It should not be utilized with any data that can be considered Personal Identifiable according to the General Data Protection Regulation (GDPR) and other privacy laws worldwide. As such, this feature should not be used with DID Documents representing people. It is ideally used for Organizational credentials such as certifications or used for Identity of Things for similar certifications, specifications, or proof of origin.

  • Determine specs of the feature
  • Implement Service Endpoint
  • Standardize Service Endpoint
  • Document very explicity the dangers of using this with Identity for People (GDPR compliance)
  • Add WASM bindings
  • Add examples

Internal design document: https://docs.google.com/document/d/1VE0jtPsd_9Ewtfj53pdHPJXzwS3lmR0yd4Uk0dpNjzM/edit

Add crate descriptions

Add crate descriptions for all cargo crates inside their respective lib.rs folders. The description should be self-sufficient, provide a relevant example, and link to relevant resources.

Crates:

  • Identity - #891
  • Identity Core - #883
  • Identity Credential - #873
  • Identity DID - #892
  • identity-diff - #894
  • identity-diff-derive - #894
  • identity-iota - #889
  • Identity-iota-core - #888
  • Identity Account - #887
  • Identity-account-storage - #890

[Task] Don't run build-and-test Action on documentation PRs

Description

Describe the task, this may be scoped beyond a single PR.

Change the Github action for "build-and-test" to ignore PRs that contain only documentation changes. It was already done via a paths-ignore: - 'docs/**' but this may either be extended by adding preferably **.md to paths-ignore or otherwise adding a branches-ignore: docs/**. The latter is more developer error-prone, so the former is the preferred solution. We might want to check that the former solution actually doesn't ignore larger PRs that have both code changes and .md changes.

Motivation

Describe the motivation for the feature to be developed.

Unnessacary Github actions execution costs resources, time and this solution would be a temporary workaround for #183

Resources

Link to any resources relevant for the task such as Issues, PRs, reference implementations, or specifications.

To-do list

Create a task-specific to-do list . Please link PRs that match the To-do list item behind the item after it has been submitted.

  • Update CI
  • Test that it doesn't execute build-and-run with only .md changes
  • Test that it does execute build-and-run with .md changes AND other code changes

Add functionality to insert/remove services

Description

It is currently not possible to add/remove services from a DID Document without using unsafe.

Motivation

Services are not constrained by the method spec; adding/removing is not an unsafe operation

Requirements

  • Add the following API to identity::iota::Document:
    • Service ids must have a fragment
    • Services must be unique (should be handled by OrderedSet)
pub fn insert_service(&mut self, service: Service) -> bool;
pub fn remove_service(&mut self, did: &DID) -> Result<()>;
  • Add to bindings/wasm

Are you planning to do it yourself in a pull request?

No

Fix MessageIndex determinism

Description

values stored in MessageIndex should be ordered by message_id, currently they are not

Motivation

required for resolution

To-do list

  • Ensure values added to MessageIndex are sorted by T::message_id
    • Replace scope.insert with equivalent binary search

Change checklist

  • The feature or fix is implemented in Rust and across all bindings whereas possible.
  • The feature or fix has sufficient testing coverage
  • All tests and examples build and run locally as expected
  • Every piece of code has been document according to the documentation guidelines.
  • If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
  • If the feature is not currently documented, a documentation task Issue has been opened to address this.

[Task] Add Benchmarking Tests

Description

Describe the task, this may be scoped beyond a single PR.

Add a set of benchmarking scenarios where we test the speed of key operations in high-scale and with high-frequency. This should be an easily executable set of scenarios that provide a rapport of the timings. It should enable a similar discussion thread like Stronghold.

Motivation

Describe the motivation for the feature to be developed.

Many DID implementations struggle with scaling and performance due to both the used Blockchain technology and the implementation of the standard. With our usage of the Tangle and Rust, we should be benchmarking really well. Let's actually prove that!

Resources

Link to any resources relevant for the task such as Issues, PRs, reference implementations, or specifications.

To-do list

Create a task-specific to-do list . Please link PRs that match the To-do list item behind the item after it has been submitted.

  • Define benchmarking scenario's and strategy
  • Adds to-dos for the benchmarking tests in this issue.

RUSTSEC-2020-0036: failure is officially deprecated/unmaintained

failure is officially deprecated/unmaintained

Details
Status unmaintained
Package failure
Version 0.1.8
URL rust-lang-deprecated/failure#347
Date 2020-05-02

The failure crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.

The following are some suggested actively developed alternatives to switch to:

See advisory page for additional details.

Add better WASM errors

Description

Add better error messages to the wasm bindings - the current implementation doesn't provide a stack trace.

Currently most functions return Result<T, JsValue> and this gives an error message but the context is lost. The Error type from the js-sys crate should be used instead: Result<T, js_sys::Error>

Resources

  • js-sys
    • Should already be a version include by wasm-bindgen (check Cargo.lock) but will need to be included to access the API.

To-do list

  • Replace Result<T, JsValue> functions with Result<T, js_sys::Error> wherever appropriate

Change checklist

  • The feature or fix is implemented in Rust and across all bindings whereas possible.
  • The feature or fix has sufficient testing coverage
  • All tests and examples build and run locally as expected
  • Every piece of code has been document according to the documentation guidelines.
  • If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
  • If the feature is not currently documented, a documentation task Issue has been opened to address this.

[Request] Generate absolute URI for `verificationMethod`

Description

when generating a VC the proof.verificationMethod just has the fragment identifier i.e. #key but not the full DID URI pointing to the method, not sure if it should contain the full URI or what the standard says at that respect

Motivation

Alignment with W3C standard

Requirements

Write a list of what you want this feature to do.

  1. Required for proofs

Open questions (optional)

Are you planning to do it yourself in a pull request?

No

[Request]: DID Comms Message DID Authorization (AuthZ)


Authorization

Giving consent or permission.

The Authorization flow consists of a simple request-response message exchange, where the Initiator requests authorization from the authorizer to carry out some action. It is similar to the authentication flow in structure, however the intent of the interaction is different. Authentication is about proving the identity of an agent (e.g. SSO), while authorization is about giving permission or privilege for a service to act on an agents behalf.

Roles

  • Authorized: Agent requesting authorization to perform some action
  • Authorizer: Agent granting authorization to the authorized

Messages

Authorization Request

The authorized broadcasts a message representing the intent of the action which permission is required for.

Layout
authorizationRequest: {
    "callbackURL": "<URL as String>",
    "description": "<Text as String>",
    "imageURL": "<Image URL as String>",
    "action": "<Text as String>",
}

Authorization Response

The authorizer responds with a message containing the same contents as the authorizationRequest as consent.
TODO: respond with a VC, think about including frost into the vc for the action field, remove for now and submit an issue

Layout
authorizationResponse: {
    "callbackURL": "<URL as String>",
    "description": "<Text as String>",
    "imageURL": "<Image URL as String>",
    "action": "<Text as String>",
}

Examples

The authorized would like to open the authorizers door and sends an authorizationRequest for said action to the authorizer:

{
    "callbackURL": "https://example.com/authz",
    "description": "Front Door",
    "imageURL": "https://example.com/lockImage.png",
    "action": "Open the door",
}

The authorizer reponds with the same content, consenting to the action:

{
    "callbackURL": "https://example.com/authz",
    "description": "Front Door",
    "imageURL": "https://example.com/lockImage.png",
    "action": "Open the door",
}

Replace `immutable` property with DID URL query param

The immutable property currently determines whether we fetch updates from the diff-chain of a particular auth-chain record. This property should be removed from the DID Document type as the same optimization can be accomplished with query params, eg. did:iota:1234?diff=false.

  • Remove immutable property from Document type
  • Add support for diff=true|false DID query param in Client::read_document_chain

[Task] Implement JSON-LD output format for DID Documents

Description

Implement JSON-LD output format for DID Documents. Previous iteration of this Issue held more DID Core updates, but they have either been tackled or have their own issues right now.

Resources

To-do list

Create a task-specific to-do list . Please link PRs that match the To-do list item behind the item after it has been submitted.

  • Allow output of JSON-LD (Aka, just add the default context)

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

  • The feature or fix is implemented in Rust and across all bindings whereas possible.
  • The feature or fix has sufficient testing coverage
  • All tests and examples build and run locally as expected
  • Every piece of code has been document according to the documentation guidelines.
  • If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
  • If the feature is not currently documented, a documentation task Issue has been opened to address this.

Add bindings to readme

The readme.md file should show the existence of the WASM bindings and link to the ressources.

[Task] Open Discussion Points for DID Comms Specification v0.3

This issue is a list of open discussion points for v0.3:

  • In report/report: Define an actual error communication / information field that is parseable and includes error codes. See #209
  • In revocation: How do we deal with unauthorized revocations, i.e. invalid ones?
  • Discuss field id optionality over whole specification.
  • Create sequence diagrams / state machines for every interaction.
  • Discuss constraints to fields such that large message or spam attacks aren't a thing.
  • Work on supported signatures (signature types) and signature suites and communication about those ("... and I offer these types of signatures and signature suites ...").
  • Discuss who signs what, how exactly and why.
  • Discuss list of VC requirements
  • Discuss credential schemata for credentialSchemaResponse
  • Discuss how to deal with lists
  • Discover Features: Do we want versioning with regex?
  • Do we have / need a way to ask others to start an interaction? Relevant for request
  • DID Introduction: n parties or just 2?
  • Shall we split up all interactions to seperate files for better overview?
  • Formatting for all split interactions

Combine Credential and VerifiableCredential types

Description

Combine the Credential and VerifiableCredential types. We only need to have VerifiableCredential.

The same should be done for presentations

Motivation

The current approach is tedious to work with and doesn't provide any security benefits.

You currently have to wrap a Credential with a VerifiableCredential to make it signable...

let mut target = VerifiableCredential::new(credential, Vec::new());
document.sign_data(&mut credential, secret)?;

...instead, you should be able to sign a Credential directly:

document.sign_data(&mut credential, secret)?;

To-do list

  • Merge VerifiableCredential -> Credential

    • proof/proof_mut methods
    • identity_core::crypto trait implementations
    • Change proof type: OneOrMany<Signature> -> Option<Signature>
  • Merge VerifiablePresentation -> Presentation

    • proof/proof_mut methods
    • identity_core::crypto trait implementations
    • Change proof type: OneOrMany<Signature> -> Option<Signature>

Change checklist

  • The feature or fix is implemented in Rust and across all bindings whereas possible.
  • The feature or fix has sufficient testing coverage
  • All tests and examples build and run locally as expected
  • Every piece of code has been document according to the documentation guidelines.
  • If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
  • If the feature is not currently documented, a documentation task Issue has been opened to address this.

Wrong formet in the ID Attribute of the PublicKey

Issue description

We try to add an public key to an existing DID Document.
After that, we have in the public_key attribute the DID as object in the id attribute.

Is this the expected behavior? Or should is just be an string?

Our Code:

        // Create example did document
        let mut did_doc = DIDDocument {
            context: Context::from("https://w3id.org/did/v1"),
            id: Subject::from("did:iota:123456789abcdefghi"),
            ..Default::default()
        }
        .init();

        // Create example public key
        let key_data = KeyData::Base58("H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV".into());
        let public_key_object = PublicKey {
            id: "did:iota:123456789abcdefghi#keys-1".into(),
            key_type: "RsaVerificationKey2018".into(),
            controller: "did:iota:123456789abcdefghi".into(),
            key_data,
            ..Default::default()
        }
        .init();
        // Add public key to did_doc
        did_doc.update_public_key(public_key_object.clone());
        println!("{:?}", did_doc);

The result:

...
 public_key: [PublicKey {
                    id: Subject(DID {
                        method_name: "iota",
                        id_segments: ["123456789abcdefghi"],
                        params: None,
                        path_segments: None,
                        query: None,
                        fragment: Some("keys-1")
                    }),
...

It should look like:

...
 public_key: [PublicKey {
                    id: "did:iota:123456789abcdefghi#keys-1"),
...

Add conceptual documentation

Add conceptual documentation for the DID, VC, and IOTA Identity topics on the documentation website. This should include in-depth descriptions of IOTA Identity's unique features.

  • DID and IOTA Method spec
  • Verifiable Credentials
  • DID Communications
  • Account Module / Actor
  • Detailed roadmap
  • Future plans: Beyond the framework
  • Glossary
  • Contribute

Account API

Add an API for managing Identity-related data

TODO

  • Add an optional background-sync process
  • Add automatic auth-chain publishing
    • Ability to change publish threshold
    • Ability to publish with/without key change

Communications Specification

Research and design the message exchanges between different IOTA Identity powered actors. Write out a specification for all different exchanges between actors such as DID Authentication, Verifiable Presentation, request for Verifiable Credentials etc...
The specification is a pre-requisite for the implementation of an actor who eventually will be able to handle all of the flows.

Prior Art:

[Request]: DID Comms Credentials/Presentations

PR #186 adds three interactions for Verifiable Credential issuance.


The Verifiable Credential (VC) issuance flow consists of a three step interaction process between two parties, the issuer and the holder. The Credential Revocation interaction notifies a holder that a previously issued credential has been revoked. The Presentation Verification interaction verifies a presentation.
Discussion Wednesday afternoon.


Open discussion points, among others:

  • How exactly do we define the credentialSchemas?
  • How exactly will these schemas be structured and communicated?
  • Do we offer single issuance or do we use lists everywhere?
  • Probably some more stuff we need to talk about

[Enchancement] Add Test coverage

Description

Adding source-based code coverage

Motivation

There should be better testing.

Resources

crypto.rs (we should copy this - in-house tool)

To-do list

Create a task-specific to-do list . Please link PRs that match the To-do list item behind the item after it has been submitted.

  • Add Coverage Badge
  • Add Github workflow for testing
  • Make project wide testing guidelines

Add Domain Name Verification Service

Implement and standardize a service endpoint called DomainNameVerification. It links to a domain that is owned by the identity, such as the website of the organization. This domain can be queried, which should resolve in a standardized JSON response that lists the DID(s) used to represent the domain owner. If the DID that lists the service is also listed in the returning query, we have proof that the DID is in control over the domain. This URL may be displayed to a Verifier to add additional trust to an identity.

Resources:

TODO: Find other resources of other projects

  • Write a specification for the DomainNameVerification service endpoint
  • Implement service
  • Create a test / example

Handle "main" network as default more consistently

A DID Document that is created without a network defaults to the mainnet called "main". The main part is left out of the id and keys. Such that they are did:iota:uuid instead of did:iota:main:uuid. However, if I input "main" into the generate key function, it does add main into the did's such that they render did:iota:main:uuid. Even though they work the same, this creates an inconsistent DID Document. I suggest we handle main as a default input better such that no input or "main" as network input is handled the same.

Move Cryptographic logic to Crypto.rs

Migrate all Cryptographic primitives and complex primitive uses to the Crypto.rs repository.

  • Add HMAC-SHA384 to Crypto.rs PR
  • Add SHA384 to Crypto.rs PR
  • Add AES-128-GCM and AES-192-GCM to Crypto.rs PR Issue
  • Add ChaCha20Poly1305 PR
  • Add AES Key Wrap to Crypto.rs PR
  • Add AES-CBC to Crypto.rs PR Issue
  • Add pbkdf hmac sha256/sha384 to Crypto.rs PR
  • Update Identity.rs to use Crypto.rs

DID Method Specification

Write a DID Method Specification for the iota method. The document should conform to the requirements from W3C for the submission of a DID Method specification. In addition, set up a folder structure for future extending features outside of the DID scope: support for non-standard public keys such as Merkle Key Collection and non-standard service endpoints that we standardize for the IOTA Identity framework. Must follow the guidelines from W3C.

  • Abstract
  • DID Method Name
  • DID Format
  • DID Messages
  • CRUD Operations
  • List of additional standards
  • Privacy and Security Considerations
  • Submitted to W3C
  • Accepted by W3C

Stronghold Wrapper

Add a higher-level API for Stronghold that handles actor management and provides conveniences for commonly used patterns

  • Based on tauri-plugin
  • Based on wallet.rs
  • Add high-level Stronghold wrapper (see tauri-plugin)
  • Add Store-like API for indexed records (see wallet.rs)

Ideally we would be able to share this with wallet.rs and possibly tauri-plugin-stronghold

[Bug] Github Action fails unexpectedly on build-and-test (macOS-latest)

Bug description

Github action "build-and-test macOS-latest" fails unexpectedly, while windows and ubuntu succeed. The provided error below was during a readme change and can therefore not be related to code changes.

error[E0463]: can't find crate for serde_derive which serde_json depends on

Link to an example error.

It may be related to this issue which triggered on the same environment and even the same crate serde_derive and this issue.

Potential workaround: Disable cache.

Errors

error[E0463]: can't find crate for serde_derive which serde_json depends on
Error: --> identity-diff/src/object.rs:4:5
|
4 | use serde_json::Value;
| ^^^^^^^^^^ can't find crate

Chrysalis Phase 2 support

Rewrite interactions with the IOTA Tangle to be exclusively working for the Chrysalis Phase 2 network. The old network does not need to be supported.

  • Writing to the Tangle with the new message structure
  • Add confirmation reporting logic through polling, MQTT, and/or ZMQ
  • Add promoting logic if confirmation doesn't happen within a reasonable timeframe
  • Reading from the Tangle with new indexation
  • Handle pagination logic
  • Run all existing examples to check for unexpected behavior, including bindings

[Bug] Diff traits merge method sets controller fields to None

Bug description

When using the merge method of the Diff trait impl for Document, the controller field will be set to None, if the diff objects controller field was None.

Language version

What programming language are you using? Rust or one of the bindings?
Which version of the language are you running?

  • Language: Rust
  • Version: latest

IOTA Identity version

current Dev

  • Version (version number, commit, or branch):

Hardware specification

What hardware are you using? (Delete if not relevant)

  • Operating system:
  • RAM:
  • Cores:
  • Device:

Steps To reproduce the bug

Explain how the maintainer can reproduce the bug.


  #[test]
  fn test_also_known_as() {
    let doc = document();
    let mut new = document();
    new.also_known_as_mut().push("diff:diff:1234".parse().unwrap());
    assert_ne!(doc, new);
    let diff = doc.diff(&new).unwrap();
    let merge = doc.merge(diff).unwrap();
    dbg!(merge.controller(), new.controller());
    assert_eq!(merge, new);
  }

Expected behaviour

I'm expecting the last assert_eq! to not panic.

Actual behaviour

Panics

Errors

Paste any errors that you see, including logs, errors, or screenshots.

Changing

like this gives me what I expect:

 let controller: Option<DID> = diff
      .controller
      .flatten()
      .and_then(|value| self.controller().map(|controller| controller.merge(value)))
      .transpose()?
      .or_else(|| self.controller().cloned());

Add proper documentation for Code Editor Preview

Today's code editors show possible functions with some examples, how to use it.

Goal: The library should show, which attributes by name. and types are needed for a function.

This is the current state:
unknown-1

This is how it should look like:
intellisense

Add debug methods to identity_iota::Client

Add support for resolving a DID Document with additional debug information

Should include:

  • All messages received from the Tangle
  • The entire auth chain and any diff chain(s) (deserialized)
  • Some indicator when auth/diff chains diverge
  • Bindings in various languages (currently just WASM)

[Task] Rename Authentication Key and Chain

Description

Describe the task, this may be scoped beyond a single PR.

Instead of using the authentication field and key for DID messages, utilize a general verification method. As this removes the logic behind the authentication chain name, I request a rename to the Integration chain (Also in the code). The name of the key we use for signing DID messages may be anything, but we can default to #_sign-x, where x is the number of the key, incremented every time it is updated. This should not be enforced though.

Motivation

Describe the motivation for the feature to be developed.

We currently always use an authentication key for signing and updating DID messages. This doesn't fall in line with the standardized way of using the authentication verifiable relationship according to the DID standard. Instead, we should utilize a general verification method.

Resources

Link to any resources relevant for the task such as Issues, PRs, reference implementations, or specifications.

To-do list

Create a task-specific to-do list . Please link PRs that match the To-do list item behind the item after it has been submitted.

  • Rename AuthChain and other references to IntChain (Integration Chain) in the code
  • Remove enforcement of signing with "auth key"
  • Edit examples to add verification method with a #_sign-1 key.
  • Edit account to standardize the #_sign-x naming instead of auth keys.
  • Edit documentation to rename all references to AuthChain

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

  • The feature or fix is implemented in Rust and across all bindings whereas possible.
  • The feature or fix has sufficient testing coverage
  • All tests and examples build and run locally as expected
  • Every piece of code has been document according to the documentation guidelines.
  • If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
  • If the feature is not currently documented, a documentation task Issue has been opened to address this.

[Request]: DID Comms Message DID Introduction

DID Introduction

AKA "now kiss"-protocol: Introducing two parties through an intermediary.

Add to DID COMMS Specification

Roles

  • Introducer: Agent who introduces two introducees to each other
  • Introducee: Agents who get introduced to each other by the introducer

Add Selective Disclosure Support to VC

As an option, update the way verifiable credentials are signed by hashing individual data points inside the credentialSubject object of a verifiable credential using the Merkle Tree algorithm. The last remaining hash is used to sign the verifiable credential. During the revealing of the verifiable credential, fields may either be revealed or may be replaced by its hash.

  • Add option to sign using the Merkle Tree, enabling Selective Disclosure for the Holder
  • Salt the individual fields to prevent brute force guessing
  • Generate Verifiable Presentation while hiding/revealing specific fields in the VC
  • Verify a Verifiable Presentation that is signed with the Selective Disclosure method

For reference: W3C Verifiable Credentials Selective Disclosure

Tasks

  1. UMR1352
  2. wulfraem

Storage Adapter

Add traits and types for using various storage backends, including Stronghold

  • Add a StorageAdapter trait for common functionality
    • get/set/del/all Documents
    • get/set/del/all Credentials
    • get/set/del/all Presentations (?)
    • generate_key/retrieve_key
    • sign/verify
  • Add a StrongholdAdapter type that implements StorageAdapter

Add identity::prelude

Description

Define a prelude of commonly used types for the identity crate

Motivation

This is idiomatic rust and makes it easier to work with the library

A good starting point might be:

pub mod prelude {
  pub use identity::core::KeyPair;
  pub use identity::iota::DID;
  pub use identity::iota::Document;
}

which enables to most basic usage:

use identity::prelude::*;

let keypair = KeyPair::new_ed25519()?;
let document = Document::from_keypair(&keypair)?;

Resources

std: https://doc.rust-lang.org/std/prelude/index.html

rand: https://docs.rs/rand/0.8.3/rand/prelude/index.html

To-do list

  • Add a prelude module to re-export common types

Change checklist

  • The feature or fix is implemented in Rust and across all bindings whereas possible.
  • The feature or fix has sufficient testing coverage
  • All tests and examples build and run locally as expected
  • Every piece of code has been document according to the documentation guidelines.
  • If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
  • If the feature is not currently documented, a documentation task Issue has been opened to address this.

Improve identity::iota::Document type consistency

Description

The Deref implementation for identity::iota::Document leads to situations where unexpected "core" types are returned when IOTA-specific types are expected.

This trait can be removed and the relevant methods from iota::did::Document can be re-implement in identity::iota::Document while also performing the necessary type conversions.

Motivation

This can be confusing and often leads to type inconsistencies

Resources

https://rust-unofficial.github.io/patterns/anti_patterns/deref.html

There is no one good alternative

To-do list

  • Remove Deref from identity::iota::Document

  • Validate all DID Document verification methods in iota::Document::try_from_core**

    for method in document.methods() { Method::check_validity(method)?; }
  • Re-implement the following methods for identity::iota::Document***:

    • controller
    • methods
    • resolve
    • try_resolve

** This is required for unsafe casts between references (safe alternatives require a clone and refs are needed for iterators, etc.)

*** This should just call the "core" document method and convert the output type (see iota::Document::id(...))

Change checklist

  • The feature or fix is implemented in Rust and across all bindings whereas possible.
  • The feature or fix has sufficient testing coverage
  • All tests and examples build and run locally as expected
  • Every piece of code has been document according to the documentation guidelines.
  • If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
  • If the feature is not currently documented, a documentation task Issue has been opened to address this.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.