authorization-model

AUTHORIZATION_MODEL Skill (DAML)

Trigger Pattern: Always required for DAML audits Inject Into: Breadth agents, depth-state-trace, depth-external Finding prefix: [DML-AM-N] Rules referenced: R4, R6, R12, R13

DAML's authorization model has no msg.sender. Authority flows through the transaction tree: the required authorizers of every node MUST be a subset of the parties who authorized the submission. A create requires the new contract's signatory parties; an exercise/fetch requires the choice's controller parties; an archive requires the signatories. Signatory authority propagates exactly ONE hop into a choice's consequences. The most common critical bug class is a choice whose controller is derived from a choice argument (privilege injection), or a choice that performs a privileged action with only one authorizer where joint authorization is required.

1. Choice-Authority Inventory

For EVERY choice in each template, record who must authorize it and what it does:

Template.Choice	Consume-Mode	Controller Expr	Controller Source	Privileged Action?	Co-Auth Required?
{T.C}	consuming/nonconsuming/pre/postconsuming	{controller expr}	FIXED-SIGNATORY / ARG-DERIVED / FETCHED	YES/NO	YES/NO

Critical patterns to flag:

• A choice that moves value, changes ownership, or updates config but lists only ONE controller where the action affects multiple parties (single-where-joint → [ELEVATE:MISSING_COAUTH]).
• A controller expression that reads a field of the choice argument rather than a template signatory/fixed party (privilege injection → [ELEVATE:PARAM_CONTROLLER], ALWAYS flag).

DAML note: controller p makes p the required authorizer AND an automatic observer. A controller derived from arg.someParty lets the caller name themselves as the authorizer — there is no msg.sender to constrain it.