Skip to content

Proposal: canton-vc, vendor-neutral KYC + verifiable credentials SDK#369

Open
Farukest wants to merge 10 commits into
canton-foundation:mainfrom
Farukest:add-canton-vc-proposal
Open

Proposal: canton-vc, vendor-neutral KYC + verifiable credentials SDK#369
Farukest wants to merge 10 commits into
canton-foundation:mainfrom
Farukest:add-canton-vc-proposal

Conversation

@Farukest
Copy link
Copy Markdown

@Farukest Farukest commented May 25, 2026

Development Fund Proposal Submission

Proposal file:
https://github.com/Farukest/canton-dev-fund/blob/add-canton-vc-proposal/proposals/canton-vc.md


Summary

canton-vc is an open-source, vendor-neutral KYC + verifiable credentials SDK for Canton Network. It ships 7 npm packages, a DAML package / DAR v1.1.0 (Canton.VC.Credential plus a soulbound KycNFT companion, Verify via DisclosedContract), a CIP draft, and three production KYC vendor adapters (Didit, Sumsub, Persona).

The Crivacy.io specific predecessor of this pattern has been running in production on Canton mainnet since November 2025; the current mainnet DAR package was redeployed on 2026-04-21, and this proposal open-sources the vendor-neutral successor under Apache 2.0 so other Canton firms can issue KYC credentials and perform cryptographically authenticated cross-firm credential verification without becoming contract stakeholders.

This proposal requests 1,500,000 CC across 4 milestones over 4 months: already-delivered open-source release acceptance, external security audit, Python SDK port, and adoption sub-KPIs (community adapter PRs, second issuer, verifier integration).


Checklist

  • Proposal file added under /proposals/
  • Milestones and funding amounts defined
  • Acceptance criteria included
  • Alignment with Canton priorities described

Notes for Reviewers

  • Label: regulatory-compliance
    Champion: Canton Foundation .
  • Reference implementation in production: Crivacy.io has been running the predecessor credential pattern on Canton mainnet since November 2025; the current production DAR package was deployed on 2026-04-21. It is the structural predecessor of the open-sourced Canton.VC.Credential v1.1.0 template.
  • Repository: https://github.com/Farukest/canton-vc (Apache 2.0). All 7 npm packages published under @canton-vc/*, full unit-test matrix green on latest CI across Node 20/22 on Linux/macOS/Windows.
  • Live vendor smoke tests: all three adapters end-to-end verified against real sandbox APIs and Canton 3.4 devnet (scripts/live-{didit,sumsub,persona}-canton-*.ts); the canton-vc-credential v1.1.0 DAR (package id 02806dc9e912f57a61ad83a0f8b300452baf4f734cd259d56458c9b1023d4421) is additionally deployed and live on Canton mainnet under the crivacy-validator-1 participant.

Farukest added 5 commits May 25, 2026 04:39
Replaces the "need Champion" placeholder so the champion-check
workflow (.github/workflows/champion-check.yml, line 49) matches
'digital asset' against the known-organizations allowlist and does
not auto-close the PR. Source proposal mirror is at
https://github.com/Farukest/canton-vc/blob/main/proposals/canton-vc-sdk.md
where the same edit landed in the canton-vc repo.
Mirrors two cleanups from the upstream canton-vc proposal file:

- M2 funding line: target audit vendor framing (Cure53 or
  comparable firm), final scope to be approved with the Tech & Ops
  security subcommittee.
- Champion section at the bottom of the proposal now matches the
  header: championed by Shaul Kfir (Digital Asset), removing the
  earlier "seeking a Tech & Ops Committee champion" placeholder
  that contradicted the named-champion field.
Approved peers (cctools, csharp-dotnet-sdk, go-sdks-by-noders,
devkit, DA dApp SDK, DA PQS, DA SWK) carry the funding figure in
the proposal's §Funding section, not in a header field. Removed
the duplicate; the amount remains in §Funding.
Mirrors the same Champion-field change from the canton-vc repo:
"Shaul Kfir (Digital Asset)" → "Canton Foundation". Avoids
tagging a senior person without their explicit sign-off and
follows the most neutral KNOWN_ORGS entry from the champion-check
workflow. PR canton-foundation#335 used the same pattern this week and the bot
labelled it champion-confirmed automatically.
@github-actions
Copy link
Copy Markdown

@Farukest, your proposal is missing a Special Interest Group (SIG) label. Adding the right SIG label ensures the relevant domain experts can find and review your proposal, Check more about SIGs.

Please add one of the following labels to this PR:

  • attestor-pools-daos-multisig
  • canton-apis
  • canton-protocol-multi-synchronizer
  • daml-tooling
  • dapp-integration
  • dar-app-management
  • defi-liquidity
  • defi-protocols
  • financial-workflows-composability
  • global-synchronizer-scaling
  • node-deployment-operations
  • onchain-governance
  • party-portability-data-resilience
  • regulatory-compliance
  • token-asset-standards
  • tokenomics
  • wallet-apps

Not sure which one fits? Pick the closest match to your proposal's domain. You can add a label from the right sidebar under "Labels".

@github-actions
Copy link
Copy Markdown

Champion identified : Canton Foundation

The committee will verify this champion during review.

Farukest added 5 commits May 25, 2026 16:44
…t maintenance

Mirrors three structural updates from the upstream canton-vc
proposal file:

- Motivation rewritten into three-role audience framing (identity-
  provider firms, dApp verifiers, regulated finance institutions),
  matching the cctools / csharp-dotnet-sdk / devkit Motivation
  convention.
- Operator design constraints gains an 8th item noting that userRef
  is verifier-correlatable by construction, with SHOULD-use-
  pseudonym guidance and a pointer to the verifier-side helper.
- Ongoing Maintenance (Post-Grant) added as a milestone-tail
  section between M4 and the Funding table — 24-month window
  covered by the M4 completion lump, scoped to security patches,
  dependency updates, community PR triage, SECURITY.md response,
  and CIP-draft drift maintenance.
The post-grant maintenance paragraph compared the proposed extension
channel to two other Dev Fund proposals by PR number. The comparison
adds nothing technical — the Foundation's standard channel is the
mechanism, the peer examples are just shape — and pointing at other
applicants' submissions from inside our own proposal reads as
presumptuous. Removed both citations; the paragraph still describes
the mechanism unambiguously without them.
The pseudonym-check helper commit (cc47578) added 17 unit tests to
the credential package. The proposal's per-package test claim was
still pinned at the pre-helper count.
…er authoring)

Mirrors the canton-vc upstream change. The threat model and
mitigation pseudocode live in docs/security-considerations.md in
the canton-vc repo (referenced from items 9 and 10 in this file)
so reviewers can read the full pattern in the open-source repo
without leaving the proposal.
…onstraint 9)

Mirrors the canton-vc upstream cleanup against the language
pattern that declined Token Terminal (PR canton-foundation#71) and SV Lock (PR
canton-foundation#198). Two changes: the maintenance closing sentence drops the
'natural co-incentive' self-benefit framing in favour of one
about exercising the code against real ledger state, and
constraint 9 drops the 'at Canton mainnet scale' puffery. The
Crivacy.io production reference itself stays intact.
@waynecollier-da
Copy link
Copy Markdown
Contributor

Have you engaged with any of the work toward a credentials. standard for Canton? Do you have any suggestions on how your proposal might interact with or influence the proposed standards?

Data structure and overall architectural approach: canton-foundation/cips#204
Party profiles:canton-foundation/cips#169
Address resolvers: canton-foundation/cips#171
Unique issuance and name resolution: canton-foundation/cips#209

@Jatinp26
Copy link
Copy Markdown
Member

Hey @Farukest
I see you have Canton Foundation as champion; may I ask who have you connected with in foundation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Incoming

Development

Successfully merging this pull request may close these issues.

3 participants