Version: 2.3 (Glossary at the end)

Smart Data Scheme Architecture Diagram

1) Purpose

The Dataswyft Wallet runs on a self-owned server (individual or individual with authority of an organization) so data is portable without pre-integrating with every relying party’s systems. This document defines the architecture and lifecycle of Smart Data Schemes (SDS) implemented by Dataswyft on the Dataswyft Network with Dataswyft Wallets (Service Layer above HAT Microservers), Data Gateways, and SDS Packs. All Smart Data Schemes on the Dataswyft Network are registered with the HAT Community Foundation, which oversees the network.

2) Role Model (Participants in SDS)

• Scheme Authority (SA): Authors, versions, and registers SDS Packs; curates trust anchors and dispute processes.
• HAT Community Foundation as Network Registry & Trust Services: Discovery of SDS Packs, templates, accreditation lists, revocation registries, and template status/versioning.
• Scheme Administrator: Onboard all parties to their roles
• Wallet User: Any individual operating their own Dataswyft Wallet. The Wallet is a service orchestration layer above a single HAT Microserver. Each HAT may contain multiple Data Profiles (each tied to a Data Profile Provider), but the Wallet User themselves is distinct from the Data Profile Providers. There is no concept of an “organization wallet”; organizations appear only as Data Profile Providers whose data describes roles and authorities of individual Wallet Users.
• Data Profile Provider: A legal entity that owns upstream data and provides it into Wallets through APIs (via the Data Gateway). They are not Wallet Users but are formal participants in the SDS. They dictate Data Use Rules, including:
  • Which proof templates their data may be used with.
  • Which Validators/receivers may receive proofs containing their data.
  • In some cases, an organization Provider specifies the role and authority of the Wallet User within that organization.
• Issuer (Wallet User role): Publishes Proof/Badge Templates & Rules from within their Wallet, choosing from standard templates and pre-existing SDS Packs. Issuers may select which fields (from one or more Data Profiles) are required as evidence for a claim, but must comply with Provider Data Use Rules.
• Holder (Wallet User role): Claims a proof/badge by composing evidence from one or more Data Profiles in their Wallet, per Issuer template and Provider rules. Holder approves each proof claimed/presented.
• Validator (Wallet User role): Requests and validates presented proofs/badges. Validates crypto, template version pinning, revocation, and checks that Provider and SDS rules are satisfied.
• Data Verifier (Wallet User role, optional): Reviews and verifies Holder-submitted data where:
  • A Data Profile Provider does not exist for the data type; or
  • Additional verification is required (e.g., certifications, attestations). Issues a verification record that is stored in the Holder’s Data Profile inside their HAT. Verifiers do not publish templates or validate proofs; they strengthen or create Data Profiles through pre-validation at the data level.

Policy resolution is the intersection: Provider Data Use Rules ∩ Holder approval/license (at proof level) ∩ Issuer Template Rules ∩ SDS Policy.

Note: On-ramp uses Data Subject Access/Portability (not consent) because data is copied into the Wallet User’s self-owned HAT.

3) Technical Components

3.1 Dataswyft Wallet (Service Layer above HATs)

• Service orchestration layer that sits above the HAT Microserver owned by the Wallet User.