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 |
|
@Farukest closing PR until we get some clearity on yoir champion and who have you contacted from Foundation. |
github-project-automation
Bot
moved this from Incoming
to Declined
in Dev Fund Incoming
Hi @waynecollier-da, Apologies for the delay. We've spent the last three days heads down on a Pure CIP #204 migration of the SDK plus DAR plus our production mainnet deployment, and I wanted to come back with something concrete instead of a placeholder. We've been tracking the #204 draft as it evolved, mapping the deltas against our own KYC implementation along the way. Your question was the prompt to formalize the migration onto the published surface. Two rounds of work. v2.1.0 picked up the structural #204 shape (joint signatory, Two observations from the production run that might be worth folding into the standards work.1. A starter claim key set for KYC. The KYC Verification Services section of the #204 spec puts the invitation directly:
That is exactly the experiment we have been running. A single reverse-DNS claim key set covered all three vendors with no per vendor reshaping on chain; vendor differences live entirely at the adapter layer. When the Foundation is ready to open the KYC claims CIP the spec anticipates, this is a ready starting point. Happy to draft a small companion CIP with the set and per key rationale if the SIG sees value. 2. An issuer side compliance revoke path. The interface today covers holder initiated archive via The scope question that usually comes up here is whether such a revoke can spill over into credentials other issuers wrote for the same holder. It cannot. CIP #204 already models each credential as a per-(issuer, holder) contract, so an issuer's authority is bounded to records it signed; credentials the same holder carries from other issuers are untouched. Worth either documenting this as a recognised implementer pattern in the rationale, or carrying it as an optional interface in a follow up, so future implementers don't fan out into incompatible shapes. On #169, #171 and #209: read each. None of them changes anything on our SDK surface and we don't have pushback on any. #169 sits cleanly on top of #204 as a separate issuer vocabulary, useful for verifier side rendering. #171 and #209 operate at an identity naming layer above where the credential SDK lives; adopting either is an implementer choice that doesn't change the on-chain credential shape. If either of the first two is worth turning into a PR, happy to open one. |
Hey @Jatinp26, sorry for the late reply. We've been heads down on development and at the same time working Foundation comms channels for an answer to your question, but nothing concrete crystallized fast enough to come back to you sooner. "Canton Foundation" in the original PR was a placeholder, fair catch. My colleague Ufuk was in touch with @hythloda, who pointed us at the SIG directory; I'm working through the Regulatory Compliance and Identity & Metadata SIGs. Would you mind reopening the PR while the champion search is in flight? It would help me push the proposal refresh in parallel. Thanks. |
On this, which comms did u tried, and who have u reached out?
Please don't use a champion in your PR even as a placeholder, falsifying a champion isn't a prefer practice that we encourage and you should just leave it blank, please have SIG review and see if they champion.
Let us know when you were able to find a champion then we can reopen. |
We reached out to @hythloda via email; she pointed us at the SIG directory. The rest is as I mentioned above.
Understood, that was my mistake. I assumed the PR would auto close if the champion field was left empty, so I put a placeholder rather than leave it blank. I won't do that again.
Quick procedural question on this. To put the proposal in front of the SIG so a member can decide whether to champion: should I reach out to specific SIG members through outside channels (email or DM), or is it fine to tag them here on the PR so they see it directly and we continue the conversation in the thread? I've read through the SIG directory and happy to follow whichever route you consider correct. |
3 participants
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 at v0.3.0, a DAML package and DAR at v2.2.0 (Canton.VC.Credentialimplementing the CIP #204Cip204.Standard.Credentialinterface plus the optionalCip204.Factory.CredentialFactoryinterface, a soulboundKycNFTcompanion, andCredential_PublicFetchfor verifier-side disclosure verification), 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 implements the CIP #204 standard verbatim, and this proposal open-sources the vendor-neutral surface 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-complianceCanton.VC.CredentialimplementsCip204.Standard.Credentialverbatim; v2.2.0 also adopts the optionalCip204.Factory.CredentialFactoryinterface for bulk credential refresh.562bbc757d5ec55fba320bf7370588b356811b3f2556817f49098de467758ea4) and shipped the optional factory interface with DAR v2.2.0 on 2026-05-29 (package id16fb51c2e9703cef173c76babd755afca9c7a01e34fc947aebc12205fdf0f719, vetted alongside v2.1.0 for the upgrade window).@canton-vc/*. CI matrix covers typecheck, biome, vitest, and DAML build across Node 20/22 on Linux, macOS, and Windows.scripts/live-{didit,sumsub,persona}-canton-e2e-v2.ts). The 16-phase smoke per vendor exercises every DAML choice includingCredential_PublicFetch,Credential_ArchiveAsHolder,RevokeCredentialwith NFT cascade,CredentialFactory_UpdateCredentials,createKycNft, standaloneBurnNft, and the substitution-guard reject path.