📖Appendix
Definitions and Concepts
Kepler
Kepler is the primary form of storage used in SSX. With Kepler, users can define exactly where their data are stored, and who has access to their personal data vault known as an Orbit. An Orbit designates a list of trusted hosts for their data, and all of the interactions around permissioning access to data is managed via a user's keypair.
Kepler uses capabilities-based permissioning, which works similarly to an access pass. A resource owner can specify who has access to data within Kepler and under what conditions, then sign off on it.
Rebase
Rebase is a set of libraries for handling cryptographically verifiable claims and issuing Verifiable Credentials (VC) based on this programmatic witnessing and self-issued credentials. Rebase simplifies the process of creating links between identity providers or self-attested claims using VCs by providing a convenient wrapper around ssi. Rebase is intended for various uses ranging from server-side "witness" services, to VC reading validation services, to in-browser usage via WASM.
ReCaps
A ReCap is a valid EIP-4361 message that follows additional structure defined in EIP-5573, allowing an Ethereum account to delegate a set of capabilities (ReCaps) to a delegate through informed user consent. SIWE ReCap implements an object-capability (ocap) model using Ethereum-native signature algorithms and data models.
For more information on ReCaps, check out the following post:
Session Keys
A session key is an ephemeral key generated for a user’s session, stored in the browser, and further downscoped in permissions to allow exactly what the user needs to do and nothing more. With session keys, we can adopt standard ways to represent capabilities that are platform agnostic, as opposed to cookies which are typically only readable by the issuing website and have proprietary formats.
For more information on Session Keys, check out the following post:
Last updated
