Looking for some guidance on actAs and readAs practical usage:
When submitting a command the command can take a actAs and readAs command that is compared with the available parties in the token as per: Access Token vs actAs/readAs command arguments (java bindings) - #2 by stefanobaghino-da
In practice usage, when do command submissions contain only specific actAs/readAs lists compared to sending the entire list of possible parties.
In practice the current condition i see would be where users have significant numbers of parties in actAs and readAs to a point where the token becomes “large” enough to warrant a chopped down version of the token that is more scoped to the request requirements.
But assuming the token always had 100% of the user’s actAs and readAs parties, what would be the practical usage for sending a command with actAs and readAs being a filtered down list?
Thanks!
I’d go for the principle of least privilege here: Don’t submit commands with more actAs/readAs parties than you need to avoid surprises.
To accomplish this when using the role party pattern seems complex:
the user would need to constantly select which role/party to exercise
or some sort of logic needs to be implemented to check what party would be needed and if the current user has actAs for that party, and if they have actAs, then to submit using that party.
Given that a signatory, controller, and observer are always based on a fields in the contract, what “surprise” could occur by passing the complete list of read and actAs in each command submission?
If you exercise a choice on a contract id or a key, you don’t necessarily know the payload so you don’t necessarily know the controllers. With interfaces that becomes even trickier to reason about.
I don’t really understand why role patterns make this more complex. In what case do you not know what you act as?
That said, I’d say this is more of a rule of thumb than a hard rule.
@cocreature the party-role pattern creates a scenario where a single user can have many actAs parties:
In my scenario the actAs parties are “role parties” such as the the Organization Contract that has a “root” party which is the role party representing the org. This could be carried down into Teams, Team Leader Contracts. I don’t want to get stuck on a specific example here, just the concept described in the part role pattern.
If a user had multiple organizations/teams/etc role parties as part of their actAs, it would be very possible for the user to be unaware/unsure what role party to submit as. A UI ~could automate much of this depending on the flow of the UI to navigate down the proper chain of contracts to create the context.
But assuming that UI did not exist, the user was interacting with a swagger UI or any other UI that did not take the contextual chain into account, it would mean (from my understanding, please correct me if there is another way), the user would not know what party to submit as, so they would just expect to submit as “user bob” and all of their actAs would be submitted with that request.
I think the important part here is that actAs only matters for your root node. Let’s ignore creates (because they’re even simpler) and say I’m exercising a choice. The only thing that matters is that my actAs party is a controller on that choice. I don’t need to look down further into the consequences. Within the body of that choice, my actAs rights don’t matter at all. From there on I only have authorization from the union of signatories & controllers.
Looking at the example you linked, if I call AddMember I’m explicitly specifying the controller by specifying the member so setting my actAs party to match doesn’t require particularly complex logic.
Now readAs does affect consequences. I think there being lax and just passing all parties is usually fine. Reading a few more contracts is fairly harmless compared to passing your authorization to something that shouldn’t have it.
1 Like
@cocreature that’s sounds like a manageable compromise.