The office that signs
They already know the person. They publish a sealed tag. The file stays with them. We never see the name.
What this is
Two offices sometimes need to know they mean the same person. They should not post the person’s file around to find out.
SealRelay only answers that. It keeps sealed tags, not names. A yes means a signed note was published. A yes does not mean the person is good, employed, or still agreeing today. If you need “true now”, you ask again.
A no looks the same every time. Nobody watching can tell why. There is no master list of a person across every office. You never make a password here.
Two sides
The office that asks
They ask if that tag exists. Yes or no. Papers, if any, go office to office — never through us.
In real work
A lender and a bank
A bank already checked who owns a company. A lender asks: is there a sealed tag for this person at that bank. Yes or no. The papers, if any, go bank to lender — never through us.
Before a collections call
They ask payroll: did this person allow a confirmation of employment. They do not get salary. They get yes or no. A watcher cannot tell which from the shape of the answer.
You
You do not register. If you want to see who holds a tag, you use the app that already knows you. To stop it, you tell that office. We get a signal, not your login.
Who is who
- You The person a note is about. You have no SealRelay account, PIN, or key file. Binding happens at the office that signs, with the ID they already use.
- The office that signs They attest and publish a sealed tag. We do not keep a central list of who is allowed to sign.
- The office that asks They look up. A yes and a no are the same class of answer: a match result, not a licence to stop thinking.
- The operator Runs the matching service. Has no name file. Does not take over the asking office’s risk.
Two applications, three roles
Two applications are built on the same client surface. They differ in what earns the right to an answer — not in a launch country. Domain rules stay out of matching.
Both use the same three roles, and they are the three offices above under their working names: the Subject is you, the person a note is about; Part A is the office that signs and publishes it; Part B is the office that asks. The rest of this page uses those names.
Consent-share
What makes the ask allowed is consent. The Subject consents at Part A. Part A publishes a signed note. Part B asks in a share flow. The consent exists before anything is published.
Identity layer only: a legal-entity id, that a qualified eID or seal was used, and ownership or control at signing time. No risk scores. No watchlists. No extra attributes smuggled in.
- Subject The person or firm the note is about. They consent at Part A. They make no account here.
- Part A Holds the consent and the papers. Publishes the signed note. The file stays with them.
- Part B Asks, with that consent, whether a sealed tag exists. Gets yes or no, and nothing else.
Part B sees only what this share flow returns. Absence of a flag is not absence of conflict. Nothing raised is not the same as nothing there.
Every result carries a coverage indicator. Coverage says how recently Part A published. It is freshness, not completeness. A partial result without that indicator is not shown at all.
Self-discover
What makes the ask allowed is that you are asking about yourself. The Subject asks whether anyone holds anything about them. That is a discover flow. There is no consent object, because nobody else is being told anything.
The answer is existence and who holds it — not identity-layer fields. What is known and not known stays three separate flags: coverage, a break in the record, and a missing completeness note. Never one “incomplete” badge, and never a share of a life.
- Subject Asks. Binding still happens with a qualified eID or seal at the office that already knows them. Still no SealRelay account.
- Part A The office that published a discovery note. It does not learn who else the Subject asked.
- Part B Does not ask in this application. The pairwise shape still hides the Subject’s other asks from every Part A.
Every result carries a coverage indicator here too. Coverage is freshness, not completeness. If the rest were known, it would not be missing.
Is this log still watched
Independent roles sign that they still see the same log. The client counts how many signed in the last window, and checks that against the floor this domain set. Only roles are shown — never a name, a person, or an office.
Below the witness floor — this log is NOT fully verified
Waiting for a liveness signal
No liveness signal received yet. Until one arrives, do not treat this log as fully verified. The counts below stay blank on purpose — a blank is honest, a guessed number would not be.
- Co-signed: not received
- Witness roles on the roster: not received
- Window: 24 hours (86400 seconds)
- Floor: not received
- Below floor: not received
- Fully verified: not received
A domain may run with no witnesses at all. That is legal: roster is 0, co-signed is 0, and the client says split-view detection is not active rather than pretending the log is watched.
When below-floor is true the client refuses to treat the log as fully verified, and says so where the answer is read — not in a log line and not in a footnote.
Open rules
The written rules will be published, so anyone can build their own client and check our answers instead of taking our word for them. They are not published yet, and they are not on this page. When they are, you will find them here first.
Closed matching
Matching stays ours. Open rules do not turn the operator’s matching service into a public audit of every customer. When artefacts are published, this site is the source.