readAs delegation

Subject: Clarification on readAs Across Participants and the Role of Party Replication

Hi Canton Team,

I would appreciate some clarification regarding readAs authorization across participants.

From my reading of the Canton documentation, my understanding is the following:

1. A participant can only act on behalf of parties that it hosts.

2. A party may be hosted on multiple participants using party replication.

3. Hosting a party with Submission permission makes the participant a Submitting Participant Node (SPN) for that party.

4. SPNs are trusted to authorize and submit transactions on behalf of the party.

Given that understanding, I would like to confirm whether the following conclusions are correct.

Scenario

Assume:

• Party A is hosted on Participant A.

• Party B is hosted only on Participant B.

My understanding is that Participant A cannot submit a command using:

actAs = [PartyA]
readAs = [PartyB]

because Participant A does not host Party B. Is that correct?

Party Replication

If Party B is replicated onto Participant A, I would like to understand the implications.

1. Is party replication the recommended approach when a participant needs to submit commands that require readAs access to a party that is primarily hosted elsewhere?

2. If Party B is replicated onto Participant A with Submission permission, can Participant A then successfully submit commands using readAs = PartyB?

3. Does readAs require the participant to host the party with Submission permission specifically, or would Observation or Confirmation hosting be sufficient?

The documentation explains that a party entrusts its SPNs to authorize transactions on its behalf.

Because of that, I would like to clarify the security implications of using party replication for this purpose.

1. If Party B is replicated to Participant A with Submission permission, is it correct to think of this as Party B explicitly trusting Participant A to act on its behalf?

2. Would using party replication solely to enable readAs be considered a normal architectural pattern, or is it generally discouraged because it broadens the trust boundary?

3. Is there a recommended alternative for enabling cross-participant read access without granting submission authority for the replicated party?

4. If the goal is only to satisfy readAs requirements, would Observation hosting be sufficient, or is Submission hosting required by the Ledger API authorization model?

5. Are there any roadmap items or planned features that would allow cross-participant delegation of readAs rights without requiring party replication?

My primary goal is to understand whether party replication is the intended solution for cross-participant readAs scenarios, and if so, what the recommended permission model and trust assumptions should be.

Thanks