Applying SCITT to Hardware, IoT Device, and Cloud Compute Resource Supply Chains
draft-nobuo-scitt-hardware-iot-cloud-use-cases-00

Supply Chain Integrity, Transparency, and Trust Working Group    N. Aoki
Internet-Draft   The Graduate University for Advanced Studies (SOKENDAI)
Intended status: Informational                               7 July 2026
Expires: 8 January 2027

   Applying SCITT to Hardware, IoT Device, and Cloud Compute Resource
                             Supply Chains
           draft-nobuo-scitt-hardware-iot-cloud-use-cases-00

Abstract

   This document describes how SCITT can be applied to supply chains
   that include hardware components, IoT devices, firmware, cloud
   compute resources, confidential-computing environments, accelerators,
   and related operational evidence.  It gives use cases and scope
   guidance.  It also explains how SCITT can work with RATS, COSE, TCG
   technologies, SBOM, HBOM, CBOM, and cloud attestation systems without
   replacing those technologies.

   This document is informational.  It does not define hardware
   assurance rules, cloud assurance rules, device identity systems,
   manufacturing requirements, or payload formats.  Its purpose is to
   show where SCITT statements and receipts can provide transparency for
   heterogeneous supply-chain evidence, and where other standards or
   domain profiles should remain responsible.

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-hardware-iot-cloud-use-cases/draft-
   nobuo-scitt-hardware-iot-cloud-use-cases.html.  Status information
   for this document may be found at https://datatracker.ietf.org/doc/
   draft-nobuo-scitt-hardware-iot-cloud-use-cases/.

   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-hardware-iot-cloud-use-
   cases.

Aoki                     Expires 8 January 2027                 [Page 1]
Internet-Draft         SCITT Hardware and Compute              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.  Scope Position  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   6.  Relationship to Existing Work . . . . . . . . . . . . . . . .   6
     6.1.  SCITT . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.2.  RATS  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.3.  TCG, TPM, DICE, and Hardware Roots of Trust . . . . . . .   7
     6.4.  SBOM, HBOM, CBOM, and VEX . . . . . . . . . . . . . . . .   7
   7.  Use Case 1: Device-to-Cloud Firmware Provenance . . . . . . .   7
   8.  Use Case 2: Extending Provenance from Firmware to Hardware  .   8
   9.  How SCITT Can Represent a Lifecycle Graph . . . . . . . . . .   8
   10. Use Case 3: Device Lifecycle Evidence Graph . . . . . . . . .   9
   11. Use Case 4: Cloud Compute Resource Integrity  . . . . . . . .  10

Aoki                     Expires 8 January 2027                 [Page 2]
Internet-Draft         SCITT Hardware and Compute              July 2026

   12. Use Case 5: Device Repair, Transfer, and End of Life  . . . .  10
   13. Scope Questions . . . . . . . . . . . . . . . . . . . . . . .  11
   14. Common Evidence Types . . . . . . . . . . . . . . . . . . . .  12
   15. Scope Boundary Examples . . . . . . . . . . . . . . . . . . .  12
   16. Possible Future Work  . . . . . . . . . . . . . . . . . . . .  13
   17. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  14
   18. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   19. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   20. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     20.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     20.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Open Questions  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Design Notes for Future Revisions . . . . . . . . . . . . . . . .  17
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   SCITT [RFC9943] provides building blocks for registering signed
   supply-chain statements in Transparency Services and for verifying
   those statements later.  Although SCITT started from software supply-
   chain problems, real computing systems often contain software,
   firmware, hardware, identity, deployment, and runtime evidence
   together.

   An IoT device is not only a software package.  It is a physical
   device with hardware components, firmware, bootloaders, operating
   system images, application containers, device identities, update
   policies, and operational state.  A cloud compute resource is also
   not only a software image.  It can include a VM image, hardware root
   of trust, confidential-computing environment, accelerator allocation,
   cloud-region policy, runtime attestation result, and operator
   authorization.

   SCITT can help by making statements about these objects transparent
   and verifiable.  SCITT does not need to define the internal format of
   every evidence type.  It can register statements from manufacturers,
   software suppliers, cloud providers, auditors, device operators, and
   verifiers.  A relying party can later verify receipts and evaluate
   the evidence under its own policy.

   This document collects use cases and explains how to keep this work
   within a clear scope.  It is intended to support future discussion of
   two possible building blocks:

   *  object binding and statement relationships; and

   *  composite verification over statement graphs.

Aoki                     Expires 8 January 2027                 [Page 3]
Internet-Draft         SCITT Hardware and Compute              July 2026

2.  Working Group Context

   Recent SCITT discussions show both interest and caution for hardware
   and graph use cases.  The OCP case study showed that software and
   firmware provenance can be expressed with SCITT and that similar
   questions arise for hardware components, HBOM data, device identity,
   end-of-life state, and circular-economy evidence.

   The same discussion also made the scope question clear.  Hardware
   supply-chain assurance can be outside the present charter if the WG
   tries to define hardware rules.  However, hardware-related statements
   can still be carried as SCITT statements when another profile or
   venue defines their payload meaning and trust policy.

   The IETF 122 discussion is also relevant.  It noted that several
   organizations can make statements about the same subject, and that
   SCITT can link things by subjects and statements even though this is
   not inherent in the basic common layer.  It also raised the value of
   statements about statements and reliable locators.

   This document uses those points as design guidance.  It does not ask
   SCITT to become a hardware standards body.  It uses hardware, IoT,
   and cloud cases to show where a generic statement and graph layer may
   be useful.

3.  Scope Position

   This document is careful about the SCITT scope.  Hardware supply-
   chain details can be outside the current charter if the WG tries to
   standardize them as a hardware assurance system.  At the same time,
   statements about hardware can be registered and verified as SCITT
   statements when the payload format and trust policy are defined
   elsewhere.

   Therefore, this document does not propose that SCITT define hardware
   assurance.  It proposes that SCITT can provide transparency for
   signed statements about hardware, firmware, devices, and cloud
   resources, in the same way that SCITT can provide transparency for
   signed statements about software.

   The important boundary is this:

   *  SCITT can say that a statement was signed, registered, and linked
      to other statements.

   *  Domain profiles decide what the statement means and who is allowed
      to make it.

Aoki                     Expires 8 January 2027                 [Page 4]
Internet-Draft         SCITT Hardware and Compute              July 2026

   *  A relying party decides whether the evidence is enough for its
      decision.

4.  Non-Goals

   This document does not:

   *  define how to design secure IoT hardware;

   *  define manufacturing assurance requirements;

   *  define HBOM, CBOM, SBOM, VEX, attestation evidence, or cloud
      configuration schemas;

   *  define how a verifier decides whether an attested measurement is
      acceptable;

   *  define a universal hardware or cloud-resource registry;

   *  define a global device identity infrastructure;

   *  prevent authenticated issuers from making false claims;

   *  replace RATS, TCG, TPM, DICE, EAT, CoRIM, cloud-provider
      attestation, or existing BOM formats; or

   *  define procurement or compliance best practices.

5.  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 the terms defined in SCITT [RFC9943] and RATS
   [RFC9334].

   Hardware Component:  A physical component such as a chip, sensor,
      board, secure element, module, accelerator, or peripheral.

   Device Instance:  A specific physical device, such as an IoT gateway,
      sensor, controller, or embedded system.

   Device Class:  A product model, configuration, or type shared by
      several Device Instances.

Aoki                     Expires 8 January 2027                 [Page 5]
Internet-Draft         SCITT Hardware and Compute              July 2026

   Cloud Compute Resource:  A cloud-provisioned resource such as a
      virtual machine, container worker, managed node, GPU allocation,
      accelerator resource, or serverless execution context.

   Confidential-Computing Environment:  A trusted execution environment,
      confidential VM, enclave, or similar execution environment that
      can produce attestation evidence or results.

   Lifecycle Evidence:  Statements that describe a protected object
      during design, manufacturing, provisioning, deployment, operation,
      update, audit, repair, transfer, retirement, or decommissioning.

   Device Lifecycle Evidence Graph:  A statement graph that connects
      lifecycle evidence for a Device Instance or Device Class.

   TODO: Align these terms with TCG, RATS, cloud-provider, OCP, and
   existing IETF terminology.

6.  Relationship to Existing Work

6.1.  SCITT

   SCITT provides the transparency and accountability layer for signed
   statements.  In the use cases in this document, SCITT registers and
   verifies statements about hardware, firmware, device identity, cloud
   resources, and runtime evidence.

   SCITT does not need to understand each payload.  A hardware statement
   can use an HBOM payload.  A firmware statement can use an SBOM
   payload.  A runtime statement can use a RATS Attestation Result.
   SCITT can provide registration and receipt verification around those
   payloads.

6.2.  RATS

   RATS defines roles such as Attester, Verifier, and Relying Party.  It
   defines a model for producing and evaluating evidence about a
   computing environment.  SCITT can be used after or around that
   process.  For example, a RATS Verifier can issue an Attestation
   Result and register it as a SCITT statement.  A relying party can
   later verify that the result was signed and registered.

   SCITT should not define the meaning of the attested measurements.
   That remains with RATS profiles, platform profiles, and verifier
   policy.

Aoki                     Expires 8 January 2027                 [Page 6]
Internet-Draft         SCITT Hardware and Compute              July 2026

6.3.  TCG, TPM, DICE, and Hardware Roots of Trust

   Hardware roots of trust can provide device identity and measurements.
   These technologies can help create statements about device identity,
   boot state, firmware state, and platform configuration.

   SCITT can make those statements transparent.  It does not replace the
   hardware root of trust or the protocol that produces evidence.

   TODO: Add exact references for TPM, DICE, CoRIM, and other relevant
   TCG work.

6.4.  SBOM, HBOM, CBOM, and VEX

   BOM formats describe components, dependencies, vulnerabilities, or
   hardware composition.  These formats are payloads from the SCITT
   point of view.  SCITT can register statements carrying or referring
   to these payloads, but SCITT does not need to define the payload
   formats.

   TODO: Add references and examples for SPDX, CycloneDX, HBOM, CBOM,
   and VEX once the draft chooses the examples to include.

7.  Use Case 1: Device-to-Cloud Firmware Provenance

   A device manufacturer produces a device with firmware and identity
   material.  A component or platform vendor produces an SBOM for
   firmware.  An audit report is recorded.  A metadata service or
   signing service produces a signed certificate or statement.  A final
   device or data center operator can verify receipts and check that the
   expected evidence exists.

   SCITT can help by registering statements for:

   *  device identity created during manufacturing;

   *  firmware SBOMs from component or platform vendors;

   *  firmware signing and release statements;

   *  audit reports;

   *  update authorization statements;

   *  attestation results from devices or verifiers; and

   *  receipts showing that these statements were registered.

Aoki                     Expires 8 January 2027                 [Page 7]
Internet-Draft         SCITT Hardware and Compute              July 2026

   This use case is close to firmware and software supply-chain
   transparency.  It also shows why hardware identifiers and device
   identity may appear in SCITT statements.

8.  Use Case 2: Extending Provenance from Firmware to Hardware

   Hardware supply-chain provenance can include hardware identifiers,
   component source, device identity, identity management, end-of-life
   state, repair state, and circular economy information.  A hardware
   bill of materials can describe the hardware composition of a device,
   while firmware and software statements describe the software that
   runs on it.

   SCITT can register statements that refer to HBOM or hardware
   provenance data.  It should not define the HBOM format itself.

   Example statements include:

   *  a manufacturer statement for a device class;

   *  a component supplier statement for a hardware component;

   *  a device identity statement for a device instance;

   *  an auditor statement about a manufacturing or assembly step;

   *  a repair statement;

   *  an end-of-life or transfer statement; and

   *  a statement that links a device instance to firmware and software
      evidence.

   The value of SCITT here is not that it knows whether a hardware claim
   is true.  The value is that the claim is signed, registered, and can
   be linked to other claims and receipts.

9.  How SCITT Can Represent a Lifecycle Graph

   A lifecycle graph can be represented without changing the basic SCITT
   registration model.

   One possible pattern is:

   1.  Each evidence item is a SCITT Signed Statement.

   2.  Each statement is registered with a Transparency Service and
       receives a receipt.

Aoki                     Expires 8 January 2027                 [Page 8]
Internet-Draft         SCITT Hardware and Compute              July 2026

   3.  A relationship statement or graph manifest links the statements.

   4.  The graph manifest can itself be registered as a SCITT Signed
       Statement.

   5.  A verifier checks statements, receipts, and graph edges under its
       policy.

   This pattern lets different parties issue their own statements.  A
   component supplier can issue a component statement.  A manufacturer
   can issue a device identity statement.  A software supplier can issue
   an SBOM statement.  A RATS Verifier can issue an attestation result.
   An auditor can issue an audit statement.

   The graph can be discovered in different ways.  A deployment can use
   locators in statements, a graph manifest, a subject-based index, or
   an auxiliary service.  The SCITT Reference API does not need to
   become a full graph API for this use case.

   TODO: Decide which discovery pattern should be described as the main
   example and which should remain non-normative.

10.  Use Case 3: Device Lifecycle Evidence Graph

   An IoT device can be described by evidence over time.  A Device
   Lifecycle Evidence Graph can connect those statements.

   Device Instance
    ├─ manufacturedFrom  -> Hardware Component Statement
    ├─ provisionedWith   -> Device Identity Statement
    ├─ runsFirmware      -> Firmware SBOM or Firmware Signature Statement
    ├─ updatedBy         -> Firmware/software Update Authorization Statement
    ├─ measuredBy        -> RATS Attestation Result
    ├─ affectedBy        -> Vulnerability Status Statement
    ├─ mitigatedBy       -> Patch, Rollback, or Configuration Statement
    ├─ repairedBy        -> Repair Statement
    └─ decommissionedBy  -> End-of-Life Statement

   The graph does not need a single monolithic payload.  Each statement
   can be issued by the party that is responsible for it.  A composite
   verifier can later check whether the graph has the evidence required
   by a policy.

   This graph is not meant to be stored as one large payload.  It can be
   built from separate statements and relationship statements.  Earlier
   SCITT discussion raised the same idea through "statements about
   statements" and through reliable locators that can be used as
   pointers.  The graph model in this document follows that direction.

Aoki                     Expires 8 January 2027                 [Page 9]
Internet-Draft         SCITT Hardware and Compute              July 2026

11.  Use Case 4: Cloud Compute Resource Integrity

   A cloud compute resource can involve several layers:

   *  cloud image or container image;

   *  host hardware platform;

   *  hypervisor or node software;

   *  confidential-computing environment;

   *  GPU or accelerator allocation;

   *  region or data residency constraint;

   *  tenant identity;

   *  deployment authorization; and

   *  runtime attestation result.

   SCITT can register statements about these layers.  For example, a
   cloud provider can issue a statement about a VM image and its host
   platform.  A verifier can issue an attestation result.  A tenant or
   deployment controller can issue an authorization statement for a
   workload.  An auditor can issue an audit result.

   A composite verification profile can then check whether:

   *  the workload image matches the authorized digest;

   *  the runtime attestation result is recent;

   *  the confidential-computing environment is acceptable;

   *  the resource is in an allowed region;

   *  the accelerator firmware is covered by an accepted statement; and

   *  no statement revokes or conflicts with the evidence set.

12.  Use Case 5: Device Repair, Transfer, and End of Life

   Devices can change hands, be repaired, or be retired.  These events
   matter for supply-chain trust, especially for industrial IoT and
   enterprise hardware.  These definitions are useful for meeting the
   industry's need for maintenance on a 10-year basis.

Aoki                     Expires 8 January 2027                [Page 10]
Internet-Draft         SCITT Hardware and Compute              July 2026

   SCITT can register statements for:

   *  repair events;

   *  replacement of a hardware component;

   *  re-provisioning of identity material;

   *  transfer of device ownership;

   *  end-of-support status;

   *  end-of-life status; and

   *  secure disposal or recycling status.

   This document does not define the operational policy for these
   events.  It only shows that they can be represented as lifecycle
   statements and linked into a graph.

13.  Scope Questions

   *Question:* Does this document ask SCITT to publish hardware
   assurance rules?

   *Answer:* No.  It describes how SCITT statements and receipts can be
   used for hardware-related evidence.  Hardware assurance rules, HBOM
   formats, and device identity policy should be defined elsewhere.

   *Question:* If hardware supply chain is out of scope, why discuss
   hardware at all?

   *Answer:* Because SCITT statements can carry or refer to hardware-
   related payloads.  The useful SCITT question is not "how should
   hardware be built?"  The useful SCITT question is "how can a signed
   hardware-related statement be registered, linked, and verified with
   other statements?"

   *Question:* Should graph relationships be put in the payload or
   header?

   *Answer:* This document does not decide that.  It lists possible
   placements: payloads, protected metadata if later defined, graph
   manifest statements, or auxiliary services.  A profile must say which
   placement is authoritative.

   *Question:* Does a device lifecycle graph prove that the device is
   safe?

Aoki                     Expires 8 January 2027                [Page 11]
Internet-Draft         SCITT Hardware and Compute              July 2026

   *Answer:* No.  It helps a relying party see which statements exist
   and how they relate.  The relying party still applies its own policy.

14.  Common Evidence Types

   The following evidence types appear across the use cases:

   *  manufacturing statement;

   *  component provenance statement;

   *  device identity statement;

   *  firmware SBOM statement;

   *  hardware BOM statement;

   *  cloud image statement;

   *  deployment authorization statement;

   *  update authorization statement;

   *  RATS Attestation Result statement;

   *  vulnerability status statement;

   *  audit result statement;

   *  repair statement;

   *  transfer statement; and

   *  decommissioning statement.

   TODO: Decide which evidence types should be examples only and which
   should be registered in a future object-binding or relationship
   vocabulary document.

15.  Scope Boundary Examples

   The following table gives examples of what belongs in SCITT and what
   should stay outside SCITT.

Aoki                     Expires 8 January 2027                [Page 12]
Internet-Draft         SCITT Hardware and Compute              July 2026

    +================+==========================+====================+
    | Topic          | SCITT role               | Other responsible  |
    |                |                          | work               |
    +================+==========================+====================+
    | Firmware SBOM  | register and receipt a   | SBOM format and    |
    |                | signed statement         | tooling            |
    +----------------+--------------------------+--------------------+
    | HBOM           | register and receipt a   | HBOM format and    |
    |                | signed statement         | hardware domain    |
    +----------------+--------------------------+--------------------+
    | TPM quote      | carry or refer to an     | TCG, RATS,         |
    |                | attestation result       | platform profile   |
    +----------------+--------------------------+--------------------+
    | Cloud region   | register and link the    | cloud provider and |
    | claim          | signed claim             | policy profile     |
    +----------------+--------------------------+--------------------+
    | Device         | register statements and  | manufacturer, TCG, |
    | identity       | link evidence            | device profile     |
    +----------------+--------------------------+--------------------+
    | False hardware | preserve signed evidence | issuer governance  |
    | claim          | and audit trail          | and legal process  |
    +----------------+--------------------------+--------------------+
    | Composite      | provide evidence and     | relying-party      |
    | decision       | result structure         | policy             |
    +----------------+--------------------------+--------------------+

                                 Table 1

16.  Possible Future Work

   This document motivates two possible follow-on drafts.

   First, a Protected Object Binding draft can define how a statement
   refers to a software, firmware, hardware, device, or cloud object.
   It can also define a small relationship vocabulary.

   Second, a Composite Evidence Verification draft can define how a
   verifier asks for a graph-level decision and how the verifier reports
   missing, stale, or conflicting evidence.

   Both follow-on drafts should keep payload definitions out of scope
   unless a separate charter or venue says otherwise.

Aoki                     Expires 8 January 2027                [Page 13]
Internet-Draft         SCITT Hardware and Compute              July 2026

17.  Privacy Considerations

   Hardware and cloud evidence can reveal sensitive information.  Device
   identifiers can identify customers.  Graph edges can reveal
   suppliers, cloud regions, tenants, repair history, or operational
   dependencies.

   Deployments should avoid placing directly identifying information in
   public logs.  They can use pseudonymous identifiers, salted
   commitments, encrypted payloads, access control, or selective
   disclosure.  The chosen method should still allow the intended
   verifier to check the required evidence.

18.  Security Considerations

   The main risk is over-reading SCITT evidence.  A valid receipt does
   not prove that a hardware claim is true.  It proves that a signed
   statement was registered and that the receipt verifies under the
   relevant profile.

   Relying parties must still decide:

   *  which issuers are trusted for each statement type;

   *  which statements are required;

   *  how fresh each statement must be;

   *  how conflicts are handled;

   *  how revocation or supersession is handled; and

   *  whether a domain-specific payload is acceptable.

   Other risks include:

   *  linking the wrong device instance to a statement;

   *  treating a device class statement as a device instance statement;

   *  accepting old attestation results;

   *  accepting a hardware statement from an unauthorized issuer;

   *  exposing sensitive graph data; and

   *  assuming that SCITT replaces RATS or hardware root-of-trust
      mechanisms.

Aoki                     Expires 8 January 2027                [Page 14]
Internet-Draft         SCITT Hardware and Compute              July 2026

19.  IANA Considerations

   This document has no IANA actions.

20.  References

20.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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9943>.

20.2.  Informative References

   [I-D.ietf-scitt-receipts-ccf-profile]
              "CCF Profile for COSE Receipts", n.d.,
              <https://datatracker.ietf.org/doc/draft-ietf-scitt-
              receipts-ccf-profile/>.

   [I-D.ietf-scitt-scrapi]
              "Supply Chain Integrity, Transparency, and Trust (SCITT)
              Reference APIs", n.d., <https://datatracker.ietf.org/doc/
              draft-ietf-scitt-scrapi/>.

   [I-D.nobuo-scitt-composite-evidence-verification]
              "Composite Evidence Verification for SCITT Statement
              Graphs", n.d., <https://aoki-n1.github.io/draft-nobuo-
              scitt-composite-evidence-verification/draft-nobuo-scitt-
              composite-evidence-verification.html>.

   [I-D.nobuo-scitt-protected-object-binding]
              "SCITT Statement Relationship and Protected Object
              Binding", n.d., <https://aoki-n1.github.io/draft-nobuo-
              scitt-protected-object-binding/draft-nobuo-scitt-
              protected-object-binding.html>.

Aoki                     Expires 8 January 2027                [Page 15]
Internet-Draft         SCITT Hardware and Compute              July 2026

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9052>.

   [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, <https://www.rfc-editor.org/rfc/rfc9334>.

   [RFC9335]  Uberti, J., Jennings, C., and S. Murillo, "Completely
              Encrypting RTP Header Extensions and Contributing
              Sources", RFC 9335, DOI 10.17487/RFC9335, January 2023,
              <https://www.rfc-editor.org/rfc/rfc9335>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9942>.

   [TODO-OCP-SAFE]
              "TODO - OCP S.A.F.E. Program", n.d.,
              <https://www.opencompute.org/community/ocp-safe-program>.

   [TODO-SBOM-HBOM-CBOM]
              "TODO - Add SBOM, HBOM, CBOM, VEX, SPDX, and CycloneDX
              references as appropriate", n.d.,
              <https://example.com/TODO>.

   [TODO-TCG] "TODO - Add Trusted Computing Group references such as
              TPM, DICE, CoRIM, and related profiles", n.d.,
              <https://example.com/TODO>.

Open Questions

   *  Should SCITT define generic object binding, or should each domain
      profile define its own binding?

   *  Should relationship metadata live in payloads, protected headers,
      graph manifests, or auxiliary services?

   *  Should SCRAPI remain focused on registration and receipt retrieval
      while graph discovery is handled by later auxiliary services?

   *  Which use cases require WG action, and which should be handled by
      other WGs or standards bodies?

Aoki                     Expires 8 January 2027                [Page 16]
Internet-Draft         SCITT Hardware and Compute              July 2026

   *  How should this document describe hardware use cases if the
      current charter does not allow the WG to publish a hardware-
      specific standards-track item?

Design Notes for Future Revisions

   This revision treats hardware and cloud compute as use cases for
   SCITT statements, not as a request for SCITT to define hardware or
   cloud assurance.  That distinction is important for charter
   discussion.

   This revision also adds the IETF 122 points on multi-party
   statements, statements about statements, reliable locators, and the
   limits of the basic common layer.  These points support the Device
   Lifecycle Evidence Graph without requiring SCRAPI to become a graph
   API.

Acknowledgments

   The author thanks the SCITT WG participants for discussion of OCP
   hardware assertions, generic APIs, graph building over opaque
   payloads, and the boundary between SCITT and domain-specific hardware
   or cloud profiles.  The OCP case study helped identify the need to
   discuss hardware identifiers, device identity, HBOM provenance, end-
   of-life information, and circular-economy evidence without turning
   SCITT into a hardware assurance framework.

Author's Address

   Nobuo Aoki
   The Graduate University for Advanced Studies (SOKENDAI)
   Japan
   Email: n_aoki@ieee.org

Aoki                     Expires 8 January 2027                [Page 17]