Mod note: As of SDK 1.5.0 Scenarios have been superseded by the more powerful Daml Script. We now recommend using that for all purposes. For more information, and to learn how to use Script please check out @Andreas’ post on our blog.
I was going to post a question about some code that “doesn’t” work, but then I reread the documentation and started to understand more subtleties. Please consider,
daml 1.2 module Dk where -- Disclosure via keys? template Request with user : Party admin : Party where signatory user controller admin can Approve : ContractId Capabilities do create Capabilities with .. template Capabilities with admin : Party user : Party where signatory admin, user key (admin, user) : (Party, Party) maintainer key._1 controller user can nonconsuming HasCapabilitiesByLookup : Bool with anotherUser : Party do r <- lookupByKey @Capabilities (admin, anotherUser) case r of None -> do debug "None" return False Some r -> do debug $ "Some" <> (show r) return True test = scenario do admin <- getParty "admin" alice <- getParty "alice" bob <- getParty "bob" request <- alice `submit` do create Request with user = alice, .. capabilities <- admin `submit` do request `exercise` Approve canLookupSelf <- alice `submit` do capabilities `exercise` HasCapabilitiesByLookup with anotherUser = alice assert canLookupSelf -- No authority from admin, the maintainer. alice `submitMustFail` do lookupByKey @Capabilities (admin, alice) canLookupBob <- alice `submit` do capabilities `exercise` HasCapabilitiesByLookup with anotherUser = bob -- doesn't have capabilities yet or ... assert $ not canLookupBob bob_request <- bob `submit` do create Request with user = bob, .. bob_capabilities <- admin `submit` do bob_request `exercise` Approve stillCantLookupBobo <- alice `submit` do capabilities `exercise` HasCapabilitiesByLookup with anotherUser = bob -- Can't lookup because alice is not a stakeholder on the Capabilities contract between admin and bob. assert $ not stillCantLookupBobo return ()
- There is a difference between performing a (1)
Scenarioand as a (2) part of a
Choiceon an agreed to contract. When you write this out the distinction becomes clearer.
- The reason why a
Nonecan be different!
When I wrote this code I had intended that last lookup to actually work. I do want
alice to discover that
Capabilities. I have two proposals in mind. The first, simpler, is to change the meaning of
lookupByKey when the contract that it refers to is the same a
self. Perhaps a different name,
lookupSelfByKey would be appropriate? In this case
bob can see the contract to which he agrees to, and part of that contract is the ability for others to discover that he has this contract.
The second, more radical, idea is to remove the restriction that the “submitting party is a stakeholder of a matching contract”. ie, make keys only restricted by the maintainer authorizing it. If you do want privacy via the key one could already add a password/shared secret as part of the key,
key (maintainerParty, userParty, password) : (Party, Party, Text) -- make it really good. maintainer key._1