Principles for Comparing Independently Derived Identifiers
draft-le-comparing-derived-identifiers-00

Network Working Group                                              T. Le
Internet-Draft                                            22 August 2026
Intended status: Informational                                          
Expires: 23 February 2027

       Principles for Comparing Independently Derived Identifiers
               draft-le-comparing-derived-identifiers-00

Abstract

   When separate implementations independently derive identifiers and
   later compare them for equality, interoperability depends on more
   than the final identifier syntax or digest algorithm.  The
   implementations need common semantics for which values are in scope,
   which distinctions matter to the comparison, and how identifiers are
   derived.  Otherwise values intended to compare as equivalent can
   produce different identifiers, or processing can erase a relevant
   distinction before a later lossy or cryptographic operation is
   reached.

   This document gives principles for specifications that define such
   identifiers.  It covers the comparison domain and equivalence
   relation, complete derivation semantics, the semantics under which
   output equality is interpreted, and processing that can create false
   matches before properties of a later operation are relied upon.  It
   complements identifier comparison and hash-based naming
   specifications by focusing on the specification boundary from source
   values to independently reproducible identifiers.  The document does
   not define a new identifier syntax, canonicalization format,
   resolver, registry, trust framework, or hash procedure.

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.

Le                      Expires 23 February 2027                [Page 1]
Internet-Draft        Comparing Derived Identifiers          August 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specify What Is Compared  . . . . . . . . . . . . . . . . . .   4
     2.1.  Domain and Equivalence  . . . . . . . . . . . . . . . . .   4
     2.2.  Source Values and Representations . . . . . . . . . . . .   6
   3.  Specify Complete Derivation Semantics . . . . . . . . . . . .   7
   4.  Compare Under Defined Semantics . . . . . . . . . . . . . . .   8
     4.1.  Applicable Comparison Semantics Must Be Unambiguous . . .   9
     4.2.  Changes Define Different Comparison Semantics . . . . . .  10
   5.  Account for Information Loss and False Matches  . . . . . . .  10
     5.1.  Preserve Relevant Distinctions Before Downstream
           Operations  . . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Characterize False Matches  . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  13
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  14
   Appendix A.  Relationship to Existing Work  . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Deriving an identifier is often straightforward.  Deciding what
   equality of two independently derived identifiers means is not.  In
   this document, an independently derived identifier is a deterministic
   result that separate implementations can compute under specified
   derivation semantics without a shared authority assigning the result.
   The term describes an analysis case, not a new identifier class at
   the wire level.  The document is intended for specifications that
   define content addresses, thumbprints, semantic validators, canonical
   digests, deterministic references, roots, or similar values that are
   later compared for equality.

Le                      Expires 23 February 2027                [Page 2]
Internet-Draft        Comparing Derived Identifiers          August 2026

   Two implementations can use the same digest algorithm and still
   disagree because they operate on different values or apply different
   field selection, framing, normalization, domain separation inputs,
   parameters, or other choices that can change the result.  Conversely,
   preprocessing can erase a distinction that the specified comparison
   intends to preserve, causing later identifier equality to reflect an
   earlier merge rather than a property of the final digest or other
   lossy operation.  Distinct representations can also denote values
   that the specification intends to compare as equivalent, so
   representational difference alone need not require different derived
   identifiers.

   Deterministic derivation, canonicalization, hashing, content
   addressing, and independent recomputation are established techniques.
   Some specifications already define a domain-specific equivalence
   relation and a canonical form together; RDF Dataset Canonicalization
   [W3C-RDFC-1.0], for example, defines a canonicalization function
   whose equal canonical results correspond to isomorphic RDF datasets.
   The architectural concern here is therefore not a claim that semantic
   equivalence before canonicalization or hashing is new.  It is the
   reusable comparison contract around such techniques: the derivation
   domain and equivalence relation, the complete derivation semantics,
   the semantics under which outputs may be compared, and the location
   and consequences of processing that can merge distinctions relevant
   to the comparison.  This document collects principles for that
   boundary across derived-identifier specifications; concrete
   specifications remain responsible for their domain-specific rules.

   [RFC6943] analyzes identifier comparison for security purposes and
   discusses identifier generation, canonicalization, equivalence
   procedures, and false positive and false negative outcomes.  This
   document narrows attention to specifications in which separate
   implementations recompute an identifier from an underlying value
   under shared derivation semantics.  It makes explicit the source-to-
   domain boundary, coherence between the specified equivalence relation
   and derivation, and the location of any many-to-one processing before
   a downstream operation whose properties are relied upon.  The
   resulting concern is not a replacement for identifier comparison
   rules; it is the derivation contract under which equality of the
   resulting identifiers can be interpreted as evidence about the
   underlying values.

   The central question is:

   Under what specified semantics, and with what stated false match
   properties, does equality of independently derived identifiers
   support treating their inputs as equivalent for the comparison being
   performed?

Le                      Expires 23 February 2027                [Page 3]
Internet-Draft        Comparing Derived Identifiers          August 2026

   This document calls equality of derived identifiers for two values
   that are not equivalent for the specified comparison a "false match".
   The term specializes the false-positive comparison concern of
   [RFC6943] to equality of derived outputs evaluated against the
   equivalence relation specified for the derivation domain.

   The principles do not depend on the final identifier being a
   cryptographic digest; any deterministic result compared this way
   needs defined comparison semantics.

   The principles apply when separate implementations deterministically
   derive identifiers or comparison tokens and later compare those
   outputs by equality without relying on one runtime authority to
   assign the result for both sides.  The derivation domain can contain
   byte strings, structured values, graphs, or other precisely defined
   values.  The intended relation over inputs is an equivalence
   relation.  Directional, approximate, similarity, containment, and
   other non-equivalence relations are outside scope, as are identifiers
   whose comparison semantics are supplied entirely by authoritative
   assignment or lookup.  This document does not prescribe one
   identifier format, one encoding, or one cryptographic topology.

2.  Specify What Is Compared

2.1.  Domain and Equivalence

   A specification defines a domain of values to which its comparison
   applies and an equivalence relation over that domain.  The relation
   is reflexive, symmetric, and transitive.  The specification is
   precise enough that independent implementations can determine whether
   a value is in the domain and whether two values are equivalent for
   the specified comparison.

   If the derivation is written as F, F denotes the fully instantiated
   derivation after every applicable algorithm, parameter set, suite,
   and other result-affecting choice has been fixed.  It is constant on
   each equivalence class:

   v1 ~ v2  =>  F(v1) = F(v2)

Le                      Expires 23 February 2027                [Page 4]
Internet-Draft        Comparing Derived Identifiers          August 2026

   This implication is the minimum coherence condition between the
   comparison semantics and the derivation.  If equivalent in-domain
   values produce different identifiers under the same applicable
   derivation semantics, the derivation fails this coherence condition;
   that divergence is a conformance or interoperability failure, not a
   permitted comparison outcome.  The reverse implication is not
   automatic.  A bounded or otherwise lossy derivation can assign the
   same identifier to values from different equivalence classes;
   Section 5 addresses that case.

   The relation is part of the specification semantics.
   Canonicalization can be one technique for implementing or testing
   those semantics, but it does not by itself decide which distinctions
   are relevant.  As discussed in [RFC6943], comparison can be defined
   through canonical forms or through other equivalence procedures; a
   unique canonical representation is not a prerequisite for every
   comparison rule.

   The equivalence relation is the specification's statement of which
   distinctions matter for this comparison.  A distinction intentionally
   ignored by that relation need not be preserved by the derivation.  A
   distinction that separates values the relation treats as non-
   equivalent remains relevant to the comparison and is not silently
   erased by preceding processing unless the resulting false match
   behavior is itself part of the specified mechanism.

   The specification also defines domain membership, including invalid
   values and any feature or form that the specification itself
   excludes.  That semantic boundary is distinct from a particular
   implementation's local inability to process an otherwise in-domain
   value because of memory, message size, time, or deployment limits.  A
   value outside the specified domain does not acquire comparison
   semantics merely because one implementation can serialize or hash it;
   conversely, a local capability failure does not make an otherwise in-
   domain value semantically invalid.  Domain membership is therefore
   independently testable rather than inferred from whatever input an
   implementation happens to process.  A resource bound intended to
   affect domain membership is part of the domain definition; a local
   deployment ceiling that is not so specified remains an operational
   limitation rather than comparison semantics.

   An equivalence relation need not be byte equality.  It can, for
   example, ignore ordering where the domain defines a mathematical set,
   or treat multiple accepted encodings as representations of the same
   value.  Conversely, a specification can deliberately use exact byte
   string equality.  The important property is not which relation is
   chosen, but that the choice is explicit and independently applicable.

Le                      Expires 23 February 2027                [Page 5]
Internet-Draft        Comparing Derived Identifiers          August 2026

   The relation defined here is scoped to the specified comparison.  The
   document does not require it to answer whether two richer application
   objects are universally "the same" for every purpose.  A different
   protocol can define a different comparison over the same source
   material without contradiction.

2.2.  Source Values and Representations

   Specifications frequently receive richer source objects or serialized
   representations before reaching the value on which identifier
   derivation operates.  Those steps need to be described carefully
   because any distinction removed before derivation cannot later affect
   the identifier.

   Suppose a source value s is mapped by P into the derivation domain:

   s  --P-->  v  --F-->  identifier

   If P(s1) = P(s2), no later deterministic processing can make the
   derived identifiers differ.  A specification that intends a source
   distinction to affect comparison therefore retains that distinction
   in the value passed to the derivation, or otherwise includes it in
   the specified input semantics.  If the distinction is intentionally
   discarded, the identifier does not distinguish it.

   This condition is loss in the source mapping, not by itself a false
   match between two values in the derivation domain.  Once P(s1) =
   P(s2), the derivation receives one and the same domain value.  If s1
   and s2 were intended to remain distinguishable for the surrounding
   comparison, the source-to-value mapping did not preserve that
   intended distinction.  False-match analysis of F begins with distinct
   in-domain values.  Keeping these cases separate prevents properties
   of a downstream derivation operation from being used to justify a
   distinction that was already removed by P.

   Completeness relative to the declared derivation domain does not by
   itself establish that the source mapping preserved every source
   distinction that ought to matter.  A mapper can populate every field
   required by the destination value while the destination model still
   omits a material distinction present in the source.  The
   specification or profile that defines P therefore remains responsible
   for identifying which source distinctions are material to the
   intended comparison and for stating how they are represented,
   deliberately excluded, or otherwise accounted for.  Mechanical
   completeness of a mapping is not a substitute for that semantic
   judgment.

Le                      Expires 23 February 2027                [Page 6]
Internet-Draft        Comparing Derived Identifiers          August 2026

   The source mapping is itself part of the applicable comparison
   semantics.  Given the same specified source input and the same
   applicable mapping semantics, independent implementations produce the
   same mapped domain value.  Any dependency that can change the mapped
   value while those specified inputs and semantics are otherwise
   unchanged is either part of the defined input to P or fixed
   unambiguously by the mapping.  Implementation preference or ambient
   mutable discovery, validation, registry, clock, ledger,
   configuration, or network state is insufficient if different
   selections can change the mapped value.  If such external state is
   intentionally comparison-relevant, the mapping defines the particular
   state or version on which the result depends and how that selection
   is fixed.

   This is different from representation decoding.  Multiple wire
   representations can map to equivalent values without implying that
   the source semantics were projected away.  A specification that
   accepts several representations defines their decoding and validation
   sufficiently precisely that independent implementations agree on the
   resulting values and rejected inputs.

   Representation rules are therefore not incidental when they affect
   which value reaches the derivation.  Parser differentials, duplicate
   handling, number conversion, Unicode processing, field omission,
   ordering, or defaulting can otherwise make implementations derive
   identifiers from different values while believing they implement the
   same comparison.  In particular, absence, null or sentinel values,
   typed empty values, and exceptional numeric values are not presumed
   interchangeable when the distinction affects the comparison domain.
   Handling of duplicate keys is defined before a generic host object
   model can silently apply first-wins or last-wins behavior.

   Specifications state source mapping separately from representation
   decoding so that deliberate projection from a richer source is not
   confused with accidental loss during parsing.

   Testability of this boundary includes accepted and rejected cases
   near the domain edge, because agreement on expected final outputs
   alone does not establish agreement on which values enter the
   derivation.

3.  Specify Complete Derivation Semantics

   A specification fixes every semantic choice needed to derive the
   identifier from a value in the domain.  Depending on the mechanism,
   these can include:

   *  selected fields or components;

Le                      Expires 23 February 2027                [Page 7]
Internet-Draft        Comparing Derived Identifiers          August 2026

   *  normalization or canonicalization, framing, ordering, and domain
      separation rules;

   *  algorithm, output length, and other fixed parameter choices; and

   *  external material on which the derivation intentionally depends,
      with an unambiguous binding to the value or version used.

   These are normative semantics that can change the result, not
   implementation internals.  Any dependency that can change the result
   while the specified input is otherwise unchanged is either part of
   the defined input or fixed unambiguously by the applicable rules.  A
   mutable registry label, unrecorded clock value, current ledger head,
   local configuration choice, or network response is insufficient if
   different selections can change the result.  Secret material or
   material subject to access control is not prohibited, but the
   selected key, key version, or other parameter is part of the
   applicable derivation semantics even when the material itself is not
   public.

   Given an in-domain value, the applicable rules, and any specified
   material they are authorized to use, independent implementations can
   reproduce the same identifier without a shared authority assigning it
   or selecting hidden state that can change the result.  Registries,
   resolvers, repositories, or negotiation services can locate or
   authenticate applicable specification material, but once those
   semantics are fixed, loss of the acquisition mechanism does not
   change what the derivation means.

   "Independent" in this document refers to implementation-level
   reproducibility under fixed semantics.  It does not require inputs to
   be public, every party to possess the same protected material, or
   public recomputation by arbitrary observers.  However, if material
   required for the derivation is held exclusively by one party such
   that no separate conforming implementation with the required
   authorization can reproduce the result, that case does not satisfy
   the independently derived analysis used here.  This distinguishes
   reproducible derivation from assignment of an opaque identifier by an
   authority.  Production of a value whose result can only be accepted
   from one runtime authority is likewise outside this analysis case.

4.  Compare Under Defined Semantics

Le                      Expires 23 February 2027                [Page 8]
Internet-Draft        Comparing Derived Identifiers          August 2026

4.1.  Applicable Comparison Semantics Must Be Unambiguous

   In this document, the applicable comparison semantics comprise the
   comparison domain and equivalence relation, the derivation semantics,
   and any additional rules needed to interpret equality of the
   resulting outputs.

   Output octets do not necessarily carry all of those semantics.  Equal
   octets can arise under different domains, equivalence relations,
   derivation rules, algorithms, parameters, or interpretation rules.
   Output equality therefore has shared comparison meaning only when the
   applicable comparison semantics are unambiguous to the parties
   performing the comparison.

   A surrounding protocol can fix those semantics by protocol version
   and message position, carry a binding to them, select a defined
   profile, bind to immutable specification material, negotiate among
   defined alternatives, or use another unambiguous mechanism.  This
   document does not require a globally allocated identifier for a rule
   set or a universal negotiation mechanism.  The binding also need not
   be part of the derived output itself.  Portability of output octets
   and portability of their comparison meaning are separate properties.

   Representation equality does not establish interpretation equality.
   Equal context strings, profile labels, selectors, namespace tokens,
   references, or derived identifiers do not by themselves prove that
   two parties apply the same semantics.  Names, URIs, registry numbers,
   package names, and version labels can help locate candidate material,
   but discovery is distinct from establishing which semantics apply
   [RFC3986].  Mutable aliases or locators are insufficient when their
   resolution can change semantics that affect comparison.

   When applicable semantics depend on a schema, registry entry,
   normalization table, imported profile, executable module, parameter
   set, or similar material whose change can affect the domain,
   equivalence relation, derivation, or interpretation, the surrounding
   protocol fixes that dependency unambiguously, either directly or
   through a deterministic immutable rule.  A name derived from content
   can help bind a reference to exact bytes [RFC6920], but byte identity
   or authentication alone does not establish semantic compatibility.
   If information required to determine the applicable semantics is
   unavailable or ambiguous for a comparison, output equality alone is
   insufficient to interpret the inputs as equivalent; that condition
   does not establish either a match or a non-match conclusion.

Le                      Expires 23 February 2027                [Page 9]
Internet-Draft        Comparing Derived Identifiers          August 2026

   Two different specification documents can describe the same
   applicable semantics.  Conversely, different semantics are not made
   directly comparable merely because their output formats or output
   octets happen to match.  If a protocol needs comparison across
   different derivation schemes, it defines that bridge explicitly.

4.2.  Changes Define Different Comparison Semantics

   Changing a rule in a way that changes the domain, equivalence
   relation, derived output, or interpretation defines different
   comparison semantics.  Existing identifiers are interpreted under the
   semantics with which they were produced; changing an algorithm,
   framing rule, normalization rule, domain separation input,
   dependency, or other choice that can change the result does not
   silently reinterpret them.

   Different applicable derivation semantics can also result from
   selecting among alternatives already defined by one specification,
   such as different algorithm or parameter suites.  Such a selection
   does not by itself require a new specification or profile version.
   The selected alternatives remain different derivation semantics
   unless an explicit bridge defines how their outputs are compared.

   A surrounding protocol can define migration, negotiation, succession,
   or explicit comparison between old and new outputs, but that does not
   make the derivations the same operation or directly comparable by
   default.  Cryptographic algorithm transition is one instance of this
   more general rule, and applicable agility guidance remains relevant
   [RFC7696].

5.  Account for Information Loss and False Matches

5.1.  Preserve Relevant Distinctions Before Downstream Operations

   A later operation cannot repair a distinction that earlier processing
   has already erased.

   Suppose the derivation is described for security analysis as:

   v  --E-->  x  --H-->  identifier

   and the specification relies on a false match or cryptographic
   property of H.  If two values that are not equivalent for the
   specified comparison satisfy E(v1) = E(v2), then equal final
   identifiers for those values are not a collision of H; H received the
   same input.

Le                      Expires 23 February 2027               [Page 10]
Internet-Draft        Comparing Derived Identifiers          August 2026

   More generally, for a given pair of non-equivalent accepted values
   and a normative derivation path containing several deterministic
   transforms, review can localize loss at the first transform whose
   outputs for that pair become equal after the immediately preceding
   normative values were unequal.  Every later deterministic transform
   then receives equal inputs and cannot restore the distinction.  This
   first-merge localization is an analysis method, not a requirement to
   expose implementation-internal stages.  A merge in the source mapping
   P is the distinct upstream case described in Section 2.2; within the
   derivation, the same method separates pre-downstream loss from loss
   introduced by the downstream operation itself.

   Therefore, when a specification relies on properties of a downstream
   operation, preceding normative processing either preserves the
   distinctions relevant to the comparison or explicitly characterizes
   the loss it introduces.  This requirement concerns the normative
   semantic path, not an implementation's private decomposition into
   functions or internal states.  A specification can define one
   compound transform or several named steps; the relevant question is
   whether processing before the downstream operation can merge inputs
   that the comparison intends to distinguish.

   If earlier processing deliberately removes such distinctions, that
   loss is analyzed on its own terms.  The security argument cannot
   transfer the downstream primitive's collision properties backward
   across an already many-to-one transform.  Conversely, if E(v1) =
   E(v2) implies v1 ~ v2 for accepted inputs, then a later equal input
   to the primitive cannot have arisen from an earlier merge of values
   that the comparison intends to distinguish.

   Ambiguous concatenation is a common example.  If a domain
   distinguishes ordered pairs of strings but a preimage encoder simply
   concatenates the components, then ("ab", "c") and ("a", "bc") both
   become "abc".  A later hash receives the same bytes in both cases, so
   collision resistance of the hash says nothing about that merge.
   Boundaries, lengths, or another unambiguous encoding need to preserve
   the distinction when the comparison requires it.  Cryptographic
   specifications address the same class of problem through injective or
   otherwise unambiguous encodings and domain separation.  [RFC9380],
   for example, requires injective domain separation encodings so
   distinct invocations do not collapse onto the same downstream input.
   The same condition applies when variable-length context, profile, or
   domain separation values are composed with other inputs: their
   framing preserves component boundaries so distinct tuples do not
   merge before the downstream operation.

Le                      Expires 23 February 2027               [Page 11]
Internet-Draft        Comparing Derived Identifiers          August 2026

   Normalization, truncation, duplicate elimination, field omission,
   case folding, ordering changes, or projection can have the same
   architectural effect when they erase a distinction that the specified
   comparison intends to preserve.

5.2.  Characterize False Matches

   A derivation need not permit false matches.  If F(v1) = F(v2) implies
   v1 ~ v2 for values in the domain, then identifier equality and input
   equivalence coincide for that specification.

   When distinct equivalence classes can produce the same identifier,
   false match behavior is part of the mechanism's correctness and
   security analysis.  Merely documenting that an operation is lossy
   does not make its output useful for comparison.  A function that maps
   every value to one constant output is fully deterministic and fully
   specified, yet equality of its outputs provides no useful evidence
   about whether its inputs are equivalent.

   A practical review starts with the downstream operation whose
   properties the specification relies upon.  The reviewer identifies
   the exact input presented to that operation, follows the normative
   processing that maps an accepted value in the comparison domain to
   that input, and asks whether two non-equivalent accepted values can
   arrive there as the same input.  If they can, that earlier merge is
   analyzed on its own terms.  If they cannot, equal output behavior can
   then be assessed under the properties and threat model of the
   downstream operation.  This review order does not require a
   specification to expose an implementation's internal pipeline.

   Cryptographic compression is an important form of deliberate loss.  A
   fixed-width digest is not a proof of mathematical uniqueness over an
   arbitrarily large input space.  The relevant security property
   depends on the attacker's control over the compared inputs.
   Collision resistance can be relevant when the attacker can choose
   both inputs; second-preimage resistance can be the more direct
   property when one target input is fixed [RFC4270].  Concrete
   specifications analyze their attacker model rather than treating
   every event with equal outputs as the same cryptographic problem.

   Loss before a cryptographic primitive and collision at that primitive
   are different failure modes.  A strong hash does not compensate for
   ambiguous framing or another earlier transform that has already
   merged values the comparison intends to distinguish.

Le                      Expires 23 February 2027               [Page 12]
Internet-Draft        Comparing Derived Identifiers          August 2026

6.  IANA Considerations

   This document has no IANA actions.

7.  Security Considerations

   Comparison semantics are security-sensitive.  If an attacker can
   substitute a rule that can change the result while both parties
   believe the same semantics apply, a correctly computed identifier can
   still be interpreted incorrectly.  Mechanisms that acquire,
   negotiate, or select those semantics therefore protect the selection
   and its binding to the derived output against substitution and
   downgrade according to their threat model.  Protecting each candidate
   profile is insufficient if an attacker can influence which candidate
   is selected.  Applicable algorithm agility guidance remains relevant
   [RFC7696].  Transparency can make changes observable but does not
   itself establish which semantics apply.

   Representation differentials can cause implementations to accept
   different inputs or derive from different values; Section 2 describes
   the required semantic boundary.  Likewise, processing that merges
   non-equivalent values before a downstream lossy or cryptographic
   operation cannot inherit the later operation's collision or second-
   preimage properties; Section 5 describes that analysis.

   Where derivation permits false matches, concrete specifications state
   properties, algorithm strength, and transition behavior appropriate
   to their comparison use and threat model.  Equal derived identifiers
   do not by themselves establish authentication, authorization,
   provenance, freshness, ownership, revocation status, consensus, or
   trust.  Where a security decision relies on preventing an observer
   from testing guesses about the underlying value, a public
   deterministic derivation over a low-entropy or predictable domain
   does not provide that protection.  Operational resource limits remain
   necessary for denial-of-service protection even when they do not
   affect comparison semantics.

8.  Privacy Considerations

   Stable derived identifiers can enable correlation across interactions
   or contexts [RFC6973].  This document does not provide unlinkability
   or anonymity.  Hashing also does not provide confidentiality for low-
   entropy or predictable domains because an observer can derive
   identifiers for guessed values and compare them.

   An explicit scoping input can limit the scope over which equality is
   stable and reduce unintended correlation, but it changes the derived
   result and does not by itself provide a privacy guarantee.

Le                      Expires 23 February 2027               [Page 13]
Internet-Draft        Comparing Derived Identifiers          August 2026

   Registries, resolvers, logs, transparency systems, and other
   surrounding services can expose additional metadata and require their
   own privacy analysis.

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

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

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

Le                      Expires 23 February 2027               [Page 14]
Internet-Draft        Comparing Derived Identifiers          August 2026

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

   [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, May 2024,
              <https://www.w3.org/TR/rdf-canon/>.

Appendix A.  Relationship to Existing Work

   [RFC6943] analyzes identifier comparison for security purposes,
   including identifier generation, canonicalization, differing
   comparison procedures, and the consequences of false positive and
   false negative comparison results.  This document focuses more
   narrowly on independently recomputed identifiers and makes the
   source-to-domain boundary and derivation coherence conditions
   explicit.  It requires complete and established derivation and
   comparison semantics and localizes merges that occur before a
   downstream operation whose properties are relied upon.  Under one
   fixed set of applicable semantics, equivalent inputs that derive
   different outputs violate the coherence condition described in
   Section 2.1 rather than constituting an allowed negative comparison
   result.  A false match is the corresponding false-positive concern at
   this derived-output boundary: equal outputs arise from inputs that
   are not equivalent for that comparison.  [RFC6920] defines hash-based
   names for digital objects and bindings between hash algorithms,
   digest values, and those names.  JWK Thumbprints [RFC7638] and COSE
   Key Thumbprints [RFC9679] are concrete constructions that select key
   members, fix deterministic representations, and define digest
   derivation.

   [RFC8785] defines canonical JSON so cryptographic operations over
   JSON can be repeatable across implementations.  [RFC8949]
   distinguishes the CBOR data model from serialization variants and
   allows application-specific data models to define value equivalence
   independently of those variants.  [W3C-RDFC-1.0] goes further for one

Le                      Expires 23 February 2027               [Page 15]
Internet-Draft        Comparing Derived Identifiers          August 2026

   concrete graph data model: it defines canonical RDF dataset results
   such that two datasets produce the same canonical result if and only
   if they are isomorphic.  These specifications show that value
   equivalence and deterministic representation can be specified
   together for a particular domain.  This document does not replace
   those domain-specific rules; it isolates the reusable comparison
   contract a derived-identifier specification needs to establish around
   them.  [RFC9380] provides a cryptographic example in which
   unambiguous, injective domain separation encoding is required before
   downstream properties are relied upon.  [RFC3986] remains relevant
   when derived identifiers are carried in broader naming systems.

Author's Address

   Thanh Le
   Viet Nam
   Email: vnlemanhthanh@gmail.com

Le                      Expires 23 February 2027               [Page 16]