Example Overview

Overview of the Rebase example app
rebase/demo at main · spruceid/rebase
GitHub
The demo directory includes a Cloudflare Worker that acts as a server-side witness (demo/witness) and a front-end UI for interacting with the witness (demo/dapp). 
The Cloudflare Worker acts as a proof-of-concept that Rebase can be packaged for WASM environments, including the browser. Otherwise, it essentially functions as a tiny HTTP server. 
It contains 3 routes
 /instructions where the client can retrieve user-facing instructions for a witness flow along with JSON schema representations of the expected user input.
 /statement, where the client is expected to post a struct that implements Statement and then receives the generated statement from the witness.
 /witness where a struct that implements Proof is posted, and the witness uses its generator to produce a VC (assuming all the details check out).
The UI is a thin client that simply: 
Gathers the information required to generate the statement. 
Interacts with browser extensions to get the user to sign the statement.
Informs the user where to post the statement (if necessary).
Gathers the information on the location of the post (if necessary). 
Returns it to the witness for a VC, then displays the VC and allows the user to download it.
The Rebase Faucet Demo
The following is a visual overview of the Rebase Faucet Demo. 
First, a user has access to see what credentials they can obtain from the interface, and those they've already obtained. 
 
​
Once a user has connected their account, they can go through one of the various flows to obtain a credential.
​
​
In this example, a user must enter their Twitter handle, and sign a message containing both that handle and their public key.
​
​
Once completed, then, the user has to Tweet out the given attestation and submit the Tweet's URL to the service. At that point, the Tweet will be "witnessed" and if the signatures match, a credential will be issued. 
​
​
Finally, the credential is issued to the user, and eventually can be stored in their data vault of choice.
Other Flow Outlines:
Several other flows are supported by the Rebase Faucet example, including:
DNS
1.The User connects their signing key.
2.The User supplies their domain.
3.The User is provided with a statement to sign.
4.The User is provided value to insert into their TXT record including the signature from step 3.
5.The Witness retrieves the TXT record -- makes sure the signature, domain, and key all line up -- then generates a credential.
Email:
1.The User connects their signing key.
2.The User supplies their email.
3.The Witness generates a timestamp, uses that to generate a challenge, sends the challenge and email to the user supplied email.
4.The User is provided with a statement to sign.
5.The User sends the Witness the signature, the challenge, and the timestamp to the witness.
6.Assuming the challenge is valid, the signature is valid and the timestamp isn't too old, it then generates a credential.
GitHub:
(Identical to the Twitter Example, but utilizing a Gist instead)
1.The User connects their signing key.
2.The User supplies their GitHub handle.
3.The User is provided with a statement to sign.
4.The User posts the statement and signature as a Gist from the account provided in step 2.
5.The User provides a link to the Gist.
6.The Witness looks up the Gist -- verifies the statement, signature, key, and handle all line up as expected -- then generates a credential.
Reddit:
1.The User connects their signing key.
2.The User supplies their Reddit handle.
3.The User is provided with a statement to sign.
4.The User updates their Reddit profile's "About" section to include only the signature from step 3.
5.The Witness looks up the Reddit account's "About" section -- verifies the signature, key, and handle all line up -- then generates a credential.
Same: (Links two Subjects to eachother)
1.The User connects the first signing key they want to link.
2.The User connects the second signing key they want to link.
3.The User is supplied with a statement to sign.
4.The User uses the key from step 2 to sign the statement (because it is already connected).
5.The User reconnects the key from step 1.
6.The User uses the key from step 1 to sign the statement.
7.The User sends both signatures and public keys to the Witness.
8.The Witness verifies that both keys signed the statement pertaining to them, then generates a credential.
SoundCloud:
(Identical to Reddit, but utilizing the "Bio" section instead)
1.The User connects their signing key.
2.The User supplies the link to their SoundCloud profile.
3.The User is provided with a statement to sign.
4.The User updates their SoundCloud profile's "Bio" section to include only the signature from step 3.
5.The Witness looks up the SoundCloud account's "Bio" section -- verifies the signature, key, and link all line up -- then generates a credential.