Returns the parties the participant knows about, with whether it hosts each one and
what your credential is permitted to do as it. This is ledger-level identity — it
exists on any Canton participant and needs no Daml packages.

Not the same question as /dtcc/parties. That returns registry credentials —
claims, allow-list membership, who issued them. This returns whether a party exists
on the ledger at all, whether this participant hosts it, and whether you can act or
read as it. A party can be perfectly valid here and hold no registry credential, and
vice versa.

hint and keyFingerprint are the two halves of the party identifier, split out so
you need not parse it. Filter on hint to find a party by its readable label —
preferable to prefix-matching partyId, and honest about the fact that a hint is
not unique: two parties may share one and only the fingerprint distinguishes them.

hasActAsRight and hasReadAsRight describe your credential, not the party. They are the
practical answer to "why does this query return nothing" — a party you cannot read as
will appear to have no contracts.

What this does not give you is a human-readable entity name. The hint is a label
chosen at allocation, not a legal name; the ledger's own party metadata carries no
name this deployment populates; and the network name service has no entries for these
parties. If a legal-entity name is needed, it has to come from reference data supplied
out of band or from the network Scan service, neither of which this API serves.

Superset of the Ledger API's PartyManagementService record.
The response carries the native party-record fields (localMetadata among them)
under their native names, with hint/keyFingerprint kept as this API's own
additive split of the identifier rather than a reshaping of the record.