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

[Linda Dunbar <[e-mail]>]

Iman,

Thank you very much for the detailed review and comments.
Please see the response and resolutions marked by [Linda] below.

Linda

-----Original Message-----
From: Iman Schrock <team=[e-mail]>
Sent: Monday, July 13, 2026 5:19 PM
To: [e-mail]
Subject: [dmsc] Comments on draft-dunbar-dmsc-gw-scenarios-gap-analysis-02: evidence for action-level authorization (5.4, 6.9, 7.7)

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.

[Linda] I agree with your distinction between conditions the gateway can evaluate directly, such as spatial, temporal, and risk conditions, and human approval state, which requires independently verifiable evidence from another party. Do you adding the following paragraph right after the bullets can address your concern?
      "Among the conditions listed above, human approval state has a different evidence property from spatial, temporal, and risk conditions. The Gateway can evaluate spatial, temporal, and risk conditions using local policy, network context, site configuration, or operational state. Human approval, however, represents an action by another party. Therefore, when strong auditability is required, Gateway may need to verify approval evidence that was created outside the Gateway, bound to the specific action being authorized, and recorded separately from the Gateway's own allow-or-deny decision."


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.


[Linda] Agree with your points. How about adding the following text right after the bullets to address your suggestion?
      "The authorization context exchanged across gateways may include human-approval evidence, either carried inline or referenced by the sending gateway. Such evidence should identify the approving party or role, the specific action being authorized, the material parameters of that action, and the time or validity constraints under which the approval applies. To prevent replay or reuse for a different action, the evidence should be bound to a canonical representation or digest of the action request.

      When a receiving gateway's local policy requires human approval, the receiving gateway evaluates the approval evidence under its own configured trust anchors and policies. The receiving gateway is not required to trust the sending gateway's allow-or-deny decision. Instead, it verifies the evidence, determines whether it satisfies local policy, and records its own enforcement decision. Correlated audit records across gateways may reference the same action digest so that later audit can relate the approval evidence, forwarded request, and local enforcement decisions without merging the gateways' trust boundaries."


3. On 7.7's standardization candidate.
[Linda] Section 7.7 is  "Physical-World Action Authorization". Are you talking about another section? Or the DMSC BoF Part 3 on potential venues for the work?

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.

[Linda] Agree. Do you think the additional paragraphs added above under Section 6.9 can address your concern?

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.emiliaprotocol.ai%2Ftry&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cb1a126b0ddd74d16eb2008dee13d8bb2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639195851631820481%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aF4jMG85r8gu2WeXj4eD%2B0OCqjXI7%2BK7WHn%2BsupLohQ%3D&reserved=0 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,
DMSC mailing list
To subscribe or manage your subscription: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman3.ietf.org%2Fmailman3%2Flists%2Fdmsc.ietf.org%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cb1a126b0ddd74d16eb2008dee13d8bb2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639195851631862279%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BvXR0hceaybAgQ%2BfQCRIhRtc7F8mOpIHBD%2BFoNLoTHU%3D&reserved=0