Proposal: canton-vc, vendor-neutral KYC + verifiable credentials SDK#369
Proposal: canton-vc, vendor-neutral KYC + verifiable credentials SDK#369Farukest wants to merge 10 commits into
Conversation
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.
|
@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:
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". |
…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.
|
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 |
|
Hey @Farukest |
Development Fund Proposal Submission
Proposal file:
https://github.com/Farukest/canton-dev-fund/blob/add-canton-vc-proposal/proposals/canton-vc.md
Summary
canton-vcis 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.Credentialplus a soulboundKycNFTcompanion,VerifyviaDisclosedContract), 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
/proposals/Notes for Reviewers
regulatory-complianceChampion: Canton Foundation .
Canton.VC.Credentialv1.1.0 template.@canton-vc/*, full unit-test matrix green on latest CI across Node 20/22 on Linux/macOS/Windows.scripts/live-{didit,sumsub,persona}-canton-*.ts); the canton-vc-credential v1.1.0 DAR (package id02806dc9e912f57a61ad83a0f8b300452baf4f734cd259d56458c9b1023d4421) is additionally deployed and live on Canton mainnet under the crivacy-validator-1 participant.