Aramid Secrets — composable Daml credential primitive (Apache 2.0); SIG fit + Tech & Ops champion sought

1. #1cns04-05-2026source ↗
   Hi all,
   
   Posting per Dr. Amanda Martin's suggestion that proposals seeking a
   Tech & Ops champion engage this list first.
   
   I'm Curtis Guider (independent builder, no prior Daml — production
   Cloudflare / Rust / algorithmic-trading / cybersecurity RMF (DoD/DHS) background; completing Daml Fundamentals before M1 starts).

   I'm preparing a Canton Foundation Development Fund proposal for Aramid Secrets — a composable Daml
   primitive for zero-knowledge credential exchange on Canton Network,
   Apache 2.0.
   
   Why posting here, why now:
   
     - M1 acceptance criterion #1 ("end-to-end demonstration on LocalNet:
       create encrypted secret -> deliver to recipient -> burn with proof
       recorded on-chain -> verify proof") already runs end-to-end
       against a real Canton 3.4.11 ledger today — exit 0, both
       assertions pass, reproducible from a pinned cn-quickstart commit
       in roughly 15 minutes.
     - The architecture maps cleanly onto several institutional gaps
       publicly discussed by Super Validators and adjacent working
       groups: BIS Project Agorá's stated goal of reducing redundant
       cross-bank compliance checks via verifiable attestations
       (https://www.bis.org/innovation_hub/projects/agora_faq.pdf);
       Visa Trusted Agent Protocol's agentic delegation; the JPM
       Kinexys / DBS framework for cross-bank tokenized-deposit
       KYC-equivalence; and the FATF Travel Rule envelope. Forward-
       looking roadmap at ROADMAP-POST-M4.md documents these with
       citations; explicitly non-binding.
     - Standards angle: the longer-term move is a CIP for an "Aramid
       Credential Standard" (mirroring CIP-0056's structure for credential
       exchange; complementary, not competing). Want SIG feedback on
       shape and timing.
   
   SIG alignment (per sig-directory.md in canton-foundation/canton-dev-fund):
   
     - Primary: Token Standards / Asset Standards — CIP-0056 + CIP-0047
       token-ecosystem integration is the principal Canton-side surface
     - Cross-references:
       * Daml Language & Developer Tooling — composable DAR, dpm 3.4.11
       * Regulatory Compliance — PQC FIPS-203/204/205 NSA/CISA-2030
         alignment
   
   Ask: 75,000 CC over 16 weeks across four milestones (M1 Daml + CIP-0056
   + LocalNet; M2 x402 + CIP-0047 + DevNet; M3 PQC FIPS-203/204/205;
   M4 MainNet + Featured App). Looking for: (a) technical feedback,
   (b) SIG members willing to discuss the standards shape, (c) a Tech &
   Ops champion to guide milestone definition.
   
   Pointers (repo currently private — read access on request):
   
     - Proposal:
       https://github.com/CryptoNeverSleeps/aramid-zk/blob/main/proposals/aramid-secrets.md
     - Pre-submission technical evidence (live-ledger demo + every
       verified artifact):
       https://github.com/CryptoNeverSleeps/aramid-zk/blob/main/proposals/aramid-secrets.md#pre-submission-technical-evidence
     - Forward-looking roadmap (post-M4, non-binding):
       https://github.com/CryptoNeverSleeps/aramid-zk/blob/main/ROADMAP-POST-M4.md
     - Live demo (the Worker side; classical AES-256-GCM today, PQC is M3):
       https://aramid.support-331.workers.dev
   
   License is Apache 2.0; deliverables become public on milestone
   completion. Repository is operationally private (zero public ports,
   SSH-via-Cloudflare-Tunnel only — NIST CSF posture); read access
   available on request to a prospective champion or Foundation reviewer.
   
   Thank you,
   Curtis Guider

   
   
2. #2Wayne Collier04-05-2026source ↗
   Thanks, Curtis! Looks interesting

    

   For additional background, there's an active collaboration underway to define standards for recording and sharing user credentials on Canton. Here's some background: 
   
   

   1. Data structure and overall architectural approach: https://docs.google.com/document/d/1wsjfsAfEnW_nPJcZ8SsV0PyVsXPgqy2tOoBtyIWulMs/edit?tab=t.0

   2. Party profiles:https://github.com/canton-foundation/cips/pull/169

   3. Address resolvers: https://github.com/canton-foundation/cips/pull/171

   4. Unique issuance and name resolution for Registrars: WIP; should be available soon (Axymos / Dave M draft underway).

    

   In essence these docs will provide a standard data format for metadata associated with partyIDs and assetIDs; a minimum set of attributes for party profiles; a means for importing and resolving party and asset metadata from multiple sources, and a standard way for a registrar to claim a given namespace. It seems like your proposal might fit alongside these.
   
   You may also be interested in joining the identity and metadata Slack channel where these topics are discussed, and join the monthly SIG call. Please reach out to me on Slack for more details.
3. #3Simon Meier05-05-2026source ↗
   BTW: you can find the data structure proposal now also as a PR here: https://github.com/canton-foundation/cips/pull/204