VN vnlemanhthanh@gmail.com

derived identifiers identifier comparison comparison domain equivalence relation false match false non-match false merge false split interoperability 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.

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

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 . The relation is established from the intended comparison, rather than selected merely to fit observed outputs.

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

Specify What Is Compared

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

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

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

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

Compare Under Defined Semantics

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

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.

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 .

Account for Information Loss and False Matches

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

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

Worked Example: JWK Thumbprints An incorrect variant of JWK Thumbprints 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 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: 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. 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.

Composition Review: JWK Thumbprint URIs JWK Thumbprint URIs add a URI representation. Fixing SHA-256 and the source domain of Section 6, this review covers the exact generated ASCII form: 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 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 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).

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: Worked Review Record

Review item	Evidence and limitation
Scope and contract	Section 7; fixed ASCII folding, exact structural equality, and common context.
Source controls	s1 ~S s3; s1 not-~S s2. These check selected equivalence and distinction cases.
Mapping failure	Pbad(s1) = Pbad(s2) witnesses failure of reflection at the source-mapping boundary.
Mapping repair	Pgood retains exactly the normalized pair set defining ~S: a general argument for preservation and reflection.
Encoding	No concrete encoder is instantiated. Its obligations remain unestablished here.
Remaining evidence	Hash properties, implementation agreement, and consumer binding are not established by this example.

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.

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

Privacy Considerations Stable derived identifiers can correlate interactions and contexts . 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.

IANA Considerations This document has no IANA actions.

References Informative References Dhall authors Living documentation, accessed 7 September 2026.

Relationship to Existing Work 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. defines hash-based names for digital objects. JWK Thumbprints and COSE Key Thumbprints select key members, fix deterministic representations, and derive digests. defines canonical JSON, while separates the CBOR data model from serialization variants and permits application-specific value equivalence. 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. illustrates domain separation with injective encodings at specified steps and separate cryptographic treatment of long tags, as discussed in Section 5.1. remains relevant when derived identifiers are carried in broader naming systems. TupleHash in directly addresses unambiguous hashing of tuples of strings. Name-based UUID generation in fixes the namespace and canonical name representation for reproducible output. Dhall semantic integrity checks 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. 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.