Domain Topology Manager Request Service

Questions
1

Hello all,

We were looking into deploying a permissioned Daml Ledger using the Canton infrastructure and wanted to delve deeper into the specifics of identity management in such a setting. As described in the documentation here, it describes a:

Domain Topology Manager Request Service - Any topology transaction upload from the domain service is processed through the request service. The request service is configured with a request strategy. The request strategy inspects the topology transaction and decides how to deal with an topology transaction. Right now, three strategies have been implemented: auto-approve for un-permissioned domains, queue for permissioned domains (where transactions are just stored for later decision in the Request Store ) and reject for closed domains.

For our usecase, we could want to use the “queue” request strategy. Where is this configured exactly? Does the topology manager sit inside the canton image or is it a seperate service?

If I understand correctly, topology transaction changes are submitted by participants to the domain, where they are then added to a request store. These requests should then be accessible and managed through the Domain Topology Manager Request Service. However, I had a look at the Canton Administrative APIs and could find no documentation for such a service.

1 Like
2

Hi @benedict_chan

We’ve implemented these three strategies in order to ensure that our architecture and the interface we’ve defined can support all these variants which span all extremes (open network to totally restricted). However, from an operational view-point, we have not made them customer-ready. That’s why you can’t find any explicit documentation about them, although the management endpoints already exist.

Generally, the rationale was that we do not know exactly our clients requirements on managing access to a network. Therefore, we’ve ensured that we architect the system such that we can provide the necessary means once we get specific input.

In this respect, for the current quarter, we decided to extend the default “auto-approve” strategy with explicit whitelisting, which we currently perceive as a better solution in terms of security and user-experience: transactions will be accepted, if they are coming from a white-listed participant.

In that sense, please contact your sales / product representative and provide them with the details on your requirements, such that we can assess the effort required in order to make the queue strategy available to you, or if there are other alternatives that you could use.

Does this help?

Best,
Ratko