Specification v0.1
A layer-2 taxonomy on the base protocol for comparing patterns and exchanging fraud signals without sharing the underlying data.
Status: Draft, pending technical review Version: 0.1 Date: 2026-07-17 This is a layer-2 taxonomy on the base data-sharing protocol. It references the base specification normatively and adds no base-layer rule of its own. The overview page orients and links, and does not repeat this content. Initiator and first maintainer: mintBlue (see Section 8, Governance). The initiator is not the owner.
Abstract
This taxonomy specifies how independent parties compare patterns and exchange fraud signals without sharing the underlying data behind them. It is a light, domain-level agreement that sits above the base protocol. Each party derives an irreversible, deterministic fingerprint from an underlying attribute using an Oblivious Pseudorandom Function (RFC 9497), submits only the fingerprint, and never releases the attribute. Two parties holding the same underlying fact produce the same fingerprint, so the system can establish that a common signal exists, without either party learning what the other holds, because the key that computes the fingerprint is held by a role separate from the participating parties, a separation this taxonomy requires but whose concrete key-custody construction is still open pending technical review (Section 11). At a configured overlap threshold, a single match signal is delivered to exactly one mandated receiver, which learns only that a match exists and never the underlying records. Every match-signal exchange is anchored to the public audit layer: the anchor records that a match exchange occurred and when, never what was compared. The taxonomy defines three functional roles, participating parties, sector coordinators acting as moderators, and a single mandated receiver, and it configures the base protocol's request-response and cross-sector exchange patterns. No party ever hands its records to a shared store; only irreversible fingerprints are compared, and only a threshold-gated match reaches one receiver.
1. Introduction and scope
1.1 What this taxonomy is
This taxonomy specifies what fraud-signal data independent parties share and with whom, so that they compare patterns without sharing the underlying data. It is a domain-level agreement above the base layer, in the sense fixed by the base protocol (§1.2): it fixes the domain rules for one field of work and defers every base-layer mechanism to the base specification. It exists so that a bank, a payment service, and a delivery firm, each holding a fragment of the same pattern and none permitted to share the personal data behind it, can establish a common signal and route it to one authorised recipient without any of them disclosing a record.
1.2 What this taxonomy is not
This taxonomy defines no base-layer mechanism. It specifies no envelope, no key derivation, no addressing, and no anchoring mechanics of its own. Those are provided by the base protocol and are referenced here by section number, never restated (Section 3). It carries no legal determination and no authority designation. The mandated receiver is a functional role in this specification; whether a given party may hold that role, and under which legal mandate, is outside this document. Where a legal grounding is relevant, this taxonomy states only that a mandated receiver operates under an applicable legal mandate, and says no more.
1.3 The organising principle
The organising principle is comparison without disclosure. A party turns an underlying attribute into a fingerprint that cannot be turned back into the original. Matching operates over fingerprints only. A single onward signal is delivered when, and only when, enough independent parties have produced the same fingerprint to satisfy an agreed threshold. Two properties hold throughout. A participating party never learns whether its own submission contributed to a match, so no party is warned that it is under scrutiny (the anti-tipping-off intent). The mandated receiver never learns the underlying records, only that a match exists.
1.4 External context
The design follows the open-protocol position that the base protocol adopts (§1.4). That position is cited there and is not repeated here; this taxonomy stays consistent with it.
1.5 Adoption path (non-normative)
A working group MAY adopt this taxonomy in stages. An early stage typically exchanges qualitative signal classes: modus-operandi descriptions (typified fraud patterns, in a vocabulary the working group agrees) and intervention notices (measures that proved effective against them). These classes are framed as typologies and measures, not as records about persons; they use the base protocol's standard exchange patterns, run under the same three roles and moderation rules defined in Section 7, and inherit the same audit semantics: the public audit layer records that a notice was exchanged, never its operational content. The fingerprint mechanism in Sections 4 to 6 is the target state for record-level comparison. A working group migrating from qualitative classes to fingerprint comparison changes the version of its domain agreement, not the base protocol, and nothing in the transition alters the roles or the audit trail. This subsection is descriptive: conformance (Section 9) is defined against the fingerprint mechanism.
2. Terminology and conventions
2.1 Normative key words
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174, and only when they appear in capital letters.
2.2 Citation of open standards
The fingerprint derivation in this taxonomy rests on RFC 9497, "Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups" (IRTF CFRG, December 2023). It is cited the way one cites an RFC: neutrally, as the published open standard on which a mechanism rests and which any party may implement independently. The base-protocol standards, the open overlay standards, the key-derivation standard, the canonical-encoding standard, and the open identity standards, are inherited from the base specification (§2.2) by reference and are not re-listed here.
Throughout this document, a reference of the form §n.n denotes a section of the base data-sharing specification, published at /protocols/data-sharing/v0.1. This document's own sections are always written in full (for example, "Section 4").
2.3 Glossary
Base-protocol terms (party, record, recorded action, envelope, field, placement, the public audit layer, anchor, proof, mandate, delegation, epoch) are defined in the base specification's glossary (§2.3) and are not redefined here. This taxonomy adds the following domain terms.
| Term | Definition |
|---|---|
| Fingerprint | An irreversible, deterministic value derived from an underlying attribute using an Oblivious Pseudorandom Function (RFC 9497). Identical inputs under the same evaluation key yield identical fingerprints; the underlying attribute cannot be recovered from the fingerprint. |
| Participating party | A party that holds underlying records, derives fingerprints locally, and submits only fingerprints into an exchange. |
| Sector coordinator | A sector representative acting as a moderator: it admits participating parties into an exchange, aggregates and routes fingerprints within a sector, and moderates, without gaining access to underlying attributes. |
| Mandated receiver | The single functional role authorised to receive and act on a match signal. It learns only that a match exists, never the underlying records, and it acts under a scoped, time-bounded, revocable mandate (§3.6). |
| Match | Equality of two fingerprints. A match reveals nothing about the underlying attribute beyond the fact that two parties hold a common fingerprint. |
| Overlap threshold | The minimum number of independent participating parties that MUST produce the same fingerprint before a match signal is eligible for delivery. |
| Match signal | The fact-and-metadata message delivered to the mandated receiver when the overlap threshold is satisfied. |
3. Relationship to the base protocol
This taxonomy adds no rule to the base protocol. Each mechanism below is provided by the base protocol and is referenced here by section, never restated. A fingerprint travels inside a base-protocol record; a match-signal exchange is a base-protocol recorded action; the audit trail, the delegated identity, and the encryption of the fingerprint field are all base-protocol machinery. The taxonomy's own rules, in Sections 4 to 7, sit on top of that machinery.
| Base-protocol mechanism | Base section | How this taxonomy uses it |
|---|---|---|
| Record and recorded-action shape; deterministic canonical encoding | §3.1 | A fingerprint is carried as a field inside a record; a match-signal exchange is a recorded action with the fixed action shape. |
| Per-field encryption, placement descriptor, per-field commitment | §3.3 | The fingerprint is an independently encrypted and committed field; its placement follows the base rules. |
| Key derivation, dual-curve, per-epoch rotation | §3.3 | Fingerprints MAY be scoped to an epoch so they are not linkable across time windows beyond what matching needs. |
| Addressing and discovery over the open overlay standards | §3.2 | Participating parties, sector coordinators, and the mandated receiver are addressed, and topics admitted, through the base rules. |
| Anchoring every exchange to the public audit layer; commitment; independently verifiable proof | §3.4 | A match-signal exchange is anchored: the audit layer records that a match exchange occurred and when, never what was compared. |
| Deterministic replay and drift detection | §3.5 | The match-signal log reconstructs identically for any party that holds the keys it is entitled to. |
| Identity and delegation; scoped, time-bounded, revocable mandates; local verification | §3.6 | The mandated receiver receives and acts under a mandate; every role's actions are signed by a mandated actor. |
| Data-protection erasable-mandate pattern | §3.6, PROV-4 | Referenced, not resolved: a fingerprint and any pseudonymous mapping honour an erasure request the same way the base pattern does. |
| Conformance model: MUST/SHOULD/MAY levels; test-vector suites named, not embedded | §6 | This taxonomy's conformance section inherits these levels and the named-not-embedded vector convention. |
| Governance: open licence, public working group, initiator-not-owner, hand-over at three or more active parties | §7 | This taxonomy's governance paragraph is consistent with, and defers to, that model. |
Rule. An implementation of this taxonomy MUST be a conforming implementation of the base protocol (§6) before it adds the rules in Sections 4 to 7.
4. Fingerprint derivation
A fingerprint is derived from an underlying attribute with an Oblivious Pseudorandom Function as specified in RFC 9497. The derivation has four load-bearing properties. It is deterministic: the same input under the same evaluation key always yields the same fingerprint, which is what lets two parties match. It is irreversible: the function is one-way, and the underlying attribute cannot be recovered from the fingerprint. It is keyed: evaluation requires a secret key, so a party that holds only fingerprints and the public parameters cannot enumerate candidate inputs offline, a property that a plain hash of a low-entropy identifier does not have. It is oblivious: the key-holder role evaluates the function without learning the input. A fingerprint is carried as an independently encrypted and committed field per the base rules (§3.3).
Rules.
- An implementation MUST derive a fingerprint from an underlying attribute using an OPRF as specified in RFC 9497, such that identical inputs under the same evaluation key yield identical fingerprints and the underlying attribute cannot be recovered from the fingerprint.
- An implementation MUST NOT transmit the underlying attribute. Only the fingerprint, with its commitment and placement per §3.3, leaves a participating party's environment.
- An implementation MUST key the derivation so that a party holding only fingerprints and the public parameters cannot enumerate candidate inputs offline.
- The evaluation MUST be oblivious as specified in RFC 9497: the key-holder role MUST NOT learn the underlying attribute during evaluation.
- An implementation SHOULD support verifiable evaluation (the VOPRF mode of RFC 9497) so that a participating party can confirm the committed evaluation key was used. This verifies the key that was used, not the outcome of any match, and so it does not conflict with the anti-tipping-off rule in Section 6.
- An implementation SHOULD scope fingerprints to an epoch (§3.3) to limit cross-window linkability. Where partially oblivious evaluation is used, the epoch tag MAY be the public input (the POPRF mode of RFC 9497).
Technical detail (provisional, pending technical review)
[FS-PROV-1] The OPRF ciphersuite selection, the prime-order group and hash chosen under RFC 9497, and its alignment with the base protocol's curves (§3.3), is not pinned here. Only the interop-load-bearing shape is normative in the body above: an OPRF per RFC 9497 that is deterministic, irreversible, keyed, and oblivious.
[FS-PROV-2] The key-custody and evaluation-key model, that is, which role holds the OPRF evaluation key, and whether it is a single key-holder or a distributed or threshold construction, is the sharpest technical-review question and is not decided here. It touches the separation between the key-holder role and a participating party (Section 7). The requirement is stated; the construction is deferred.
[FS-PROV-4] The epoch scoping of fingerprints in the SHOULD-rule above (§3.3 epoch model) trades cross-window linkability against the base forward-secrecy behaviour (the base specification's PROV-2): fingerprints scoped per epoch will not match across epochs. Whether, and how far, to scope is subject to technical review; the rule is stated as a SHOULD in the body and the epoch construction is deferred to the base protocol.
The concrete construction is fixed by a named, not embedded, test-vector approach, mirroring the base protocol's convention (§6). The byte-level values are fixed by the named test vectors, not by this document.
5. Matching semantics and thresholds
Matching is equality over fingerprints. Two fingerprints match if and only if they are equal, and a match reveals nothing about the underlying attribute beyond the fact that two parties hold a common fingerprint. There is no fuzzy or partial match in this version. A configured overlap threshold gates any onward signal: below it, nothing is delivered and nothing is disclosed.
Rules.
- Two fingerprints MUST be treated as a match if and only if they are equal. No partial or fuzzy match is defined in this version.
- Matching MUST operate only over fingerprints. No rule in this taxonomy discloses an underlying attribute to any party.
- A deployment MUST define an overlap threshold: the minimum number of independent participating parties that MUST independently produce the same fingerprint before a match signal is eligible for onward delivery. This specification fixes the requirement; the value is a per-agreement parameter set by the working group.
- Below the threshold, an implementation MUST NOT deliver a match signal and MUST NOT disclose the partial overlap to participating parties.
- A single participating party MUST NOT be counted more than once toward the threshold.
Technical detail (provisional, pending technical review)
[FS-PROV-3] The default overlap-threshold value and the concrete anti-inflation counting mechanics, that is, how independence of a participating party is established so that one party cannot inflate the count, are per-agreement and their framing is subject to technical review. The requirement is normative in the body; the value and the counting construction are deferred to the working group.
6. Match-signal delivery to a single mandated receiver
When the overlap threshold is satisfied, exactly one mandated receiver receives a single match signal. The signal carries only the fact and metadata of the match, never an underlying record. The exchange is anchored to the public audit layer per §3.4, so that it is independently verifiable that a match exchange occurred and when, without the audit layer recording what was compared. The mandated receiver acts under a mandate per §3.6.
Rules.
- Exactly one mandated receiver MUST be the recipient of a match signal per agreement.
- A match signal MUST carry only the fact and metadata of a match: a reference to the matched fingerprint, the count and the threshold that were satisfied, and the time. It MUST NOT carry any underlying record or attribute.
- The match-signal exchange MUST be recorded as an action anchored to the public audit layer per §3.4. The anchor records that a match exchange occurred and when, and MUST NOT record what was compared.
- Participating parties MUST NOT learn whether their submission contributed to a match, nor the identity of other contributors, except where the mandated receiver is separately authorised to disclose. This is the anti-tipping-off guarantee.
- The mandated receiver MUST act under a scoped, time-bounded, revocable mandate per §3.6, and every role's actions MUST be signed by a mandated actor per §3.6.
- A match signal is a signal to investigate under the mandated receiver's own legal basis, not a determination that any party or person committed fraud. A match means only that two parties hold the same fingerprint, which may reflect a coincidence or a benign shared attribute. The mandated receiver MUST NOT treat a match as dispositive.
7. Roles and the three-layer moderation model
This taxonomy defines three distinct functional layers. Participating parties hold the underlying records and submit only fingerprints. Sector coordinators, acting as moderators, admit participating parties and route fingerprints within a sector without reading underlying attributes. A single mandated receiver receives and acts on a match signal. Admission runs through a working group, which is the base protocol's cross-sector exchange pattern.
The diagram uses functional role labels only and is free to copy. Underlying records never leave a participating party's environment; only fingerprints move up, and only a single match signal moves to the mandated receiver.
Rules.
- Participating parties MUST derive fingerprints locally and submit only fingerprints. Underlying data MUST NOT leave their environment.
- Sector coordinators MUST admit participating parties through the working-group admission process (the cross-sector pattern,
/patterns/cross-sector), MAY aggregate and route fingerprints within a sector, and MUST NOT gain access to underlying attributes. - A sector coordinator MUST NOT deliver a match signal to any party other than the single mandated receiver.
- The three layers MUST be distinct functional roles. Where a single legal entity holds more than one role, it remains bound by the separation guarantees of this taxonomy: obliviousness, anti-tipping-off, and single-receiver delivery. The specific separation between the OPRF key-holder role and a participating party is provisional (see
[FS-PROV-2]). - This taxonomy configures the base protocol's request-response pattern (
/patterns/request-response, a bounded match or no-match answer) and its cross-sector pattern (/patterns/cross-sector, sector-coordinator mediation and working-group admission). It introduces no new base-layer pattern.
Boundary with the roadmap growth mechanic. The matching of independent submissions onto one fingerprint, routed to one mandated receiver, is the domain matching semantics of this taxonomy over the V1 request-response and cross-sector patterns. It is not the deferred demand-aggregation growth mechanic, which bundles demand across many parties and is roadmap text only in the exchange-patterns library. The two are distinct and MUST NOT be conflated.
Relationship to secure-compute clean rooms. Where an implementation combines this taxonomy with a data clean room or secure multi-party compute, the two are complementary and are not rivals: a clean room answers a bounded, batch research question over data no one can see, while this taxonomy establishes a common signal in a continuing stream and anchors that it happened. An implementation MAY use both together.
Relationship to a central shared fraud database. The common status-quo alternative in this domain is a central shared fraud list or consortium clearing-house: every party hands its records to one trusted holder that keeps the combined dataset. That model concentrates every party's records in a single store, which is a honeypot and a single point of breach or compromise, and it requires each party to disclose records to the holder. Under this taxonomy no such store exists: records never leave a party's environment, only irreversible fingerprints are compared, and only a threshold-gated match signal moves to one mandated receiver. No single party sees everyone's data. The two approaches answer the same need by opposite means, and this is stated as a factual contrast, not a claim against any specific deployment.
8. Governance
This taxonomy is governed under the base protocol's model (§7). It is developed in a public working group; anyone may join to review it, propose changes, or help define the domain rules. It will be published under the open, royalty-free licence being finalised for the base protocol, with no registration requirement and no fee, so that anyone is free to implement, fork, and run it. mintBlue initiated this taxonomy and maintains its first version; the initiator is not the owner, and stewardship is intended to pass to the working group as participation grows, on the same hand-over intent as the base protocol (at three or more active parties). Versions are explicit and forkable. The domain parameters that this specification deliberately leaves open, the overlap-threshold value (FS-PROV-3), the OPRF ciphersuite (FS-PROV-1), and the key-custody model (FS-PROV-2), are ratified through the working group and are not set unilaterally. The full governance model is documented at /governance.
9. Conformance
Conformance inherits the base protocol's levels (§6). A MUST rule is required for interoperability; a SHOULD rule is recommended and its absence must be justified; a MAY rule is optional. An implementation states which SHOULD and MAY provisions it supports.
An implementation of this taxonomy is interoperable when it demonstrates the following. Each item maps to a rule in Sections 4 to 6 and to a named, not embedded, test-vector or behavioural check.
| # | An implementation MUST demonstrate | Maps to | Check |
|---|---|---|---|
| 1 | Fingerprint determinism and irreversibility per RFC 9497 | Section 4 | named test vector (RFC 9497 derivation) |
| 2 | Oblivious evaluation: the key-holder role learns no input | Section 4 | behavioural |
| 3 | Equality matching over fingerprints, with no fuzzy match | Section 5 | behavioural |
| 4 | Overlap-threshold gating, with no delivery or disclosure below the threshold | Section 5 | behavioural |
| 5 | A single-receiver match signal carrying only fact and metadata, no underlying data | Section 6 | behavioural |
| 6 | The match-signal exchange anchored per §3.4, recording that not what | Section 6 | inherits base anchoring vector |
| 7 | Mandate-scoped receipt per §3.6 | Section 6 | inherits base delegation check |
How to connect. A third party connects to an exchange under this taxonomy in one of three roles.
- Participating party. Be a conforming base-protocol implementation (§6). Derive fingerprints per RFC 9497 with the agreed ciphersuite. Submit fingerprint fields as base-protocol record fields (§3.1, §3.3). Anchor the exchange per §3.4. Never transmit an underlying attribute.
- Sector coordinator. Implement the working-group admission and moderation of the cross-sector pattern (
/patterns/cross-sector). Support oblivious evaluation and aggregation of fingerprints without reading underlying attributes. Route a match signal only to the single mandated receiver. - Mandated receiver. Receive a match signal under a scoped, time-bounded, revocable mandate (§3.6). Verify the anchored exchange (§3.4). Act only on the fact of a match, never on an underlying record you were not given.
The named test-vector suites and the concrete OPRF ciphersuite will be published alongside the base-protocol reference implementation, mirroring the base convention (§6). The vectors are not embedded in this document.
10. Versioning and changelog
This is version 0.1, status Draft, pending technical review. The base-protocol version this taxonomy targets is 0.1. Future versions are proposed and ratified through the public working group; a change to a MUST rule requires working-group ratification, and versions remain explicit so that adopters choose when to move.
Changelog
- v0.1 (2026-07-17) Initial specification. Establishes fingerprint derivation via an OPRF (RFC 9497), equality matching and the overlap threshold, single-receiver match-signal delivery anchored to the public audit layer, the three-layer functional role model, the relationship to the base protocol, the governance paragraph, and the conformance section. Four items are marked provisional pending technical review (Section 11).
11. Provisional-items register
The following items are the only content in this specification pending technical review. Each is written inside a collapsed technical-detail block at its point of use and tagged inline. This taxonomy uses its own FS-PROV-n numbering to avoid collision with the base protocol's PROV items.
| Item | Topic | Provisional because | Handling in this version |
|---|---|---|---|
| FS-PROV-1 | OPRF ciphersuite selection (Section 4): prime-order group and hash per RFC 9497, and alignment with the base curves | The selection is a technical-review call | The shape is fixed and normative in the body; the ciphersuite is deferred to a named test vector |
| FS-PROV-2 | OPRF key-custody and evaluation-key model (Section 4, Section 7): single key-holder versus distributed or threshold, and the key-holder to participant separation | The sharpest security and technical-review question | The requirement is stated; the construction is deferred to the working group |
| FS-PROV-3 | Overlap-threshold default and anti-inflation counting (Section 5) | Per-agreement, and the framing is subject to review | The requirement is normative; the value and counting construction are per working group |
| FS-PROV-4 | Epoch scoping and cross-window linkability of fingerprints (Section 4) | Fingerprints scoped per epoch will not match across epochs, a trade-off subject to review | Written as a SHOULD in the body; references the base epoch model (§3.3) and the base forward-secrecy trade-off (the base specification's PROV-2) |
Inheritance note. Where this taxonomy touches base-protocol provisional items, it references and does not resolve them: the settlement-layer naming (the base specification's PROV-1) stays as "the public audit layer", and the data-protection erasable-mandate pattern (the base specification's PROV-4) is referenced for how a fingerprint and any pseudonymous mapping honour an erasure request. Content from any internal security analysis, threat model, or privacy study is excluded from this version, not deferred: it does not appear here in any form.