Supply Chain Integrity, Transparency, and Trust Working Group N. Aoki Internet-Draft The Graduate University for Advanced Studies (SOKENDAI) Intended status: Standards Track 7 July 2026 Expires: 8 January 2027 SCITT Statement Relationship and Protected Object Binding draft-nobuo-scitt-protected-object-binding-00 Abstract This document defines a small common model for relating Supply Chain Integrity, Transparency, and Trust (SCITT) Signed Statements to the supply-chain objects that those statements describe, measure, authorize, revoke, or audit. The model can be used for software artifacts, firmware artifacts, hardware components, device instances, cloud compute resources, and other objects that appear in supply- chain evidence. The document also defines a relationship vocabulary and an optional Statement Graph Manifest. These parts help verifiers connect heterogeneous SCITT statements without requiring SCITT to define the payload formats of those statements. This document does not define SBOM, HBOM, CBOM, attestation, audit, vulnerability, or regulatory payload formats. It only defines a common binding and graph layer around SCITT statements and receipts. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://aoki- n1.github.io/draft-nobuo-scitt-protected-object-binding/draft-nobuo- scitt-protected-object-binding.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- nobuo-scitt-protected-object-binding/. Discussion of this document takes place on the SCITT Working Group mailing list (mailto:scitt@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/scitt/. Subscribe at https://www.ietf.org/mailman/listinfo/scitt/. Source for this draft and an issue tracker can be found at https://github.com/aoki-n1/draft-nobuo-scitt-protected-object- binding. Aoki Expires 8 January 2027 [Page 1] Internet-Draft SCITT Object Binding July 2026 Status of This Memo 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." This Internet-Draft will expire on 8 January 2027. Copyright Notice 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Working Group Context . . . . . . . . . . . . . . . . . . . . 4 3. Why This Is Still About Statements . . . . . . . . . . . . . 5 4. Scope Questions and Answers . . . . . . . . . . . . . . . . . 5 5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Conventions and Definitions . . . . . . . . . . . . . . . . . 7 8. Protected Object Binding Model . . . . . . . . . . . . . . . 8 9. Statement Reference . . . . . . . . . . . . . . . . . . . . . 9 10. Receipt Reference . . . . . . . . . . . . . . . . . . . . . . 10 11. Relationship Edge . . . . . . . . . . . . . . . . . . . . . . 10 12. Initial Relationship Vocabulary . . . . . . . . . . . . . . . 11 13. Initial Object Types . . . . . . . . . . . . . . . . . . . . 12 14. Statements about Statements . . . . . . . . . . . . . . . . . 13 15. Statement Graph Manifest . . . . . . . . . . . . . . . . . . 13 Aoki Expires 8 January 2027 [Page 2] Internet-Draft SCITT Object Binding July 2026 16. Graph Digest Requirements . . . . . . . . . . . . . . . . . . 16 17. Placement of Binding Data . . . . . . . . . . . . . . . . . . 16 18. Verification Procedure . . . . . . . . . . . . . . . . . . . 17 19. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 20. Security Considerations . . . . . . . . . . . . . . . . . . . 18 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 22.1. Normative References . . . . . . . . . . . . . . . . . . 19 22.2. Informative References . . . . . . . . . . . . . . . . . 20 Design Notes for Future Revisions . . . . . . . . . . . . . . . . 21 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction SCITT [RFC9943] defines an architecture for trustworthy and transparent supply-chain statements. A producer signs a statement, a Transparency Service registers it, and a consumer can later verify the signed statement and its receipt. Many supply-chain decisions need more than one statement. A device can be covered by a device identity statement, a hardware statement, a firmware SBOM, an update authorization statement, an attestation result, a vulnerability statement, and an audit statement. Each statement can be valid by itself, but a consumer often needs to know whether these statements refer to the same object and how they relate to each other. SCITT intentionally keeps payloads opaque to the common layer. This is useful because different ecosystems use different payload formats. It also creates a small gap: a generic verifier can verify that a statement was registered, but it may not know what object the statement is about unless it understands the payload. That makes graph discovery, evidence packaging, and cross-domain tools harder. This document fills that gap with a narrow binding model. It does not turn SCITT into a hardware or cloud assurance framework. It also does not ask the Transparency Service to understand every payload. Instead, it defines a small set of optional common fields that can be carried by a profile, a payload, or a future envelope extension. These fields say which object a statement is about and how that statement relates to other statements. The model is intended to support the following tasks: * linking a statement to a software, firmware, hardware, device, or cloud object; Aoki Expires 8 January 2027 [Page 3] Internet-Draft SCITT Object Binding July 2026 * referring to a SCITT statement and its receipt in a stable way; * expressing common relationships such as describes, measures, authorizes, supersedes, and revokes; * building a small graph of evidence for later verification; and * keeping domain-specific semantics in domain profiles. TODO: Align this document with the latest SCITT Architecture terminology before submission. In particular, confirm whether the term "Protected Object" should be replaced with "Supply-Chain Object", "Artifact Subject", or another term. 2. Working Group Context The design of this draft follows two points that have come up in SCITT discussions. First, SCITT is already able to carry statements from more than one party about the same subject. One party can publish a statement about an artifact, and another party can later publish a counter- statement, a fix statement, or an audit statement. This draft makes that pattern easier to use by giving tools a small way to name the subject and to describe the relationship between statements. Second, SCITT is content-agnostic by design. This is important. It lets SCITT work with many payload formats. The same design also means that a generic tool cannot always find the subject, the graph, or the latest related statement without help. This draft provides that help as optional metadata and graph statements. The signed statement is still the SCITT unit of registration. The IETF 122 discussion noted that SCITT can link things together through subjects and statements, but that this is not inherent in the basic model. It also noted that reliable locators in SCRAPI can be used as pointers, and that "statements about statements" may help describe messy build or update flows. The IETF 124 discussion raised the same design question for software, hardware, and other artifacts: where should graph information live, and how much should the common SCITT layer expose? This draft takes a conservative position. It does not change the basic Transparency Service function. A Transparency Service can still register signed statements and return receipts. Graph support can be provided by profiles, graph manifest statements, protected metadata if defined by a future profile, or auxiliary services. Aoki Expires 8 January 2027 [Page 4] Internet-Draft SCITT Object Binding July 2026 3. Why This Is Still About Statements A likely question is why SCITT needs an object binding model when SCITT already works with statements. The answer is that this document does not make objects a new primary SCITT resource. The signed statement remains the unit registered in SCITT. The object binding is only a common way to say what that statement is about. This distinction matters for scope: * A Transparency Service can continue to register opaque signed statements. * A domain profile can decide whether the binding is placed in the payload, in a protected header, or in a separate graph manifest. * A verifier can use the binding only when it needs cross-statement analysis. * The truth of the payload remains a domain and issuer matter. The binding is therefore an aid for statement discovery and statement graph construction. It is not a new guarantee that the object is safe, compliant, or correct. 4. Scope Questions and Answers This section records expected scope questions. *Question:* SCITT handles statements. Why define Protected Objects? *Answer:* Protected Objects are not a new SCITT registry resource. They are a small way to identify what a statement is about. The registered item remains a Signed Statement. The binding only helps a verifier connect several statements that refer to the same object. *Question:* Does this draft make SCITT a hardware supply-chain standard? *Answer:* No. Hardware-specific assurance, HBOM formats, hardware roots of trust, and manufacturer policy remain outside this draft. This draft only says how a signed statement about such material can be linked to other SCITT statements and receipts. *Question:* Does this draft require SCRAPI to become a graph API? Aoki Expires 8 January 2027 [Page 5] Internet-Draft SCITT Object Binding July 2026 *Answer:* No. SCRAPI can remain a registration and receipt API. Graph discovery can be done by a later auxiliary service or by exchanging a Statement Graph Manifest. *Question:* Does a valid graph prove that all claims are true? *Answer:* No. A valid graph proves that the statements, receipts, and relationships satisfy a chosen verification policy. It does not prove that an issuer told the truth. 5. Scope This document is in scope when it defines common building blocks for relating SCITT Signed Statements and receipts. These building blocks are useful across software, firmware, hardware, IoT, cloud, and other supply-chain domains. This document defines: * a Protected Object Binding information model; * Statement Reference and Receipt Reference information models; * a small relationship vocabulary; * an optional Statement Graph Manifest; and * common verification and security considerations. 6. Non-Goals This document does not: * define the payload format for SBOM, HBOM, CBOM, VEX, attestation evidence, audit reports, regulatory reports, or operational logs; * define whether a manufacturer, cloud provider, device operator, auditor, or regulator made a true claim; * define a global registry for devices, hardware, cloud resources, or supply chain objects; * define best practices for designing a software, hardware, IoT, or cloud supply chain; * require a Transparency Service to index or query graphs; Aoki Expires 8 January 2027 [Page 6] Internet-Draft SCITT Object Binding July 2026 * require a particular identifier scheme for devices, hardware, or cloud resources; * define an authorization policy language; or * define domain-specific compliance rules. TODO: Decide whether this document should stay Standards Track or begin as Informational until the WG agrees on the boundary between generic SCITT metadata and domain-specific payloads. 7. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses CBOR diagnostic notation where helpful. JSON examples are illustrative unless a profile states otherwise. Protected Object: A physical or non-physical supply-chain object about which one or more SCITT Signed Statements are made. Examples include a software package, firmware image, source repository, container image, hardware component, device instance, virtual machine, confidential-computing enclave, GPU allocation, cloud service, or integrated product. Object Binding: A data structure that relates a SCITT Signed Statement to a Protected Object. Statement Reference: A stable reference to a SCITT Signed Statement, a statement digest, a Transparency Service registration identifier, or another identifier that lets a verifier retrieve or identify the statement. Receipt Reference: A stable reference to a SCITT receipt or receipt bundle that lets a verifier verify registration of a statement in a Transparency Service. Relationship Edge: A directed edge that states how two nodes are related. A node can be a Protected Object, a Statement Reference, or a Receipt Reference. Statement Graph: A set of nodes and Relationship Edges. Statement Graph Manifest: A signed statement that commits to a Aoki Expires 8 January 2027 [Page 7] Internet-Draft SCITT Object Binding July 2026 Statement Graph or to a useful subset of a Statement Graph. Subject: The main node to which a graph, manifest, or verification request applies. 8. Protected Object Binding Model A Protected Object Binding identifies the object that a statement describes, measures, authorizes, revokes, audits, or otherwise relates to. The binding is meant to be small. A profile can add fields, but it SHOULD keep the common binding stable enough for generic tools to compare objects and build graphs. ; This CDDL is provisional and needs WG review. protected-object-binding = { object_type: tstr, object_id: tstr, ? object_digest: digest, ? object_locator: [+ tstr], ? object_instance_id: tstr, ? lifecycle_phase: lifecycle-phase, ? object_namespace: tstr, ? issuer_scope: tstr, ? object_attributes: {* tstr => any} } digest = { alg: tstr, value: bytes } lifecycle-phase = "design" / "build" / "manufacture" / "provision" / "deploy" / "operate" / "update" / "audit" / "repair" / "transfer" / "retire" / "decommission" / tstr The object_type field identifies the kind of object. Initial values are listed in Section 13. The object_id field identifies the object within a namespace chosen by an issuer, a domain profile, or another recognized authority. This document does not create a single global identifier system. Aoki Expires 8 January 2027 [Page 8] Internet-Draft SCITT Object Binding July 2026 The object_digest field binds the object to bytes, measurements, a canonical descriptor, or another profile-defined representation. Some hardware and cloud resources do not have one stable byte string. In such cases, a profile can use a measurement digest, configuration digest, or other fingerprint. The object_locator field gives one or more locations where an object or object descriptor can be found. A locator MUST NOT be treated as stable identity unless a profile says so. The object_instance_id field distinguishes an object class from a specific object instance. For example, a firmware digest can identify an artifact, while a serial number or attested device identity can identify a device instance. The lifecycle_phase field gives coarse lifecycle context. It is not a full lifecycle model. A domain profile can define more precise values. The issuer_scope field can be used when an object_id is only meaningful in the issuer's namespace. 9. Statement Reference A Statement Reference identifies a SCITT statement that is part of a graph. ; This CDDL is provisional and needs WG review. statement-reference = { ? statement_uri: tstr, ? statement_digest: digest, ? registration_id: tstr, ? transparency_service: tstr, ? content_type: tstr, ? issuer: tstr, ? issued_at: time, ? attributes: {* tstr => any} } A Statement Reference MUST contain enough information for the intended verifier to identify the statement. A profile MAY require a digest, URI, registration identifier, or a combination of these values. A verifier MUST NOT trust a URI by itself. When a digest is present, the retrieved statement MUST match the digest. When a receipt is present, the verifier MUST verify the receipt under the applicable receipt profile. Aoki Expires 8 January 2027 [Page 9] Internet-Draft SCITT Object Binding July 2026 10. Receipt Reference A Receipt Reference identifies a receipt for a statement. ; This CDDL is provisional and needs WG review. receipt-reference = { ? receipt_uri: tstr, ? receipt_digest: digest, ? receipt_type: tstr, ? transparency_service: tstr, ? registration_id: tstr, ? attributes: {* tstr => any} } A Receipt Reference MAY identify a detached receipt, an embedded receipt, or a bundle of receipts. A verifier MUST apply the receipt profile named or implied by the receipt. 11. Relationship Edge A Relationship Edge connects two graph nodes. The edge states a relation name, the source node, and the target node. ; This CDDL is provisional and needs WG review. relationship-edge = { from: node-id, relation: relation-name, to: node-id, ? asserted_by: statement-reference, ? valid_from: time, ? valid_until: time, ? confidence: tstr, ? attributes: {* tstr => any} } node-id = tstr relation-name = tstr The asserted_by field can identify the statement that asserts the edge. A profile SHOULD use this field when edge authority matters. A verifier MUST apply a policy that states which issuers are allowed to assert which relations. A valid signature alone does not give authority to assert any relation. Aoki Expires 8 January 2027 [Page 10] Internet-Draft SCITT Object Binding July 2026 12. Initial Relationship Vocabulary This document defines the following initial relation names. Relation names are case-sensitive ASCII strings. A profile MAY define extra names using a URI or a registered extension value. describes: The source statement describes the target object or statement. identifies: The source statement provides identity information for the target object. partOf: The source object is a part of the target object. contains: The source object contains the target object. builtFrom: The source object was built from the target object. derivedFrom: The source object or statement is derived from the target object or statement. runsOn: The source software, firmware, or workload runs on the target platform or compute resource. measures: The source statement reports a measurement of the target object. attests: The source statement attests to a property of the target object. authorizes: The source statement authorizes an action concerning the target object. observes: The source statement records an observed state or event concerning the target object. supersedes: The source statement replaces the target statement for a purpose defined by policy. revokes: The source statement says that the target statement should not be accepted for a purpose defined by policy. conflictsWith: The source statement cannot be accepted with the target statement under the same policy unless that policy resolves the conflict. aggregates: The source statement groups the target statements or objects. Aoki Expires 8 January 2027 [Page 11] Internet-Draft SCITT Object Binding July 2026 dependsOn: The source statement or object depends on the target statement or object. audits: The source statement is an audit result for the target statement or object. TODO: Decide whether this vocabulary should be an IANA registry, a closed list, or a profile-specific registry with expert review. 13. Initial Object Types This document defines the following initial object type strings: * source-repository * software-package * container-image * firmware-image * hardware-component * hardware-platform * device-class * device-instance * cloud-image * cloud-compute-resource * confidential-computing-environment * accelerator-resource * service-endpoint * integrated-product TODO: Decide whether terms such as TPM, TEE, GPU, and IoT gateway should be registered object types or examples under broader object types. Aoki Expires 8 January 2027 [Page 12] Internet-Draft SCITT Object Binding July 2026 14. Statements about Statements A Statement Graph can include a statement that is about another statement. This pattern is useful when a later event changes how a previous statement should be used. Examples include: * a vulnerability statement that refers to a previous SBOM statement; * a fix statement that says a reported issue has been corrected; * a revocation statement for a previous release statement; * an audit statement about a submitted statement; * a supersession statement that says a new statement is the current one for a given purpose; and * a graph manifest statement that commits to a set of statement references and relationship edges. This draft does not define the payload format of these statements. It only defines references and relation names that allow a verifier to build a graph. A profile MUST say which issuers are allowed to assert a relationship about another statement. For example, an arbitrary third party should not be able to revoke a manufacturer statement unless the verification policy grants that authority. 15. Statement Graph Manifest A Statement Graph Manifest packages a set of nodes and edges. It can be used for offline verification, for evidence exchange, or to commit to a graph digest. The manifest MAY itself be a SCITT Signed Statement. Aoki Expires 8 January 2027 [Page 13] Internet-Draft SCITT Object Binding July 2026 ; This CDDL is provisional and needs WG review. statement-graph-manifest = { graph_type: "scitt-statement-graph/v1", subject: node-id, nodes: [+ graph-node], edges: [+ relationship-edge], ? graph_policy: tstr, ? graph_digest: digest, ? generated_at: time, ? expires_at: time, ? profile: tstr, ? attributes: {* tstr => any} } graph-node = { id: node-id, node: protected-object-binding / statement-reference, ? receipt: receipt-reference, ? attributes: {* tstr => any} } The following example is illustrative. Aoki Expires 8 January 2027 [Page 14] Internet-Draft SCITT Object Binding July 2026 { "graph_type": "scitt-statement-graph/v1", "subject": "device", "nodes": [ { "id": "device", "node": { "object_type": "device-instance", "object_id": "urn:example:device:gateway-1234" } }, { "id": "firmware-sbom", "node": { "statement_digest": { "alg": "sha-256", "value": "TODO-base64url" }, "content_type": "application/example-firmware-sbom+json" }, "receipt": { "receipt_digest": { "alg": "sha-256", "value": "TODO-base64url" } } } ], "edges": [ { "from": "firmware-sbom", "relation": "describes", "to": "device" } ], "graph_policy": "iot-device-integrity/v1" } TODO: Define a canonical graph digest algorithm. The algorithm needs to handle node ordering, edge ordering, duplicate edges, and differences between JSON and CBOR encodings. The IETF 124 discussion noted that deterministic encoding is an open issue for graph work; this draft should not claim that problem is solved until the WG agrees on an approach. Aoki Expires 8 January 2027 [Page 15] Internet-Draft SCITT Object Binding July 2026 16. Graph Digest Requirements A graph digest is useful when a graph is exchanged between tools or registered as a statement. A graph digest can also help a verifier detect that a graph was changed after it was prepared. A future version of this document needs a deterministic graph digest algorithm. The algorithm should define at least the following: * the canonical form of each node; * the canonical form of each edge; * how node identifiers are sorted; * how edges are sorted; * how duplicate edges are handled; * how missing optional fields are handled; * how JSON and CBOR encodings are compared, if both are allowed; and * how profiles add fields without breaking the digest. Until that algorithm is defined, implementations SHOULD NOT compare graph digests across independent implementations unless they use the same private profile. TODO: Define or reference a deterministic encoding and graph digest method after WG review. 17. Placement of Binding Data A binding can appear in more than one place. This document does not require one placement. A profile MAY place binding data: * inside the payload of a domain-specific SCITT statement; * in a generic graph manifest statement; * in a protected header if a future SCITT or COSE profile defines such use; or * in an auxiliary service response that is verified against registered statements and receipts. Aoki Expires 8 January 2027 [Page 16] Internet-Draft SCITT Object Binding July 2026 A profile MUST state which placement it uses. A verifier MUST know which placement is authoritative for the profile it is applying. TODO: Coordinate this section with any SCITT list discussion on whether some metadata about opaque payloads belongs in a COSE protected header. 18. Verification Procedure A verifier that processes a Statement Graph Manifest SHOULD perform the following steps: 1. Parse the manifest and validate its syntax. 2. Resolve each Statement Reference required by the applicable policy. 3. Verify each Signed Statement according to COSE and SCITT requirements. 4. Verify each receipt according to the applicable receipt profile. 5. Validate that each required statement is bound to the expected Protected Object. 6. Construct the graph from nodes and edges. 7. Check that each required edge is present. 8. Check that each edge was asserted by an issuer allowed by policy. 9. Report missing statements, invalid receipts, stale statements, unresolved references, and conflicts. A verifier MUST NOT treat successful graph verification as proof that all claims inside the statement payloads are true. Successful graph verification only means that the statements, receipts, and edges satisfy the selected policy. 19. Privacy Considerations Object identifiers and graph edges can reveal sensitive information about customers, devices, cloud tenants, locations, supply-chain partners, and operational dependencies. Aoki Expires 8 January 2027 [Page 17] Internet-Draft SCITT Object Binding July 2026 Profiles using this document SHOULD minimize public identifiers when public Transparency Services are used. They MAY use pseudonymous identifiers, salted commitments, encrypted payloads, access- controlled graph manifests, or selective disclosure. A privacy mechanism MUST still allow the intended verifier to confirm the object binding and relationship semantics required by policy. 20. Security Considerations This document introduces graph-level relationships that can affect verifier decisions. A wrong or malicious edge can make an evidence set look complete when it is not. Implementations MUST verify signatures and receipts before using any edge. Implementations MUST also apply an authorization policy for relation assertions. The following risks need attention: * Confused identity: two different objects are treated as the same object. * Graph injection: a presenter adds irrelevant but valid statements to a graph. * Omitted conflict: a presenter omits a conflicting statement. * Unauthorized revocation: an issuer revokes or supersedes a statement without authority. * Stale graph: a verifier accepts old evidence as if it were current. * Privacy leakage: a graph reveals sensitive operational relationships. * Ambiguous encoding: two implementations compute different graph digests for the same intended graph. TODO: Add a formal threat model aligned with the SCITT Architecture threat model and with RATS terminology where attestation results are used. 21. IANA Considerations This document requests no IANA action yet. Aoki Expires 8 January 2027 [Page 18] Internet-Draft SCITT Object Binding July 2026 TODO: The WG should decide whether to create registries for: * SCITT protected object type names; * SCITT relation names; * SCITT graph manifest media types; and * graph verification result codes. If registries are created, this document should define registration policies and initial contents. 22. References 22.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . Aoki Expires 8 January 2027 [Page 19] Internet-Draft SCITT Object Binding July 2026 [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . 22.2. Informative References [I-D.ietf-scitt-receipts-ccf-profile] "CCF Profile for COSE Receipts", n.d., . [I-D.ietf-scitt-scrapi] "Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs", n.d., . [I-D.nobuo-scitt-composite-evidence-verification] "Composite Evidence Verification for SCITT Statement Graphs", n.d., . [I-D.nobuo-scitt-hardware-iot-cloud-use-cases] "Applying SCITT to Hardware, IoT Device, and Cloud Compute Resource Supply Chains", n.d., . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9335] Uberti, J., Jennings, C., and S. Murillo, "Completely Encrypting RTP Header Extensions and Contributing Sources", RFC 9335, DOI 10.17487/RFC9335, January 2023, . [TODO-SBOM-HBOM-CBOM] "TODO - Add references for SBOM, HBOM, CBOM, VEX, and related payload formats", n.d., . Aoki Expires 8 January 2027 [Page 20] Internet-Draft SCITT Object Binding July 2026 Design Notes for Future Revisions This revision reflects four working assumptions. First, the generic layer should not need to parse every domain payload. A small binding layer can help tools build graphs even when payloads remain opaque. Second, graph support should not delay the core SCITT Reference API. A graph manifest or auxiliary service can be developed outside the basic Transparency Service registration path. Third, statements about statements are useful for build failures, fixes, revocations, audit results, and "latest statement" questions. The relation vocabulary should support this pattern without forcing every payload to use the same schema. Fourth, hardware and cloud examples should be used carefully. They motivate the generic binding model, but they do not turn this draft into a hardware or cloud assurance specification. Acknowledgments The author thanks the SCITT WG participants for discussions on opaque payloads, relationship metadata, graph building, and hardware supply- chain use cases. The SCITT and OCP case-study discussion helped sharpen the scope boundary between SCITT statements and domain- specific hardware claims. Author's Address Nobuo Aoki The Graduate University for Advanced Studies (SOKENDAI) Japan Email: n_aoki@ieee.org Aoki Expires 8 January 2027 [Page 21]