Canton Party Resolution Protocol - PR

[pdomenighetti]

PR from Freename AG

[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]

Not part of this PRs files. Should it be?

[meiersi-da]

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.

[pdomenighetti]

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.

[meiersi-da]

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.

[pdomenighetti]

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]

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

[pdomenighetti]

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

[meiersi-da]

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.

[pdomenighetti]

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]

What about profile information?

[meiersi-da]

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

[meiersi-da]

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]

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]

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]

"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.

[dave-axymos]

Context

In the working group, we’ve spoken about implementing a “DNS/ENS clone”, but it’s worth unpacking that, while these aim to solve the same problem, they are fundamentally different implementations

DNS

Takes a hierarchical approach.

• Governance is centralised but then delegated down.
• e.g. ICANN controls that there should be a TLD called .com
• Verisign as a registry holds the canonical list
• GoDaddy as a registrar is allowed to sell the address
• There are multiple partitioned namespaces (by TLD) but then within those TLDs, registries are free to set their own requirements. E.g. Nominet has no clashes with Verisign as they control difference namespaces

ENS

A centralised authority but decentralised governance via its DAO.

• In theory there are multiple “TLDs” that can be used, but for the large majority of users, they’re focused around a single one (.eth)
• In this approach, the root governance and the registry are basically collapsed into a single layer
• Clashes are resolved not because of partitioning but because multiple parties can register names against a single canonical list, with the on-chain list the source of truth.

the CPRP approach (this CIP)

The Freename CIP put together a comprehensive document about what seems to be a third way — a federated resolution approach.

It may be that the federated model is the best fit for the specific needs of the Canton network, but think that if we do want to create a standard at this juncture, we first need a discussion outlining the pros/cons of each approach:

1. DNS-like
2. ENS-like
3. Freename’s proposal (this CIP)

Adoption of this CIP as-is begs the question that that is the approach that we want to take network-wide, when we haven’t explicitly decided on that.

We think that only after we’ve decided on our “philosophy” to address naming do we think we should get into the level of CIPs.

---

Before getting into more technical feedback, we feel that the core architecture of this CPRP model is comprehensive and has real merit, but that it’s aimed at the wrong problem — multi-resolver consensus would be a fantastic fit for verification and it’s there a lot of their core principles come into their own:

• My dApp only cares about vLEI, so can solely configure a vLEI verification resolver
• My dApp does it’s own off-chain verification so I can use my local address book
• Even if a dApp is configured with lots of resolvers the user doesn’t care about, it’s a tangible problem for non-technical users to understand e.g. the UX flow of using an app like UniSwap and being present with a conflict dialog of “The party ID you’ve entered…”
  • ✅ owns the domain name acme.com
  • ✅ is verified on Companies House
  • ✅ has this vLEI ID: 1234
  • ❌ does not own @acme on Twitter

This is great information to display as additional verification, but it shouldn’t form the backbone of name resolution in our view — naming should be canonical & unambiguous to drive the most user value on the network.

We’d encourage the working group to look again at our higher level goals for a naming standard first before getting to the CIP approval stage.

Technical feedback on this CPRP CIP specifically

In the last meeting, we received feedback that we weren’t engaging with the process, so in the interest of doing so, we wanted to offer feedback on this CIP as it exists today in addition to the reframe above.

If we assume that this federated identity model is the chosen approach for name resolution we have some questions/considerations on the implementation as outlined, such as:

Griefing

The risk of griefing — i.e. a resolver acting in bad faith giving a deliberate divergent resolution to force dApps to display a conflict —  is that the barrier to entry for a permissionless resolver is essentially nil, but then there is an asymmetrical burden placed on dApps or the governance process of resolvers to solve for this.

• By the spec, a dApp then MUST surface this to the user — this feels like it flies in the face of name resolution, since it’s creating ambiguity where we wanted a system to create clarity.
• the CIP mentions a mitigation approach of T4 credentials being rejected by institutional policies (off by default?) — If this is the only safe mitigation though, then I think T4 resolvers should be removed from the spec.

Squatting

Squatting — sitting on in-demand names to extract value — feels like it’s a potentially worse problem than with DNS as the system by design is based on weights.

• We’re baking in the assumption that even with all resolvers operating in good faith, that we may have different resolvers giving different answers to the question “who is alice.canton?”
• This creates a fan-out, where a user needs to claim their name for their party across multiple resolvers so that they don’t hit a potential conflict (since each resolver is maintaining their own internal registry separate to the others)
• For example, I could create a TwitterResolver that says “if you own the twitter handle @alice, you can claim alice.canton.

This would be a perfectly reasonable resolution strategy under the framework but is liable to create a lot of potential conflicts.

Governance

• Different resolvers giving different answers to the question “who is alice.canton?” depends heavily on resolvers acting in good faith but even so, multiple divergent answers to name resolution seems like a “feature, not a bug” of this model.
• Understanding what even constitutes acting in bad faith (and subject to removal) vs what’s the system working as intended is currently a missing piece that’s crucial to understanding how this model would work end-to-end — e.g. addition/removal of featured resolver status, any stake/slash mechanics. That is, we believe that we can’t consider this CIP in isolation without rolling in details of how the governance would work.
• As mentioned re: griefing, with T4 resolvers (but even the featured resolvers, too) there’s a mismatch in the level of effort and “time horizon” of removing a bad actor? E.g. does this move at the speed of standard SV votes?

Registry

A minor one, but the preamble to the CIP under “missing layer” mentions “Digital Asset is building credential formats and a registry” but then it further down mentions a PartyNameRegistration contract

It’s currently unclear how these are meant to interact as a source of truth, if at all. Is this CIP expecting names to be stored via Digital Asset’s registry CIP, via its own contracts or some combination of both?

Ambiguity on names

Even with only good faith actors, there are times that end-users can get a different answer to “who is alice.canton?” depending on…

• Which dApp they’re talking to — e.g. two apps configured with different resolvers (e.g. a local “address book” resolver taking priority)
• One dApp over the course of different usages (e.g. priority mode uses resolver A on query 1 but resolver B on query 2, e.g. in the case of a timeout)
• We feel that name conflicts are something that would be better to solve at registration time, not resolution time — it follows the “principle of least surprise” to the end user in the large majority of cases.

Collision detection is  described as a mitigation, but it’s really more of a recoverable failure mode of the system — in practice, it means pushing the problem back on to the end user at execution time and largely negates the value proposition of a naming system (that non-technical end-users don’t need to interact with the network at the level of hints/fingerprints).

• With “execution time” resolution, I can never be assured that if I give alice.canton to an end-user to send funds that they won’t hit a collision.
• Then I need to:
  1. explain collision detection to every end-user that I want to give my name to (hard for in-person, even worse in an async scenario - including a name in documentation, say)
  2. hope that they acknowledge a collision and don’t pick the wrong address
  3. come back to me to clarify which fingerprint they should be talking to

This undermines the purpose of names within the system to begin with. While other aspects of name resolution (like display metadata) may mitigate this, they don’t solve for it — it’s also a forcing function, meaning that I as a user would have to go through some level of verification or metadata storage to make my name worthwhile.

Some institutional users of the network may wish to make use of heavy verification layers, but in our opinion, name resolution shouldn’t need to rely on metadata or verification for its utility.

Tokenomics

• Is the plan for the registry/resolution mechanisms to be ran as a not-for-profit concern across interested companies? If so, how?
• If not, what is the economic incentive for companies to act as a resolver/registrar?
• If there is a financial incentive for registrations/resolutions, how is that mitigated against the squatting concern?

For example, if it’s in my financial interest to create a lot of resolvers and get end-users to register on each (e.g. TwitterResolver, GithubResolver, LinkedInResolver) — it’s not insurmountable to guard against this, but we need to consider what those guardrails as part of this CIP (or in tandem with it as another CIP)

XNS alternative — Sketch of approach

Our initial go-to-market implementation was:

• As per ENS, a single registry which prevents conflicts at registration time, on-chain. Currently, we (Axymos) are the sole registrar party writing to the registry.
• Each name record is stored on-chain as its own contract. The registrar validates that an existing NameRecord contract doesn’t exist before it creates a new one.
• Activity Markers wired in to both the registry (add new entry) and the NameRecord contracts (extend expiry, transfer, sell).

Our short-term goal for this was to get name resolution live on the network and provide utility as soon as possible, but our vision has always been to have a roadmap to decentralisation so that Axymos are not the sole gatekeeper or custodian of naming on the network.

To extend this process to allow for decentralisation, we have been looking at a model similar to ENS:

• Maintain a single registry on-chain
• A trustless process that can
  • allow for multiple registrars, but against one unpartitioned namespace
  • vote on adding/removing registrars
  • the possibility of adding new TLDs if the group of registrars acting as governance desire e.g. .cc in addition to .canton.

As a sketch of what this process could look like…

1. Decentralization of the registry owner party — either through a multi-sig style set-up or via a multi-hosted party with a quorum of Submitting Party Nodes signing a new addition to the registry.
2. An efficient way to track which names are registered on-chain that can be shared in a trustless way among multiple registrars
   1. Our current working model for our next iteration is having a merkle tree which is stored off-chain, with the root held on-chain
3. On new registration, each of the custodian parties would verify that the name is available in their own off-chain copy of the Merkle tree.
   1. The current root hash would be passed in on choice execution as a nonce to prevent a race condition on multiple registrations crossing over.
4. We are also looking to explore other options —
   1. E.g. we’d mentioned previously in this group around the use of ContractKeys, though it seems like there’s not support for that in the language on Canton.
   2. if we had an adopted CIP in place for NFTs on Canton we could look to use this to manage ownership and transfers, similar to ENS names being granted as literal tokens in the end-user wallet.
   3. We’re looking at the feasibility of a custom Holdings contract piggybacking on the current CIP-56 that enforces a non-divisible asset (or only resolves the name if all tokens are held by one individual)
5. Allow any of the registrars to be the “submitter” of a new registration.
   1. They can be the company that claims end-user fees, minus some shared fee to the group of registrars.
   2. In addition, newly created records are assigned a registrarParty of the company carrying out the registration. This means that the on-chain rewards for activity by the user could come to the registrar who secured the registrant for flows like renewals/sales/transfers.

All of this would need to be fully fleshed out as a CIP proposal if that’s the direction we agree we’re interested to take.

We’re aware that, any CIP would need to address similar points to what we’ve raised above re: the Freename CIP, such as governance over…

• How a company becomes a registrar.
• How companies can raise grievances against bad actors (in this case most likely submitted disputed TXs on chain that other registrars don’t agree with).
• Some type of stake/slash mechanism for this
• Deciding on fee structure (e.g. what level of fees should come to the collective registry (e.g. royalties on sales, including postmarket), weighting of activity marker rewards, since each registrar would need to countersign registrations
• Adding new “TLDs”
• Evolution of the standard.

---

In the interest of expending effort where it will have the most value, we want to answer the question of “what approach is being endorsed as a standard” (if any, at this time) before drafting something more in-depth that may become moot.

If the working group feel that a fuller alternative CIP is needed to compare approaches and move the discussion on we can look into that.

[meiersi-da]

Thanks a lot for the extensive detail in the provided CIPs.

I've done a pass over CPRP-resolution in particular. The ideas look comprehensive, but I have not yet had enough time to engage with them to fully understand how they would work in practice and where their snags are. Looking forward to doing so once the time is available.

[meiersi-da]

How do you distinguish between mainnet/party and devnet/party ? or are these resolvers available in all networks, which is definitely an option.

[meiersi-da]

What is self ? there's no example for that below.

[meiersi-da]

Content makes sense. The paragraph itself comes a bit out of the blue. Could there be some text missing?

[meiersi-da]

What's the argument for not using the address book first for this mode as well?

[meiersi-da]

Unicode has a lot of typo-squatting space, and weird behavior in undefined ranges. Do you know what the latest guidance is for allowing Unicode in names?

[meiersi-da]

Collision management (Section 8) handles this.

That sounds like lots of collisions are bound to happen. What's the argument why that won't be a problem?

[meiersi-da]

Note that assets are identified by

-- | A globally unique identifier for instruments.
data InstrumentId = InstrumentId
  with
    admin : Party
      -- ^ The party representing the registry app that administers the instrument.
    id : Text
      -- ^ The identifier used for the instrument by the instrument admin.
      --
      -- This identifier MUST be unique and unambiguous per instrument admin.
  deriving (Eq, Ord, Show)

see https://github.com/hyperledger-labs/splice/blob/804e7c68cc68135821a96307198d3d77b4c0043b/token-standard/splice-api-token-holding-v1/daml/Splice/Api/Token/HoldingV1.daml#L11-L20

Thus the assets are essential sub-names of the name of the admin party. I wonder though how to best fit them into the current scheme of building FQPNs. Do you have a good idea?

[meiersi-da]

Suggested change

	"cprp/trust-anchor": "T4",
	"cprp/endpoint:token-admin": "https://api.dtcc.com/canton/v1/token-admin",
	"cprp/entity-type": "custodian",
	"cprp/capability": "custody,settlement,issuance",
	"cprp/jurisdiction": "US"
	"cprp/endpoint:token-admin": "https://api.dtcc.com/canton/v1/token-admin",

AFAIS, the URL is the only information required. Can we limit the publication to that one only?

[meiersi-da]

Wow! Thanks for this detail. I have not yet done a detailed pass due to a lack of time.

[meiersi-da]

Let's move grant requests out of the CIP.

That is prone to create confusion.

[meiersi-da]

Thank you @dave-axymos for the detailed and valuable input. It hints at an important distinction in the problem space:

1. how to reliabley/verifably "import" names from existing naming systems (e.g., DNS, LEI, ENS)
2. how to setup the .canton namespace so that it provide maximal value to the network

For the "import" problem, we can define standard verification methods, which in turn then imply that resolvers are expected to agree by default. The CPRP proposal seems to fit this problem quite well. We still do need to look at the concerns you mention like the economic model, avoiding grievances by T4 resolvers, and others.

For the .canton namespace problem, your direction makes sense. Key concerns to address seem to be: governance, economic model, and implementation.

If this decomposition makes sense, then we can actually split the work, and make the best of both worlds, wdyt?

[dave-axymos]

Thank you @dave-axymos for the detailed and valuable input. It hints at an important distinction in the problem space:

1. how to reliabley/verifably "import" names from existing naming systems (e.g., DNS, LEI, ENS)

2. how to setup the `.canton` namespace so that it provide maximal value to the network

For the "import" problem, we can define standard verification methods, which in turn then imply that resolvers are expected to agree by default. The CPRP proposal seems to fit this problem quite well. We still do need to look at the concerns you mention like the economic model, avoiding grievances by T4 resolvers, and others.

For the .canton namespace problem, your direction makes sense. Key concerns to address seem to be: governance, economic model, and implementation.

If this decomposition makes sense, then we can actually split the work, and make the best of both worlds, wdyt?

Hi @meiersi-da, thanks.

I think that distinction makes sense alright, and our "worry" was definitely more around 2) than 1) alright - we can definitely see the value in being able to link external sources of truth as a verification layer ("the party ID you entered tallies with X LLC on Companies House or Y profile on Twitter" etc.)

Thanks
Dave

[dave-axymos]

two small comments here — the example is assuming one good faith bank and one phishing attempt (party::imposter). It could also be two good faith actors having a natural collision.

e.g. both TSB and TSB might legitimately register tsb.canton (and via featured resolvers of the same weight, if they were using different sources).

Or more likely, as a retail end-user, you could have multiple people looking to register dave.canton (where in this case there's less metadata to act as a fallback verification)

[leonidr-c7]

Following up on @dave-axymos and @meiersi-da

I do not understand why we need a uniform resolution proposal. These resolution algorithms, will fundamentally rely on who is issuing a given token and what the consumers of those tokens want with respect to an acceptable trust model. It seems very early to try and standardize how an entire network SHOULD resolve claims.

Wrt to the genera import question.

@meiersi-da I disagree with

For the "import" problem, we can define standard verification methods,

There are very different claims of

1. self-attesting to a DNS entry,
2. a multi signed DNS attestation after a challenge/response.
3. a self-attesting LEI entry.
4. a self-attesting vLEI entry.
5. a multi-sign vLEI entry because an attesting party runs KERI verification
6. a Party that is backed by keys on the KERI node, ie a native IDP integration.

Suggestion.

Can we have a standalone CIP that focuses on creating .canton , I like the idea’s @dave-axymos is describing with XNS and think some things from this one could be repurposed.