Verification before platform
Most product trust problems are not solved by asking users to believe another dashboard. They are solved by producing artifacts that can be checked later: hashes, signatures, timestamps, ID packages, and callback records.
OTRUST starts from those artifacts. The UI exists to make ID creation usable, but the core object is the record that survives the UI.
Blind notarization
The timestamping flow hashes content in the browser. The service receives the hash, signature, public key, timestamps, and record metadata. It does not need the raw document to verify that the document existed.
- The user keeps the original file.
- The public record can still be verified later.
- The service minimizes what it must know to be useful.
Anchors and independence
OpenTimestamps gives OTRUST a path to external anchoring without pretending that a hosted service alone is the source of truth. A record can be useful immediately and stronger once it is anchored externally.
Issuer-bound identity
Identity is not only login. In B2B flows, the important question is narrower: does this user control a current credential from a trusted issuer, and can the relying party verify that fact without receiving the source document?
OTRUST therefore keeps Auth disabled until issuer provenance and exact partner redirects can be verified. The partner experience can be branded, but the credential verifier remains visible.
Why the boundary matters
A trust product should not hide who performs the trust-sensitive step. OTRUST keeps URLs, disclosures, ID links, and privacy notes explicit so users know when they are interacting with OTRUST and when they return to a partner.