Pull Request: Credential Sharing Contract

[Wilfred007]

Summary
Extends the existing DataSharing Soroban smart contract with a full-featured credential sharing system for health credentials. Adds granular permission levels (View, Download, Re-share), time-limited access with expiry, revocation with audit trail, and on-chain event tracking for all sharing operations.
Changes
New Types (types.rs)

• SharingPermission enum: View (read-only status verification), Download (full credential access), ReShare (can share with others)
• CredentialShareEvent struct: captures share_id, owner, recipient, permission, action, and timestamp for audit events
  New Error Variants (errors.rs)
• PermissionDenied (21) - returned when a share holder lacks sufficient permission for an operation
• ShareExpired (22) - returned when attempting operations on an expired share
• CannotReShare (23) - returned when a non-ReShare holder attempts to re-share
  Storage Layer (storage.rs)
• SharingDataKey enum with persistent storage keys: ShareCounter, ShareRecord(u64), ShareByOwner(Address), ShareByRecipient(Address)
  Event Emission (events.rs)
• emit_credential_share_event() - publishes on-chain events for share/revoke/extend/re-share operations with owner, share ID, and full event payload
  Contract Functions (data_sharing.rs)
• share_credential(owner, recipient, credential_hash, encrypted_key, permission, duration_seconds) -> u64 - creates a time-limited credential share with specified permission level, emits event, populates owner/recipient indices
• check_credential_access(grantee, credential_hash) -> bool - verifies if a grantee has active, non-expired access to a credential by scanning recipient index
• get_credential_share(share_id) -> CredentialShare - retrieves full share details including permission, expiry, and revocation status
• get_shares_by_owner(owner) -> Vec - lists all share IDs created by an owner
• get_shares_by_recipient(recipient) -> Vec - lists all share IDs received by a recipient
• revoke_credential_share(share_id, reason) -> Result<(), Error> - soft-deletes a share with reason and timestamp for audit, emits revocation event
• extend_credential_share(share_id, additional_seconds) -> Result<(), Error> - extends share expiry, emits extension event
• re_share_credential(share_id, new_recipient, new_permission, duration_seconds) -> Result<u64, Error> - creates a new share from an existing ReShare holder, enforces permission check and recipient authorization
  Data Model (CredentialShare struct)
  owner, recipient, credential_hash, encrypted_key,
  permission, access_expiry, is_active, shared_at,
  revoked_at, revocation_reason
  Storage Pattern
  Uses persistent storage with TTL management (matching verification.rs pattern):
• Counter in instance storage
• Per-share records in persistent storage with bump_persistent() TTL extension
• Owner/recipient indices for efficient party-based lookups
  Testing
  117 tests passing (13 new credential sharing tests):
  Happy Path (7 tests)
• test_share_credential_and_retrieve - share creation and full data retrieval
• test_check_credential_access_active - access verification for active shares
• test_check_credential_access_denied_for_unknown - no access for unregistered parties
• test_revoke_credential_share - revocation disables access and preserves reason
• test_extend_credential_share - extension grants additional time window
• test_share_credential_expires - expired shares deny access
• test_re_share_credential - ReShare permission creates independent sub-shares
  Edge Cases (6 tests)
• test_re_share_denied_without_permission - View/Download holders cannot re-share
• test_revoke_expired_share - revoking expired shares still records reason
• test_get_shares_by_owner_and_recipient - index queries return correct counts
• test_get_nonexistent_credential_share_panics - invalid ID panics
• test_revoke_nonexistent_credential_share_panics - invalid ID panics
• test_re_share_credential - third party receives View access via ReShare chain
  Auth Rules
• share_credential: owner must authorize
• revoke_credential_share: owner must authorize
• extend_credential_share: owner must authorize
• re_share_credential: current recipient must authorize (only if permission == ReShare)
• Read functions: no auth required
  Tradeoffs
• Index writes on share creation: Each share_credential and re_share_credential call appends to two persistent storage indices (owner, recipient). This increases gas cost per share creation but enables O(1) party-based lookups. The alternative (scan all shares) would be prohibitively expensive for large share volumes.
• Persistent vs instance storage: New credential sharing uses persistent storage with TTL (matching verification.rs), while legacy SharedData remains in instance storage. This adds a migration consideration if the old sharing API is ever deprecated.
• ReShare cascading: Re-shared shares are independent records with their own expiry. A re-share does not inherit the original share's TTL - the original holder controls the new share's duration. This prevents cascading expiry issues but means revoking the original share does not automatically revoke re-shares.
• Event emission overhead: Every mutation emits an on-chain event. This increases transaction cost but provides a complete audit trail required for health credential compliance.
  Out of Scope
• Frontend integration for the new credential sharing API
• Backend API endpoints for credential sharing (existing data-sharing NestJS module handles this)
• Migration of legacy SharedData shares to the new CredentialShare format
• Batch sharing (sharing with multiple recipients in one transaction)

Closes #88

[vercel]

@Akatenvictor is attempting to deploy a commit to the Josie's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Josie123-Dev]

Kindly check failing ci checks @Wilfred007

[Wilfred007]

Kindly check failing ci checks @Wilfred007

Okay, I'm on it

[Wilfred007]

Kindly confirm ci check pass @Josie123-Dev