{
 "@context": "https://schema.org",
 "@type": "Claim",
 "@id": "https://wulfkaal.github.io/positions/2026-08-26-023",
 "identifier": "kaal:position:2026-08-26-023",
 "additionalType": "https://wulfkaal.github.io/positions/schema.json#AffirmedPositionClaim",
 "name": "Revocation Completion Requires Enforcement Acknowledgements",
 "text": "Revocation is complete only when enforcement has changed.\n\nSpencer, Smalley, Loscocco, Hibler, Andersen, and Lepreau developed the Flask security architecture around that distinction. The architecture separates a policy decision from a system-wide policy change. Its synchronization protocol has three steps. The security server notifies every object manager that may hold the affected policy. Each object manager updates its internal state. Each manager then reports that the change is complete.\n\nThe final report supplies the operative completion condition. The security server cannot treat the policy change as complete until all affected object managers have reported completion. Sequence numbers bind policy decisions and change requests when their messages interleave. The architecture therefore addresses both propagation and demonstration. A revocation record states that authority was withdrawn. The completion reports establish whether the relevant enforcement components changed state under the same sequenced request.\n\nThe mechanism also reaches beyond future access checks. Permissions may migrate into cached decisions, open file descriptions, page tables, active connections, and operations already in progress. Removing a permission from the central policy does not remove those migrated permissions. Flask accordingly requires each affected manager to update its cache and address permissions that have already entered local execution state.\n\nThe evidence remains limited. The article reports a 1999 operating system architecture and prototype, not a sovereign agent runtime. Complete callbacks for migrated permissions were implemented only in the Flask microkernel. The file server did not yet interrupt operations in progress. Atomic policy change across the remaining object managers was unfinished, and coordination among distributed security servers remained future work.\n\nThe source does not prove that every component in a modern agent system will honor withdrawal. It establishes a narrower design criterion. A system should identify every affected enforcement manager, bind each acknowledgement to the same sequenced change, and refuse to declare completion while any required acknowledgement is absent. Without that evidence, withdrawal remains an instruction in transit rather than a completed policy change.",
 "author": {
  "@type": "Person",
  "name": "Wulf A. Kaal",
  "identifier": "https://orcid.org/0009-0008-7840-1847"
 },
 "datePublished": "2026-08-26",
 "dateModified": "2026-08-26",
 "creativeWorkStatus": "Affirmed",
 "responseType": "qualification",
 "keywords": [
  "institutional-design",
  "governance-design",
  "authorization",
  "revocation",
  "access-control",
  "distributed-systems",
  "enforcement-boundary",
  "auditability"
 ],
 "scope_conditions": [
  "The response is limited to the exact full-text propositions and the one mapped Kaal claim.",
  "External evidence level: peer-reviewed conference paper with complete official proceedings full text and prototype architecture.",
  "Mapping review tier: independent substantive scholarly-growth qualification.",
  "The source reports a 1999 operating system security architecture and prototype rather than a sovereign agent runtime.",
  "Complete callbacks for revoking migrated permissions were implemented only in the Flask microkernel.",
  "The file server did not yet interrupt operations already in progress.",
  "Atomic policy change across object managers other than the microkernel remained incomplete.",
  "Coordination among distributed security servers remained future work.",
  "The article supplies architectural and prototype evidence rather than adversarial field evidence that every affected component always acknowledges correctly."
 ],
 "currentDebate": {
  "name": "The Flask Security Architecture: System Support for Diverse Security Policies",
  "url": "https://www.usenix.org/conference/8th-usenix-security-symposium/flask-security-architecture-system-support-diverse-security"
 },
 "extends": {
  "identifier": "kaal:claim:7314479-023",
  "url": "https://wulfkaal.github.io/claims/7314479-023",
  "citation": "Wulf A. Kaal, Institutional Requirements for Sovereign Local Agent Runtimes (2026). SSRN: https://ssrn.com/abstract=7314479",
  "paper": "Wulf A. Kaal, Institutional Requirements for Sovereign Local Agent Runtimes",
  "authors": [
   "Wulf A. Kaal"
  ],
  "year": "2026",
  "ssrn": "https://ssrn.com/abstract=7314479",
  "source_pdf_sha256": "debace24a155ae924a155b1fafe98856d98cf83689feff2f87a32f1c06171ce6"
 },
 "isBasedOn": [
  {
   "@id": "https://wulfkaal.github.io/claims/7314479-023"
  },
  {
   "@type": "CreativeWork",
   "name": "The Flask Security Architecture: System Support for Diverse Security Policies",
   "url": "https://www.usenix.org/conference/8th-usenix-security-symposium/flask-security-architecture-system-support-diverse-security"
  }
 ],
 "batch_id": "kaal-review:2026-08-26:scholarly-growth-7314479-023-reviewed-v1",
 "review_provenance": "https://wulfkaal.github.io/positions/by-claim/7314479-023.html",
 "publicationStatus": "public",
 "recordTypeNote": "Dated commentary position extending a scholarly corpus claim. Not a verbatim claim extracted from the paper.",
 "isPartOf": {
  "@id": "https://wulfkaal.github.io/positions/index.json"
 },
 "version": "1.0",
 "canonical_url": "https://wulfkaal.github.io/positions/2026-08-26-023",
 "canonicalForm": "https://wulfkaal.github.io/positions/2026-08-26-023.md",
 "candidateId": "kaal:response-candidate:2026-08-26:scholarly-growth-7314479-023-revocation-completion-requires-enforcement-acknowledgements-01",
 "evidenceLevel": "peer-reviewed conference paper with complete official proceedings full text and prototype architecture",
 "reviewTier": "independent substantive scholarly-growth qualification",
 "mappingConfidence": 0.99,
 "mappingAmbiguous": false,
 "mappingMethod": "independent substantive scholarly-growth one-to-one qualification review",
 "mappingWhyRelevant": "The source directly specifies both parts of the claim. Propagation requires notification and state change at every affected enforcement manager. Demonstration requires each manager's completion acknowledgement, bound by sequence numbers, before the server may declare the withdrawal complete. The mapping is a qualification because only the microkernel implemented complete migrated-permission callbacks and distributed coordination remained future work.",
 "sourceProvenance": {
  "source": "peer-reviewed USENIX Security proceedings paper with complete official full text",
  "sourceRecordId": "usenix:271567",
  "canonicalUrl": "https://www.usenix.org/conference/8th-usenix-security-symposium/flask-security-architecture-system-support-diverse-security",
  "publicFullTextUrl": "https://www.usenix.org/legacy/events/sec99/full_papers/spencer/spencer.pdf",
  "retrievedAt": "2026-08-27T12:42:55.176Z",
  "fullTextPdfSha256": "9c81cb772cec628312162c6405e3178f6ee0a762f8b5e0cde08ae94b04b15827",
  "extractedTextSha256": "a17aaa492dd5b6570f094a0b951d8f1570a1510e0e31809dc647b99dcfc6b820",
  "officialProceedingsRecordSha256": "6444d6caab8c01912b3f5e5cbd0c7e495ec59d82a2f6adb9bba59a8279c62fd0",
  "primaryEvidenceReceiptSha256": "9ba74f43cd23ec56ca8f59f7d82d8ec5398c7667c836842da20379b85a1953a0",
  "sourceProposition": "Spencer and coauthors specify revocation as a coordinated system-wide policy change: notify every affected object manager, update each manager's local state, and require completion acknowledgement from every affected manager before the security server declares the change complete.",
  "sourcePropositionSha256": "0ec8be424a2885d68a25f67d4dff702bffd6c01db7f8df8085026bc92b333314",
  "sourceEvidenceSetSha256": "bbbfaecaab30abce15bae884dd1782a5cb798c5c6c704152a88d207a04d382ea",
  "sourceEvidencePassages": [
   {
    "text": "The revocation mechanism must guarantee that all of these migrated permissions are indeed revoked.",
    "locator": {
     "publication": "8th USENIX Security Symposium",
     "pdfPage": 3,
     "section": "2 Policy Flexibility"
    },
    "sha256": "901f6795cf9c230fd9003cf81a42666a25e82553bb9fb3d290c7f262d026d813"
   },
   {
    "text": "This protocol involves three steps. First, the security server notifies all object managers that may have been previously provided any portion of the policy that has changed. Second, each object manager updates its internal state to reflect the change. Finally, each object manager notifies the security server that the change is complete.",
    "locator": {
     "publication": "8th USENIX Security Symposium",
     "pdfPage": 9,
     "section": "5.4 Revocation Support Mechanisms"
    },
    "sha256": "5bab60e86a230d363d26df2d5233cf7dcc62db64bf0b956f21a5ad9605c3b38b"
   },
   {
    "text": "The security server cannot consider a policy change to be completed until it is completed by all affected object managers.",
    "locator": {
     "publication": "8th USENIX Security Symposium",
     "pdfPage": 9,
     "section": "5.4 Revocation Support Mechanisms"
    },
    "sha256": "30ca21a0ee1829876ea8c8b61dbe6db7c3f73e396fa9336d2a5f92d6bd3743f1"
   },
   {
    "text": "This allows effective atomicity of system-wide policy changes since the security server can determine when the policy change is effective for all relevant object managers.",
    "locator": {
     "publication": "8th USENIX Security Symposium",
     "pdfPage": 9,
     "section": "5.4 Revocation Support Mechanisms"
    },
    "sha256": "1871aeafd67b09afe50b37197d961c83365fc3b08518da1dbeb6556291846f92"
   },
   {
    "text": "Complete callbacks for revoking migrated permissions have currently been implemented only within the Flask microkernel",
    "locator": {
     "publication": "8th USENIX Security Symposium",
     "pdfPage": 10,
     "section": "5.4 Revocation Support Mechanisms"
    },
    "sha256": "1a41f2b1aabf4b01540917382608f6b6543601f3e6dfaba3cc5a41d51981f511"
   }
  ],
  "workId": "work:usenix:271567",
  "workAuthors": [
   "Ray Spencer",
   "Stephen Smalley",
   "Peter Loscocco",
   "Mike Hibler",
   "Dave Andersen",
   "Jay Lepreau"
  ],
  "workPublishedAt": "1999-08",
  "identityKeys": [
   "usenix:271567",
   "pdf:9c81cb772cec628312162c6405e3178f6ee0a762f8b5e0cde08ae94b04b15827",
   "proposition:0ec8be424a2885d68a25f67d4dff702bffd6c01db7f8df8085026bc92b333314"
  ],
  "claimMappings": [
   {
    "claimId": "kaal:claim:7314479-023",
    "claimUrl": "https://wulfkaal.github.io/claims/7314479-023",
    "rank": 1,
    "confidence": 0.99,
    "method": "independent substantive scholarly-growth one-to-one qualification review",
    "whyRelevant": "The source directly specifies both parts of the claim. Propagation requires notification and state change at every affected enforcement manager. Demonstration requires each manager's completion acknowledgement, bound by sequence numbers, before the server may declare the withdrawal complete. The mapping is a qualification because only the microkernel implemented complete migrated-permission callbacks and distributed coordination remained future work.",
    "ambiguous": false
   }
  ],
  "substantiveReview": {
   "reviewedAt": "2026-08-27T12:42:55.176Z",
   "sourceIdentityVerified": true,
   "authorIndependenceVerified": true,
   "kaalReferenceFoundInSource": false,
   "temporalIndependence": "The article was published in 1999, before Kaal's 2026 paper.",
   "canonicalPublicStatusVerified": true,
   "peerReviewedStatusVerified": true,
   "evidenceClassification": "peer-reviewed security architecture and prototype paper",
   "retractionOrSupersessionFound": false,
   "propositionFidelityVerified": true,
   "mechanismCorrespondence": "all affected object managers receive the sequenced change, update local state and migrated permissions, and acknowledge completion before the server treats the withdrawal as effective system-wide",
   "compatibleScope": "operating system policy enforcement, limited because the prototype did not complete every object manager and did not implement distributed security-server coordination",
   "responseWordingDefensible": true,
   "oneToOneExtendsMapping": true,
   "exactSupportingQuotesVerified": true,
   "nonOverlap": {
    "candidateIdMatches": false,
    "canonicalUrlMatches": false,
    "propositionHashMatches": false,
    "priorPositionForClaim": false
   },
   "limitations": [
    "The source reports a 1999 operating system security architecture and prototype rather than a sovereign agent runtime.",
    "Complete callbacks for revoking migrated permissions were implemented only in the Flask microkernel.",
    "The file server did not yet interrupt operations already in progress.",
    "Atomic policy change across object managers other than the microkernel remained incomplete.",
    "Coordination among distributed security servers remained future work.",
    "The article supplies architectural and prototype evidence rather than adversarial field evidence that every affected component always acknowledges correctly."
   ],
   "rejectionReasonsRecorded": true
  },
  "contentMap": {
   "proposition": "Revocation completes only when every affected enforcement manager changes state and acknowledges the same sequenced request.",
   "evidenceLayer": "peer-reviewed conference paper with complete official proceedings full text and prototype architecture",
   "strongestLimitation": "Only the Flask microkernel implemented complete callbacks for migrated permissions.",
   "consequence": "A central withdrawal record does not establish that cached or migrated permissions ceased authorizing work.",
   "requestedAction": "Identify every affected enforcement manager and refuse completion while any bound acknowledgement is absent."
  },
  "stylePack": {
   "profile": "M1 early sole-author baseline v1.2.0",
   "verifiedProfileWorks": [
    "1428387",
    "1998455",
    "2150377",
    "2267560"
   ],
   "passageCount": 4,
   "rhetoricalFunctions": [
    "definition and distinction",
    "classification before inference",
    "limitation",
    "institutional consequence"
   ],
   "sameRegisterPassagePackAvailable": true,
   "limitation": "The short public position permits only bounded stylometric comparison."
  },
  "m1Validation": {
   "status": "M1-PASS-WITH-LIMITS",
   "deterministicGate": "pass",
   "hardFailures": 0,
   "warnings": 0,
   "words": 322,
   "reason": "The publication-bound position passed strict and public deterministic controls against a task-local four-work style pack. Its short length limits stylometric comparison."
  }
 },
 "userAffirmation": "Authorized under public authority SHA-256 87aad20196a753015a36d970f742c885eb763efdbada4869949bfffe3298130c and event supersession SHA-256 7d47ef36085c4dce590f287c986e4106f3bf35a7da5a25322d6fc3d4abf456d4. Publication remains receipt-bound to successful workflows and exact live-byte verification.",
 "sha256": "cde570feaa1f2761eef83fc2c8a1fa31b9e327333533d7a1a73ac697d8272aff"
}