Canton Party Resolution Protocol - PR by pdomenighetti · Pull Request #171 · canton-foundation/cips

pdomenighetti · 2026-03-06T15:14:09Z

PR from Freename AG

first commit Signed-off-by: Paolo Domenighetti <paolo@freename.io>

initial commit Signed-off-by: Paolo Domenighetti <paolo@freename.io>

formatting Signed-off-by: Paolo Domenighetti <paolo@freename.io>

txt tuning and review Signed-off-by: Paolo Domenighetti <paolo@freename.io>

styling Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Real CIP submission after error in uploading. Signed-off-by: Paolo Domenighetti <paolo@freename.io>

correction after wrong submission Signed-off-by: Paolo Domenighetti <paolo@freename.io>

styling anf formatting fixes Signed-off-by: Paolo Domenighetti <paolo@freename.io>

formatting and styling fixes Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Signed-off-by: Paolo Domenighetti <paolo@freename.io>

meiersi-da

Very nice work @pdomenighetti ! Thank you 🙏

I believe this has the right ingredients, and will result in a great improvement for the ecosystem after a few rounds of polishing. See my comments to drive a first iteration.

Some of the comments hint at scope that we might be able to remove: e.g, encrypted fields. In my experience, keeping scope tight is very valuable to focus our limited attention on the pieces with the highest ROI; and deliver the overall improvement in a timely fashion.

meiersi-da · 2026-03-09T12:04:38Z

cprp-resolution.md

+
+This CIP focuses on the naming and resolution mechanics. Trust evaluation, issuer classification, verification policies, and encrypted metadata are defined in the companion CIP-YYYY (Party Identity Verification).
+
+A shared technical specification accompanies both CIPs: [CPRP-spec.md](./CPRP-spec.md).


Not part of this PRs files. Should it be?

meiersi-da · 2026-03-09T12:15:33Z

cprp-resolution.md

+| `n` | Specific name within the namespace | `default`, `treasury`, `trading-desk-3` |
+
+Examples:
+- `mainnet/dns:goldmansachs.com:default`


Suggested change

- `mainnet/dns:goldmansachs.com:default`

- `party:<canton-party-name-space>:<canton-party-prefix>`

- `mainnet/dns:goldmansachs.com:default`

consider the benefit of injecting the party names in a uniform way into this system as well. This ensures every party has always at least FQPN referring to them.

cool, a built in party resolver would mean every Canton party automatically gets an FQPN like mainnet/party:: with no registration needed (so always resolvable) Would be T4 trust. i'll add it.

consider avoiding the mainnet/ prefix, as parties are not bound to networks. You might use party: without a qualifier or use protocol/party. Or perhaps avoid even stating that as party and just use the Canton concept: uid:, which stands for Universal Identifier, and is cryptic enough so that people don't attach too many unwarranted concepts to it.

i will keep the protocol syntax/composition rules in a separate review session just for complexity in managing reviews. I will proceed like this: answer to comments. apply agreed changes to both CIPs and SPEC not related to protocol syntax then we may iterate specifically on that :)

meiersi-da · 2026-03-09T12:17:49Z

cprp-resolution.md

+| `resolve` | namespace, name | `ResolutionResult` | Forward lookup: name → Party ID + metadata |
+| `reverseResolve` | partyId | `ReverseResolutionResult` | Reverse lookup: Party ID → registered names |
+| `resolveMulti` | queries[] | `ResolutionResult[]` | Batch resolution (latency optimization) |
+| `changelog` | since timestamp | `ChangelogEntry[]` | Credential changes since a given time |


Are these HTTP methods? Can you add references to their specification?

They're logical interface methods. the spec also maps into HTTP endpoints. will make this explicit in the CIP text.

meiersi-da · 2026-03-09T12:21:00Z

cprp-resolution.md

+
+### Profile Rendering Guidelines
+
+Profile claims (`cns-2.0/name`, `cns-2.0/avatar`, `cns-2.0/email`, `cns-2.0/website`) are informational only and MUST NOT be interpreted as verified identity attributes. Verification status is determined exclusively by CIP-YYYY's trust evaluation, not by profile content. Display names SHOULD be ≤64 Unicode characters. Avatars SHOULD be `https://` URLs; applications MAY additionally support `ipfs://` URIs.


The cns-2.0 prefix is not defined. Do you mean the namespace of PixelPlex's CIP? Consider defining the symbolic names for these in a preamble to avoid confusion.

right, this is confusing as written. cns-2.0/* was our working name for the profile claims while PixelPlex is defining in their CIP (PR #169). Will add a preamble to both CIPs when defining namespaces

meiersi-da · 2026-03-09T12:21:34Z

cprp-resolution.md

+- Org-scoped: Corporate LDAP/directory service exposed via the resolver interface
+- Validator-configured: Pre-loaded at the validator level for all apps on that node
+
+Address books provide display names only — they cannot override trust tier or verification status (those come from CIP-YYYY).


What about profile information?

meiersi-da · 2026-03-09T12:59:07Z

cprp-verification.md

+
+Given a `ComposedResolutionResult` from CIP-XXXX's composition engine, the trust evaluator:
+
+1. For each credential in the result, checks on-ledger state (active, archived, expired)


Why not make the composition engine only query for active, unexpired credentials in the first place?

meiersi-da · 2026-03-09T13:00:49Z

cprp-verification.md

+The highest-trust automated verification path for institutions:
+
+1. Party publishes DNS TXT record: `_canton.<domain> TXT "party=<party_id>"`
+2. SV nodes verify the DNSSEC chain and confirm the record exists


Is it required up front to the SV nodes to implement the DNS verification, or could we define the default DNS verification policy to be a quorum of featured resolvers?

meiersi-da · 2026-03-09T13:03:28Z

cprp-verification.md

+
+Supports both Legal Entity vLEI (LE) and Official Organizational Role vLEI (OOR).
+
+### Encrypted Fields


What are two example use-cases for these encrypted fields? Why can these use-cases not be handled via application specific on-ledger communication? e.g., onboarding to a trading app requires the specification of shared parameters for settlement instructions.

meiersi-da · 2026-03-09T13:05:29Z

cprp-verification.md

+### ResolverFeaturedStatus
+
+Records SV-approved featured resolver status. Fields: `resolver_operator` (Party), `resolver_id` (Text), `approved_by` (DSO Party), `approved_date` (Time), `renewal_deadline` (Time), `network` (Text). Choices: `RevokeStatus`, `RenewStatus`.
+
+### CollisionArbitration
+
+Records governance decisions on disputed name mappings between featured resolvers. Fields: `arbitrated_name` (Text), `winning_party_id` (Text), `losing_resolver_id` (Text), `decision_rationale` (Text), `arbitrated_by` (DSO Party). Published as T1 authority.


As on the other CIP: consider how to encode this as a credential in a credential registry; and double-check whether it even needs to be in the DSO registry.

meiersi-da · 2026-03-09T13:06:27Z

cprp-verification.md

+
+Why post-quantum encryption: Canton's institutional users (DTCC, Goldman Sachs, HSBC) hold assets with multi-decade time horizons. ML-KEM-768 provides NIST-standardized post-quantum security for encrypted metadata that may remain sensitive for decades.
+
+Why separate from resolution: Resolution and verification are independently useful and independently evolvable. An explorer resolves without verifying. A compliance tool verifies without resolving (it receives a Party ID directly). Coupling them would force unnecessary dependencies.


"An explorer resolves without verifying." I'm less sure about this. A good explorer might well want to do verification as well to provide better information to its users.

pdomenighetti added 10 commits March 6, 2026 15:29

Create cprp-resolution.md

743395c

first commit Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Create cprp-verification.md

dbdb325

initial commit Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-resolution.md

7544e43

formatting Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-verification.md

47ea550

formatting Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-verification.md

8d90b83

txt tuning and review Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-resolution.md

b022dd1

txt tuning and review Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-resolution.md

4877cc5

styling Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-verification.md

b560fc6

styling Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-resolution.md

fa0667f

styling Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-verification.md

5e0f000

styling Signed-off-by: Paolo Domenighetti <paolo@freename.io>

pdomenighetti requested a review from a team as a code owner March 6, 2026 15:14

pdomenighetti requested review from hythloda, isegall-da, stas-sbi, tkatrichenko and waynecollier-da March 6, 2026 15:14

pdomenighetti added 10 commits March 9, 2026 09:52

Update cprp-resolution.md

0c04f32

Real CIP submission after error in uploading. Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-verification.md

2dbf6e1

correction after wrong submission Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-resolution.md

14eca6c

styling anf formatting fixes Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-verification.md

3891325

formatting and styling fixes Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-verification.md

58a6078

Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-resolution.md

c07c8bf

Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-resolution.md

7e623d6

Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-verification.md

9fdb2c2

Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-resolution.md

4f3291e

Signed-off-by: Paolo Domenighetti <paolo@freename.io>

Update cprp-verification.md

ebfd0be

Signed-off-by: Paolo Domenighetti <paolo@freename.io>

meiersi-da reviewed Mar 9, 2026

View reviewed changes

meiersi-da mentioned this pull request Mar 9, 2026

profile credentials proposal #169

Open


		This CIP focuses on the naming and resolution mechanics. Trust evaluation, issuer classification, verification policies, and encrypted metadata are defined in the companion CIP-YYYY (Party Identity Verification).

		A shared technical specification accompanies both CIPs: [CPRP-spec.md](./CPRP-spec.md).

	- `mainnet/dns:goldmansachs.com:default`
	- `party:<canton-party-name-space>:<canton-party-prefix>`
	- `mainnet/dns:goldmansachs.com:default`


		### Profile Rendering Guidelines

		Profile claims (`cns-2.0/name`, `cns-2.0/avatar`, `cns-2.0/email`, `cns-2.0/website`) are informational only and MUST NOT be interpreted as verified identity attributes. Verification status is determined exclusively by CIP-YYYY's trust evaluation, not by profile content. Display names SHOULD be ≤64 Unicode characters. Avatars SHOULD be `https://` URLs; applications MAY additionally support `ipfs://` URIs.


		Given a `ComposedResolutionResult` from CIP-XXXX's composition engine, the trust evaluator:

		1. For each credential in the result, checks on-ledger state (active, archived, expired)


		Supports both Legal Entity vLEI (LE) and Official Organizational Role vLEI (OOR).

		### Encrypted Fields


		Why post-quantum encryption: Canton's institutional users (DTCC, Goldman Sachs, HSBC) hold assets with multi-decade time horizons. ML-KEM-768 provides NIST-standardized post-quantum security for encrypted metadata that may remain sensitive for decades.

		Why separate from resolution: Resolution and verification are independently useful and independently evolvable. An explorer resolves without verifying. A compliance tool verifies without resolving (it receives a Party ID directly). Coupling them would force unnecessary dependencies.

Conversation

pdomenighetti commented Mar 6, 2026

Uh oh!

meiersi-da left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants