A Structured Value Model for Derived Identifiers
draft-le-structured-value-model-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 | Thanh Le | ||
| Last updated | 2026-08-22 | ||
| 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-le-structured-value-model-00
Network Working Group T. Le
Internet-Draft 22 August 2026
Intended status: Informational
Expires: 23 February 2027
A Structured Value Model for Derived Identifiers
draft-le-structured-value-model-00
Abstract
This document defines a structured value model independent of
serialization for use by derived identifier constructions and
profiles. A Value consists of exact context octets, exact content
octets, and a finite set of scoped opaque identifiers. The model
defines structural admission, exact equivalence, placement of
distinctions that affect comparison, and rules for importing
identifiers from independently governed systems.
The model does not define a wire representation, canonicalization
procedure, cryptographic hash, identifier syntax, application
profile, resolver, registry, or trust model. Source mappings and
concrete derived identifier profiles are defined by surrounding
specifications.
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 23 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Le Expires 23 February 2027 [Page 1]
Internet-Draft Structured Value Model August 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Scoped Identifiers . . . . . . . . . . . . . . . . . . . . . 4
4. Structured Value . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Content . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Placement of Comparison Distinctions . . . . . . . . . . 8
4.4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Separation of Comparison Responsibilities . . . . . . . . 10
5. Admission . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Equivalence . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Imported Identifiers . . . . . . . . . . . . . . . . . . . . 12
8. Model Boundaries . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Derived Identifier Constructions . . . . . . . . . . . . 13
8.2. Mapping and Binding Mechanisms . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
12. Normative References . . . . . . . . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Model Test Considerations . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This specification defines a structured value model independent of
serialization for use by derived identifier constructions and
profiles. It defines the comparison domain, the distinctions that
participate in value equivalence, and how identifiers imported from
independently governed schemes participate in comparison.
This model is intended for profiles in which the complete membership
of imported identifiers participates jointly in comparison. It is
not a generic container for every protocol that carries multiple
identifiers. Scoped identifiers, composite values, exact octet
comparison, and finite-set membership are established techniques; the
specification choice here is their combination into one
Le Expires 23 February 2027 [Page 2]
Internet-Draft Structured Value Model August 2026
representation-independent comparison domain with exact conjunctive
membership semantics for imported identifiers. Other Internet and
Web specifications use multiple identifiers with materially different
combination semantics, including aliases that identify the same
subject [RFC9493], lists in which any acceptable reference identifier
can match a presented identifier [RFC9525], alias and verification
relationships in Controlled Identifiers [W3C-CID-1.0], and controller
relationships in DIDs [W3C-DID-1.1]. A surrounding specification
that needs alias, alternative, capability, controller, succession,
authorization, graph-edge, or other relationship semantics resolves
those semantics before admission or represents every comparison-
relevant distinction explicitly in the admitted Value. Bare co-
membership in identifiers does not preserve such a relationship;
placing alternatives or relationship-bearing identifiers there
without representing the relationship would instead make only the
distinct members, not the relation between them, part of this model's
exact comparison state.
Requirements in this document apply to mappings, profiles, and
implementations that adopt this model. This document does not define
a concrete serialization or wire representation, canonical byte
encoding, binding or framing construction, cryptographic derivation
mechanism, identifier syntax, application profile, transparency
service, resolver, registry, or trust model. It also does not define
a generic semantic projection across source formats. A companion
profile can map concrete representations into this model and can
define a deterministic identifier derivation from admitted values.
A surrounding mapping can project richer or heterogeneous source
objects into this model. Any equivalence introduced by that
projection is part of the mapping before model admission, not of this
model. For a fixed mapping from source material to Value, accepted
source material and every explicit input that can change the result
MUST determine one admitted Value. Inputs that can change the result
MUST NOT be left to implementation discretion or ambient mutable
state.
The comparison principles in [I-D.le-comparing-derived-identifiers]
provide architectural guidance for the semantics defined here.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
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.
Le Expires 23 February 2027 [Page 3]
Internet-Draft Structured Value Model August 2026
An octet string is a finite sequence of octets. This document
defines ScopedIdentifier in Section 3 and Value in Section 4.
3. Scoped Identifiers
A scoped identifier is the pair:
ScopedIdentifier := {
scope : finite octet string,
identifier : finite octet string
}
Both components are opaque octet strings at this model boundary.
Either component can be empty. An empty scope or identifier is still
an exact value and is distinct from absence of the ScopedIdentifier
from the set. A surrounding profile may impose a non-empty
requirement when required by the imported identifier system; this
model does not impose that restriction on every future system. This
specification does not impose a namespace syntax on imported
identifier systems, require a registry lookup, require resolution, or
interpret the semantics associated with an imported scope.
Imported scope semantics are interpreted relative to the context of
the containing value. A specification or interoperability profile
that imports an identifier system MUST define, for each context value
it uses, the exact mapping from scope octets to imported identifier
semantics and the exact identifier octets carried for that system.
Within one context value, incompatible imported semantics MUST NOT
use the same scope octets. The same scope octets can be reused under
different context values because context itself affects comparison.
Because this model compares each complete ScopedIdentifier exactly, a
mapping also has to adapt any native comparison semantics of an
imported identifier system to that exact boundary. Exact equality
represents an equivalence relation. A profile that claims to
preserve an imported identifier comparison unchanged therefore MUST
identify an equivalence relation to be represented. If, after the
applicable imported interpretation is fixed, that matching behavior
is not an equivalence relation, the surrounding mapping MUST first
define the equivalence being projected into this model; any
additional collapse introduced by that projection occurs before model
admission.
Under one context and applicable mapping, accepted imported instances
equivalent under the fixed interpretation MUST produce the same
(scope, identifier) pair before admission. A profile claiming to
import that comparison unchanged MUST also reflect equivalence: with
that interpretation fixed, accepted instances produce the same exact
Le Expires 23 February 2027 [Page 4]
Internet-Draft Structured Value Model August 2026
pair if and only if they are equivalent under the imported relation.
Direct copying is sufficient only when the relevant equality is
already exact octet equality and the selected scope is stable for
that comparison. For aliases, the mapping MUST deterministically
select or derive the exact pair for the equivalence class under the
imported relation under the fixed interpretation. Under the same
mapping and interpretation, that pair MUST NOT vary with
implementation preference, time, or ambient mutable state; changing
representative selection changes the import mapping. Merging
imported identifiers that the imported comparison considers different
is upstream loss and cannot be reversed by preserving the resulting
pair.
At this model boundary, scope participates in fixing the
interpretation of that imported identifier within the containing
Value, not necessarily only the public name of the imported
identifier scheme. A distinction that changes the imported
identifier interpretation or imported comparison relation MUST be
fixed by the imported identifier octets, the containing context, or
the scope octets; it MUST NOT exist only in content or ambient
mapping state if that would let the same (context, scope, identifier)
tuple carry incompatible imported meanings. A separate application-
specific distinction, such as a role, relationship class, position,
or occurrence label that changes only how the imported identifier
participates in this Value, MUST be made observable under the
placement rule in Section 4.3 and can be carried in scope or content.
A context mapping can define a whole family of scope encodings; this
model still treats every resulting scope as opaque octets and defines
no scope grammar.
Conceptually, an imported identifier is qualified by:
(context, scope, identifier)
The context is represented once at the level of the containing Value.
A ScopedIdentifier copied out of a Value does not carry that context.
A consumer MUST NOT assume that the same (scope, identifier) pair has
the same imported meaning under another context unless a surrounding
specification defines it.
A profile may use an allocated name, self-certifying value, Uniform
Resource Identifier (URI), including a Uniform Resource Name (URN),
an identifier defined by another standard, or another stable octet
string as a scope. This specification does not prefer or require one
such mechanism.
Le Expires 23 February 2027 [Page 5]
Internet-Draft Structured Value Model August 2026
Equality of scoped identifiers is exact equality of both scope octets
and identifier octets. This is the model-level equality relation for
the pair. The pair is not self-interpreting: its imported meaning is
determined by the containing context and the applicable mapping
described above.
4. Structured Value
The comparison domain consists of records of the following form:
Value := {
context : finite octet string,
content : finite octet string,
identifiers : finite set of ScopedIdentifier
}
Emptiness is typed. The empty octet string is a valid value of
context, content, scope, or identifier, and the empty mathematical
set is a valid value of identifiers. Absence and source
representation sentinel or exceptional values are not additional
model values and MUST NOT be silently treated as those empty values.
A surrounding source mapping can intentionally define how such source
states map into this model, but the result MUST be an explicit
admitted Value before model comparison.
The record is deliberately small. It provides exact local material
and a set of identifiers imported from this or other identifier
systems. It does not define an application grammar, resolver, graph
language, provenance model, serialization, or trust model.
A profile is not required to admit a non-empty identifiers set. When
no imported identifiers participate in comparison, identifiers is the
empty mathematical set and context and content carry the remaining
comparison-relevant material. The empty-set case remains the same
Value type and equivalence relation; it does not define a second core
model or an extension variant.
4.1. Context
context carries exact octets that select the interpretation used for
comparison. A surrounding specification or interoperability profile
defines the exact context octets and their interpretation.
The context can distinguish identical content and identifiers when
their application or protocol meaning is intentionally different.
When identifier systems are imported, context also provides the
interpretation domain under which identifier scope octets are
understood.
Le Expires 23 February 2027 [Page 6]
Internet-Draft Structured Value Model August 2026
This specification assigns no global meaning to context values and
requires no registry, resolver, network lookup, global authority, or
distribution mechanism. Exact context equality is required for model
equivalence but does not prove that independently governed
environments use compatible definitions; such interpretation depends
on agreement about applicable context and scope semantics outside
this model.
context octets participate directly in Value equivalence and select
the interpretation domain used for comparison. The same context
octets MUST NOT be reused for an incompatible interpretation of the
Value as a whole. Within a fixed context, the same (context, scope)
combination MUST NOT acquire an incompatible imported-identifier
meaning. Adding a new distinct scope meaning under an existing
context does not by itself require new context octets when existing
(context, scope) meanings remain unchanged. Selection, distribution,
authentication, or agreement on surrounding definitions is outside
this model and is not an additional Value field or input to model
equality.
4.2. Content
content is exact local material that participates in comparison.
This model does not perform Unicode normalization, character set
conversion, media type processing, decompression, canonicalization,
or any other transformation.
An application starting from a richer source object is responsible
for defining any mapping from source material to content before
admission to this model. Different native representations are not
considered equivalent merely because an application believes they
describe the same thing; a surrounding specification has to define
that mapping explicitly before the resulting exact octets enter
content. If that mapping collapses a distinction the application
later expects identifier comparison to preserve, no later encoding or
cryptographic operation can restore the distinction.
Accordingly, content is exact local material after any semantic
projection defined by the application. It is not a universal
canonical form and this model is not a substitute for
canonicalization or mapping rules specific to a source format.
Le Expires 23 February 2027 [Page 7]
Internet-Draft Structured Value Model August 2026
4.3. Placement of Comparison Distinctions
This model does not define separate occurrence, nonce, revision,
timestamp, sequence, role, relationship, or position fields. A
surrounding specification that needs such a distinction to affect
comparison MUST make the distinction observable in the admitted Value
rather than leave it as ambient state that can change the result.
The intended placement rule is:
1. a distinction that changes interpretation of the Value as a whole
belongs in context;
2. exact local comparison material that is not represented by an
independently governed identifier belongs in content; and
3. a distinction that qualifies the application-specific
participation of one imported identifier belongs in that
identifier's scope, unless the application deliberately
represents the distinction as exact local material in content. A
distinction that changes the imported identifier interpretation
or imported comparison relation is governed by Section 3 and is
not moved only into content.
scope is therefore not a generic metadata channel for each member.
Material belongs in scope only when its comparison meaning is
specific to that imported identifier's membership in the Value.
Semantics of the whole Value remain in context, and independently
meaningful local structure remains in content.
For example, if the same imported identifier can participate once as
a "subject" and once as an "input", and that role changes Value
equality, a profile can define two distinct scope octet strings that
encode the role. If ordered occurrences or multiplicity matter, a
profile can similarly bind an occurrence or position label into the
applicable scope, or encode the relevant application structure
exactly in content.
A surrounding mapping specifies how source distinctions become these
octets; it is not an alternative storage location for a distinction
that varies between Values and is intended to affect comparison. If
such a distinction is omitted from the admitted Value, this model
necessarily treats source values differing only in that omitted
distinction as the same Value. No later profile encoding or
cryptographic operation can recover it.
Le Expires 23 February 2027 [Page 8]
Internet-Draft Structured Value Model August 2026
4.4. Identifiers
identifiers is a mathematical finite set of ScopedIdentifier values.
Membership is relevant to comparison. For each admitted Value, the
entire finite membership of this set is part of the comparison state:
adding, removing, or substituting a distinct member changes the Value
when context and content are unchanged. The set is not an
alternatives list, capability advertisement, inventory, discovery
result, history, or version-negotiation mechanism. A surrounding
source mapping that constructs identifiers remains subject to the
mapping-determinism requirement in Section 1; fixed explicit inputs
and fixed mapping semantics determine the complete admitted set
rather than an implementation-selected subset. Order of presentation
and duplicate occurrences are not semantic distinctions. Duplicate
presentation is not a way to express multiplicity. If multiplicity
or occurrence identity is relevant to comparison, the surrounding
profile MUST represent that distinction explicitly under the
placement rule in Section 4.3.
Set membership means only that the complete scoped identifier
participates in the structured value for model comparison.
Membership or co-membership does not by itself assign an application-
specific role or relationship between a member and the Value or
another member. Co-membership is not an implicit join between
identifier systems; cross-system identity or equivalence is outside
this model as described in Section 7. A source relation such as
alias-of, equivalent-to, controls, authorized-for, supersedes,
component-of, or alternative-to is not preserved merely by admitting
both endpoint identifiers as members. If that relation is relevant
to comparison, the surrounding mapping resolves it before admission
or materializes the required distinction under Section 4.3; otherwise
flattening the relation to bare co-membership is upstream semantic
loss.
Any loss relevant to comparison already embodied in an imported
identifier is inherited by the Value. If the imported construction
or its applicable comparison deliberately or accidentally maps two
source values to the same imported identifier result, preserving that
result as opaque octets cannot recover the discarded source
distinction. This inherited upstream loss is distinct from a
collision or loss introduced by a later derived identifier profile.
If an application needs role, order, position, multiplicity, edge
type, or another relationship distinction, it MUST apply the
placement rule in Section 4.3. In particular, a distinction for one
identifier that changes comparison cannot exist only in an external
relationship table while the same Value octets are supplied to the
derivation.
Le Expires 23 February 2027 [Page 9]
Internet-Draft Structured Value Model August 2026
This specification does not require the resulting relationships to
form a directed acyclic graph (DAG), tree, line, or other global
topology and does not traverse or resolve identifiers.
4.5. Separation of Comparison Responsibilities
The three fields expose separate comparison responsibilities; this
document does not claim that they are the only representation able to
carry the same information. Projecting away any field can erase a
distinction this model exposes:
* removing context loses the explicit boundary that distinguishes
otherwise identical Values interpreted under different semantics
of the Value as a whole or of imported scopes;
* removing content removes the dedicated location for exact local
material that affects comparison, which then has to be carried
elsewhere; and
* removing identifiers removes the dedicated model-level boundary
for opaque results imported from independently governed identifier
systems. A surrounding specification can still encode equivalent
information in content, but then has to define the per-system
qualification, complete-membership, order and duplicate treatment,
and imported-comparison adaptation needed for that application
rather than reusing the ScopedIdentifier and mathematical-set
semantics defined here.
The value of the identifiers field is therefore semantic factoring
and reuse, not expressive completeness: it standardizes how opaque
imported identifier results participate in comparison while leaving
the internal identifier schemes, resolution, trust, and relationships
outside the model. context, content, and identifiers expose
interpretation context, exact local material, and opaque imported
identifier results. Additional roles or relationships need no new
primitive field, but every distinction that affects comparison MUST
be represented in the admitted Value under Section 4.3.
5. Admission
A candidate value is structurally admitted to the model only when:
1. context and content are finite octet strings;
2. every identifier is a ScopedIdentifier whose scope and identifier
are finite octet strings; and
3. identifiers is finite.
Le Expires 23 February 2027 [Page 10]
Internet-Draft Structured Value Model August 2026
Structural admission determines the mathematical domain and is
independent of external discovery or interpretation. It does not
assert that arbitrary identifier octets are valid according to an
imported identifier system. A surrounding profile that imports such
a system defines any validation required by that identifier system as
part of its mapping from source material to Value.
These are conditions of the model domain, not capability limits.
Local memory, time, storage, or denial-of-service limits do not
redefine admission or equivalence; resource refusal does not place an
otherwise admitted Value outside the mathematical domain.
Model semantics are independent of implementation scale. Streaming,
bounded storage, resource refusal, profile subsets, sharding,
replication, or long-delay operation MUST NOT change an admitted
Value, ScopedIdentifier equality, identifier set membership, or the
equivalence relation in Section 6.
The model requires no continuously reachable authority, synchronized
clock, current ledger head, mutable global registry, network lookup,
or object traversal. A surrounding profile can use such facilities,
but state that changes a Value or its comparison semantics MUST be
explicit rather than ambient.
Implementations processing the same admitted Values MUST apply the
same model equivalence semantics. Profile capability minima do not
become Value fields, change equality, or turn local resource refusal
into model domain rejection.
6. Equivalence
Two admitted values are equivalent if and only if all of the
following hold:
1. their context octet strings are equal;
2. their content octet strings are equal; and
3. their identifiers are the same mathematical set under exact
ScopedIdentifier equality.
Le Expires 23 February 2027 [Page 11]
Internet-Draft Structured Value Model August 2026
This relation is reflexive, symmetric, and transitive. Under any
fixed applicable derivation semantics, a derived identifier profile
using this model MUST treat Values equivalent under this model as
equivalent derivation inputs; accepted source or wire representations
MUST NOT split one model equivalence class. This requirement does
not require different surrounding derivation semantics to produce
equal outputs from the same Value. Any merge of non-equivalent
Values belongs to the surrounding mapping or construction and its
loss boundaries, not to model equality.
The equivalence relation, not a wire representation, states which
distinctions matter. Concrete representations do not alter this
model unless the profile defines a different mapping from source
material to Value.
Model equivalence is an equality relation over admitted Values.
Interpreting that equality under imported identifier semantics
additionally requires compatible surrounding context and scope
definitions. Representation equality does not establish
interpretation equality.
7. Imported Identifiers
This model can represent identifiers from multiple independently
governed systems in one Value without translating between their
internal semantics. For example:
context = profile_X
identifiers = {
(scope_A, identifier_A),
(scope_B, identifier_B),
(scope_C, identifier_C)
}
The surrounding definition for profile_X specifies the imported
meaning of each scope. Bare identifier octet equality across scopes
or systems is not an implicit join. A bridge asserting identity or
equivalence across systems is a separate protocol decision and is
outside this model.
A complete identifier produced by another system can be imported as
opaque identifier octets without parsing or absorbing that system's
internal canonicalization, digest, registry, or derivation semantics
when its relevant comparison is already represented by the selected
exact octets. Otherwise the surrounding import mapping performs the
adaptation of the imported comparison rules described in Section 3
before admission. The surrounding profile defines the imported
Le Expires 23 February 2027 [Page 12]
Internet-Draft Structured Value Model August 2026
identifier meaning associated with the exact (context, scope,
identifier) tuple; other application-specific distinctions can be
carried elsewhere in the Value under Section 4.3. This model
preserves those exact materials for comparison without assigning
additional semantics to them.
8. Model Boundaries
8.1. Derived Identifier Constructions
This specification defines what is compared; it does not define the
bytes that are hashed or the syntax of a resulting identifier.
A derived identifier profile using this model is expected to make the
following boundaries explicit:
source representation
-> profile mapping
-> admitted Value
-> deterministic profile encoding
-> optional cryptographic compression
-> identifier
A derived identifier profile MAY define a derivation domain that is a
proper subset of structurally admitted Values when required by its
encoding or downstream operation. Membership in that profile domain
MUST be determined from the admitted Value under fixed profile
semantics, MUST NOT depend on which accepted source or wire
representation produced the Value, and MUST NOT depend on
implementation-local resource availability. The profile domain MUST
be closed under this model's equivalence relation: if v1 ~ v2, either
both Values are in the profile domain or neither is. Restricting a
profile derivation domain does not redefine model admission or model
equivalence.
Loss introduced by the mapping from source material to Value or by a
profile encoding is upstream of any cryptographic collision. A
profile claiming independent recomputation MUST define enough
information for separate implementations applying the same fixed
applicable derivation semantics to produce the same identifier from
equivalent admitted values without hidden state that can change the
result.
Le Expires 23 February 2027 [Page 13]
Internet-Draft Structured Value Model August 2026
8.2. Mapping and Binding Mechanisms
This document defines a comparison model independent of
serialization, not a concrete serialization or wire format and not a
universal source canonicalization. The information model/data model
distinction in [RFC3444] is an architectural analogy; [RFC8949]
likewise separates an abstract data model from encoding choices.
Concrete serializations belong to surrounding profiles.
Source mappings determine which distinctions survive into an admitted
Value. Imported identifier systems retain their own internal
derivation and comparison semantics; the import mapping adapts the
relevant comparison to this model's exact (scope, identifier)
boundary. Downstream binding, graph, provenance, lifecycle, or
relationship protocols can carry derived identifiers without becoming
part of model equality.
The model neither repairs distinctions already collapsed upstream nor
assigns relationship semantics merely from membership in identifiers.
W3C specifications provide contrasting examples: Controlled
Identifiers [W3C-CID-1.0] gives explicit semantics to relationships
such as alsoKnownAs and verification relationships; DIDs
[W3C-DID-1.1] distinguish independent and group controller
arrangements; and Recognized Entities [W3C-RECOGNIZED-ENTITIES-1.0]
uses sameAs for cross-system references to the same entity. These
are relationship-bearing structures, not evidence that bare exact co-
membership has those meanings.
Changing a representation, binding construction, or cryptographic
mechanism does not by itself change an admitted Value. A change to
the value domain, admission rules, ScopedIdentifier semantics,
identifier set semantics, or equivalence relation changes the
applicable model semantics; existing Values are not silently
reinterpreted under changed semantics. A semantic change that
affects comparison defines different applicable mapping, context, or
model semantics rather than a change only in representation.
9. IANA Considerations
This document has no IANA actions.
Le Expires 23 February 2027 [Page 14]
Internet-Draft Structured Value Model August 2026
10. Security Considerations
The primary security requirement of this model is correct
preservation of distinctions that affect comparison by surrounding
mappings and profiles. Ambiguous parsing, lossy preprocessing,
normalization, default insertion, field exclusion, omitted role or
occurrence qualification, scope remapping, or copying an unadapted
imported alias or spelling into a boundary based on exact octet
comparison can make intended equivalence diverge or make non-
equivalent source objects enter the same model value. Later
cryptography cannot repair either error or recover a distinction that
has already been erased.
An identifier does not authenticate or validate an object it denotes.
Consumers requiring authenticity, authority, freshness, revocation,
provenance, or trust evaluate those properties separately.
Operational resource limits used for denial-of-service protection do
not redefine the model domain.
Distribution or selection of the mapping from source material to
Value, context definitions, and scope definitions can be security-
sensitive. Mutable locators, replaceable aliases, or partially fixed
dependencies can make parties apply incompatible semantics to the
same source material. When a mapping constructs identifiers,
attacker-controlled member injection, omission, or substitution
changes model equality unless that membership difference is
explicitly part of the applicable mapping semantics. Such a change
is a mapping-integrity failure before any downstream binding or
cryptographic construction, not a collision in that downstream
construction. A surrounding protocol MUST protect each definition
that affects comparison and each attacker-controlled selection step
according to its threat model.
11. Privacy Considerations
Values can contain stable, identifying, or low-entropy material. A
deterministic profile derived from this model can therefore enable
correlation or offline guessing. Placing identifiers from
independently governed systems in one Value can create linkage across
systems even though generic set membership asserts no identity or
trust across systems. The conjunction of several members can be more
identifying than any member alone because the combination can narrow
the set of source objects consistent with the Value. Deriving or
exposing a stable opaque identifier for the composite Value does not
by itself remove that correlation risk even when the imported member
octets are not directly exposed. Persistent identifiers and
linkability are discussed more generally in [RFC6973]. Applications
Le Expires 23 February 2027 [Page 15]
Internet-Draft Structured Value Model August 2026
need to consider whether unnecessary identifying material should be
omitted when resulting identifiers will be broadly observable.
Opaque identifiers do not make denoted or associated values
confidential.
12. 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/info/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/info/rfc8174>.
13. Informative References
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.
[I-D.le-comparing-derived-identifiers]
Le, T., "Principles for Comparing Independently Derived
Identifiers", Work in Progress, Internet-Draft, draft-le-
comparing-derived-identifiers-00, August 2026,
<https://datatracker.ietf.org/doc/html/draft-le-comparing-
derived-identifiers-00>.
[RFC9493] Backman, A., Scurtescu, M., and P. Jain, "Subject
Identifiers for Security Event Tokens", RFC 9493,
DOI 10.17487/RFC9493, December 2023,
<https://www.rfc-editor.org/info/rfc9493>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[W3C-CID-1.0]
World Wide Web Consortium, "Controlled Identifiers v1.0",
W3C Recommendation, May 2025,
<https://www.w3.org/TR/controller-document/>.
Le Expires 23 February 2027 [Page 16]
Internet-Draft Structured Value Model August 2026
[W3C-DID-1.1]
World Wide Web Consortium, "Decentralized Identifiers
(DIDs) v1.1", W3C Candidate Recommendation Snapshot, March
2026, <https://www.w3.org/TR/did-1.1/>.
[W3C-RECOGNIZED-ENTITIES-1.0]
World Wide Web Consortium, "Recognized Entities v1.0",
W3C First Public Working Draft, May 2026,
<https://www.w3.org/TR/vc-recognized-entities-1.0/>.
[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/info/rfc8949>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
Appendix A. Model Test Considerations
This appendix is informative.
Useful corpus cases include typed emptiness; the distinction between
an empty set and an empty member; arbitrary opaque octets; duplicate
and reordered presentations; scoped distinctions; leading zeros;
ambiguity in tuple framing; deterministic mappings under fixed
explicit inputs; stable adaptation of imported equivalence classes;
and rejection rather than coercion outside the model domain. Such
vectors test model semantics without imposing a wire format,
normalization, hash, API shape, or resource floor.
Author's Address
Thanh Le
Viet Nam
Email: vnlemanhthanh@gmail.com
Le Expires 23 February 2027 [Page 17]