-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
13 changed files
with
3,466 additions
and
8 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
Large diffs are not rendered by default.
Oops, something went wrong.
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,141 @@ | ||
# `x/did` | ||
|
||
The Decentralized Identity module is responsible for managing native Sonr Accounts, their derived wallets, and associated user identification information. | ||
|
||
## State | ||
|
||
The DID module maintains several key state structures: | ||
|
||
### Controller State | ||
|
||
The Controller state represents a Sonr DWN Vault. It includes: | ||
- Unique identifier (number) | ||
- DID | ||
- Sonr address | ||
- Ethereum address | ||
- Bitcoin address | ||
- Public key | ||
- Keyshares pointer | ||
- Claimed block | ||
- Creation block | ||
|
||
### Assertion State | ||
|
||
The Assertion state includes: | ||
- DID | ||
- Controller | ||
- Subject | ||
- Public key | ||
- Assertion type | ||
- Accumulator (metadata) | ||
- Creation block | ||
|
||
### Authentication State | ||
|
||
The Authentication state includes: | ||
- DID | ||
- Controller | ||
- Subject | ||
- Public key | ||
- Credential ID | ||
- Metadata | ||
- Creation block | ||
|
||
### Verification State | ||
|
||
The Verification state includes: | ||
- DID | ||
- Controller | ||
- DID method | ||
- Issuer | ||
- Subject | ||
- Public key | ||
- Verification type | ||
- Metadata | ||
- Creation block | ||
|
||
## State Transitions | ||
|
||
State transitions are triggered by the following messages: | ||
- LinkAssertion | ||
- LinkAuthentication | ||
- UnlinkAssertion | ||
- UnlinkAuthentication | ||
- ExecuteTx | ||
- UpdateParams | ||
|
||
## Messages | ||
|
||
The DID module defines the following messages: | ||
|
||
1. MsgLinkAuthentication | ||
2. MsgLinkAssertion | ||
3. MsgExecuteTx | ||
4. MsgUnlinkAssertion | ||
5. MsgUnlinkAuthentication | ||
6. MsgUpdateParams | ||
|
||
Each message triggers specific state machine behaviors related to managing DIDs, authentications, assertions, and module parameters. | ||
|
||
## Query | ||
|
||
The DID module provides the following query endpoints: | ||
|
||
1. Params: Query all parameters of the module | ||
2. Resolve: Query the DID document by its ID | ||
3. Sign: Sign a message with the DID document | ||
4. Verify: Verify a message with the DID document | ||
|
||
## Params | ||
|
||
The module parameters include: | ||
- Allowed public keys (map of KeyInfo) | ||
- Conveyance preference | ||
- Attestation formats | ||
|
||
## Client | ||
|
||
The module provides gRPC and REST endpoints for all defined messages and queries. | ||
|
||
## Future Improvements | ||
|
||
Potential future improvements could include: | ||
1. Enhanced privacy features for DID operations | ||
2. Integration with more blockchain networks | ||
3. Support for additional key types and cryptographic algorithms | ||
4. Improved revocation mechanisms for credentials and assertions | ||
|
||
## Tests | ||
|
||
Acceptance tests should cover all major functionality, including: | ||
- Creating and managing DIDs | ||
- Linking and unlinking assertions and authentications | ||
- Executing transactions with DIDs | ||
- Querying and resolving DIDs | ||
- Parameter updates | ||
|
||
## Appendix | ||
|
||
### Account | ||
|
||
An Account represents a user's identity within the Sonr ecosystem. It includes information such as the user's public key, associated wallets, and other identification details. | ||
|
||
### Decentralized Identifier (DID) | ||
|
||
A Decentralized Identifier (DID) is a unique identifier that is created, owned, and controlled by the user. It is used to establish a secure and verifiable digital identity. | ||
|
||
### Verifiable Credential (VC) | ||
|
||
A Verifiable Credential (VC) is a digital statement that can be cryptographically verified. It contains claims about a subject (e.g., a user) and is issued by a trusted authority. | ||
|
||
### Key Types | ||
|
||
The module supports various key types, including: | ||
- Role | ||
- Algorithm (e.g., ES256, EdDSA, ES256K) | ||
- Encoding (e.g., hex, base64, multibase) | ||
- Curve (e.g., P256, P384, P521, X25519, X448, Ed25519, Ed448, secp256k1) | ||
|
||
### JSON Web Key (JWK) | ||
|
||
The module supports JSON Web Keys (JWK) for representing cryptographic keys, including properties such as key type (kty), curve (crv), and coordinates (x, y) for EC and OKP keys, as well as modulus (n) and exponent (e) for RSA keys. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,145 @@ | ||
# `x/dwn` | ||
|
||
The DWN module is responsible for the management of IPFS deployed Decentralized Web Nodes (DWNs) and their associated data. | ||
|
||
## Concepts | ||
|
||
The DWN module introduces several key concepts: | ||
|
||
1. Decentralized Web Node (DWN): A distributed network for storing and sharing data. | ||
2. Schema: A structure defining the format of various data types in the dwn. | ||
3. IPFS Integration: The module can interact with IPFS for decentralized data storage. | ||
|
||
## State | ||
|
||
The DWN module maintains the following state: | ||
|
||
### DWN State | ||
|
||
The DWN state is stored using the following structure: | ||
|
||
```protobuf | ||
message DWN { | ||
uint64 id = 1; | ||
string alias = 2; | ||
string cid = 3; | ||
string resolver = 4; | ||
} | ||
``` | ||
|
||
This state is indexed by ID, alias, and CID for efficient querying. | ||
|
||
### Params State | ||
|
||
The module parameters are stored in the following structure: | ||
|
||
```protobuf | ||
message Params { | ||
bool ipfs_active = 1; | ||
bool local_registration_enabled = 2; | ||
Schema schema = 4; | ||
} | ||
``` | ||
|
||
### Schema State | ||
|
||
The Schema state defines the structure for various data types: | ||
|
||
```protobuf | ||
message Schema { | ||
int32 version = 1; | ||
string account = 2; | ||
string asset = 3; | ||
string chain = 4; | ||
string credential = 5; | ||
string did = 6; | ||
string jwk = 7; | ||
string grant = 8; | ||
string keyshare = 9; | ||
string profile = 10; | ||
} | ||
``` | ||
|
||
## State Transitions | ||
|
||
State transitions in the DWN module are primarily triggered by: | ||
|
||
1. Updating module parameters | ||
2. Allocating new dwns | ||
3. Syncing DID documents | ||
|
||
## Messages | ||
|
||
The DWN module defines the following message: | ||
|
||
1. `MsgUpdateParams`: Used to update the module parameters. | ||
|
||
```protobuf | ||
message MsgUpdateParams { | ||
string authority = 1; | ||
Params params = 2; | ||
} | ||
``` | ||
|
||
## Begin Block | ||
|
||
No specific begin-block operations are defined for this module. | ||
|
||
## End Block | ||
|
||
No specific end-block operations are defined for this module. | ||
|
||
## Hooks | ||
|
||
The DWN module does not define any hooks. | ||
|
||
## Events | ||
|
||
The DWN module does not explicitly define any events. However, standard Cosmos SDK events may be emitted during state transitions. | ||
|
||
## Client | ||
|
||
The DWN module provides the following gRPC query endpoints: | ||
|
||
1. `Params`: Queries all parameters of the module. | ||
2. `Schema`: Queries the DID document schema. | ||
3. `Allocate`: Initializes a Target DWN available for claims. | ||
4. `Sync`: Queries the DID document by its ID and returns required information. | ||
|
||
## Params | ||
|
||
The module parameters include: | ||
|
||
- `ipfs_active` (bool): Indicates if IPFS integration is active. | ||
- `local_registration_enabled` (bool): Indicates if local registration is enabled. | ||
- `schema` (Schema): Defines the structure for various data types in the dwn. | ||
|
||
## Future Improvements | ||
|
||
Potential future improvements could include: | ||
|
||
1. Enhanced IPFS integration features. | ||
2. Additional authentication mechanisms beyond WebAuthn. | ||
3. Improved DID document management and querying capabilities. | ||
|
||
## Tests | ||
|
||
Acceptance tests should cover: | ||
|
||
1. Parameter updates | ||
2. DWN state management | ||
3. Schema queries | ||
4. DWN allocation process | ||
5. DID document syncing | ||
|
||
## Appendix | ||
|
||
| Concept | Description | | ||
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| Decentralized Web Node (DWN) | A decentralized, distributed, and secure network of nodes that store and share data. It is a decentralized alternative to traditional web hosting services. | | ||
| Decentralized Identifier (DID) | A unique identifier that is created, owned, and controlled by the user. It is used to establish a secure and verifiable digital identity. | | ||
| HTMX (Hypertext Markup Language eXtensions) | A set of extensions to HTML that allow for the creation of interactive web pages. It is used to enhance the user experience and provide additional functionality to web applications. | | ||
| IPFS (InterPlanetary File System) | A decentralized, peer-to-peer network for storing and sharing data. It is a distributed file system that allows for the creation and sharing of content across a network of nodes. | | ||
| WebAuthn (Web Authentication) | A set of APIs that allow websites to request user authentication using biometric or non-biometric factors. | | ||
| WebAssembly (Web Assembly) | A binary instruction format for a stack-based virtual machine. | | ||
| Verifiable Credential (VC) | A digital statement that can be cryptographically verified. | |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,91 @@ | ||
# `x/svc` | ||
|
||
The svc module is responsible for managing the registration and authorization of services within the Sonr ecosystem. It provides a secure and verifiable mechanism for registering and authorizing services using Decentralized Identifiers (DIDs). | ||
|
||
## Concepts | ||
|
||
- **Service**: A decentralized svc on the Sonr Blockchain with properties such as ID, authority, origin, name, description, category, tags, and expiry height. | ||
- **Profile**: Represents a DID alias with properties like ID, subject, origin, and controller. | ||
- **Metadata**: Contains information about a svc, including name, description, category, icon, and tags. | ||
|
||
### Dependencies | ||
|
||
- [x/did](https://github.com/onsonr/sonr/tree/master/x/did) | ||
- [x/group](https://github.com/onsonr/sonr/tree/master/x/group) | ||
- [x/nft](https://github.com/onsonr/sonr/tree/master/x/nft) | ||
|
||
## State | ||
|
||
The module uses the following state structures: | ||
|
||
### Metadata | ||
|
||
Stores information about services: | ||
|
||
- Primary key: `id` (auto-increment) | ||
- Unique index: `origin` | ||
- Fields: id, origin, name, description, category, icon (URI), tags | ||
|
||
### Profile | ||
|
||
Stores DID alias information: | ||
|
||
- Primary key: `id` | ||
- Unique index: `subject,origin` | ||
- Fields: id, subject, origin, controller | ||
|
||
## Messages | ||
|
||
### MsgUpdateParams | ||
|
||
Updates the module parameters. Can only be executed by the governance account. | ||
|
||
### MsgRegisterService | ||
|
||
Registers a new svc on the blockchain. Requires a valid TXT record in DNS for the origin. | ||
|
||
## Params | ||
|
||
The module has the following parameters: | ||
|
||
- `categories`: List of allowed svc categories | ||
- `types`: List of allowed svc types | ||
|
||
## Query | ||
|
||
The module provides the following query: | ||
|
||
### Params | ||
|
||
Retrieves all parameters of the module. | ||
|
||
## Client | ||
|
||
### gRPC | ||
|
||
The module provides a gRPC Query svc with the following RPC: | ||
|
||
- `Params`: Get all parameters of the module | ||
|
||
### CLI | ||
|
||
(TODO: Add CLI commands for interacting with the module) | ||
|
||
## Events | ||
|
||
(TODO: List and describe event tags used by the module) | ||
|
||
## Future Improvements | ||
|
||
- Implement svc discovery mechanisms | ||
- Add support for svc reputation and rating systems | ||
- Enhance svc metadata with more detailed information | ||
- Implement svc update and deactivation functionality | ||
|
||
## Tests | ||
|
||
(TODO: Add acceptance tests for the module) | ||
|
||
## Appendix | ||
|
||
This module is part of the Sonr blockchain project and interacts with other modules such as DID and NFT modules to provide a comprehensive decentralized svc ecosystem. |
Empty file.
Oops, something went wrong.