Delegated authorization in choice exercise

Questions
1

This question regarding signing made me realize that I am very possibly misunderstanding how authorization is propagated in a Canton setup - specifically the fact that:

A typical transaction will be signed by more than one participant, as it will involve more than one party and those parties may be represented on different participants.

Now say I have a super simple situation where a delegator allows a delegate to act on their behalf - specifically to send some kind of Proposal to third parties. Delegator is in P1, delegate is in P2, and the receiver of the proposal is in P3 (of course all 3 participants within the same domain). Example:

template Delegation
  with
    delegator : Party -- in P1
    delegate : Party   -- in P2
  where
    signatory delegator
    observer delegate

    nonconsuming choice CreateProposal: ContractId Proposal
      with
        receiver : Party -- in P3
      controller delegate
      do
        create Proposal with sender = delegator, ..

template Proposal
  with
    sender: Party
    receiver: Party
  where
    signatory sender
    observer receiver

When the delegate party in P2 issues a CreateProposal to a receiver party in P3, my understanding is that when the transaction is submitted the participant will receive their sequenced share of the transaction. Specifically, both P1 and P2 will “see” the whole exercise (delegate is the controller, delegator is a signer) while P3 will only see a new Proposal “sent” to them (the “create Proposal” action) signed by someone (i.e. delegator in P1) - and will learn nothing about the Delegation contract and the delegate party. What i fail to understand is how the delegator in P1 can sign said transaction, which has been submitted by the delegate in P2, within the same sequencer + mediator round. For P2 it’s easy, because it knows the Delegation contract and therefore can reason about authorization locally, but P3 has no way of knowing that P2 can act on behalf of P1. So what does P3 receive from the sequencer that convinces them that the contract it got has been really signed by P1?

I mistakenly thought that the mediator was sort of “fixing-up” the authorizations because ultimately P1 must have agreed with the creation of the Proposal at some point and the mediator receives that acknowledgement - and since the mediator knows the required confirmers it can somehow pass along the “proof of authorization” to the involved parties. However this clearly is not the case since the mediator confirmation message seem authoritative in the diagrams, i.e. there’s no other chance for the participants to reject the confirmation after it has been issued. Many thanks!

2

Hi @davide_ooz

I think P3 does not need to receive any particular evidence from the sequencer that the contract got signed by P1.

On the Proposal contract, P1 hosts a signatory, so under Canton’s default conformation policy, the mediator will expect a confirmation from P1 on the create action for the proposal. However, like you mentioned, the mediator doesn’t forward the participant confirmations to the recipients; all that P3 gets is a signature from the mediator. In that sense, the mediator is trusted to aggregate the confirmations correctly. If the receiver was also signatory for Proposal then the mediator would also expect a confirmation from P3.

Hope this answers your question.

3

Many thanks @Joao_Sa_Sousa. After some further thinking your answer matches what I expected to happen. On the other hand if I were P3 I would be a lot more comfortable to get a proof that the Proposal contract I received was genuinely signed by P1 rather than trust the mediator attesting that everything followed the protocol - albeit I understand the trust assumption that the domain must be a trusted entity.

I’m wondering how hard it would be for a malicious P2 to craft an ad-hoc bogus transaction with the purpose of making P3 believe there is really a Proposal contract “signed” by P1 - although there is really none (this would not be very useful as P3 won’t be able to do much with that contract, but I see a use case for fraud if P3 is an auditor collecting certain type of contracts). Essentially P2 could omit P1’s view altogether from the submission and required confirmers.

i guess this is taken care by the fact that sequencer and mediator know all confirmers (P1 and P2 in our example), and the appropriate subset of these confirmers is sent “in clear” to P3 with the confirmation request by the sequencer (that would be P1 - because it is a signatory). This way P3 can verify that the mediator “knows” about the signatory P1 and that it will therefore take care of gathering the required confirmation. This is the only way I can imagine P3 can trust what it gets from the sequencer is consistent - i.e. that there isn’t a bogus transaction requiring P1’s authority that the domain does not know it needs to get confirmation from. But that implies the domain knows the confirmers of each subview and not only the per-transaction list - otherwise I still think P2 could cheat?

4

Yes your reasoning is correct. And indeed the domain knows the confirmers of each subview.

5

Understood. Many thanks!