mirror of
https://github.com/onsonr/sonr.git
synced 2025-03-10 13:07:09 +00:00
Merge branch 'feature/1119-allocate-vault-macaroon' into feature/1110-implement-dwn-wallet-abstraction
This commit is contained in:
commit
1ae8a8675e
2
.cz.toml
2
.cz.toml
@ -2,6 +2,6 @@
|
||||
name = "cz_conventional_commits"
|
||||
tag_format = "v$version"
|
||||
version_scheme = "semver"
|
||||
version = "0.5.15"
|
||||
version = "0.5.16"
|
||||
update_changelog_on_bump = true
|
||||
major_version_zero = true
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
## v0.5.16 (2024-10-21)
|
||||
|
||||
## v0.5.15 (2024-10-21)
|
||||
|
||||
## v0.5.14 (2024-10-21)
|
||||
|
||||
124
x/did/README.md
124
x/did/README.md
@ -4,60 +4,118 @@ The Decentralized Identity module is responsible for managing native Sonr Accoun
|
||||
|
||||
## State
|
||||
|
||||
Specify and describe structures expected to marshalled into the store, and their keys
|
||||
The DID module maintains several key state structures:
|
||||
|
||||
### Account State
|
||||
### Controller State
|
||||
|
||||
The Account state includes the user's public key, associated wallets, and other identification details. It is stored using the user's DID as the key.
|
||||
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
|
||||
|
||||
### Credential State
|
||||
### Assertion State
|
||||
|
||||
The Credential state includes the claims about a subject and is stored using the credential ID as the key.
|
||||
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
|
||||
|
||||
Standard state transition operations triggered by hooks, messages, etc.
|
||||
State transitions are triggered by the following messages:
|
||||
- LinkAssertion
|
||||
- LinkAuthentication
|
||||
- UnlinkAssertion
|
||||
- UnlinkAuthentication
|
||||
- ExecuteTx
|
||||
- UpdateParams
|
||||
|
||||
## Messages
|
||||
|
||||
Specify message structure(s) and expected state machine behaviour(s).
|
||||
The DID module defines the following messages:
|
||||
|
||||
## Begin Block
|
||||
1. MsgLinkAuthentication
|
||||
2. MsgLinkAssertion
|
||||
3. MsgExecuteTx
|
||||
4. MsgUnlinkAssertion
|
||||
5. MsgUnlinkAuthentication
|
||||
6. MsgUpdateParams
|
||||
|
||||
Specify any begin-block operations.
|
||||
Each message triggers specific state machine behaviors related to managing DIDs, authentications, assertions, and module parameters.
|
||||
|
||||
## End Block
|
||||
## Query
|
||||
|
||||
Specify any end-block operations.
|
||||
The DID module provides the following query endpoints:
|
||||
|
||||
## Hooks
|
||||
|
||||
Describe available hooks to be called by/from this module.
|
||||
|
||||
## Events
|
||||
|
||||
List and describe event tags used.
|
||||
|
||||
## Client
|
||||
|
||||
List and describe CLI commands and gRPC and REST 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
|
||||
|
||||
List all module parameters, their types (in JSON) and identitys.
|
||||
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
|
||||
|
||||
Describe future improvements of this module.
|
||||
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.
|
||||
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
|
||||
|
||||
Supplementary details referenced elsewhere within the spec.
|
||||
|
||||
### 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.
|
||||
@ -69,3 +127,15 @@ A Decentralized Identifier (DID) is a unique identifier that is created, owned,
|
||||
### 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.
|
||||
|
||||
@ -7,9 +7,9 @@ import (
|
||||
|
||||
var _ sdk.Msg = &MsgUpdateParams{}
|
||||
|
||||
// ╭────────────────────────────────────────────────────────╮
|
||||
// │ MsgUpdateParams │
|
||||
// ╰────────────────────────────────────────────────────────╯
|
||||
// ╭───────────────────────────────────────────────────────────╮
|
||||
// │ MsgUpdateParams type definition │
|
||||
// ╰───────────────────────────────────────────────────────────╯
|
||||
|
||||
// NewMsgUpdateParams creates new instance of MsgUpdateParams
|
||||
func NewMsgUpdateParams(
|
||||
|
||||
@ -1,62 +1,104 @@
|
||||
# `x/macaroon`
|
||||
|
||||
The Macaroon module is responsible for providing decentralized access control and service authorization for the Sonr ecosystem.
|
||||
The Macaroon module is responsible for providing decentralized access control and service authorization for the Sonr ecosystem. It implements macaroon-based authentication and authorization mechanisms.
|
||||
|
||||
## Concepts
|
||||
|
||||
Macaroons are a type of bearer credential that allow for decentralized delegation, attenuation, and third-party caveats. This module implements the core functionality for creating, validating, and managing macaroons within the Sonr ecosystem.
|
||||
|
||||
## State
|
||||
|
||||
Specify and describe structures expected to marshalled into the store, and their keys
|
||||
The module maintains the following state:
|
||||
|
||||
### Account State
|
||||
### Grant
|
||||
|
||||
The Account state includes the user's public key, associated wallets, and other identification details. It is stored using the user's DID as the key.
|
||||
Represents a permission grant with the following fields:
|
||||
- `id`: Unique identifier (auto-incremented)
|
||||
- `controller`: Address of the controller
|
||||
- `subject`: Subject of the grant
|
||||
- `origin`: Origin of the grant
|
||||
- `expiry_height`: Block height at which the grant expires
|
||||
|
||||
### Credential State
|
||||
### Macaroon
|
||||
|
||||
The Credential state includes the claims about a subject and is stored using the credential ID as the key.
|
||||
Represents a macaroon token with the following fields:
|
||||
- `id`: Unique identifier (auto-incremented)
|
||||
- `controller`: Address of the controller
|
||||
- `subject`: Subject of the macaroon
|
||||
- `origin`: Origin of the macaroon
|
||||
- `expiry_height`: Block height at which the macaroon expires
|
||||
- `macaroon`: The actual macaroon token
|
||||
|
||||
## State Transitions
|
||||
|
||||
Standard state transition operations triggered by hooks, messages, etc.
|
||||
State transitions occur through the following messages:
|
||||
- `MsgUpdateParams`: Updates the module parameters
|
||||
- `MsgIssueMacaroon`: Issues a new macaroon
|
||||
|
||||
## Messages
|
||||
|
||||
Specify message structure(s) and expected state machine behaviour(s).
|
||||
### MsgUpdateParams
|
||||
|
||||
## Begin Block
|
||||
Updates the module parameters. Can only be executed by the governance account.
|
||||
|
||||
Specify any begin-block operations.
|
||||
Fields:
|
||||
- `authority`: Address of the governance account
|
||||
- `params`: New parameter values
|
||||
|
||||
## End Block
|
||||
### MsgIssueMacaroon
|
||||
|
||||
Specify any end-block operations.
|
||||
Issues a new macaroon for a given controller and origin.
|
||||
|
||||
## Hooks
|
||||
Fields:
|
||||
- `controller`: Address of the controller
|
||||
- `origin`: Origin of the request in wildcard form
|
||||
- `permissions`: Map of permissions
|
||||
- `token`: Macaroon token to authenticate the operation
|
||||
|
||||
Describe available hooks to be called by/from this module.
|
||||
## Queries
|
||||
|
||||
The module provides the following queries:
|
||||
|
||||
- `Params`: Retrieves the current module parameters
|
||||
- `RefreshToken`: Refreshes a macaroon token (post-authentication)
|
||||
- `ValidateToken`: Validates a macaroon token (pre-authentication)
|
||||
|
||||
## Parameters
|
||||
|
||||
The module has the following parameters:
|
||||
|
||||
- `methods`: Defines the available DID methods
|
||||
- `default`: Default method
|
||||
- `supported`: List of supported methods
|
||||
- `scopes`: Defines the set of scopes
|
||||
- `base`: Base scope
|
||||
- `supported`: List of supported scopes
|
||||
- `caveats`: Defines the available caveats
|
||||
- `supported_first_party`: List of supported first-party caveats
|
||||
- `supported_third_party`: List of supported third-party caveats
|
||||
- `transactions`: Defines the allowlist and denylist for transactions
|
||||
- `allowlist`: List of allowed transactions
|
||||
- `denylist`: List of denied transactions
|
||||
|
||||
## Events
|
||||
|
||||
List and describe event tags used.
|
||||
The module may emit events related to macaroon issuance, validation, and refreshing. (Specific event details to be implemented)
|
||||
|
||||
## Client
|
||||
|
||||
List and describe CLI commands and gRPC and REST endpoints.
|
||||
|
||||
## Params
|
||||
|
||||
List all module parameters, their types (in JSON) and identitys.
|
||||
The module provides gRPC endpoints for all queries and message types defined in the protobuf files.
|
||||
|
||||
## Future Improvements
|
||||
|
||||
Describe future improvements of this module.
|
||||
- Implement more advanced caveat types
|
||||
- Add support for third-party caveats
|
||||
- Enhance macaroon revocation mechanisms
|
||||
- Implement additional security features and checks
|
||||
|
||||
## Tests
|
||||
|
||||
Acceptance tests.
|
||||
(To be implemented: Acceptance tests for the module's functionality)
|
||||
|
||||
## Appendix
|
||||
|
||||
Supplementary details referenced elsewhere within the spec.
|
||||
his is a module base generated with [`spawn`](https://github.com/rollchains/spawn).
|
||||
For more information on macaroons and their implementation, refer to the original macaroon paper: "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud" by Arnar Birgisson, et al.
|
||||
|
||||
@ -7,6 +7,10 @@ import (
|
||||
|
||||
var _ sdk.Msg = &MsgUpdateParams{}
|
||||
|
||||
// ╭───────────────────────────────────────────────────────────╮
|
||||
// │ MsgUpdateParams type definition │
|
||||
// ╰───────────────────────────────────────────────────────────╯
|
||||
|
||||
// NewMsgUpdateParams creates new instance of MsgUpdateParams
|
||||
func NewMsgUpdateParams(
|
||||
sender sdk.Address,
|
||||
|
||||
@ -1,63 +1,81 @@
|
||||
# `x/service`
|
||||
|
||||
The Service module is responsible for managing the registration and authorization of services within the Sonr ecosystem. It leverages
|
||||
the native NFT module associated with DID Methods to provide a secure and verifiable mechanism for registering and authorizing services.
|
||||
The Service 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 service 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 service, including name, description, category, icon, and tags.
|
||||
|
||||
## State
|
||||
|
||||
Specify and describe structures expected to marshalled into the store, and their keys
|
||||
The module uses the following state structures:
|
||||
|
||||
### Account State
|
||||
### Metadata
|
||||
|
||||
The Account state includes the user's public key, associated wallets, and other identification details. It is stored using the user's DID as the key.
|
||||
Stores information about services:
|
||||
- Primary key: `id` (auto-increment)
|
||||
- Unique index: `origin`
|
||||
- Fields: id, origin, name, description, category, icon (URI), tags
|
||||
|
||||
### Credential State
|
||||
### Profile
|
||||
|
||||
The Credential state includes the claims about a subject and is stored using the credential ID as the key.
|
||||
|
||||
## State Transitions
|
||||
|
||||
Standard state transition operations triggered by hooks, messages, etc.
|
||||
Stores DID alias information:
|
||||
- Primary key: `id`
|
||||
- Unique index: `subject,origin`
|
||||
- Fields: id, subject, origin, controller
|
||||
|
||||
## Messages
|
||||
|
||||
Specify message structure(s) and expected state machine behaviour(s).
|
||||
### MsgUpdateParams
|
||||
|
||||
## Begin Block
|
||||
Updates the module parameters. Can only be executed by the governance account.
|
||||
|
||||
Specify any begin-block operations.
|
||||
### MsgRegisterService
|
||||
|
||||
## End Block
|
||||
|
||||
Specify any end-block operations.
|
||||
|
||||
## Hooks
|
||||
|
||||
Describe available hooks to be called by/from this module.
|
||||
|
||||
## Events
|
||||
|
||||
List and describe event tags used.
|
||||
|
||||
## Client
|
||||
|
||||
List and describe CLI commands and gRPC and REST endpoints.
|
||||
Registers a new service on the blockchain. Requires a valid TXT record in DNS for the origin.
|
||||
|
||||
## Params
|
||||
|
||||
List all module parameters, their types (in JSON) and identitys.
|
||||
The module has the following parameters:
|
||||
- `categories`: List of allowed service categories
|
||||
- `types`: List of allowed service types
|
||||
|
||||
## Query
|
||||
|
||||
The module provides the following query:
|
||||
|
||||
### Params
|
||||
|
||||
Retrieves all parameters of the module.
|
||||
|
||||
## Client
|
||||
|
||||
### gRPC
|
||||
|
||||
The module provides a gRPC Query service 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
|
||||
|
||||
Describe future improvements of this module.
|
||||
- Implement service discovery mechanisms
|
||||
- Add support for service reputation and rating systems
|
||||
- Enhance service metadata with more detailed information
|
||||
- Implement service update and deactivation functionality
|
||||
|
||||
## Tests
|
||||
|
||||
Acceptance tests.
|
||||
(TODO: Add acceptance tests for the module)
|
||||
|
||||
## Appendix
|
||||
|
||||
Supplementary details referenced elsewhere within the spec.
|
||||
his is a module base generated with [`spawn`](https://github.com/rollchains/spawn).
|
||||
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 service ecosystem.
|
||||
|
||||
@ -1 +0,0 @@
|
||||
package types
|
||||
@ -7,6 +7,10 @@ import (
|
||||
|
||||
var _ sdk.Msg = &MsgUpdateParams{}
|
||||
|
||||
// ╭───────────────────────────────────────────────────────────╮
|
||||
// │ MsgUpdateParams type definition │
|
||||
// ╰───────────────────────────────────────────────────────────╯
|
||||
|
||||
// NewMsgUpdateParams creates new instance of MsgUpdateParams
|
||||
func NewMsgUpdateParams(
|
||||
sender sdk.Address,
|
||||
|
||||
@ -4,62 +4,136 @@ The Vault module is responsible for the management of IPFS deployed Decentralize
|
||||
|
||||
## Concepts
|
||||
|
||||
The Vault 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 vault.
|
||||
3. IPFS Integration: The module can interact with IPFS for decentralized data storage.
|
||||
|
||||
## State
|
||||
|
||||
Specify and describe structures expected to marshalled into the store, and their keys
|
||||
The Vault module maintains the following state:
|
||||
|
||||
### Account State
|
||||
### DWN State
|
||||
|
||||
The Account state includes the user's public key, associated wallets, and other identification details. It is stored using the user's DID as the key.
|
||||
The DWN state is stored using the following structure:
|
||||
|
||||
### Credential State
|
||||
```protobuf
|
||||
message DWN {
|
||||
uint64 id = 1;
|
||||
string alias = 2;
|
||||
string cid = 3;
|
||||
string resolver = 4;
|
||||
}
|
||||
```
|
||||
|
||||
The Credential state includes the claims about a subject and is stored using the credential ID as the key.
|
||||
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
|
||||
|
||||
Standard state transition operations triggered by hooks, messages, etc.
|
||||
State transitions in the Vault module are primarily triggered by:
|
||||
|
||||
1. Updating module parameters
|
||||
2. Allocating new vaults
|
||||
3. Syncing DID documents
|
||||
|
||||
## Messages
|
||||
|
||||
Specify message structure(s) and expected state machine behaviour(s).
|
||||
The Vault module defines the following message:
|
||||
|
||||
1. `MsgUpdateParams`: Used to update the module parameters.
|
||||
|
||||
```protobuf
|
||||
message MsgUpdateParams {
|
||||
string authority = 1;
|
||||
Params params = 2;
|
||||
}
|
||||
```
|
||||
|
||||
## Begin Block
|
||||
|
||||
Specify any begin-block operations.
|
||||
No specific begin-block operations are defined for this module.
|
||||
|
||||
## End Block
|
||||
|
||||
Specify any end-block operations.
|
||||
No specific end-block operations are defined for this module.
|
||||
|
||||
## Hooks
|
||||
|
||||
Describe available hooks to be called by/from this module.
|
||||
The Vault module does not define any hooks.
|
||||
|
||||
## Events
|
||||
|
||||
List and describe event tags used.
|
||||
The Vault module does not explicitly define any events. However, standard Cosmos SDK events may be emitted during state transitions.
|
||||
|
||||
## Client
|
||||
|
||||
List and describe CLI commands and gRPC and REST endpoints.
|
||||
The Vault 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 Vault available for claims.
|
||||
4. `Sync`: Queries the DID document by its ID and returns required information.
|
||||
|
||||
## Params
|
||||
|
||||
List all module parameters, their types (in JSON) and identitys.
|
||||
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 vault.
|
||||
|
||||
## Future Improvements
|
||||
|
||||
Describe future improvements of this module.
|
||||
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.
|
||||
Acceptance tests should cover:
|
||||
|
||||
1. Parameter updates
|
||||
2. DWN state management
|
||||
3. Schema queries
|
||||
4. Vault allocation process
|
||||
5. DID document syncing
|
||||
|
||||
## Appendix
|
||||
|
||||
Supplementary details referenced elsewhere within the spec.
|
||||
|
||||
| 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. |
|
||||
|
||||
@ -7,9 +7,9 @@ import (
|
||||
|
||||
var _ sdk.Msg = &MsgUpdateParams{}
|
||||
|
||||
// ╭──────────────────────────────────────────────────────╮
|
||||
// │ MsgUpdateParams │
|
||||
// ╰──────────────────────────────────────────────────────╯
|
||||
// ╭───────────────────────────────────────────────────────────╮
|
||||
// │ MsgUpdateParams type definition │
|
||||
// ╰───────────────────────────────────────────────────────────╯
|
||||
|
||||
// NewMsgUpdateParams creates new instance of MsgUpdateParams
|
||||
func NewMsgUpdateParams(
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user