Internet-Draft M. Norton Intended status: Informational Independent Expires: January 17, 2027 July 17, 2026 SDLP Security Architecture (SDLP RFC 4) draft-norton-sdlp-sec-arch-03 M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com July 2026 Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 1. Introduction The Secured Digital Lifecycle Protocol (SDLP) defines a unified security model for digital objects that require authenticated actors, authorized lifecycle transitions, and verifiable lineage. SDLP provides object-level security by binding identity, lifecycle state, and lineage integrity into a single enforceable architecture. This document specifies the SDLP security architecture. It defines the security model, threat surfaces, authentication requirements, authorization boundaries, integrity guarantees, and environment validation rules that apply to all SDLP-governed objects. The architecture ensures that every lifecycle event—creation, activation, transformation, transfer, verification, retention, and retirement—is cryptographically attributable and verifiable. The SDLP security architecture operates in conjunction with three companion specifications: * SDLP Identity Model (SDLP RFC 1): Defines actor identities, object identities, and cryptographic bindings. * SDLP Lifecycle Model (SDLP RFC 2): Defines the deterministic state machine governing object transitions. * SDLP Lineage Model (SDLP RFC 3): Defines the canonical structure, sequencing, and verification of lineage entries. Together, these documents establish the complete security foundation for SDLP-governed digital objects. This document defines only the security properties and enforcement requirements that ensure authenticated transitions, authorized operations, and tamper-evident lifecycle behavior across all compliant implementations. 2. Security Model The SDLP security model is based on authenticated actors, deterministic lifecycle transitions, and verifiable lineage. All lifecycle events MUST be cryptographically attributable to the entity that performed them, and all state changes MUST be validated against the SDLP Identity, Lifecycle, and Lineage specifications. SDLP-governed objects operate under three foundational security principles: * Identity Integrity: All actors and objects MUST possess stable, verifiable identities bound to approved cryptographic keys. Identity bindings MUST be authenticated before any lifecycle operation is permitted. * Transition Integrity: All lifecycle transitions MUST follow the deterministic state machine defined in the SDLP Lifecycle Model. Unauthorized, unverifiable, or out-of-order transitions MUST be rejected. * Lineage Integrity: All lifecycle events MUST produce canonical, signed lineage entries. Lineage MUST form a continuous, tamper-evident chain that reflects the complete history of the object. The SDLP security model ensures that every transformation, transfer, validation, and retirement event is authenticated, authorized, and cryptographically verifiable. This model provides a unified security foundation across all SDLP-compliant implementations. 3. Threat Model SDLP defines a security model intended to preserve the integrity, identity, and lineage of digital objects as they traverse distributed ecosystems. The model assumes a heterogeneous environment composed of distributors, creators, consumers, automated systems, and third-party platforms. SDLP does not provide confidentiality; instead, it ensures that each object maintains a verifiable, tamper-evident lifecycle record independent of transport or storage conditions. 3.1. Attacker Personas The following attacker personas represent the primary threats SDLP is designed to mitigate: Unauthorized Modifier An actor attempting to alter a digital object, its identity tuple, or its lineage chain without possessing the required authority. This includes malicious editors, compromised applications, or automated processes performing silent modification. Provenance Breaker An actor attempting to sever, rewrite, or forge lineage information to obscure the origin or transformation history of an object. This includes cloning objects, injecting false parentage, or resetting lineage to conceal prior misuse. Distributor Impersonator An actor attempting to present themselves as a legitimate distributor by issuing objects with falsified DistributorID values. This includes compromised distribution systems, spoofed services, or unauthorized mirrors. Lifecycle Diverter An actor attempting to redirect an object's lifecycle path, causing it to appear as though it passed through different systems or workflows. This includes manipulation of download, upload, or transformation events. Metadata Stripper An actor removing SDLP metadata fields (identity, lineage, object- format) to degrade traceability. This includes tools that intentionally or accidentally discard structured metadata during export, transcoding, or editing. Mass-Forgery Automator An actor using automated systems to generate large numbers of falsified SDLP objects in an attempt to overwhelm verification endpoints or poison provenance databases. 3.2. Assumptions SDLP's security model assumes the following: * Distributors maintain secure control over DistributorID issuance systems. * Identity tuples are generated by trusted components within the distributor workflow. * Lineage updates occur only through authorized SDLP-aware applications. * Consumers may use untrusted tools, but verification endpoints remain trustworthy. * Network transport is not inherently secure; SDLP relies on object- level integrity rather than channel security. 3.3. Out-of-Scope Threats SDLP does not attempt to mitigate the following: * Confidentiality breaches. * Digital Rights Management (DRM) enforcement. * Watermark removal. * Platform-level account compromise. * Attacks on external provenance ecosystems (e.g., C2PA, CAI, MovieLabs) beyond the SDLP object boundary. 3.4. Security Goals The SDLP security architecture defines explicit security goals that guide the design, enforcement, and verification of all lifecycle operations. These goals ensure that SDLP-governed objects maintain stable identity, authorized state transitions, and tamper-evident lineage across distributed environments. Identity Authenticity: All actors and objects MUST possess authenticated and verifiable identities. Identity bindings MUST be stable, non-repudiable, and cryptographically attributable throughout the object's lifecycle. Authorized Lifecycle Behavior: All lifecycle transitions MUST be performed only by authenticated and authorized actors. Unauthorized, unverifiable, or out-of-order transitions MUST be rejected. Continuous Lineage Integrity: All lifecycle events MUST produce canonical, signed lineage entries. Lineage MUST form a continuous, tamper-evident chain that accurately reflects the complete history of the object. Tamper-Evident State: All modifications to identity, state, or lineage MUST be detectable. Any attempt to alter, remove, reorder, or forge lifecycle data MUST result in rejection of the operation. Verifiable Lifecycle Attribution: Every lifecycle event MUST be cryptographically attributable to the actor that performed it. Attribution MUST remain stable and verifiable across all compliant implementations. Secure Execution Environment: Objects MUST execute only in environments that preserve identity integrity, transition integrity, and lineage integrity. Execution environments MUST provide trusted signals, key protection, and tamper-evident time sources. Cryptographic Stability: All cryptographic mechanisms, including keys, hashes, and signatures, MUST remain stable and verifiable for the lifetime of their associated roles. Cryptographic validation MUST occur before accepting any lifecycle operation. These security goals define the architectural requirements necessary to ensure that SDLP-governed objects remain authenticated, authorized, and tamper-evident across all lifecycle transitions and distributed environments. 3.5. Security Properties Matrix The SDLP security architecture defines a set of core security properties that mitigate the attacker personas described in Section 3.1. This matrix provides a normative mapping between attacker capabilities and the SDLP properties that prevent, detect, or limit their impact. Implementations MUST enforce these properties to ensure tamper-evident, authenticated, and authorized lifecycle behavior. +--------------------------+-------------------------------+ | Attacker Persona | Mitigating Security Properties| +--------------------------+-------------------------------+ | Unauthorized Modifier | Identity Authenticity | | | Authorized Lifecycle Behavior | | | Tamper-Evident State | | | Continuous Lineage Integrity | +--------------------------+-------------------------------+ | Provenance Breaker | Continuous Lineage Integrity | | | Tamper-Evident State | | | Verifiable Lifecycle | | | Attribution | +--------------------------+-------------------------------+ | Distributor Impersonator | Identity Authenticity | | | Cryptographic Stability | | | Authorized Lifecycle Behavior | +--------------------------+-------------------------------+ | Lifecycle Diverter | Authorized Lifecycle Behavior | | | Continuous Lineage Integrity | | | Verifiable Lifecycle | | | Attribution | +--------------------------+-------------------------------+ | Metadata Stripper | Tamper-Evident State | | | Continuous Lineage Integrity | | | Data Integrity | +--------------------------+-------------------------------+ | Mass-Forgery Automator | Identity Authenticity | | | Cryptographic Stability | | | Verifiable Lifecycle | | | Attribution | +--------------------------+-------------------------------+ This matrix defines the normative relationship between SDLP attacker personas and the architectural properties required to mitigate them. Implementations MUST ensure that all listed properties are enforced for each corresponding threat category. 3.6. Mitigations SDLP defines explicit mitigation mechanisms that address the attacker personas described in Section 3.1 and enforce the security goals defined in Section 3.4. These mitigations ensure that SDLP-governed objects remain authenticated, authorized, and tamper-evident across all lifecycle transitions and distributed environments. Identity Binding Enforcement: All actors and objects MUST use stable, cryptographically verifiable identities. Identity bindings MUST be validated before performing any lifecycle operation, preventing impersonation and unauthorized modification. Authorized Transition Enforcement: All lifecycle transitions MUST be authenticated and authorized according to the SDLP Identity and Lifecycle Models. Unauthorized, unverifiable, or out-of-order transitions MUST be rejected, mitigating attempts to divert or falsify lifecycle behavior. Canonical Lineage Generation: All lifecycle events MUST produce canonical, signed lineage entries. Each entry MUST reference the previous entry through a validated hash, forming a continuous and tamper-evident chain. This mitigates attempts to sever, rewrite, or forge lineage. Signature and Hash Validation: All signatures and hashes associated with identity bindings, lineage entries, and lifecycle transitions MUST be validated before accepting any operation. Invalid or unverifiable cryptographic material MUST result in rejection, mitigating forgery and silent modification. Environment Validation: Objects MUST validate their execution environment before performing lifecycle operations. Detection of unauthorized debugging tools, interception frameworks, or tampering mechanisms MUST result in rejection of the operation, mitigating runtime manipulation. Key Protection and Stability: All cryptographic keys MUST be stored in secure, non-exportable environments. Keys MUST NOT be regenerated, replaced, or exposed to external processes. This mitigates impersonation, forgery, and unauthorized modification. Tamper-Evident State Enforcement: All modifications to identity, state, or lineage MUST be detectable. Any attempt to alter, remove, reorder, or forge lifecycle data MUST result in rejection of the operation, mitigating metadata stripping and unauthorized modification. Verification Requirements: Verification operations MUST validate identity bindings, lineage continuity, transition integrity, and cryptographic signatures. Verification MUST detect missing, reordered, or falsified entries, mitigating provenance-breaking attacks. These mitigations collectively ensure that SDLP-governed objects maintain stable identity, authorized lifecycle behavior, and tamper-evident lineage across all compliant implementations. 4. Authentication Requirements All SDLP lifecycle operations MUST be authenticated. Actors and objects MUST present verifiable credentials bound to identities defined in the SDLP Identity Model before any lifecycle transition is permitted. Authentication ensures that every operation is attributable to a legitimate and authorized entity. Actor Authentication: Distributors, customers, and verification services MUST authenticate using approved cryptographic keys. Actor identities MUST be validated before performing creation, activation, transformation, transfer, verification, retention, or retirement operations. Object Authentication: SDLP-governed objects MUST authenticate themselves using their ObjectKey. Objects MUST verify their identity bindings, lineage continuity, and current lifecycle state before accepting any operation. Signature Requirements: All authenticated operations MUST be signed using approved signature algorithms. Signatures MUST be computed over canonical data and MUST include identity fields, event type, previous hash, new state, and timestamp. Signature verification failure MUST result in rejection of the operation. Credential Binding: Credentials used for authentication MUST be bound to stable, non-repudiable identities. Credentials MUST NOT be shared, substituted, or reused across actors or objects. Credential binding MUST be validated before accepting any lifecycle event. Authentication Failure Handling: If authentication fails, the operation MUST be rejected. Objects MUST NOT perform lifecycle transitions, accept lineage entries, or modify internal state when authentication cannot be verified. These authentication requirements ensure that all SDLP lifecycle operations are performed only by authenticated entities and that every transition is cryptographically attributable and verifiable. 5. Authorization Boundaries SDLP defines strict authorization boundaries for all lifecycle operations. Each operation MUST be performed only by actors whose identities and roles have been authenticated according to the SDLP Identity Model. Implementations MUST enforce these boundaries before permitting any lifecycle transition. Creation: Only authorized distributors MAY create new SDLP-governed objects. Creation events MUST be signed with a valid DistributorKey and MUST establish the initial identity and lineage context for the object. Activation: Activation binds an object to a customer identity. Only the legitimate customer, or an authorized activation service acting on behalf of the customer, MAY perform activation. Activation MUST be authenticated and MUST produce a canonical lineage entry. Distribution: Distribution MAY occur only through authorized SDLP mechanisms. Unauthorized redistribution, duplication, or propagation MUST be rejected. Distribution events MUST preserve identity and lineage integrity. Transformation: Transformations, including state transitions defined in the SDLP Lifecycle Model, MAY occur only when the actor performing the operation is authorized to do so. Unauthorized transformations MUST be rejected and MUST NOT produce lineage entries. Verification: Verification operations MAY be performed by any authorized SDLP participant. Verification MUST validate identity bindings, lineage continuity, and transition integrity before accepting the object's current state. Retention: Retention, including archival or long-term storage, MUST occur only under authorized conditions. Retention MUST NOT alter identity, lineage, or lifecycle state. Retirement: Retirement transitions, including termination or destruction, MUST be performed only by authorized actors and MUST follow the rules defined in the SDLP Lifecycle Model. Retirement events MUST be authenticated and MUST produce a final lineage entry. These authorization boundaries ensure that all SDLP lifecycle operations are performed only by authenticated and authorized actors, preserving the security and integrity of SDLP-governed objects across all compliant implementations. 6. Integrity Guarantees SDLP requires that all lifecycle operations preserve identity, state, and lineage integrity. Implementations MUST ensure that every transition, transformation, and verification event maintains a consistent and tamper-evident security posture across the entire lifecycle of the object. Identity Integrity: Identity bindings MUST remain stable and non-repudiable. Objects, distributors, and customers MUST use approved cryptographic keys, and identity fields MUST NOT be altered, substituted, or regenerated outside SDLP-defined processes. State Integrity: All lifecycle transitions MUST conform to the deterministic state machine defined in the SDLP Lifecycle Model. Objects MUST reject transitions that violate state rules, occur out of order, or originate from unauthorized actors. Lineage Integrity: Lineage entries MUST be canonical, complete, and signed using the ObjectKey. Each entry MUST reference the previous entry through a validated hash, forming a continuous and tamper-evident chain. Missing, reordered, or falsified entries MUST result in rejection of the operation. Transition Integrity: All lifecycle events MUST be authenticated and MUST produce verifiable lineage entries. Objects MUST validate signatures, timestamps, event types, and state transitions before accepting any operation. Data Integrity: All data used in lifecycle operations, including identity fields, lineage structures, and state information, MUST be encoded using canonical formats defined in SDLP companion specifications. Non-canonical or ambiguous encodings MUST be rejected. Integrity Failure Handling: If any integrity check fails, the operation MUST be rejected. Objects MUST NOT modify internal state, accept lineage entries, or perform lifecycle transitions when integrity cannot be verified. These integrity guarantees ensure that SDLP-governed objects remain verifiable, tamper-evident, and consistent across all compliant implementations, providing a stable foundation for secure lifecycle behavior. 7. Cryptographic Requirements SDLP relies on deterministic, verifiable, and tamper-evident cryptographic operations to ensure identity integrity, transition integrity, and lineage integrity. All cryptographic mechanisms used in SDLP-governed objects MUST conform to the requirements defined in this section. Hashing Requirements: SDLP objects MUST use approved cryptographic hash functions with at least 256-bit output. Hashes MUST be computed over canonical byte-encoded data and MUST be validated before accepting any lineage entry or lifecycle transition. Signature Requirements: All lifecycle operations MUST be authenticated using asymmetric signature algorithms providing at least 128-bit security strength. Signatures MUST be computed over canonical payloads and MUST include identity fields, event type, previous hash, new state, and timestamp. Signature verification failure MUST result in rejection of the operation. Key Roles: SDLP defines distinct cryptographic keys for specific roles: * DistributorKey: Used to authenticate creation and product metadata. * CustomerKey: Used to authenticate ownership-binding and transfer events. * ObjectKey: Used by the object to sign lineage entries and validate internal state. * PolicyAuthorityKey: Used to authenticate policy versions. Key Protection: Keys MUST be stored only in secure, non-exportable environments. Keys MUST NOT be written to disk in plaintext, included in backups, or exposed to external processes. Any attempt to access, modify, or replace key material MUST result in rejection of the operation. Key Stability: Keys MUST remain stable for the lifetime of their associated roles. ObjectKeys MUST NOT be regenerated, rotated, or replaced after instantiation. DistributorKeys and CustomerKeys MUST remain bound to their respective identities. Zeroization Requirements: When an object is retired or destroyed, its ObjectKey MUST be irreversibly zeroized. Zeroization MUST remove all key material from memory, secure storage, caches, and hardware-backed enclaves. Zeroized keys MUST NOT be recoverable or reissued. Cryptographic Validation: Objects MUST validate all hashes, signatures, and key bindings before performing lifecycle operations. Validation MUST occur at startup, before accepting lineage entries, and before executing any state transition. These cryptographic requirements ensure that SDLP-governed objects maintain stable identity, verifiable lineage, and tamper-evident lifecycle behavior across all compliant implementations. 8. Environment Validation SDLP-governed objects MUST execute only in environments that provide sufficient guarantees to preserve identity integrity, transition integrity, and lineage integrity. Before performing any lifecycle operation, an object MUST validate that its execution environment meets the minimum security requirements defined in this section. Trusted Execution Signals: The environment MUST provide stable and verifiable signals that allow the object to confirm that it is executing on a legitimate platform. These signals MAY include hardware-backed identity, secure enclaves, or equivalent mechanisms defined in companion specifications. Integrity Protection: The environment MUST prevent unauthorized modification of the object's code, data, and lineage. Protection mechanisms MUST ensure that memory tampering, binary patching, and unauthorized instrumentation cannot alter lifecycle behavior or compromise cryptographic material. Key Protection: The environment MUST provide secure storage for cryptographic keys, including the ObjectKey and any associated identity or policy keys. Secure storage MUST prevent extraction, rollback, duplication, or unauthorized access to key material. Debugging and Interception Controls: The environment MUST restrict or disable unauthorized debugging tools, interception frameworks, and runtime manipulation mechanisms. If such tools are detected, the object MUST reject the operation and MUST NOT perform lifecycle transitions. Time Source Requirements: The environment MUST provide a reliable and tamper-evident time source for validating timestamps associated with lineage entries and lifecycle transitions. Time inconsistencies MUST result in rejection of the operation. Validation Failure Handling: If environment validation fails, the object MUST reject the operation. Objects MUST NOT perform lifecycle transitions, accept lineage entries, or modify internal state when the environment cannot be verified. These environment validation requirements ensure that SDLP-governed objects execute only under conditions that preserve identity, transition, and lineage integrity across all compliant implementations. 9. IANA Considerations This document has no actions for IANA. SDLP defines no protocol parameters, registries, code points, or identifier spaces requiring IANA allocation or modification. No new registries are created, and no existing registries are updated by this specification. 10. Security Considerations This document defines the security architecture for SDLP-governed objects and therefore consists entirely of security considerations. All requirements, guarantees, and validation rules described in this specification are normative and MUST be enforced by compliant implementations. Implementers MUST ensure that identity bindings, lifecycle transitions, and lineage structures are authenticated, authorized, and cryptographically verifiable. Failure to enforce these requirements can result in impersonation, unauthorized modification, lineage forgery, or diversion of lifecycle behavior. SDLP does not provide confidentiality protections. Implementations requiring confidentiality MUST rely on external mechanisms such as transport-layer encryption, object-level encryption, or platform- specific confidentiality controls. SDLP relies on secure execution environments to preserve identity integrity, transition integrity, and lineage integrity. Implementers MUST ensure that objects execute only in environments that provide trusted signals, key protection, tamper-evident time sources, and resistance to debugging or interception. No additional security considerations beyond those described in this document are required. Appendix A. Example Lifecycle Event (Informative) This appendix provides an illustrative example of a canonical SDLP lifecycle event. The example is non-normative and is intended to demonstrate how identity bindings, lifecycle transitions, and lineage entries interact during an authorized operation. A.1. Example: Authorized Transformation Event The following example describes a transformation event performed by an authorized actor. The event demonstrates identity authentication, state validation, and canonical lineage generation. Actor Identity: ActorID: 93F2A1C8-4B77-4E2D-9A11-2C9E5E1D8F42 ActorRole: Customer ActorKey: CustomerKey-7A9C Object Identity: ObjectID: 5C11D2F4-8A33-4E9B-9F7C-1A2D4B9E7C55 DistributorID: D-2048 CustomerID: C-7781 ObjectKey: ObjectKey-992E Previous Lineage Entry: EventType: activation PreviousHash: 4F8C9A1D7E22B3C1A9D4F1C8E7A2B9C3D1F0A44 Timestamp: 2026-07-12T14:03:55Z State: active Transformation Request: RequestedEvent: transform RequestedState: transformed Timestamp: 2026-07-17T06:22:14Z Validation Steps: * Actor identity authenticated using CustomerKey-7A9C. * Object identity validated using ObjectKey-992E. * Previous state confirmed as "active". * Requested transition validated against SDLP Lifecycle Model. * Execution environment validated. Canonical Lineage Entry (Generated): EventType: transform PreviousHash: 4F8C9A1D7E22B3C1A9D4F1C8E7A2B9C3D1F0A44 NewState: transformed Timestamp: 2026-07-17T06:22:14Z ActorID: 93F2A1C8-4B77-4E2D-9A11-2C9E5E1D8F42 Signature: SIG-ObjectKey-992E-AB44F19C77D2E8C1 This example illustrates how SDLP enforces identity authenticity, authorized lifecycle behavior, and continuous lineage integrity during a transformation event. All fields shown are representative and provided for explanatory purposes only. Appendix B. Example Lineage Chain (Informative) This appendix provides an illustrative example of a canonical SDLP lineage chain. The example is non-normative and demonstrates how lifecycle events form a continuous, tamper-evident sequence of signed lineage entries. B.1. Example: Three-Event Lineage Chain The following lineage entries represent a creation event, activation event, and transformation event performed by authorized actors. Lineage Entry 1: EventType: creation PreviousHash: 0000000000000000000000000000000000000000 NewState: created Timestamp: 2026-07-10T09:14:22Z ActorID: D-2048 Signature: SIG-DistributorKey-2048-11ACF9D2E7B1C3A9 Lineage Entry 2: EventType: activation PreviousHash: 11ACF9D2E7B1C3A9F88D2C1A4E9B7C2D1F0A3341 NewState: active Timestamp: 2026-07-12T14:03:55Z ActorID: C-7781 Signature: SIG-CustomerKey-7781-9B22C1F7D4A8E3C1 Lineage Entry 3: EventType: transform PreviousHash: 9B22C1F7D4A8E3C1A7F9D2B1C4E8A3F1D0C9B244 NewState: transformed Timestamp: 2026-07-17T06:22:14Z ActorID: C-7781 Signature: SIG-ObjectKey-992E-AB44F19C77D2E8C1 This example illustrates how SDLP lineage entries form a continuous chain, where each entry references the previous entry through a validated hash and is signed using the appropriate cryptographic key. Appendix C. Example Environment Validation Failure (Informative) This appendix provides an illustrative example of an environment validation failure. The example is non-normative and demonstrates how SDLP-governed objects respond when execution conditions cannot be verified. C.1. Example: Debugger Detected The following scenario describes an object rejecting a lifecycle operation due to detection of an unauthorized debugging tool. Environment Signals: PlatformIdentity: Verified SecureStorage: Verified TimeSource: Verified DebuggerPresent: TRUE InterceptionTools: NONE Lifecycle Request: RequestedEvent: transform RequestedState: transformed Timestamp: 2026-07-17T06:22:14Z Validation Outcome: * Environment identity verified. * Key protection verified. * Time source verified. * Unauthorized debugger detected. Result: OperationStatus: rejected Reason: environment-validation-failure ErrorCode: SDLP-EV-DEBUGGER-DETECTED This example illustrates how SDLP-governed objects MUST reject lifecycle operations when unauthorized debugging or interception tools are detected, preserving transition integrity and lineage integrity. Appendix D. Example Unauthorized Transition Rejection (Informative) This appendix provides an illustrative example of an unauthorized lifecycle transition. The example is non-normative and demonstrates how SDLP-governed objects enforce authorization boundaries. D.1. Example: Unauthorized Transformation Attempt Actor Identity: ActorID: 55A1C9D2-7F33-4E1B-8A22-1C9D5E7A3F11 ActorRole: Unauthenticated ActorKey: NONE Object Identity: ObjectID: 5C11D2F4-8A33-4E9B-9F7C-1A2D4B9E7C55 CurrentState: active Unauthorized Request: RequestedEvent: transform RequestedState: transformed Timestamp: 2026-07-17T06:22:14Z Validation Steps: * Actor identity could not be authenticated. * Actor role not authorized for transformation. * Requested transition requires authenticated customer identity. Result: OperationStatus: rejected Reason: unauthorized-transition ErrorCode: SDLP-AUTH-UNAUTHORIZED-ACTOR This example illustrates how SDLP-governed objects MUST reject lifecycle transitions initiated by unauthenticated or unauthorized actors, preserving authorized lifecycle behavior and preventing tampering. Author's Address M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com Appendix E. Change Log (Informative) draft-norton-sdlp-sec-arch-04 * Added Section 3.4 Security Goals. * Added Section 3.5 Security Properties Matrix. * Added Section 3.6 Mitigations. * Added Section 9 IANA Considerations. * Added Section 10 Security Considerations. * Added Appendix A, Appendix B, Appendix C, Appendix D. * Updated title page dates and version number. draft-norton-sdlp-sec-arch-03 * Initial submission of the SDLP Security Architecture.