Role-Contracts: Using Parties per instance of a contract or shared party?

Questions
1

Continuation from: Internal templates? (templates/contracts that can only be created by other template choices?) - #25 by StephenOTT

When working with role-contract / role-party pattern, and you use those parties as the observer role: such as:

template Pool 
    with
        org: Party
        poolMemberRole: Party
        owner: Party
        poolId: Text -- Never changes
        name: Text
    where
        signatory org
        observer owner, poolMemberRole

What is the recommended pattern for party creation for the equiv of the poolMemberRole party?

In a structure of Pool > Pool Invite > Pool member: having a Pool Member gives you access / readAs rights to the poolMemberRole party, must you create a new party for every instance of Pool?

When creating a trigger, I was looking at:

  1. On creation of PoolMember,
  2. find the Pool that the PoolMember Contract is for, and grant the member the readAs rights to the poolMemberRole party.

This design seems to indicate that every instance of Pool must have a unique party for poolMemberRole? otherwise someone could create a new chain of Pool > Invite > member but share the same party.

The pool could be also signed by the poolMemberRole party, but the rights to actAs the poolMemberRole party would come from out-of-ledger rights changing for a user?

Thanks

2

A un-tested quick sample to further the understanding:

template Role
    with
        org: Party -- Org that created the role thorugh some mgmt contract
        roleName: Text -- role name that will be used by the trigger
        -- some role key could be added as well
        manager: Party -- Party that will manage this role contract
        roleParty: Optional Party -- The party to be added after creation by the trigger bot
        actAs: Set Party -- Parties to grant rights to actAs the roleParty - used by trigger bot
        readAs: Set Party -- Parties to grant rights to readAs the roleParty - used by trigger bot
    where
        signatory org, manager
    -- various choices to manage the role


template PoolFromRoles
    -- would be created from some super-mgmt contract
    with
        org: Party
        ownerRole: Party -- Party created by the Role contract for mgmt of the Pool
        memberRole: Party -- Party created by the Role contract for member read access of the pool
        poolId: Text -- Never changes
        name: Text
        -- ...other various pool attributes...
    where
        signatory org, ownerRole
        observer memberRole

        key (ownerRole, poolId): PoolKey
        maintainer key._1


template PoolMemberFromRoles
    -- would be created from a PoolInvite contract
    with
        member: Party
        poolKey: PoolKey
        org: Party
        ownerRole: Party
    where
        signatory member, org, ownerRole -- assumes that ownerRole party is ~unique per pool.
        observer member
    -- The creation of this contract would be picked up by the trigger.
    -- the trigger would grant the member the ownerRole (readAs) from the Pool.

(based on all the layering that seems to be needing to make this pattern occur for a typical business process, it feels like unless scale really became an issue, it would be much easier to deal with contract migrations/upgrades: such as if a new owner was needed then all existing contracts would be updated with the new owner party/user instead of the separation of roles and the complexity of the layers + triggers and party grants).

3

There are two parts here:

  1. Visibility of the pool contract.
  2. Authorization via the delegation contract.

The second one does not rely on readAs and you can control that separately for each pool (e.g. by fixing the contract id or a contract key you delegate authorization to in the delegation contract).

Visibility on the other hand is at the party level if you go via readAs.

So if you’re fine with sharing visibility, you could share the party and limit authorization per pool. If you also need to limit visibility, then you really do need a party per pool if you want to go for this approach. As mentioned before, we are currently working on features that would make this type of contract disclosure easier without having to resort to the very coarse-grained readAs.

1 Like