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, . [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, DOI 10.17487/RFC4270, November 2005, . [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, . [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, . [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, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . 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, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [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, . [W3C-RDFC-1.0] Longley, D., Kellogg, G., and D. Yamamoto, "RDF Dataset Canonicalization", W3C Recommendation, May 2024, . 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]