review from ocap angle

[dckc]

here's hoping

[fabcotech]

owner is the identity that initially deployed the contract

Methods available for a given ERC1155 contract, and who is allowed to call them, also there is a verification that the contract is not locked for certain features:

• CREATE_TOKEN (owner only) AND (locked = false)
• SET_LOCKED (owner only) AND (locked = false)
• PURCHASE_TOKEN (anyone, but of course, a purse with enough funds is needed)
• READ
• READ_TOKENS
• READ_TOKENS_DATA

The identity verification is based on unique nonce, for example if the owner executes CREATE_TOKEN, he must provide a signature for the current nonce, and a new nonce to be signed next time.

This is basically copied/paste from the README.MD

[dckc]

owner is the identity ...

I have trouble right there. Identity is kinda the wrong end of the stick, from an ocap perspective.

Marc Stiegler's A PictureBook of Secure Cooperation is one of my favorites:

The patterns described in this picturebook are simple because they discard the modern fascination with the identities of the participants. Individual Authentication is so pervasive, it is now a part of the problem.

Suppose that your car, instead of accepting a delegatable key, demanded that your driver’s license match the car’s title registry, which happens to be in your spouse’s name. Entrepreneurs would leap forward to develop ever more powerful "identity management" for automobiles. We would subcontract to security experts so our teenage daughters could borrow the car to buy milk. Heaven forfend that the daughter, breaking her leg, had to delegate to her best friend to get to the hospital. These patterns focus on authorization: ask not, “who are you?”, but rather, “are you allowed?”. This was always the crucial question anyway; by asking this better question, we get a better answer.”