Hi everyone,
As discussed in this week’s SIG Identity and Metadata meeting, I’d like to share two Early Draft proposals for feedback:
We’re discussing this work with the Canton Foundation and some SVs, but those conversations are ongoing; these drafts do not represent agreed positions or endorsements. I’m sharing them here to get broader feedback.
Credentials PR #204 sets out an important goal: a DSO credential registry that wallets and explorers can discover and query. Our proposals retain that goal. Delivering both a DSO Credential Registry and a DSO DID Registry is the required first reference implementation for our project. Adoption of the generic standards, however, does not require use of either DSO registry.
The main architectural change is to distinguish three concerns: the credential itself, its optional registration, and discovery of the service that exposes it.
Credential roles and subjects
PR #204 requires both issuer and holder to be Canton Parties. That does not map cleanly to a W3C credential issued by an organisation outside Canton, particularly when there is no Canton holder. Introducing a stand-in Party risks blurring who actually issued or holds the credential, and that assumption could then spread into application templates, signatories, and issuance workflows.
Our draft keeps the issuer required but permits it to be an external identifier. Non-empty Canton anchorers provide on-ledger signing authority; Canton holders may be empty. Anchoring does not, by itself, verify the external issuer’s proof or claims.
PR #204 also encodes a claim’s subject in keys such as property!subject, defaulting to the holder when the suffix is absent. For example, suppose Alice holds a credential stating that ACME has an active licence: licenseStatus!ACME identifies ACME, whereas bare licenseStatus refers to Alice.
Our draft instead represents ACME as an explicit credential subject carrying the licenseStatus claim. A key-prefix compatibility projection could support applications that rely on the earlier query convention, but that is not currently a delivered feature.
Credential versus registration
PR #204 already distinguishes intrinsic credential validity from registry-record expiry conceptually, but presents them together in a registry-centred CredentialView.
Our draft puts Credential and RegisteredCredential on the same canonical contract as separately projected interfaces. A credential can therefore exist without registration.
Importantly, the credential’s validUntil and the registration’s expiresAt are independent. Extending paid registry retention must not renew the issuer’s claims.
HTTP reads
This interface separation changes the API data model, not just the endpoint names.
Our Credentials OpenAPI separates /v1/credentials from /v1/registered-credentials, with distinct intrinsic and registration responses.
The reference work includes PQS-backed reads of active and archived records.
Discovery
PR #204 proposes publishing registry URLs through a self-published credential claim, starting from published Scan URLs and using ANS/Scan infrastructure.
Our DID draft instead proposes using a DID Document service entry, keeping service discovery separate from credential claims.
DID Documents and service entries follow the W3C DID data model. W3C does not require a DID for every credential, and DID Core does not itself provide an authoritative resolver bootstrap or endpoint-trust policy. Both approaches therefore still need a trustworthy starting point.
Our DID-to-DSO binding and deployment-discovery rules remain open questions.
Current implementation scope
The fork includes separate local Credentials and DID demos.
They exercise selected interfaces and read paths, but they are not yet an integrated DSO deployment.
Paid registration extension, final authorization rules, and production BFT-read rules still need work. Offer / Accept, AddHolder, suspension, resumption, and revocation are not currently delivered operations.
I’d particularly welcome feedback on:
-
whether these boundaries fit existing Canton application patterns;
-
where compatibility with PR #204 or existing applications is most important;
-
whether separating credentials from registration creates any practical integration problems; and
-
what the first DSO reference implementation needs to demonstrate for the standards to be useful and credible.
Thanks — comments on the drafts, implementation, or overall model are all welcome.