Composite Evidence Verification for SCITT Statement Graphs
draft-nobuo-scitt-composite-evidence-verification-00

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

       Composite Evidence Verification for SCITT Statement Graphs
          draft-nobuo-scitt-composite-evidence-verification-00

Abstract

   This document defines a common model for composite verification of
   SCITT statement graphs.  A composite verifier checks a set of SCITT
   Signed Statements, receipts, object bindings, and relationship edges
   under a named verification profile.  The result is a structured
   report that can say which statements passed, which evidence is
   missing, which evidence is stale, and which statements conflict.

   The model is intended for verifiers, auditors, deployment
   controllers, update services, and other relying-party tools.  It is
   not a new Transparency Service requirement.  It does not define a
   universal supply-chain policy language and does not define the
   payload format of any statement type.

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-composite-evidence-verification/draft-
   nobuo-scitt-composite-evidence-verification.html.  Status information
   for this document may be found at https://datatracker.ietf.org/doc/
   draft-nobuo-scitt-composite-evidence-verification/.

   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-composite-evidence-
   verification.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Aoki                     Expires 8 January 2027                 [Page 1]
Internet-Draft        SCITT Composite Verification             July 2026

   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 . . . . . . . . . . . . . . . . . . . .   3
   3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   6.  Why This Is Not a Transparency Service Requirement  . . . . .   5
   7.  Verification Model  . . . . . . . . . . . . . . . . . . . . .   6
   8.  Statements about Statements in Composite Verification . . . .   6
   9.  Verification Request  . . . . . . . . . . . . . . . . . . . .   7
   10. Evidence Completeness and Discovery . . . . . . . . . . . . .   8
   11. Evidence Bundle . . . . . . . . . . . . . . . . . . . . . . .   9
   12. Verification Result . . . . . . . . . . . . . . . . . . . . .   9
   13. Result Code Semantics . . . . . . . . . . . . . . . . . . . .  11
   14. Example: IoT Device Runtime Integrity . . . . . . . . . . . .  11
   15. Optional HTTP Binding . . . . . . . . . . . . . . . . . . . .  12
   16. Registration and Retrieval Timing . . . . . . . . . . . . . .  13
   17. Asynchronous Verification . . . . . . . . . . . . . . . . . .  13
   18. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  14
   19. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   20. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15

Aoki                     Expires 8 January 2027                 [Page 2]
Internet-Draft        SCITT Composite Verification             July 2026

   21. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     21.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     21.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Design Notes for Future Revisions . . . . . . . . . . . . . . . .  17
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   SCITT lets a consumer verify that a signed statement was registered
   in a Transparency Service.  Many real decisions need a larger
   evidence set.  A consumer may need to check that a firmware SBOM
   describes the firmware measured on a device, that an update
   authorization covers that firmware, that an attestation result was
   issued by an acceptable verifier, and that no accepted statement
   revokes or conflicts with the set.

   Without a common composite verification model, each ecosystem defines
   its own API, result terms, freshness checks, conflict handling, and
   evidence bundle format.  This can lead to tools that cannot work
   together even when the individual SCITT statements and receipts are
   valid.

   This document defines an information model and an optional HTTP
   binding for composite verification.  The model is intentionally
   small.  It provides common request and result fields while leaving
   domain policy to profiles.

   The composite verifier can be local software, a remote service, an
   auditor tool, a deployment controller, or a supply-chain risk engine.
   It does not have to be the same component as the SCITT Transparency
   Service.

2.  Working Group Context

   This draft is based on the observation that SCITT can register many
   statements about the same subject, but the basic registration path is
   not a full graph query system.  IETF 122 discussion noted support for
   multiple vendors or organizations making statements about an
   artifact, and also raised the pattern of "statements about
   statements".  The same discussion noted that reliable locators can be
   used as pointers.

   IETF 124 discussion raised the question of whether graph information
   belongs in payloads, COSE headers, or later auxiliary services.  It
   also noted that SCRAPI does not currently provide an API for graph
   work, and that adding such support directly to SCRAPI would be a
   larger effort.

Aoki                     Expires 8 January 2027                 [Page 3]
Internet-Draft        SCITT Composite Verification             July 2026

   This draft therefore treats composite verification as a verifier or
   auditor function.  It can use SCITT statements, receipts, locators,
   and graph manifests, but it does not require the Transparency Service
   to make composite decisions.

3.  Design Goals

   The goals of this profile are to:

   *  allow a requester to identify the subject of verification;

   *  allow evidence to be provided by value, by reference, or by graph
      manifest;

   *  allow the requester or profile to name required statement types;

   *  express issuer, relationship, freshness, and conflict constraints;

   *  return clear result values for pass, fail, warning, unknown,
      missing, stale, and conflict cases;

   *  support online and offline verification;

   *  allow evidence bundles to move between tools; and

   *  avoid defining the truth conditions of domain-specific payloads.

4.  Non-Goals

   This profile does not:

   *  define a universal policy language;

   *  require a Transparency Service to perform composite verification;

   *  require the SCITT Reference API to support graph discovery;

   *  require a verifier to fetch all evidence automatically;

   *  decide whether a payload claim is true;

   *  define SBOM, HBOM, CBOM, VEX, attestation, vulnerability, or audit
      schemas;

   *  define best practices for software, hardware, cloud, or IoT
      supply-chain design; or

   *  replace SCITT statement and receipt verification.

Aoki                     Expires 8 January 2027                 [Page 4]
Internet-Draft        SCITT Composite Verification             July 2026

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 imports the terms Protected Object, Statement
   Reference, Receipt Reference, Relationship Edge, and Statement Graph
   from [I-D.nobuo-scitt-protected-object-binding].

   Composite Verification:  The evaluation of several SCITT statements,
      receipts, object bindings, and relationship edges under a selected
      verification profile.

   Verification Profile:  A named set of rules that tells a verifier
      which statement types, issuers, relations, freshness limits, and
      conflict rules apply.

   Verification Request:  A request that identifies a subject, a
      verification profile, optional evidence, and optional constraints.

   Verification Result:  A result object that reports the outcome of
      composite verification.

   Evidence Bundle:  A portable package that contains statements,
      receipts, graph manifests, and policy identifiers needed for
      composite verification.

   Result Code:  A short code that states the result for the whole
      verification or for one part of the evidence graph.

6.  Why This Is Not a Transparency Service Requirement

   A Transparency Service should be able to stay small.  Its core job is
   to accept a signed statement under a registration policy and return a
   receipt.  Composite verification is different.  It applies a relying-
   party policy to a graph of evidence.

   For this reason, a conforming Transparency Service is not required to
   implement the interface in this document.  Deployments can implement
   composite verification in one of the following places:

   *  a local verifier;

   *  a remote verification service;

Aoki                     Expires 8 January 2027                 [Page 5]
Internet-Draft        SCITT Composite Verification             July 2026

   *  an auditor tool;

   *  a deployment controller;

   *  an update service;

   *  a compliance system; or

   *  an auxiliary service next to SCRAPI.

   This split keeps the SCITT registration path simple while still
   allowing ecosystems to exchange and verify graph-level evidence.

7.  Verification Model

   Composite verification runs over a Statement Graph.  The graph can be
   supplied in a Statement Graph Manifest, as separate references, or
   through another profile-defined package.

   A verifier performs four kinds of checks:

   1.  *Statement checks*: signature, syntax, profile, and optional
       payload checks.

   2.  *Receipt checks*: receipt profile, inclusion proof, and
       registration data.

   3.  *Graph checks*: object binding, required relationships,
       conflicts, supersession, revocation, and dependency edges.

   4.  *Policy checks*: issuer rules, freshness rules, required
       statement types, and domain-specific acceptance rules.

   The verifier MUST verify all individual statements and receipts
   required by the selected profile before it returns pass for the whole
   graph.

   A verifier MUST NOT claim that a payload is true only because it is
   signed and registered.  A registered false statement can still be
   false.  Composite verification only reports that the evidence set
   satisfies the selected verification profile.

8.  Statements about Statements in Composite Verification

   Composite verification can use statements that refer to other
   statements.  This is needed when the evidence set has history.

   Examples include:

Aoki                     Expires 8 January 2027                 [Page 6]
Internet-Draft        SCITT Composite Verification             July 2026

   *  an audit statement about a submitted statement;

   *  a fix statement that answers a vulnerability statement;

   *  a supersession statement that marks a newer SBOM as current;

   *  a revocation statement;

   *  a failed-build statement that records why a build chain did not
      complete; and

   *  a graph manifest statement that records a selected evidence set.

   A verifier MUST treat these as ordinary SCITT statements.  It MUST
   verify their signatures and receipts before using them.  It MUST also
   apply policy to decide whether the issuer is allowed to assert the
   relation.

9.  Verification Request

   A Verification Request identifies the subject and the verification
   profile.  A request MAY include evidence directly or by reference.

   ; This CDDL is provisional and needs WG review.
   verification-request = {
     subject: node-reference,
     verification_profile: tstr,
     ? evidence: evidence-input,
     ? required_statement_types: [+ tstr],
     ? accepted_issuers: {+ tstr => [+ tstr]},
     ? freshness: {+ tstr => duration},
     ? relationship_requirements: [+ relationship-requirement],
     ? conflict_policy: conflict-policy,
     ? result_options: result-options,
     ? nonce: bytes,
     ? request_id: tstr
   }

   node-reference = tstr / {
     ? object: any,
     ? statement: any,
     ? id: tstr
   }

   evidence-input = {
     ? statements: [+ any],
     ? receipts: [+ any],
     ? graph_manifest: any,

Aoki                     Expires 8 January 2027                 [Page 7]
Internet-Draft        SCITT Composite Verification             July 2026

     ? embedded_bundle: evidence-bundle,
     ? evidence_locations: [+ tstr]
   }

   relationship-requirement = {
     from_type: tstr,
     relation: tstr,
     to_type: tstr,
     ? required: bool
   }

   conflict-policy = "fail" / "warn" / "ignore" / tstr

   result-options = {
     ? include_graph: bool,
     ? include_statement_results: bool,
     ? include_receipt_results: bool,
     ? include_missing_evidence: bool,
     ? include_conflicts: bool,
     ? include_warnings: bool
   }

   duration = tstr

   The verification_profile field names the policy family to apply.  A
   profile can be general, such as scitt-basic-graph/v1, or domain
   specific, such as iot-device-runtime-integrity/v1.

   The accepted_issuers field is a constraint supplied by the requester
   or by a higher-level profile.  This document does not define a global
   list of trusted issuers.

   The freshness field contains duration strings.  TODO: decide whether
   this document should normatively use an existing duration syntax or
   define a small CBOR-native form.

10.  Evidence Completeness and Discovery

   Composite verification cannot assume that the submitted evidence set
   is complete.  A presenter may omit a conflicting statement, an old
   revocation, or a newer superseding statement.  A verifier therefore
   needs a policy for evidence coverage.

   A verification profile SHOULD state at least:

   *  which statement types are required;

   *  which issuers or issuer roles are accepted for each type;

Aoki                     Expires 8 January 2027                 [Page 8]
Internet-Draft        SCITT Composite Verification             July 2026

   *  whether the verifier must search for newer or conflicting
      statements;

   *  which locators or auxiliary services may be used for discovery;

   *  how old evidence may be before it becomes stale; and

   *  how to report a result when the verifier cannot check
      completeness.

   When a verifier cannot check completeness, it SHOULD return unknown
   or warning instead of pass, unless the selected profile allows
   closed-world verification over the supplied bundle.

11.  Evidence Bundle

   An Evidence Bundle packages the evidence needed for offline or
   asynchronous verification.

   ; This CDDL is provisional and needs WG review.
   evidence-bundle = {
     bundle_type: "scitt-evidence-bundle/v1",
     subject: node-reference,
     ? profile: tstr,
     ? statements: [+ any],
     ? receipts: [+ any],
     ? graph_manifest: any,
     ? related_bundles: [+ digest],
     ? created_at: time,
     ? expires_at: time,
     ? bundle_digest: digest,
     ? attributes: {* tstr => any}
   }

   digest = {
     alg: tstr,
     value: bytes
   }

   A bundle can be used when the verifier cannot reach the original
   Transparency Service during evaluation.  A verifier using a bundle
   MUST still verify the statements and receipts inside the bundle.

12.  Verification Result

   A Verification Result reports the outcome of the composite check.

Aoki                     Expires 8 January 2027                 [Page 9]
Internet-Draft        SCITT Composite Verification             July 2026

   ; This CDDL is provisional and needs WG review.
   verification-result = {
     subject: node-reference,
     verification_profile: tstr,
     overall_result: result-code,
     ? request_id: tstr,
     ? verified_statements: [+ statement-result],
     ? receipt_results: [+ receipt-result],
     ? missing_evidence: [+ missing-evidence],
     ? conflicts: [+ conflict-result],
     ? warnings: [+ warning-result],
     ? graph_digest: digest,
     ? evaluated_at: time,
     ? verifier: tstr,
     ? attributes: {* tstr => any}
   }

   result-code = "pass" / "fail" / "warning" / "unknown" /
                 "missing" / "stale" / "conflict" / "not-applicable" /
                 tstr

   statement-result = {
     statement: any,
     result: result-code,
     ? issuer: tstr,
     ? statement_type: tstr,
     ? errors: [+ tstr],
     ? warnings: [+ tstr]
   }

   receipt-result = {
     receipt: any,
     result: result-code,
     ? errors: [+ tstr],
     ? warnings: [+ tstr]
   }

   missing-evidence = {
     evidence_type: tstr,
     ? relation: tstr,
     ? expected_issuer_role: tstr,
     ? message: tstr
   }

   conflict-result = {
     conflict_type: tstr,
     nodes: [+ tstr],
     ? message: tstr

Aoki                     Expires 8 January 2027                [Page 10]
Internet-Draft        SCITT Composite Verification             July 2026

   }

   warning-result = {
     warning_type: tstr,
     ? node: tstr,
     ? message: tstr
   }

13.  Result Code Semantics

   A verifier SHOULD use the following meanings:

   pass:  The evidence satisfies the selected verification profile.

   fail:  The evidence does not satisfy the selected verification
      profile.

   warning:  The evidence satisfies mandatory checks, but the verifier
      found a condition that should be shown to the relying party.

   unknown:  The verifier could not reach a decision.  This can happen
      when evidence is unavailable or when a profile is not understood.

   missing:  Required evidence is missing.

   stale:  Evidence is older than the freshness rule allows.

   conflict:  The graph contains statements or edges that conflict under
      the selected profile.

   not-applicable:  A rule was not applicable to the subject or profile.

   TODO: Decide whether these result codes should be registered with
   IANA.

14.  Example: IoT Device Runtime Integrity

   The following example is illustrative only.

Aoki                     Expires 8 January 2027                [Page 11]
Internet-Draft        SCITT Composite Verification             July 2026

   {
     "subject": {
       "object": {
         "object_type": "device-instance",
         "object_id": "urn:example:device:gateway-1234"
       }
     },
     "verification_profile": "iot-device-runtime-integrity/v1",
     "required_statement_types": [
       "device-identity",
       "firmware-sbom",
       "firmware-update-authorization",
       "rats-attestation-result",
       "vulnerability-status"
     ],
     "accepted_issuers": {
       "device-identity": ["manufacturer"],
       "firmware-update-authorization": ["device-operator", "manufacturer"],
       "rats-attestation-result": ["trusted-verifier"],
       "vulnerability-status": ["vendor", "authorized-third-party"]
     },
     "freshness": {
       "rats-attestation-result": "PT24H",
       "vulnerability-status": "P7D"
     },
     "relationship_requirements": [
       {
         "from_type": "firmware-sbom",
         "relation": "describes",
         "to_type": "firmware-image",
         "required": true
       },
       {
         "from_type": "rats-attestation-result",
         "relation": "measures",
         "to_type": "device-instance",
         "required": true
       }
     ],
     "conflict_policy": "fail"
   }

15.  Optional HTTP Binding

   This document defines an optional HTTP binding for deployments that
   want a remote composite verifier.  The binding is not a Transparency
   Service requirement.

Aoki                     Expires 8 January 2027                [Page 12]
Internet-Draft        SCITT Composite Verification             July 2026

   POST /scitt/composite-verifications HTTP/1.1
   Content-Type: application/scitt-composite-verification-request+cbor
   Accept: application/scitt-composite-verification-result+cbor

   The response body is a verification-result.

   A server MAY also support JSON media types for debugging or
   deployment convenience:

   *  application/scitt-composite-verification-request+json

   *  application/scitt-composite-verification-result+json

   TODO: Decide whether the HTTP binding belongs in this document, in a
   separate binding document, or only in examples.

16.  Registration and Retrieval Timing

   Composite verification may be run long after the original statements
   were registered.  It may also be run while some evidence is still
   pending.  A profile should not assume that a POST to a Transparency
   Service always returns a final receipt synchronously.

   A verifier or auxiliary service can encounter:

   *  a statement reference with no receipt yet;

   *  a resource that has moved to a different locator;

   *  a failed registration;

   *  a sharded service that returns a different status location; or

   *  a bundle that was prepared before all related statements were
      available.

   The result model in this document can represent these cases with
   unknown, missing, stale, warning, or a profile-defined result code.

17.  Asynchronous Verification

   Some evidence sets can require network retrieval, large receipts,
   external policy checks, or manual audit review.  A composite verifier
   MAY support an asynchronous mode.

   In asynchronous mode, the initial response can return a status
   resource.  The final result MUST be the same verification-result
   structure used by the synchronous mode.

Aoki                     Expires 8 January 2027                [Page 13]
Internet-Draft        SCITT Composite Verification             July 2026

   TODO: Define status codes, retry handling, cancellation, and expiry
   rules if the WG decides to include asynchronous behavior.

18.  Privacy Considerations

   Composite verification can reveal more information than single-
   statement verification because graph edges show relationships among
   devices, software, services, cloud tenants, suppliers, and auditors.

   A requester SHOULD provide only the evidence needed for the selected
   profile.  A verifier SHOULD avoid returning more graph detail than
   the requester asked for.  Profiles MAY use encrypted statements,
   salted identifiers, selective disclosure, or access-controlled
   evidence bundles.

   A verifier that stores requests or results can become a sensitive
   data store.  Deployments SHOULD define retention and access-control
   rules.

19.  Security Considerations

   Composite verification depends on the integrity of every required
   statement, receipt, and edge.

   Implementations MUST verify the relevant signatures and receipts
   before making a pass decision.  Implementations MUST apply issuer
   authorization rules for each statement type and relation.

   Risks include:

   *  accepting a graph with missing evidence;

   *  accepting a stale attestation or vulnerability statement;

   *  accepting a relation asserted by an unauthorized issuer;

   *  hiding a conflicting statement;

   *  mixing evidence about two different objects;

   *  confusing statement freshness with object freshness;

   *  returning a pass result for an unsupported profile; and

   *  leaking sensitive graph information through result details.

Aoki                     Expires 8 January 2027                [Page 14]
Internet-Draft        SCITT Composite Verification             July 2026

   TODO: Add detailed error priority rules.  For example, invalid
   receipt should probably take precedence over freshness warnings,
   while unsupported policy may return unknown instead of fail.

20.  IANA Considerations

   This document requests no IANA action yet.

   TODO: Consider IANA registrations for:

   *  composite verification request media types;

   *  composite verification result media types;

   *  evidence bundle media types;

   *  result code registry; and

   *  conflict type registry.

21.  References

21.1.  Normative References

   [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>.

   [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>.

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

Aoki                     Expires 8 January 2027                [Page 15]
Internet-Draft        SCITT Composite Verification             July 2026

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/rfc/rfc8949>.

   [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>.

   [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>.

   [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>.

21.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-hardware-iot-cloud-use-cases]
              "Applying SCITT to Hardware, IoT Device, and Cloud Compute
              Resource Supply Chains", n.d., <https://aoki-n1.github.io/
              draft-nobuo-scitt-hardware-iot-cloud-use-cases/draft-
              nobuo-scitt-hardware-iot-cloud-use-cases.html>.

   [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>.

Aoki                     Expires 8 January 2027                [Page 16]
Internet-Draft        SCITT Composite Verification             July 2026

   [TODO-POLICY-LANGUAGES]
              "TODO - Add references for policy languages and audit
              result formats", n.d., <https://example.com/TODO>.

Design Notes for Future Revisions

   This revision treats composite verification as an auxiliary verifier
   function, not as an extension to the core Transparency Service.  This
   follows the concern that adding graph discovery to the basic registry
   API could make that API much larger.

   The IETF 122 discussion is reflected in this draft in three ways.
   First, the model allows more than one organization to make statements
   about the same subject.  Second, the model allows statements about
   statements, which can help when a later statement fixes, updates,
   audits, or explains an earlier statement.  Third, the model allows
   evidence to be identified by stable locators, so that a verifier can
   build a graph without requiring the Transparency Service itself to
   become a graph database.

   The IETF 124 discussion is reflected by keeping graph discovery and
   composite verification outside the mandatory SCRAPI registration
   path.  The draft leaves open whether future profiles place graph
   hints in payloads, protected metadata, separate graph manifests, or
   auxiliary services.

Acknowledgments

   The author thanks the SCITT WG participants for discussions on graph
   building, opaque payloads, receipt verification, and hardware and
   software evidence.  The IETF 124 discussion was useful in separating
   the core registry function from possible auxiliary graph and
   verification services.

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]