A Framework for Comparing Independently Derived Identifiers
draft-le-comparing-derived-identifiers-01
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-09-07 | ||
| 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-comparing-derived-identifiers-01
Network Working Group T. Le
Internet-Draft 7 September 2026
Intended status: Informational
Expires: 11 March 2027
A Framework for Comparing Independently Derived Identifiers
draft-le-comparing-derived-identifiers-01
Abstract
Specifications use equality of independently derived identifiers to
compare underlying values. Those comparisons require shared rules
for admission, equivalence, derivation, and output interpretation.
Inconsistent rules can give different identifiers to equivalent
values or equal identifiers to values that the comparison
distinguishes.
This document presents a framework for specifying and reviewing these
rules as a comparison contract. It connects source mappings to
derivation-domain equivalence and the conclusions supported by equal
and unequal outputs. It distinguishes information loss before a
downstream operation from that operation's own false match
properties. A review traces the relevant specification clauses,
records supporting evidence, and identifies failed or unestablished
obligations. The framework provides guidance for concrete identifier
specifications; it defines no identifier format or derivation
algorithm.
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 11 March 2027.
Le Expires 11 March 2027 [Page 1]
Internet-Draft Comparing Derived Identifiers September 2026
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
1.1. Terminology and Notation . . . . . . . . . . . . . . . . 4
1.2. Reviewing a Comparison Contract . . . . . . . . . . . . . 4
2. Specify What Is Compared . . . . . . . . . . . . . . . . . . 5
2.1. Domain and Equivalence . . . . . . . . . . . . . . . . . 5
2.2. Source Mappings . . . . . . . . . . . . . . . . . . . . . 6
2.3. Representation Admission and Decoding . . . . . . . . . . 7
3. Specify Complete Derivation Semantics . . . . . . . . . . . . 8
4. Compare Under Defined Semantics . . . . . . . . . . . . . . . 9
4.1. Bind the Semantics and Output Boundary . . . . . . . . . 9
4.2. Interpret the Comparison Result . . . . . . . . . . . . . 10
4.3. Changes and Cross-Scheme Comparison . . . . . . . . . . . 11
5. Account for Information Loss and False Matches . . . . . . . 11
5.1. Preserve Relevant Distinctions Before Downstream
Operations . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Characterize the Remaining False Matches . . . . . . . . 12
6. Worked Example: JWK Thumbprints . . . . . . . . . . . . . . . 13
6.1. Composition Review: JWK Thumbprint URIs . . . . . . . . . 14
7. Worked Review: Preserving Role and Member Associations . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Relationship to Existing Work . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
Le Expires 11 March 2027 [Page 2]
Internet-Draft Comparing Derived Identifiers September 2026
1. Introduction
Specifications use thumbprints, content addresses, and other derived
identifiers so that separate implementations can compare values by
computing identifiers and testing them for equality. Here, an
independently derived identifier is a deterministic result
reproducible under fixed derivation semantics without a shared
authority assigning that result.
The intended comparison determines which distinctions the derivation
represents. A key thumbprint can ignore metadata that accompanies a
key; including that metadata can make equivalent keys produce
different results. Conversely, a mapping that retains account names
and roles but loses their associations can make different assignments
produce the same result. Using the same digest algorithm does not
settle either problem.
This document calls the specified rules and assumptions governing a
comparison a comparison contract. It identifies the admitted values,
the equivalence relation stating which distinctions matter, the
derivation rules, and the interpretation of output equality. When a
conclusion concerns a richer source, the contract also covers the
source relation and its mapping into the derivation domain.
The framework helps specification authors and reviewers connect a
claimed conclusion to the rules and evidence supporting it. A review
can establish a failure at a declared boundary or identify an
obligation that remains unestablished. Section 1.2 describes the
review method; Sections 6 and 7 apply it to concrete examples.
The contracts examined here require equivalent admitted values to
produce equal outputs under the same fixed semantics. Directional,
similarity, containment, and other non-equivalence comparisons are
outside scope, as is comparison based entirely on authoritative
assignment or lookup. The domain can contain byte strings,
structured values, graphs, or other precisely defined values.
Identifier comparison and canonicalization are established techniques
[RFC6943]. This document organizes their source-to-result
obligations across specification boundaries; it defines no identifier
format or derivation algorithm. Appendix A relates the framework to
existing work, including the JWK Thumbprint construction used in
Section 6.
Le Expires 11 March 2027 [Page 3]
Internet-Draft Comparing Derived Identifiers September 2026
1.1. Terminology and Notation
The derivation domain contains the values on which derivation
operates. The symbol ~ denotes their specified equivalence relation.
F denotes a fully instantiated derivation: every applicable
algorithm, parameter, and other result-affecting choice has been
fixed.
A comparison boundary identifies the values and relation against
which a conclusion is evaluated. Output equality is equality at the
output-value boundary defined by the comparison rules, which can
differ from equality of carrier representations (Section 4.1).
Equality of source or intermediate values is equality in their stated
value domain, distinct from any separately defined equivalence.
A false match is equality of derived outputs for inputs that are not
equivalent at the declared comparison boundary. A false non-match is
inequality of outputs for equivalent inputs under the same applicable
semantics. These specialize the false-positive and false-negative
concerns of [RFC6943]. The relation is established from the intended
comparison, rather than selected merely to fit observed outputs.
1.2. Reviewing a Comparison Contract
A review begins with the conclusion that a specification intends to
draw from output equality or inequality. It then:
1. Identifies the comparison boundary, admitted domain, and intended
equivalence relation.
2. Traces the rules linking that boundary to the compared outputs,
including source mapping, representation decoding, derivation,
and selection of the applicable semantics.
3. Checks the obligations supporting the conclusion, locating their
defining clauses and examining the evidence at each boundary or
for the complete composition.
4. Records demonstrated failures, general arguments under stated
assumptions, checks limited to particular cases, and obligations
that remain unestablished.
A reusable record names the reviewed specifications and versions,
relevant clauses, domains and relations, fixed dependencies, checked
obligations, and evidence with its limitations. A counterexample can
refute a universal claim; passing selected cases does not establish
that claim for the entire domain. A specification-level argument
also does not establish implementation conformance.
Le Expires 11 March 2027 [Page 4]
Internet-Draft Comparing Derived Identifiers September 2026
Failure localization is relative to the declared contracts. Output
bytes alone do not identify a unique failing stage. If a boundary
contract or supporting evidence is missing, the corresponding
obligation remains unestablished. The framework does not prescribe
an implementation architecture or require separately exposed stages.
2. Specify What Is Compared
2.1. Domain and Equivalence
A specification defines an admitted domain and an equivalence
relation over it. The relation is reflexive, symmetric, and
transitive. The definitions are precise enough for independent
implementations to determine domain membership and equivalence.
The fully instantiated derivation F is constant on each equivalence
class:
v1 ~ v2 => F(v1) = F(v2)
This is the coherence obligation. Equivalent admitted values that
produce different outputs under those semantics demonstrate a false
non-match. The cause can be inconsistent specification rules or an
implementation that does not follow them; the witness alone does not
decide which. Determinism alone does not establish coherence.
At the partition level, a false non-match witnesses a false split:
one intended equivalence class is divided among classes induced by
output equality. Conversely, a false match witnesses a false merge,
with members of distinct intended classes sharing an output.
Coherence supports an exact inference from unequal, correctly
computed outputs to non-equivalent inputs. Equal outputs support the
reverse conclusion only within the mechanism's false match
properties. Sections 4.2 and 5 state these conditions in detail. A
mechanism that intentionally permits false non-matches cannot rely on
the unequal-output inference without establishing its condition for
the comparison being made.
Equivalence states which distinctions matter for this comparison. It
can ignore presentation order for mathematical sets, equate accepted
representations of the same value, or deliberately require exact byte
equality. Canonicalization can implement the relation, but does not
itself determine it. Comparison procedures need not all use a unique
canonical form [RFC6943]. A distinction intentionally ignored by the
relation need not be preserved; loss of a distinction between its
classes is accounted for in the false match analysis.
Le Expires 11 March 2027 [Page 5]
Internet-Draft Comparing Derived Identifiers September 2026
The relation is scoped to this comparison. It need not decide
whether richer application objects are universally the same.
Different applications can define different relations over the same
source material. Section 2.2 addresses the obligations when a
conclusion extends from the derivation domain to such a source.
The domain definition identifies invalid values and excluded features
or forms. Membership is independently testable, rather than inferred
from whatever an implementation can serialize or hash. A value
outside that domain acquires no comparison semantics merely because
an implementation processes it.
Conversely, a local inability to process an admitted value because of
memory, size, time, or deployment limits does not make the value
semantically invalid. A resource bound intended to determine domain
membership is part of the domain definition; other local ceilings are
operational limits. Section 4.2 distinguishes these outcomes from
comparison results.
2.2. Source Mappings
A source mapping P takes an accepted source value s into the
derivation domain. Write ~S for the declared source equivalence
relation and G for the complete source-to-output derivation:
G(s) = F(P(s))
A claim that P preserves source equivalence requires:
s1 ~S s2 => P(s1) ~ P(s2)
A claim that P does not merge source classes requires reflection:
P(s1) ~ P(s2) => s1 ~S s2
These are distinct obligations. Preservation keeps equivalent
sources within one derivation-domain class. Reflection keeps
different source classes apart. In particular, reflection can fail
even if P(s1) and P(s2) are literally different values: the domain
relation can still treat them as equivalent.
If P(s1) = P(s2), F receives the same domain value and produces the
same output. If the sources are non-equivalent under ~S, this is
information loss in P, not a false match between distinct inputs to
F. When P(s1) and P(s2) are merely equivalent, coherence of F
likewise makes their outputs equal. A failure of reflection forces a
source-level false match under that coherence assumption.
Le Expires 11 March 2027 [Page 6]
Internet-Draft Comparing Derived Identifiers September 2026
A failure of preservation has a different consequence. Equivalent
sources reach different domain classes, but F might still give those
classes equal outputs. The failed mapping obligation alone does not
prove a source-level false non-match. That conclusion needs evidence
about the outputs or a further property of F (Section 4.2).
The specification defining P states which source distinctions matter
and how they are represented or deliberately excluded. Populating
every required destination field does not establish that the model
represents all distinctions relevant to the source comparison. This
semantic judgment precedes treating output equality as evidence about
source equivalence.
Given the same source input and mapping semantics, independent
implementations produce the same mapped value, or equivalent values
where the mapping permits a choice of representative. Coherence of F
makes such representative choices invisible in the output. For
analysis, P denotes a mapping allowed by those rules; preservation
and reflection apply to every permitted choice. Exact intermediate
equality is required where the mapping specifies it.
Dependencies that can change the mapped equivalence class are part of
the defined source input or fixed by the mapping rules. Where exact-
value reproducibility is required, this also covers dependencies that
change a representative within its class. Section 3 describes how
result-affecting dependencies are fixed. A separate input that
intentionally preserves a source distinction is included in the
complete input semantics when defining and reviewing P and F.
2.3. Representation Admission and Decoding
Source mapping and representation decoding have different
responsibilities. A source mapping can deliberately project a richer
object. A decoder determines which value an accepted representation
denotes; accepting multiple representations need not discard a
distinction of the represented value.
A specification defines representations that conforming decoders
accept or reject, and any permitted variations in acceptance.
Implementations under the same decoding policy agree on admission and
rejection. When several policies are permitted, a representation
accepted by more than one yields equivalent derivation inputs.
Optional acceptance does not change model equivalence or result-
producing semantics.
Le Expires 11 March 2027 [Page 7]
Internet-Draft Comparing Derived Identifiers September 2026
Parsing, duplicate handling, number conversion, Unicode processing,
omission, ordering, and defaulting are specified when they affect
admission or the value passed to derivation. Otherwise, independent
implementations can derive from different values while believing they
implement the same comparison.
Absence, null or sentinel values, typed empty values, and exceptional
numeric values are not presumed interchangeable when the domain
distinguishes them. Duplicate-key handling is determined before a
host object model can silently retain the first or last occurrence.
Review includes accepted and rejected cases near the domain edge.
Agreement on final outputs for selected accepted inputs alone does
not establish agreement on admission or decoding.
3. Specify Complete Derivation Semantics
A specification fixes every semantic choice needed to derive an
identifier from an admitted value. Depending on the construction,
these include selected components; normalization, ordering, framing,
and domain separation; algorithms, output lengths, and parameters;
and any external material on which the result depends.
A dependency that can change the result while the specified input is
unchanged is either part of the defined input or fixed unambiguously
by the applicable rules. Ambient registry, resolver, validation,
clock, ledger, configuration, or network state cannot silently select
a different result. If such state is comparison-relevant, the rules
identify the particular state or version and how it is selected.
Dependencies affecting admission, equivalence, derivation, or output
interpretation are fixed unambiguously. These can include schemas,
normalization tables, imported profiles, executable modules, and
parameter sets. A stable label or authenticated response does not by
itself establish an unchanged meaning. A dependency can be fixed
directly or through a deterministic immutable rule. A content-
derived name can bind exact bytes [RFC6920]; their semantic
interpretation still needs to be defined.
Secret or access-controlled material is permitted. The selected key,
key version, or other parameter is part of the derivation semantics
even when the material is not public. Independence means that a
separate conforming implementation with the specified input, rules,
and required authorization and material can reproduce the result. It
does not require public recomputation or that such an implementation
already exist. A result available only by accepting an opaque
assignment from one runtime authority is outside this case.
Le Expires 11 March 2027 [Page 8]
Internet-Draft Comparing Derived Identifiers September 2026
Registries, resolvers, repositories, or negotiation services can
locate or authenticate the applicable material. Once its semantics
are fixed, loss of the acquisition mechanism does not change what the
derivation means, although it can prevent an implementation from
obtaining what it needs to compute or interpret a result.
4. Compare Under Defined Semantics
4.1. Bind the Semantics and Output Boundary
A comparison identifies the applicable domain, equivalence relation,
derivation, and output interpretation. For conclusions about
sources, it also identifies the source relation, mapping, and
representation admission and decoding rules. Output octets need not
carry this information themselves.
A protocol states whether it compares a textual or container
representation or a decoded identifier value. If representations are
compared, their construction is included in F. If decoded values are
compared, admission, decoding, and any normalization identify those
values unambiguously. Noncanonical encodings can decode to the same
binary value [RFC4648], so unequal carrier spellings need not be
unequal outputs at the comparison boundary.
Equal octets can also arise under different domains, relations,
algorithms, or parameters. They have shared comparison meaning only
when the applicable semantics are unambiguous to the comparing
parties. A protocol can fix those semantics by version and message
position, bind to a profile or immutable specification material, or
negotiate among defined alternatives. No universal rule-set
identifier or negotiation mechanism is required; the binding need not
be part of the derived output.
Equal profile labels, context strings, namespace tokens, or
references do not alone establish equal interpretation. Names and
URIs can locate candidate material, but discovery is distinct from
determining the applicable semantics [RFC3986]. Dependencies that
affect those semantics are fixed as described in Section 3. Byte
identity or authentication alone does not establish semantic
compatibility.
Two documents can define the same applicable semantics. Conversely,
matching output formats or octets do not make different semantics
directly comparable. Section 4.3 addresses explicit bridges between
schemes. Section 8 addresses protection of the selection and its
binding to the output.
Le Expires 11 March 2027 [Page 9]
Internet-Draft Comparing Derived Identifiers September 2026
4.2. Interpret the Comparison Result
For admitted values whose outputs are correctly computed under the
same fully instantiated F, coherence gives:
F(v1) != F(v2) => v1 not-~ v2
Here not-~ denotes non-equivalence. This is the contrapositive of
Section 2.1 and needs no collision-resistance assumption. Equal
outputs establish equivalence if F has no false matches; otherwise
that conclusion is bounded by the false match properties of the
mechanism (Section 5).
At a source boundary, the unequal-output inference instead requires
coherence of G(s) = F(P(s)) with respect to ~S. Preservation by P
together with coherence of F is sufficient to establish that
condition. It can also be established directly for G. In
particular, F can assign equal outputs to different domain classes
reached from equivalent sources, so preservation by P is not a
necessary condition for coherence of the composition. Such equality
can be a false match at the domain boundary while satisfying source
coherence. A direct argument for G does not establish a separate
preservation claim about P.
The equal-output inference about sources depends on false match
properties of the complete composition. If P reflects ~S, non-
equivalent sources reach non-equivalent domain values, so a false
match for them must arise in F. If P merges source classes, its loss
is included separately. Properties of F alone do not account for
that upstream loss. These composition properties can be justified
together or through obligations at the respective boundaries.
Reproducible computations under different semantics do not qualify
for these inferences merely because each computation is internally
consistent. Likewise, equality of supplied identifiers does not
itself establish that they were correctly derived from the claimed
inputs; a consuming protocol establishes any binding it relies on.
Unavailable or ambiguous semantics, or inability to complete a
computation, establishes neither equivalence nor non-equivalence.
Rejected out-of-domain inputs lie outside this contract. Surrounding
protocols define how these conditions affect processing or policy
without treating them as comparison evidence about admitted inputs.
Le Expires 11 March 2027 [Page 10]
Internet-Draft Comparing Derived Identifiers September 2026
4.3. Changes and Cross-Scheme Comparison
A change that affects the domain, relation, derived output, or its
interpretation defines different comparison semantics. Existing
identifiers retain the semantics under which they were produced;
changing normalization, framing, an algorithm, a dependency, or
another result-affecting rule does not silently reinterpret them.
Selecting different alternatives already defined by one
specification, such as algorithm or parameter suites, likewise
instantiates different derivations. Such a selection does not itself
require a new specification or profile version.
A protocol can define migration, negotiation, succession, or a bridge
for comparison across schemes. It states which relation that bridge
represents and how the conclusion follows. Matching formats do not
supply that argument. Cryptographic algorithm transition is one
instance of this broader obligation [RFC7696].
5. Account for Information Loss and False Matches
5.1. Preserve Relevant Distinctions Before Downstream Operations
A review that relies on a downstream operation's properties examines
the complete input presented to that operation. For analysis, write:
F(v) = H(E(v))
E is preceding processing and H is the downstream operation; H need
not be a hash. If non-equivalent admitted values satisfy E(v1) =
E(v2), their equal final outputs are not a collision of H: it
received the same input. The earlier loss has to be analyzed on its
own terms.
This argument concerns the complete input to the remaining
computation. Equality of one intermediate component is insufficient
if later processing also receives a source value, context, or other
input that distinguishes the pair. Such inputs are included when
identifying the boundary. For a sequence of deterministic transforms
carrying all information used by the remaining steps, a literal merge
is irreversible: later transforms receive equal inputs.
Le Expires 11 March 2027 [Page 11]
Internet-Draft Comparing Derived Identifiers September 2026
Given those complete boundaries, review can identify the first
literal merge for a pair where immediately preceding values were
unequal. Where intermediate equivalence relations are specified,
semantic loss can occur before literal equality and is checked
against those relations. A finding states which kind of loss and
which boundary its evidence establishes. Source-mapping loss is the
upstream case in Section 2.2.
To rely on a downstream primitive's collision properties for non-
equivalent values, earlier processing preserves their distinction or
separately characterizes any loss. A sufficient separation condition
on E is:
E(v1) = E(v2) => v1 ~ v2
Under that condition, equal final outputs for non-equivalent values
involve distinct inputs to H. The condition does not itself
establish coherence of F; Section 2.1 remains a separate obligation.
Ambiguous concatenation illustrates an earlier merge. For a domain
distinguishing ordered pairs of strings, ("ab", "c") and ("a", "bc")
both encode as "abc" if the components are simply concatenated. A
later hash receives the same bytes. Framing preserves the relevant
component boundaries, including those of variable-length context or
domain separation inputs.
Section 2.2.5 of [RFC9380] discusses injective encodings for domain-
separated oracle queries. The property is scoped to that encoding
step. Section 5.3.3 of the same RFC hashes tags longer than 255
bytes; that compression has its own cryptographic assumptions. Later
injective framing does not remove them.
5.2. Characterize the Remaining False Matches
When F(v1) = F(v2) implies v1 ~ v2 throughout the domain, coherence
and this reverse implication make output equality coincide with input
equivalence. Otherwise, the mechanism characterizes its false match
behavior for the intended use.
Merely documenting loss does not establish usefulness. A constant
function is fully deterministic and coherent, yet output equality
provides no discrimination among input classes. A review therefore
asks which distinctions survive the specified processing and what
evidence supports the resulting comparison claims.
The reviewer follows the normative rules from an admitted value to
the exact input of the operation whose properties are relied upon.
An earlier merge of non-equivalent values is assessed separately;
Le Expires 11 March 2027 [Page 12]
Internet-Draft Comparing Derived Identifiers September 2026
otherwise, false matches can be assessed under that operation's
properties and threat model. This argument uses specified semantic
boundaries, not private implementation stages.
Normalization, truncation, duplicate elimination, field omission,
case folding, reordering, or projection can merge classes if they
remove a distinction the chosen relation retains. Their effect is
evaluated against that relation, rather than classified as harmless
or harmful from the name of the operation alone.
Cryptographic compression is a deliberate source of possible false
matches. A fixed-width digest does not prove mathematical uniqueness
over an arbitrarily large input space. The relevant property depends
on control over the compared inputs: collision resistance can apply
when an attacker chooses both, while second-preimage resistance can
be more directly relevant to a fixed target [RFC4270]. A concrete
specification states its threat model and the strength required for
that use. A strong primitive does not account for a distinction
already lost before its input.
6. Worked Example: JWK Thumbprints
An incorrect variant of JWK Thumbprints [RFC7638] illustrates a
source-level false non-match. The admitted sources are symmetric-key
JWKs with unique member names; all member names and values are ASCII
strings requiring no JSON escaping. The k member is the canonical
base64url representation of the key bytes. Source equivalence ~S
means that the required members represent the same key; optional
metadata such as kid is irrelevant. The short key is illustrative
and unsuitable for operational cryptography.
s1 = {"kty":"oct","k":"AQIDBA","kid":"key-a"}
s2 = {"kid":"key-b","k":"AQIDBA","kty":"oct"}
Section 3.2 of [RFC7638] identifies k and kty as the required members
for oct keys. The correct derivation domain V contains abstract JSON
objects with exactly those members, and ~ is equality of their
values. Member order is not part of an abstract object.
P selects the required members. E serializes its input members in
lexicographic name order without insignificant whitespace, using UTF-
8. H is SHA-256, F(v) = H(E(v)), and G(s) = F(P(s)). B is canonical
unpadded base64url encoding, used to display digest octets. Its
injectivity preserves digest equality.
The correct projection gives:
Le Expires 11 March 2027 [Page 13]
Internet-Draft Comparing Derived Identifiers September 2026
P(s1) = P(s2) = {"k":"AQIDBA","kty":"oct"}
x = UTF-8('{"k":"AQIDBA","kty":"oct"}')
B(H(x)) = wu1x1E8ZalDXyCmkHbObTJtYLf1tsvgFQPkQrPV0Wl0
Here P excludes metadata because it does not distinguish the key. E
fixes one octet representation of the common projected value.
Independent implementations following these rules reproduce the same
thumbprint.
Now consider an all-members variant. Its domain V' includes the
optional members, and ~' is equality of all member values,
independent of member order. P' copies each source into V'. E is
defined on both domains and serializes every member of its input
using the rules above. The displayed hash inputs and results are:
E(P'(s1)) = UTF-8('{"k":"AQIDBA","kid":"key-a","kty":"oct"}')
B(H(E(P'(s1)))) = Clz-_36rOSZty0DktmH12iZN8lJWlQBCqpAh3GQDjLs
E(P'(s2)) = UTF-8('{"k":"AQIDBA","kid":"key-b","kty":"oct"}')
B(H(E(P'(s2)))) = s_NDqKYE4nNzgXZXX9EMdjCb0fsvPE8o3okOkxHuOg8
Although s1 ~S s2, G'(s) = H(E(P'(s))) gives different outputs for
them: a false non-match and hence a split of one source class. At
the declared boundaries, P' fails preservation because its results
are not equivalent under ~'. The encoder preserves their difference
and the hash receives different octets. The output values establish
the source-level failure; the intermediate relations locate the
failed mapping obligation. Changing H cannot establish preservation
by P'.
Attribution depends on those contracts. If the domain instead treats
metadata as irrelevant and an encoding contract requires equivalent
values to produce equal octets, including the metadata violates that
encoding contract. The observed output difference alone does not
select the intermediate contracts or a unique failing stage.
[RFC7638] already defines the correct construction and explains the
exclusion of optional members. The review makes the source relation,
projection, encoding, and output evidence explicit, distinguishing a
source-level failure from conformance to a different domain relation.
6.1. Composition Review: JWK Thumbprint URIs
JWK Thumbprint URIs [RFC9278] add a URI representation. Fixing
SHA-256 and the source domain of Section 6, this review covers the
exact generated ASCII form:
Le Expires 11 March 2027 [Page 14]
Internet-Draft Comparing Derived Identifiers September 2026
prefix = "urn:ietf:params:oauth:jwk-thumbprint:sha-256:"
U(s) = prefix || B(G(s))
Here || denotes concatenation. The defining obligations are:
* Source and digest: Section 3.2.2 of [RFC7638] excludes optional
members, Section 3.3 fixes member representation and ordering, and
Section 3.4 requires reproducing parties to select the same hash.
* Output binding: Section 3 of [RFC9278] defines the prefix and
algorithm component, Section 4 identifies the algorithm-name
registry, and Section 5 makes SHA-256 mandatory to implement.
* Composition: With the fixed prefix and injective B, U(s1) = U(s2)
if and only if G(s1) = G(s2). URI wrapping introduces no split or
merge at this boundary. It also preserves any equality already
present in G, including the equality for the two sources in
Section 6 despite their different kid values.
A consuming application must establish the relation relevant to its
own use. Consider a proposed application that admits the JWKs of
Section 6 with a kid member and defines configuration equivalence by
equal keys and exact kid equality. It proposes to decide that
comparison solely by equality of correctly derived U values.
Under this configuration relation, s1 and s2 are not equivalent.
Nevertheless, P(s1) = P(s2), and their complete URIs are equal. This
is a demonstrated source-level false match: reuse of P fails
reflection for the configuration relation. The thumbprint and URI
clauses correctly represent key comparison; they supply no argument
for retaining kid. The application needs a construction that
represents its richer relation. If the application relation is
unspecified, the review records that missing contract. Equal URI
bytes alone do not establish this application-level failure.
This review separates an established URI composition argument from a
failed hypothetical application use. A consumer also establishes any
claimed binding from a received URI to a JWK, for example by
recomputing it. Neither URI equality nor this specification review
establishes authorization state, implementation agreement, or hash
strength.
The argument covers the fixed algorithm and generated spelling.
Alternative accepted URI spellings need their own comparison rules.
Different algorithm selections instantiate different derivations;
unequal URIs across those selections do not establish different keys
without a cross-scheme argument (Section 4.3).
Le Expires 11 March 2027 [Page 15]
Internet-Draft Comparing Derived Identifiers September 2026
7. Worked Review: Preserving Role and Member Associations
Consider a mapping whose source is a finite sequence of role and
native-account-name pairs. Roles are the exact ASCII strings origin
and destination; names are nonempty ASCII letters. Native comparison
ignores ASCII letter case. Source equivalence ~S requires the same
set of role and lowercase-name pairs, ignoring presentation order and
duplicates. No resolver or mutable alias participates.
s1 = [(origin, ALICE), (destination, bob)]
s2 = [(origin, bob), (destination, alice)]
s3 = [(destination, BOB), (origin, alice)]
s1 ~S s3
s1 not-~S s2
The derivation domain admits records of exact ASCII strings, finite
sets, and pairs under a fixed common context. Its equivalence is
exact structural equality. The context is omitted below.
A proposed Pbad collects roles and adapted names into separate sets:
Pbad(s1) = Pbad(s2) =
({origin, destination}, {alice, bob})
All individual labels survive, but their association is lost. This
mapping fails reflection: distinct source classes become one domain
value. Deterministic downstream encoding and hashing receive the
same input, so their correctness cannot recover the association.
Pgood instead produces the set of role and lowercase-name pairs. It
retains exactly the set defining ~S and therefore preserves and
reflects the relation. An encoder after Pgood must represent pair
framing and set membership consistently with the comparison, and
preserve distinctions between those sets before compression.
The review method in Section 1.2 gives the following record:
Le Expires 11 March 2027 [Page 16]
Internet-Draft Comparing Derived Identifiers September 2026
+===========+=============================================+
| Review | Evidence and limitation |
| item | |
+===========+=============================================+
| Scope and | Section 7; fixed ASCII folding, exact |
| contract | structural equality, and common context. |
+-----------+---------------------------------------------+
| Source | s1 ~S s3; s1 not-~S s2. These check |
| controls | selected equivalence and distinction cases. |
+-----------+---------------------------------------------+
| Mapping | Pbad(s1) = Pbad(s2) witnesses failure of |
| failure | reflection at the source-mapping boundary. |
+-----------+---------------------------------------------+
| Mapping | Pgood retains exactly the normalized pair |
| repair | set defining ~S: a general argument for |
| | preservation and reflection. |
+-----------+---------------------------------------------+
| Encoding | No concrete encoder is instantiated. Its |
| | obligations remain unestablished here. |
+-----------+---------------------------------------------+
| Remaining | Hash properties, implementation agreement, |
| evidence | and consumer binding are not established by |
| | this example. |
+-----------+---------------------------------------------+
Table 1: Worked Review Record
Case changes and reordering exercise equivalence; swapping
associations exercises a required distinction. The mapping proof
does not depend solely on these controls. Different preimages would
still not prove that a finite hash has no collisions. Consumers of
the repaired construction need its comparison semantics; earlier
outputs cannot acquire the missing association by reinterpretation.
8. Security Considerations
Comparison semantics are security-sensitive. An attacker who can
substitute result-affecting rules can cause a correctly computed
identifier to be misinterpreted. Mechanisms that acquire, negotiate,
or select semantics protect both the selection and its binding to the
output against substitution and downgrade under their threat model.
Authenticating candidate profiles alone does not protect their
selection [RFC7696]. Transparency can expose changes but does not
itself establish the applicable semantics.
Representation differentials can change admission or the derived
value (Section 2.3). Loss before a cryptographic primitive cannot
inherit that primitive's collision or second-preimage properties for
Le Expires 11 March 2027 [Page 17]
Internet-Draft Comparing Derived Identifiers September 2026
distinctions already erased (Section 5). Concrete specifications
assess the complete source-to-output path and the cryptographic
properties appropriate to their use.
Both directions of comparison error matter. If policy grants a
privilege on a match, a false non-match can deny a permitted
operation. If policy denies a privilege on a match, the same error
can permit a forbidden operation [RFC6943]. Rejection, unavailable
semantics, and operational failure also need explicit handling;
Section 4.2 explains why they are not evidence of non-equivalence.
Equal derived identifiers alone establish no authentication,
authorization, provenance, freshness, ownership, revocation status,
consensus, or trust. Public deterministic derivation over a
predictable or low-entropy domain also permits testing guesses about
the underlying value. Hashing does not provide confidentiality in
that case. Operational resource limits remain necessary for denial-
of-service protection even when outside domain semantics.
If comparison involves a secret expected value and observable timing,
implementations should use an equality check whose timing does not
depend on secret octets or the first mismatch position. The threat
model determines whether lengths also require protection. Protecting
the final check alone does not address side channels in parsing,
mapping, or derivation.
9. Privacy Considerations
Stable derived identifiers can correlate interactions and contexts
[RFC6973]. This framework provides no unlinkability or anonymity;
predictable inputs also permit the guessing described in Section 8.
An explicit scoping input can limit where equality is stable and
reduce unintended linkage, but supplies no privacy guarantee by
itself. Systems sharing identifiers across administrative domains
assess what cross-domain correlation reveals. Scoped or ephemeral
derivations can mitigate tracking when long-lived persistence is
unnecessary. Any scope or lifetime input changing the result is
fixed by the applicable semantics; stability is assessed within that
scope or epoch.
Registries, resolvers, logs, transparency systems, and other
surrounding services can expose additional metadata and require their
own privacy analysis.
Le Expires 11 March 2027 [Page 18]
Internet-Draft Comparing Derived Identifiers September 2026
10. IANA Considerations
This document has no IANA actions.
11. References
11.1. Informative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270,
DOI 10.17487/RFC4270, November 2005,
<https://www.rfc-editor.org/info/rfc4270>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC6943] Thaler, D., "Issues in Identifier Comparison for Security
Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013,
<https://www.rfc-editor.org/info/rfc6943>.
[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>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/info/rfc7638>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
Le Expires 11 March 2027 [Page 19]
Internet-Draft Comparing Derived Identifiers September 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/info/rfc8949>.
[RFC9679] Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object
Signing and Encryption (COSE) Key Thumbprint", RFC 9679,
DOI 10.17487/RFC9679, December 2024,
<https://www.rfc-editor.org/info/rfc9679>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>.
[RFC9278] Jones, M. and K. Yasuda, "JWK Thumbprint URI", RFC 9278,
DOI 10.17487/RFC9278, August 2022,
<https://www.rfc-editor.org/info/rfc9278>.
[RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and
C. Wood, "Hashing to Elliptic Curves", RFC 9380,
DOI 10.17487/RFC9380, August 2023,
<https://www.rfc-editor.org/info/rfc9380>.
[W3C-RDFC-1.0]
Longley, D., Kellogg, G., and D. Yamamoto, "RDF Dataset
Canonicalization", W3C Recommendation, 21 May 2024,
<https://www.w3.org/TR/2024/REC-rdf-canon-20240521/>.
[Maziarz2021]
Maziarz, K., Ellis, T., Lawrence, A., Fitzgibbon, A., and
S. Peyton Jones, "Hashing Modulo Alpha-Equivalence", ACM
PLDI 2021, pp. 960-973, DOI 10.1145/3453483.3454088, June
2021, <https://doi.org/10.1145/3453483.3454088>.
[NIST-SP800-185]
Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived
Functions: cSHAKE, KMAC, TupleHash, and ParallelHash",
NIST SP 800-185, DOI 10.6028/NIST.SP.800-185, December
2016, <https://doi.org/10.6028/NIST.SP.800-185>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
Le Expires 11 March 2027 [Page 20]
Internet-Draft Comparing Derived Identifiers September 2026
[Dhall] Dhall authors, "Dhall Language Tour: Installing Packages",
<https://docs.dhall-lang.org/tutorials/Language-
Tour.html#installing-packages>. Living documentation,
accessed 7 September 2026.
Appendix A. Relationship to Existing Work
[RFC6943] analyzes identifier comparison for security purposes,
including identifier generation, canonicalization, comparison
procedures, and false positive and false negative outcomes. This
document neither updates nor replaces that guidance. It narrows the
focus to independently recomputed identifiers and a source-to-result
review path covering source mapping, equivalence in the derivation
domain, fully instantiated derivation semantics, output comparison,
and assessment of the evidence for obligations at the declared
boundaries. Section 6.1 illustrates how the review connects clauses
across a published derivation and a consuming identifier format.
[RFC6920] defines hash-based names for digital objects. JWK
Thumbprints [RFC7638] and COSE Key Thumbprints [RFC9679] select key
members, fix deterministic representations, and derive digests.
[RFC8785] defines canonical JSON, while [RFC8949] separates the CBOR
data model from serialization variants and permits application-
specific value equivalence. [W3C-RDFC-1.0] defines canonical RDF
dataset results whose equality corresponds to dataset isomorphism.
These domain-specific constructions are not replaced here; this
document isolates the reusable comparison contract around them.
[RFC9380] illustrates domain separation with injective encodings at
specified steps and separate cryptographic treatment of long tags, as
discussed in Section 5.1. [RFC3986] remains relevant when derived
identifiers are carried in broader naming systems.
TupleHash in [NIST-SP800-185] directly addresses unambiguous hashing
of tuples of strings. Name-based UUID generation in [RFC9562] fixes
the namespace and canonical name representation for reproducible
output. Dhall semantic integrity checks [Dhall] hash a canonical
representation after interpretation, so selected source-level changes
do not change the hash. These are antecedents for framing, scoped
derivation, and normalization before hashing; this framework does not
introduce those techniques.
Le Expires 11 March 2027 [Page 21]
Internet-Draft Comparing Derived Identifiers September 2026
[Maziarz2021] defines hashing of program terms modulo alpha-
equivalence, separating an equivalence-respecting summary from
ordinary hashing and collision analysis. The review path used here
applies across such constructions to distinguish incoherent
derivation that produces false non-matches and splits equivalence
classes, an earlier structural merge, and residual equality
attributable to a later lossy operation. It does not replace domain-
specific equivalence or collision analysis.
Author's Address
Thanh Le
Viet Nam
Email: vnlemanhthanh@gmail.com
Le Expires 11 March 2027 [Page 22]