Access token: readAs and ActAs: ledger link with sub?

Questions
1

How/is the actAs and readAs rights associated in the ledgers actions against the sub in the token (the user id) within the specific commit/transaction?

Additionally how does actAs get chosen if multiple values are provided and those values can all be used for a single submitter? (Such as a controller of a choice: actAs=owner, team-leader, and controller owner, teamLeader.

Thanks!

2

The rights are controlled via the user management service specifically the GrantUserRights/RevokeUserRights and the rights you specify when creating a user. You can see this in use in create-daml-app’s setup script.

For your second question, there is never a case where this is ambiguous. There are two main cases we need to consider:

  1. For a create the required authorizers are the signatories. Those are derived from the template payload which you specify explicitly so they can be derived unambiguously from that.
  2. For an exercise the required authorizers are the controllers. Controllers are specified via nice syntax in Daml but effectively they are a function Template -> ChoiceArgument -> [Party]. Importantly, all parties specified as controllers must authorize an exercise not one of the parties you specified. So again, there is nothing ambiguous in your example because both owner and teamLeader must authorize it not either of them. You can model one of multiple parties authorizing an exercise by passing it in via the exercise argument and then checking the party in your choice body. In that case, it becomes unambiguous because you specify the choice argument. Take a look at the related blogpost for an example of this.
3

@cocreature if the signatory is “org” and the user can actAs org, is there is linkage that says "for this commit/transaction, org was being used by user X ?

4

Not on-ledger, users are purely a participant-local thing. They are not stored in transactions or sent to other participants. I believe it’s included in the logs somewhere however.

5

Thanks @cocreature. Those logs would likely be at which level? In terms of an org running an analysis of actions taken on a ledger, when role-based contracts are used for authz then who is the underlying user would be an important data point.

The workaround seems to be to make everything a multi-party with the role party + submitting user.

6

INFO should be enough. It’s logged via the applicationId see User management logging - #2 by pbatko

7

In this example:

07:36:51.113 [daml.index.db.threadpool.connection.api-server-0] INFO c.d.p.u.PersistentUserManagementStore - Granted 1 user rights to user 79c64b59-0a4e-4565-acac-37f5377d7257-alice-user: CanActAs(b8f75500-b76a-44aa-a996-8f474d1ec48e) , context: {participantId: “sandbox-participant”, submissionId: “3d431421-7858-4330-a481-fae1d65f25ec”}

how does submissionId tie into the ledger transaction? Is there an actual lineage between the log and the transaction?

(or maybe this is a poor example. Will have to test further to extract the log(s) and see where a linkage can be made).

8

That log is for a GrantUserRights request not a command submission. This never produces a ledger transaction. For actual ledger transactions, you’ll see the command id which you can use to correlate with the transaction on the ledger.

9

Thank you. As always, very clear and concise :slight_smile:

1 Like