Referring to a Party via the HTTP-JSON API

Questions
1

What validation occurs for Party fields via the JSON API? For example, when we refer to a party “Foo” within some template, assume that “Foo” has no right in that template, does the server verify that “Foo” exists?

1 Like
2

The JSON API inherits the behavior from the underlying ledger here:

  1. The submitting parties have to be allocated on the participant you are submitting two.
  2. Unless you’re working on a ledger that has implicit party allocation enabled (primarily sandbox and atm still daml hub but that will change soon), parties in “significant” fields (signatories, observers, …) have to exist. However, you can have template fields that are not used as signatories, … reference parties that do not exist.
  3. For read requests, there is no validation but you’ll get empty results if the party is not allocated. I believe this is a deliberate decision to avoid slowing down read requests in the common case where you use the correct party.
1 Like
3

I was going to ask:

As Daml demands an implicit setup of Who can do What, can you please explain or even just reference in the Daml Docs, what is the benefit of allowing a non-signatory or non-observer (In your words Significant) party to exist?

However, I think that your Item 3 addresses that. Am I correct?

4

Is the reason to allow this performance, and what are the implication for a later allocations of that party?

Suppose I have a Rating template and I create a rating on Sam. Would a later allocation have the ability to refer to the same Sam ?

1 Like
5

Generally, the ledger treats Daml-LF values as a fairly opaque blob and only looks at fields that you specifically defined to be significant, e.g., via signatories. Daml-LF values are only typechecked and any string (within the format restrictions for parties) is type correct here.

That is useful for performance reasons (no need to traverse the value deeply) and I think it’s also nice from a user perspective: Rather than implicitly picking up all parties somewhere deeply nested in a value, you specify the parties explicitly.

A similar point also applies to contract ids: You can have arbitrary contract ids in a value and they are only validated once you fetch them.

1 Like
6

So in my example of a Rating on “Sam”, “Sam” isn’t a real Party yet. It is just a Daml-LF value that is meant to be a Party but has not been validated by the ledger. What would happen if I then allocate “Sam” as a party, make the payload “Sam” an observer on the Rating and try to fetch as the allocated “Sam”?

7

Having the Party ID is not quite enough to impersonate it, you would also need to have its permission somehow. And all the ways in which you collect permission (signatory, controller) do trigger a verification, so it’s hard for me to imagine a situation where you can have that kind of “latent” Party waiting to be activated.

Can you come up with a sequence of code that demosntrates that?

8

Thinking of parties as user-controlled strings is usually not the right model.

I recommend using the Canton model here where you cannot choose a specific party id.

And even outside of Canton, allocating a party is an admin operation. If you don’t trust your participant operator you have a problem anyway.

1 Like