SCITT Statement Relationship and Protected Object Binding
draft-nobuo-scitt-protected-object-binding-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Nobuo Aoki | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nobuo-scitt-protected-object-binding-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
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,
<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>.
[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>.
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,
<https://www.rfc-editor.org/rfc/rfc9943>.
22.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-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>.
[TODO-SBOM-HBOM-CBOM]
"TODO - Add references for SBOM, HBOM, CBOM, VEX, and
related payload formats", n.d.,
<https://example.com/TODO>.
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]