Files
sonr/x/svc
40eadc995e Feat/1285 es ucan formatting (#1302)
* feat: Add Enclave Usage Examples

* feat(es/ucan): Add comprehensive integration tests

- Create integration.test.ts with full UCAN token lifecycle testing
- Cover end-to-end token creation, parsing, and validation
- Test capability attenuation and delegation chains
- Validate multi-algorithm support and timestamp scenarios
- Implement error recovery and performance test scenarios

🤖 Generated with Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>

* No commit suggestions generated

* No commit suggestions generated

* chore: Remove migrated components and add migration documentation

Removed all code and references for components that have been moved to separate repositories:

**Moved to sonr-io/hway:**
- bridge/ - HTTP service with OAuth2/OIDC/WebAuthn handlers
- cmd/hway/ - Highway service binary
- internal/migrations/ - PostgreSQL schema migrations

**Moved to sonr-io/motr:**
- cmd/motr/ - Motor worker service (WASM vault operations)
- cmd/vault/ - Vault CLI tool
- crypto/ - Comprehensive cryptographic library
- packages/ - TypeScript SDK packages (es, sdk, ui, com, pkl)
- web/auth/ - Authentication web application
- web/dash/ - Dashboard web application

**Updated Configuration:**
- Makefile: Removed build/test/release targets for moved components
- CLAUDE.md: Simplified to focus on core blockchain components
- devbox.json: Removed scripts for moved services
- docker-compose.yml: Removed hway, postgres, redis, auth, dash services
- .github/scopes.yml: Removed CI scopes for migrated components
- .goreleaser.yml: Updated release configuration

**Added Migration Documentation:**
- MIGRATE_HWAY.md: Comprehensive Highway service architecture and migration guide
- MIGRATE_MOTR.md: Comprehensive Motor/Worker/Vault architecture and migration guide

These migration documents provide complete context for setting up the new repositories including architecture diagrams, component breakdowns, API documentation, and migration checklists.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* No commit suggestions generated

* chore: Remove contracts references and documentation

Removed all references to the contracts directory that was migrated to a separate repository.

**Changes:**
- .gitignore: Removed contract-specific ignore patterns for DAO and wSNR contracts
- .gitignore: Removed hway and motr binary references (already migrated)
- .rgignore: Removed contracts, chains, and crypto directory references
- docs/reference/contracts/: Removed DAO.mdx and wSNR.mdx documentation files

This completes the cleanup of migrated components from the repository.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* docs: add crypto library migration documentation

Added comprehensive migration documentation for the crypto library that was
moved to sonr-io/crypto repository. This documentation provides complete context
for understanding the cryptographic primitives and protocols used throughout
the Sonr ecosystem.

## Key Documentation Added

### MIGRATE_CRYPTO.md
Complete documentation of the crypto library covering:

**Core Cryptographic Primitives**
- Elliptic curve implementations (Ed25519, Secp256k1, P-256, BLS12-381, Pallas/Vesta)
- Native curve arithmetic with optimized field operations
- Pairing-friendly curves for BLS signatures

**Multi-Party Computation (MPC)**
- MPC enclave for vault key generation and management
- Threshold cryptography (TECDSA, TED25519 with FROST protocol)
- Distributed Key Generation (DKG) via Gennaro and FROST protocols
- Secret sharing schemes (Shamir, Feldman VSS, Pedersen VSS)

**Digital Signature Schemes**
- BLS signatures with aggregation support
- BBS+ signatures for selective disclosure
- Schnorr signatures (standard and Mina/NEM variants)
- ECDSA with deterministic nonce generation

**Zero-Knowledge Proofs**
- Bulletproofs for range proofs
- Inner Product Arguments (IPA)
- Batch verification support

**Advanced Cryptographic Protocols**
- Cryptographic accumulators for set membership proofs
- Paillier homomorphic encryption
- Oblivious Transfer (OT) protocols
- Verifiable Random Functions (VRF)

**Key Management & Identity**
- DID key management with multi-chain support
- Multi-algorithm public key handling
- Wallet address derivation (Bitcoin, Ethereum, Cosmos, Solana, etc.)

**UCAN Integration**
- User-Controlled Authorization Networks
- Capability delegation and attenuation
- JWT-based capability tokens
- MPC-enabled UCAN signing

**Security Utilities**
- AEAD encryption (AES-GCM, AES-SIV)
- Argon2 key derivation
- ECIES encryption
- Secure memory handling

### MIGRATE_MOTR.md Updates
Updated Motor migration documentation to clarify that the crypto library
is now a separate external dependency at github.com/sonr-io/crypto v1.0.1

## Repository Context

The crypto library has been successfully migrated to its own repository
and is published as a Go module. It serves as the foundational cryptographic
layer for:
- Sonr blockchain (snrd) - DID signatures, vault operations
- Highway service (hway) - UCAN token signing, WebAuthn
- Motor/Worker (motr) - MPC vault operations, threshold signatures

## Integration Impact

All Sonr ecosystem components now depend on the external crypto library:
```go
require github.com/sonr-io/crypto v1.0.1
```

The migration enables independent versioning and maintenance of cryptographic
primitives while maintaining security and compatibility across the ecosystem.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* No commit suggestions generated

* No commit suggestions generated

* No commit suggestions generated

---------

Co-authored-by: Claude <noreply@anthropic.com>
2025-10-10 11:47:18 -04:00
..
2025-10-03 14:45:52 -04:00
2025-10-03 14:45:52 -04:00
2025-10-03 14:45:52 -04:00
2025-10-03 14:45:52 -04:00
2025-10-03 14:45:52 -04:00

x/svc

The Service (SVC) module manages the registration and operation of decentralized services within the Sonr ecosystem. It provides a comprehensive framework for services to register with verified domains, define their permission requirements, and integrate with the broader Sonr authorization system through UCAN capabilities.

Overview

The SVC module provides:

  • Domain Verification: DNS-based domain ownership verification
  • Service Registration: Register services with verified domains
  • Permission Management: Define and request specific UCAN permissions
  • Service Discovery: Query services by owner, domain, or ID
  • Capability Integration: Seamless integration with the UCAN module

Core Concepts

Domain Verification

Services must verify ownership of their domain through DNS TXT records before registration. This ensures that only legitimate domain owners can register services.

Service Registration

Once domain ownership is verified, services can be registered with:

  • Unique service ID
  • Verified domain binding
  • Requested permissions (UCAN capabilities)
  • Service metadata (name, description)

Permission Model

Services request specific permissions during registration, which are granted as UCAN capabilities. These permissions define what actions the service can perform on behalf of users.

Service Identity

Each service has a unique identity composed of:

  • Service ID (chosen identifier)
  • Domain (verified TLD)
  • Owner (blockchain address)

State

Domain Verification

message DomainVerification {
  string domain = 1;                 // Domain being verified
  string owner = 2;                  // Address initiating verification
  string token = 3;                  // Verification token
  VerificationStatus status = 4;     // Pending, Verified, Failed
  int64 initiated_at = 5;           // Timestamp
  int64 expires_at = 6;             // Token expiration
}

Service

message Service {
  string service_id = 1;            // Unique service identifier
  string domain = 2;                // Verified domain
  string owner = 3;                 // Service owner address
  string name = 4;                  // Human-readable name
  string description = 5;           // Service description
  repeated string permissions = 6;   // Requested permissions
  string ucan_delegation_chain = 7; // UCAN authorization
  int64 created_at = 8;            // Creation timestamp
  int64 updated_at = 9;            // Last update timestamp
}

Messages

Domain Verification

MsgInitiateDomainVerification

Initiates domain verification by generating a DNS TXT record token.

message MsgInitiateDomainVerification {
  string owner = 1;
  string domain = 2;
}

MsgVerifyDomain

Verifies domain ownership by checking DNS TXT records.

message MsgVerifyDomain {
  string owner = 1;
  string domain = 2;
}

Service Management

MsgRegisterService

Registers a new service with a verified domain.

message MsgRegisterService {
  string owner = 1;
  string service_id = 2;
  string domain = 3;
  string name = 4;
  string description = 5;
  repeated string requested_permissions = 6;
  string ucan_delegation_chain = 7;  // Optional UCAN authorization
}

Governance

MsgUpdateParams

Updates module parameters (governance only).

message MsgUpdateParams {
  string authority = 1;
  Params params = 2;
}

Queries

Domain Queries

  • DomainVerification: Check domain verification status

Service Queries

  • Service: Get a specific service by ID
  • ServicesByOwner: List all services owned by an address
  • ServicesByDomain: List all services for a domain

Module Queries

  • Params: Get module parameters

CLI Examples

Domain Verification

# Initiate domain verification
snrd tx svc initiate-domain-verification example.com --from alice

# Check verification status
snrd query svc domain-verification example.com

# The system will provide a token like: sonr-verification=abc123xyz
# Add this as a TXT record to your domain's DNS

# Verify domain after DNS propagation
snrd tx svc verify-domain example.com --from alice

Service Registration

# Register a service with basic permissions
snrd tx svc register-service my-app example.com \
  dwn:read,dwn:write,identity:read \
  --from alice

# Register with UCAN delegation
snrd tx svc register-service vault-service vault.example.com \
  vault:access,identity:read \
  --ucan-delegation-chain="<jwt-token>" \
  --from alice

# Query service
snrd query svc service my-app

# Query services by owner
snrd query svc services-by-owner $(snrd keys show alice -a)

# Query services by domain
snrd query svc services-by-domain example.com

Integration Guide

For Service Developers

  1. Domain Setup:

    • Register your domain with a DNS provider
    • Ensure you have access to manage DNS TXT records
    • Choose a unique service ID
  2. Verification Process:

    # Step 1: Initiate verification
    snrd tx svc initiate-domain-verification your-domain.com --from your-key
    
    # Step 2: Add TXT record to DNS
    # Record: sonr-verification=<provided-token>
    
    # Step 3: Wait for DNS propagation (usually 5-30 minutes)
    
    # Step 4: Complete verification
    snrd tx svc verify-domain your-domain.com --from your-key
    
  3. Service Registration:

    • Define required permissions carefully
    • Use descriptive service names and descriptions
    • Consider permission scope and user privacy
  4. Permission Planning: Common permission patterns:

    • dwn:read,dwn:write - Basic data access
    • identity:read - Read user identity
    • vault:access - Vault operations
    • credentials:verify - Verify credentials

For Application Integrators

  1. Service Discovery:

    # Find services by domain
    snrd query svc services-by-domain app.example.com
    
    # Get service details
    snrd query svc service service-id
    
  2. Permission Verification:

    • Check service permissions before integration
    • Validate UCAN delegation chains
    • Ensure permissions match your requirements
  3. User Authorization Flow:

    • Service requests permissions from user
    • User reviews and approves via wallet
    • Service receives UCAN capability
    • Service can act on user's behalf

Domain Verification Process

DNS TXT Record Format

sonr-verification=<token>

Verification Requirements

  • Domain must be a valid TLD
  • DNS TXT record must match the generated token
  • Verification expires after 7 days if not completed
  • Each domain can only be verified by one owner

Example DNS Configuration

# For domain: app.example.com
# Add TXT record:
Type: TXT
Name: @ (or app if subdomain)
Value: sonr-verification=1234567890abcdef
TTL: 300 (5 minutes)

Security Considerations

  1. Domain Ownership: Only verified domain owners can register services
  2. Permission Scope: Services can only request, not grant permissions
  3. UCAN Validation: All capability chains are validated
  4. Unique Domains: Each domain can only have one owner
  5. Service Isolation: Services cannot access data from other services

Module Parameters

  • verification_timeout: Domain verification timeout (default: 7 days)
  • max_services_per_owner: Maximum services per owner (default: 100)
  • allowed_permissions: List of permissions services can request
  • service_registration_fee: Fee for service registration (default: 1000usnr)

Events

The module emits the following events:

  • domain_verification_initiated: When verification starts
    • domain, owner, token, expires_at
  • domain_verified: When domain is successfully verified
    • domain, owner, verified_at
  • service_registered: When a new service is registered
    • service_id, domain, owner, permissions
  • service_updated: When service is updated
    • service_id, fields_updated

Building and Testing

Running Tests

# Run unit tests
make -C x/svc test

# Run tests with race detection
make -C x/svc test-race

# Generate coverage report
make -C x/svc test-cover

# Run benchmarks
make -C x/svc benchmark

Best Practices

For Service Developers

  1. Choose Meaningful IDs: Use descriptive service IDs that reflect your service
  2. Request Minimal Permissions: Only request what you need
  3. Document Permissions: Clearly explain why each permission is needed
  4. Plan for Updates: Design your permission model for future growth
  5. Monitor Expiration: Keep track of UCAN expiration times

For Users

  1. Verify Services: Check domain ownership before granting permissions
  2. Review Permissions: Understand what each permission allows
  3. Regular Audits: Review granted permissions periodically
  4. Revoke When Needed: Remove permissions from unused services

Future Enhancements

  • Service Categories: Categorization for better discovery
  • Reputation System: User ratings and reviews
  • Permission Templates: Pre-defined permission sets
  • Multi-sig Ownership: Support for team-owned services
  • Service Analytics: Usage statistics and monitoring
  • Subdomain Support: Hierarchical service structures