# Auditability of users as opposed to parties **URL:** \ **Category:** App Development\ **Tags:** parties, auditability, party, users\ **Created:** [November 8, 2022, 9:05am UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616 "2022-11-08T09:05:16Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [November 8, 2022, 9:05am UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/1 "2022-11-08T09:05:17Z")
Suppose my participant has a party `Owner` and two users, `alice` and `bob`, both of which can act as `Owner`. Parties always leave an on-ledger trail by the very nature of how Daml works, but what about users? How could the operator of the participant audit the interactions with the Ledger API so to link a specific call back to a user? ---
**Author:** ![cocreature](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/cocreature/32/36_2.png) [@cocreature](https://forum.canton.network/u/cocreature)\ **Post date:** [November 8, 2022, 9:09am UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/2 "2022-11-08T09:09:51Z")
Command submissions log the application id which corresponds to the user id. So that provides some way to trace back command submissions to individual users. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [November 8, 2022, 9:13am UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/3 "2022-11-08T09:13:13Z")
So the application ID must match the user ID in every call to the Ledger API? ---
**Author:** ![cocreature](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/cocreature/32/36_2.png) [@cocreature](https://forum.canton.network/u/cocreature)\ **Post date:** [November 8, 2022, 9:15am UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/4 "2022-11-08T09:15:43Z")
Yes at least if you’re running with auth (which you should do in any production system where you care about auditing). You can also omit the application id in those cases since it is redundant. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [November 8, 2022, 9:16am UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/5 "2022-11-08T09:16:28Z")
That’s great to hear, thanks. This means that the [`CommandCompletionService`](https://docs.daml.com/app-dev/grpc/proto-docs.html#com-daml-ledger-api-v1-completionstreamrequest) effectively serves as a possible source for full auditability that takes into account both a user (by virtue of the matching application ID) and party, is that correct? ---
**Author:** ![cocreature](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/cocreature/32/36_2.png) [@cocreature](https://forum.canton.network/u/cocreature)\ **Post date:** [November 8, 2022, 9:18am UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/6 "2022-11-08T09:18:51Z")
Yes although I think logs are often a better option for this. They are present even for commands that get rejected on submission (so never produce a completion) and you don’t need to worry about getting tokens as the participant operator to query the completion stream. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [November 8, 2022, 9:24am UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/7 "2022-11-08T09:24:28Z")
I see, thanks! ---
**Author:** ![Leonid\_Rozenberg](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_rozenberg/32/48_2.png) [@Leonid\_Rozenberg](https://forum.canton.network/u/Leonid_Rozenberg)\ **Post date:** [November 8, 2022, 1:19pm UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/8 "2022-11-08T13:19:49Z")
Logs do not have the same persistence requirements/behavior as our ledger. I ultimately think we need some way to reconcile users set state and the ledger’s offset. Given the recommendation how does one tell the difference between actual applications? I can see that there are two distinctions that an operator would want to investigate. 1. Does user Alice mostly use HTTP-JSON or a custom integrations? 2. How does it interact with ledger metering? For example if I have 1k Users as part of an organization that I’d like to charge for their activity, would I have to aggregate all 1k Users, and how would I reconcile the history of user changes across a given period to figure out the right number of ledger events? ---
**Author:** ![cocreature](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/cocreature/32/36_2.png) [@cocreature](https://forum.canton.network/u/cocreature)\ **Post date:** [November 8, 2022, 2:17pm UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/9 "2022-11-08T14:17:07Z")
For your second question: Metering is tied to application ids which ties it to users. See [Participant Metering — Daml SDK 2.4.0 documentation](https://docs.daml.com/ops/metering.html) for details. ---
**Author:** ![Leonid\_Rozenberg](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_rozenberg/32/48_2.png) [@Leonid\_Rozenberg](https://forum.canton.network/u/Leonid_Rozenberg)\ **Post date:** [November 8, 2022, 2:38pm UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/10 "2022-11-08T14:38:47Z")
I did read that link. My point is that filtering by application when asking for usage via metering is not that useful anymore. An operator would have to store a history of users tied to a real world use case to aggregate charges against that use case, which in the past they were able to consider an “application”. I think there are two orthogonal concerns and an application does not necessarily map 1-1 to users on your node. ---
**Author:** ![cocreature](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/cocreature/32/36_2.png) [@cocreature](https://forum.canton.network/u/cocreature)\ **Post date:** [November 8, 2022, 2:40pm UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/11 "2022-11-08T14:40:41Z")
> [@Leonid\_Rozenberg](#): > > I think there are two orthogonal concerns and an application does not necessarily map 1-1 to users on your node. Not sure I’m following. As mentioned above, the participant enforces that application id = user id. You don’t get a choice. Are you asking for a new feature where this restriction does not apply and you can filter on different dimensions (whether that’s called application id or something else) than just user? ---
**Author:** ![Leonid\_Rozenberg](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_rozenberg/32/48_2.png) [@Leonid\_Rozenberg](https://forum.canton.network/u/Leonid_Rozenberg)\ **Post date:** [November 8, 2022, 2:59pm UTC](https://forum.canton.network/t/auditability-of-users-as-opposed-to-parties/5616/12 "2022-11-08T14:59:13Z")
> [@cocreature](#): > > Are you asking for a new feature where this restriction does not apply and you can filter on different dimensions (whether that’s called application id or something else) than just user? Yes. I meant “application” in a different sense, one where many users are using the same application. From an operator perspectives one would want to aggregate at that application (maybe because they’re the ones collecting the fees) as opposed to the users that use the application. I understand how tying users to applications makes sense in a broader world where everyone gets a participant node sailing on a sea of domains. But not in the current environment.