diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 33f10b6d1..63f355030 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -35,6 +35,9 @@ jobs: - uses: Swatinem/rust-cache@v2 with: cache-on-failure: "true" + - uses: taiki-e/install-action@v2 + with: + tool: cargo-rdme - name: Fmt run: cargo fmt -- --check @@ -56,6 +59,8 @@ jobs: - name: Doc run: cargo doc --no-deps --workspace --all-features + - name: cargo-rdme + run: cargo rdme --check --no-fail-on-warnings test-each-feature: if: ${{ !github.event.pull_request.draft }} diff --git a/README.md b/README.md index a533a0fa7..eee14e8eb 100644 --- a/README.md +++ b/README.md @@ -28,6 +28,7 @@ This library supports the two main families of verifiable claims: [dids]: [didkit]: [vc-data-model]: +[linked-data]: [jwt]: [jws]: [jwt-vc]: @@ -64,15 +65,18 @@ let jwt = CompactJWSString::from_string( // `example` feature. let vm_resolver = ExampleDIDResolver::default().into_vm_resolver::(); +// Setup the verification parameters. +let params = VerificationParameters::from_resolver(vm_resolver); + // Verify the JWT. -assert!(jwt.verify(&vm_resolver).await.expect("verification failed").is_ok()) +assert!(jwt.verify(¶ms).await.expect("verification failed").is_ok()) ``` #### Verifiable Credentials Verifiable Credential are much more complex as they require interpreting the input claims and proofs, such as Data-Integrity proofs as Linked-Data -using JSON-LD. This operation is highly configurable. SSI provides +using JSON-LD. This operation is highly configurable. SSI provide functions exposing various levels of implementation details that you can tweak as needed. The simplest of them is `any_credential_from_json_str` that will simply load a VC from a string, assuming it is signed using @@ -85,13 +89,16 @@ use ssi::prelude::*; let vc = ssi::claims::vc::v1::data_integrity::any_credential_from_json_str( &std::fs::read_to_string("examples/files/vc.jsonld") .expect("unable to load VC") -).await.expect("invalid VC"); +).expect("invalid VC"); // Setup a verification method resolver, in charge of retrieving the // public key used to sign the JWT. let vm_resolver = ExampleDIDResolver::default().into_vm_resolver(); -assert!(vc.verify(&vm_resolver).await.expect("verification failed").is_ok()); +// Setup the verification parameters. +let params = VerificationParameters::from_resolver(vm_resolver); + +assert!(vc.verify(¶ms).await.expect("verification failed").is_ok()); ``` ### Signature & Custom Claims @@ -135,8 +142,11 @@ let jwt = claims.sign(&key).await.expect("signature failed"); // decoding the DID back into a public key. let vm_resolver = DIDJWK.into_vm_resolver::(); +// Setup the verification parameters. +let params = VerificationParameters::from_resolver(vm_resolver); + // Verify the JWT. -assert!(jwt.verify(&vm_resolver).await.expect("verification failed").is_ok()); +assert!(jwt.verify(¶ms).await.expect("verification failed").is_ok()); // Print the JWT. println!("{jwt}") @@ -146,7 +156,7 @@ println!("{jwt}") We can use a similar technique to sign a VC with custom claims. The `SpecializedJsonCredential` type provides a customizable -implementation of the VC data-model where you can set the credential type +implementation of the VC data-model 1.1 where you can set the credential type yourself. @@ -186,7 +196,7 @@ let vm_resolver = DIDJWK.into_vm_resolver(); // Create a signer from the secret key. // Here we use the simple `SingleSecretSigner` signer type which always uses // the same provided secret key to sign messages. -let signer = SingleSecretSigner::new(key.clone()); +let signer = SingleSecretSigner::new(key.clone()).into_local(); // Turn the DID URL into a verification method reference. let verification_method = did.into_iri().into(); @@ -197,10 +207,9 @@ let cryptosuite = AnySuite::pick(&key, Some(&verification_method)) let vc = cryptosuite.sign( credential, - AnyInputContext::default(), &vm_resolver, &signer, - ProofConfiguration::from_method(verification_method) + ProofOptions::from_method(verification_method) ).await.expect("signature failed"); ``` @@ -212,6 +221,13 @@ JSON-LD context and embed it to `credential` using either parameter. +## Data-Models + +The examples above are using the VC data-model 1.1, but you ssi also has support for: +- `VC data-model 2.0` +- `A wrapper type to accept both` + + ## Features diff --git a/crates/verification-methods/README.md b/crates/verification-methods/README.md index cd6ab712f..f6a1ce6af 100644 --- a/crates/verification-methods/README.md +++ b/crates/verification-methods/README.md @@ -11,15 +11,8 @@ SSI's documentation is currently packaged with the DIDKit documentation -Verification methods implementation. - -This modules provides the implementation of common Data Integrity +This library provides the implementation of common Data Integrity verification methods such as `Multikey` or `JsonWebKey2020`. -It is separated from the Data Integrity library ([`ssi-ldp`]) to allow -verification methods providers (such as [`ssi-dids`]) to reason about -verification methods without Data Integrity. -[`ssi-ldp`]: -[`ssi-dids`]: diff --git a/crates/verification-methods/core/README.md b/crates/verification-methods/core/README.md index cd6ab712f..1c0bcc051 100644 --- a/crates/verification-methods/core/README.md +++ b/crates/verification-methods/core/README.md @@ -8,18 +8,3 @@ SSI's documentation is currently packaged with the DIDKit documentation [here](https://spruceid.dev/didkit/didkit/). - - - -Verification methods implementation. - -This modules provides the implementation of common Data Integrity -verification methods such as `Multikey` or `JsonWebKey2020`. -It is separated from the Data Integrity library ([`ssi-ldp`]) to allow -verification methods providers (such as [`ssi-dids`]) to reason about -verification methods without Data Integrity. - -[`ssi-ldp`]: -[`ssi-dids`]: - - diff --git a/src/lib.rs b/src/lib.rs index 38e00b18b..a552b05e9 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -19,6 +19,7 @@ //! [dids]: //! [didkit]: //! [vc-data-model]: +//! [linked-data]: //! [jwt]: //! [jws]: //! [jwt-vc]: