[dmsc] Comments on draft-dunbar-dmsc-gw-scenarios-gap-analysis-02: evidence for action-level authorization (5.4, 6.9, 7.7)

[Iman Schrock <[e-mail]>]

Hi all,

Linda suggested I bring comments on
draft-dunbar-dmsc-gw-scenarios-gap-analysis-02 to this list. I read it with
the gateway's evidence obligations in mind. The separation the draft draws
in 5.4 and 6.9 between communication-level trust and action-level
authorization is the right cut, and 7.7 names a real gap. Three comments.

1. Two classes of evidence with different requirements.

Of the four action-level conditions in 6.9, three (spatial, temporal, risk
classification) are conditions the gateway can measure or evaluate itself.
Human approval state is different in kind: it is a claim about another
party's act. Its evidence therefore carries a property requirement the
other three do not. If the approval state exists only as an entry in the
gateway's own audit trail (5.4), the decision trail is the enforcing system
attesting to itself, and the regulatory-audit use in 6.6 and the
cross-organization case in 4.5 inherit that weakness: the party that
enforced the action is also the only witness of its authorization.

The stronger property: the approval is a signed artifact created by the
approving human's key rather than the gateway's, bound to the specific
action it authorizes (for example by a digest of the action's canonical
form, so evidence minted for one action cannot be replayed against
another), and verifiable offline by any party against keys pinned
independently of both operators and of the gateway itself. The gateway then
does four things, and none of them create the evidence's force: it carries
the artifact with the request, verifies it before enforcement (valid, bound
to this exact action, satisfying the approval requirement local policy
imposes), records it alongside the executed-or-denied decision, and
references it in audit records. A denial for missing or invalid approval
evidence is itself worth recording as a verifiable event that names the
failed check.

2. On 6.7, authorization context across gateways.

"Conveyed to the receiving gateway in a verifiable form" is the right
requirement. Stated as protocol text, the case looks like this: when
Gateway B receives a consequential action through Gateway A, and Gateway
B's local policy requires human approval, the protocol should permit
Gateway A to carry or reference evidence binding that approval to the exact
action and its material parameters. Gateway B evaluates that evidence under
its own trust anchors and records a separate enforcement decision.

Two properties keep the chain of custody clean: each gateway verifies the
artifact itself, under keys it pins independently, and correlated audit
records across gateways join by the shared action digest. No gateway needs
to ingest another gateway's decision or log into its own trust boundary.
The artifact travels; the trust does not have to. Where freshness or
revocation of an approval matters, it enters as a presented, signed input
to that evaluation rather than as an out-of-band lookup the receiving
gateway must trust.

3. On 7.7's standardization candidate.

Suggest the model distinguish three things the current text folds together:
expression of conditions (spatial, temporal, risk: policy-language
territory), evidence of approval state (who approved, bound to what,
verifiable by whom, under which keys), and decision records (executed or
denied, with reasons). The gateway's local allow-or-deny decision and the
approval evidence it evaluated are different records with different
authors, and keeping them distinct is what lets a later audit check each
independently. The requirement DMSC could most usefully state is for the
second class: what an Agent Gateway must be able to verify about a human
approval before enforcing a consequential action, and which of that
evidence must remain independently verifiable outside any single gateway or
operator.

On where such work should happen, since Part 3 asks: the approval-evidence
class exists today as related work outside any WG. EMILIA Protocol is one
such mechanism: open source (Apache-2.0), specified in individual
Internet-Drafts (individual submissions, not the product of any IETF
working group), with a public conformance suite of 17 suites and 193
accept-and-refuse vectors, and a second, externally authored implementation
agreeing on all published vectors. I am not proposing DMSC adopt a
mechanism. The useful DMSC work is the requirement statement above, which
any conforming mechanism can then meet. A live demonstration of the
primitive is at https://www.emiliaprotocol.ai/try for anyone who wants to
see the artifact and a verification run.

If a short runnable cross-gateway example would help Part 3 (two gateways,
one approval artifact, each verifying independently and recording its own
enforcement decision), I can provide one. Happy to propose specific text
for 6.9 and 7.7 if the authors would find it useful.

Dr. I,