Licence and governance
Open to use. Each published version of the specification keeps its licence.
Specification · versions 0.x
CC BY-ND 4.0
Open to use and share with attribution. No modified versions while the format matures.
Specification · planned from 1.0
CC BY 4.0
Open to use, adapt and build on, with attribution.
Schema
Apache 2.0
Open to use in any product, with an explicit patent grant. Validator: planned.
The name
AttestScope
The name of an open format. A tool may call itself compatible with AttestScope 0.1.1 if it writes or verifies record files according to that version of the specification.
Security and privacy: what is covered, and what is planned
The threat model published with the specification, as it stands: for each threat, the format’s answer and what remains. What remains with the organisation is written down, along with what is planned.
Issuer · riftveil.ai Signer Planned
Twelve threats, one answer for each
6· nothing remains4· a risk remains, it is written down2· the organisation’s responsibility
| Status | Threat | The format’s answer | What remains |
|---|---|---|---|
| nothing remains | Text altered after issue | Every verifier recomputes the fingerprint from the record file | No risk on the record file; a PDF shown alone proves nothing |
| a risk remains, it is written down | Text altered in a PDF | Detected as soon as the record file is used to verify | Not detected on a PDF alone; a qualified seal on the PDF is planned |
| a risk remains, it is written down | ID or seal copied onto another document | Verification shows the texts sealed under that ID | A person must compare those texts with the document they were given |
| nothing remains | Registered report presented as generated | One seal label per origin: riftveil-seal-v1 and riftveil-register-v1 | None |
| nothing remains | Follow-up moved to another report | The follow-up fingerprint includes that of the report: a follow-up belongs to one report only | None |
| nothing remains | Follow-up edited after sealing | Its own fingerprint and its own seal, with the issuer’s time | None if sealed; an unsealed follow-up proves nothing |
| nothing remains | Seal time moved | The time is part of the sealed message: …|fingerprint|sealed_at | None |
| a risk remains, it is written down | Forged seal | HMAC-SHA256 truncated to 160 bits, with a secret key; Ed25519 signature on the same message | An HMAC seal can only be checked by the issuer; the Ed25519 signature is checked by anyone with the public key; the date remains the Riftveil time stamp, unless time-stamped by a third-party authority (planned) |
| a risk remains, it is written down | Stolen sealing key | Secret store, numbered keys, rotation without invalidating earlier seals; a separate signing key; no later signature for records dated after signing started | Seals made with the stolen key cannot be told apart, but new records still need the signing key. A record backdated before signing started could receive a later signature, shown as such by verifiers |
| nothing remains | Signing key used by a test deployment | Signing key in the production environment only; signing bound to the production host | None if the rule is kept |
| nothing remains | Signature removed (file relabelled 0.1) | An unsigned file dated after signing started is rejected | None |
| a risk remains, it is written down | Follow-up added by someone other than the person named | Not prevented: the seal proves when, not who; the name is shown as declared, never as verified | Identity needs a qualified signature on the PDF today; the organisation’s account and a qualified signature on the follow-up are planned |
| a risk remains, it is written down | Mass sealing by robots | Bot check; daily limits per IP address and for the whole site; refused when the counters fail | A short burst can exceed a limit |
| the organisation’s responsibility | Fabricated project assessed for real | The format records the review; judging the substance falls to the person who signs and to their organisation | Not detectable: the seal proves provenance and integrity; the truth of the project is the responsibility of the person who signs |
| the organisation’s responsibility | Nobody verifies | Organisational | Make the record file mandatory in the decision file |
What remains with the organisation, and what is planned
Judging the project and the review
A seal proves provenance and integrity: who issued the record, when, for what exact content. Riftveil asks the questions; judging whether the project is right and whether the review was good falls to the person who signs, and the decision remains theirs.
The signer’s identity
Today, on riftveil.ai: a simple electronic signature, under the name the person declared; the seal proves when the follow-up existed and that it has not changed. Verified identity is the organisation’s responsibility. Planned, in the module for organisations: the person signs in with their organisation’s account, which attests their identity and answers for it. Planned for the decisions that require it: an advanced or qualified signature from a recognised trust service provider.
The date, independently of the issuerOption · Planned
Today, the seal is checked on riftveil.ai, and the Ed25519 signature is checked with riftveil.ai’s public key, without going through riftveil.ai. In the online tool, the date is the Riftveil time stamp: the time of its clock. Planned: a time stamp from a third-party authority, which will make the date independent: an optional qualified time stamp (with AttestScope traceability) or the organisation’s own authority. Each token will be checked with its authority’s certificate.
Privacy: what each endpoint receives, what is kept
A SHA-256 fingerprint cannot be turned back into the text. The names, the decision and the signature never leave the device.
- Assessment
project · context
for a single run at the model provider; riftveil.ai keeps none of it
- POST /api/decide
ID · report fingerprint and seal · follow-up fingerprint
never the names, the decision or the signature
- POST /api/register
a fingerprint and its profile
never the project or the report: the fingerprint is computed in the browser
- POST /api/verify
ID · fingerprints · seals · times
never the texts; fingerprints recomputed on the verifier’s side
riftveil.ai · server functions · receives, computes, answers; keeps none of the items above
no text · no list of IDs · no list of fingerprints
only daily counters, keyed on a secret hash of the IP address, to limit abuse
project and context, for a single run; no training on the text
the provider’s own retention applies
IDs
60 bits
drawn at random by a cryptographic generator, on top of the date and the time to the second
- Two IDs can only collide in the same second, with the same 60 bits: 1 chance in 1.15 × 1018 for any pair.
- At 1 million records a day for one issuer: about 1 chance in 500 million per year of a single duplicate.
Sealing keys
12 months
of notice before S1 seals stop being checked
- Key in a secret store, never in code, a shared file or a conversation.
- Numbered keys: rotation without invalidating earlier seals.
- Ed25519 public keys published on GitHub, on the format’s site and at a fixed address on riftveil.ai (riftveil.ai/keys.json).
- No key is removed from that list: a compromised key stays on it, marked and dated.
- Riftveil provides an assessment tool and a record format. For a qualified trust service within the meaning of the eIDAS Regulation, turn to a provider listed on the EU trusted list.
Abuse
One usage limit per day
registrations of reports made elsewhere, per address
- Bot check on registration and on the follow-up seal.
- Daily limits per hashed IP address, and for the whole site.
- The verification endpoint stays open to any site: it receives fingerprints only and keeps nothing.
Version 0.1.1 is open for comment.