|0.1.6||Oct 18, 2023|
|0.1.5||Oct 4, 2023|
|0.1.2||Sep 13, 2023|
|0.1.1||Jun 20, 2023|
#508 in Cryptography
101 downloads per month
Used in 3 crates (via rebase_witness_sdk)
Rebase is a library for building credentialing witnesses and clients to interact with them. Rebase is built on top of SSI and uses DIDs and Verifiable Credentials (VCs) to create portable, specified credentials. Rebase provides abstractions for working with witnessed cryptographic signature-based attestations, linking cryptographic keys to traditional profiles and identities, and working with delegations to improve the experience for developers and users of applications with user-owned data models, along with other libraries available from Spruce.
Here's a short overview of the core Rebase library:
This is a diagram of the credentialing flow that Rebase enables and with each step color-coded to show the module responsible for handling that portion of the credentialing flow:
Each of the color-coded modules correspond to a folder in the
src folder of this project. The additional three directories in the
src folder are:
context: A module used for setting up the context_loader, should be irrelevant to consumers.
test_util: A module used only for internal testing.
types: A module including all type and enum definitions to avoid issues with circular dependencies.
The big idea behind Rebase is abstracting the flow of data from the key type used in VC issuance. Key types are supported at two levels, as
Subjects and as
Issuers must implement
Subject. Most often, a
Subject is the public key of a key pair and
Issuer is the full key pair of a cryptographic key pair.
flow module is the representation of the data required and the verification checks needed to make a credential. Each flow type (of which include traditional identities like "Twitter", "GitHub", "Email", credentials that link two keys, or credentials that are simply attestations by the Subject) is comprised of an entry in the
proof often includes the
statement, and the
flow is in terms of all three others.
flow and the
subject modules only deal with each other abstractly, any time a new
flow is added, it works will all existing
subjects and vice versa.
Implementing a new
flow is as simple as implementing the three underlying traits (
content) and creating a validation of the
proof, then implementing the
flow type. Examples can be found of the ten flows currently supported (Attestaion (structures and statements signed by the Subject and witnessed by the Issuer), DNS, Email, GitHub, NFT Ownership, POAP Ownership, Reddit, SameController (links two keys), SoundCloud, and Twitter).
The main reason to fork or open PRs to this repo is for the purpose of adding new flows. Hopefully soon we will have a guide on how to do so, but for now there are a lot examples here.