Face to Face

Face to Face Notary Docs

Notary Platform Status

A practical inventory of what the current notary platform provides, how it lines up with Ohio known-signer RON requirements, and what still needs to be built before the service should be treated as production-ready.

Open Notary Open RON Workflow Notary Home Docs

Summary

The platform currently supports an early Face to Face notary workflow for approved notary users. It includes private notary credentials, a notary journal/hash flow, quote and checklist tools, RON session setup, client document upload, client signature capture, Google Meet workflow notes, live Django Channels updates, and BSV blockchain anchoring for completed RON session manifests.

The RON workflow is intentionally scoped around a signer personally known to the notary. That is important because Ohio rules list personal knowledge as one allowed identity verification method for a remotely located individual.

This page is a product and engineering status document, not legal advice. Before production use, the workflow should be reviewed against current Ohio law, Secretary of State rules, platform security needs, and the notary's own authorization to perform online notarizations.

Ohio Context

Based on the email from the Ohio Secretary of State's office, Ohio does not maintain an approved-vendor list for remote notary systems. Vendors are instead expected to follow Ohio law and administrative rules.

The key source pages linked in the email are:

Known-Signer Scope

The current RON page describes a known-signer workflow. This matters because OAC 111:6-1-05 lists personal knowledge of the individual as one method for verifying the remotely located individual. The separate credential-analysis and identity-proofing path applies when identity is established through satisfactory evidence rather than personal knowledge.

The current implementation does not provide a KBA or credential-analysis vendor workflow. That is a deliberate current scope decision, not a completed universal RON identity-proofing system.

Current Features

  • Approved notary access: `/notary/` and `/notary/ron/` are limited to superusers or members of the Notary Members group.
  • Notary profile: approved notaries can save their public notary name, commission state, commission expiration, private digital signature, and private digital seal/stamp.
  • Private credential previews: signature and seal previews are served through protected Django views, not public media URLs.
  • Journal/hash flow: notary entries can create a NotaryRecord with a SHA-256 hash and review/broadcast status.
  • Quote tools: notaries can create service quotes, save client contact details, email quote links, associate quotes with RON sessions, and use quote checklists.
  • RON setup: a RON session stores signer details, saved quote, scheduled time, Google Meet URL, fee, identity method notes, and recording metadata.
  • Client document upload: each RON session has a tokenized upload page where the client can privately upload a PDF, Word document, or image.
  • Live signing room: each RON session has a tokenized signing page where the client can draw a signature during the live video session.
  • Live status updates: Django Channels sends events when the client enters the signing room, uploads a document, or captures a signature. Redis-backed Channels are configured for Docker environments, and polling remains as a fallback.
  • Completion tracking: RON sessions can be marked completed, and completed cards render with a different color.
  • RON blockchain anchor: completed RON sessions can create a linked NotaryRecord that anchors a SHA-256 hash of the private RON session manifest to BSV through an OP_RETURN payload.

BSV Anchoring

Completed RON sessions can create a blockchain anchor record. The action appears only after a session is marked Completed. It builds a private, deterministic JSON manifest of the RON session, hashes that manifest with SHA-256, creates or reuses a NotaryRecord, and then sends the notary to the record detail page for review, mock broadcast, or real BSV broadcast.

The public OP_RETURN payload uses this pattern:

Face to Face|RON1|record:<record_id>|sha256:<manifest_hash>
  • Face to Face: the application/protocol name intended for WhatsOnChain tagging.
  • RON1: Remote Online Notary protocol version 1. Keeping a version in the payload allows a future RON2 format without confusing older records.
  • record: the internal NotaryRecord id created by the app.
  • sha256: the hash of the private RON session manifest, not the raw client document or client personal data.
Privacy note: the blockchain does not receive the client's document, name, email, phone number, signature image, Google Meet link, recording URL, notes, or private RON session manifest. The chain receives a one-way SHA-256 verification hash, which works like a public timestamped receipt. Someone viewing the blockchain can see that Face to Face anchored a RON record, but they cannot reverse the hash to recover the private session details.

If the private session manifest is later needed for audit or verification, the app can hash that private manifest again and compare it to the public on-chain hash. A match proves that the private record has not changed since the blockchain anchor was created.

The manifest includes session metadata, document/signature hashes, timing fields, consent and recording fields, and hashes of sensitive values such as the Google Meet URL, recording URL, recording notes, and internal session notes. Client names and private links are not placed directly into OP_RETURN.

When viewing the raw script on a block explorer, the ASCII area may show non-readable characters before the payload, such as j or L. Those are Bitcoin script opcodes like OP_RETURN and OP_PUSHDATA1; the readable application payload begins at Face to Face|RON1|....

The record detail page displays the planned OP_RETURN payload and a copyable “Blockchain Anchor Output” log after anchor creation. That output is useful for troubleshooting and for collecting representative transaction data for WhatsOnChain Tag My App.

Requirement Map

This table-style list maps current app behavior to high-level Ohio RON topics.

  • Two-way live audio-video: the app uses Google Meet as the meeting layer and stores the Meet URL. The app itself does not provide the video transport.
  • Personal knowledge identity path: the RON workflow and script are scoped to known signers. The session model stores identity method notes and signer location.
  • Signer document interaction: the client can upload the document and submit a captured signature while the notary watches on the video call.
  • Electronic signature and seal readiness: notary signature/seal files can be uploaded privately and previewed. Applying them to the final document is not complete yet.
  • Electronic journal topics: the app stores notary records, document hashes, signer/session fields, recording notes, and fee fields. It is not yet a full ORC 147.65 journal implementation.
  • Audio-video recording evidence: the app stores recording URL, recording start/stop times, consent checkbox, and storage notes. Google Meet handles the actual recording.
  • Tamper-evidence: uploaded documents and captured signatures are hashed. Completed RON sessions can now create a BSV anchor for the private session manifest hash. Final signed PDF assembly and final PDF hash anchoring still need to be completed.
  • Certificate language: the app includes references and planning notes, but it does not yet generate or affix the final Ohio online notarial certificate.

Current Gaps

  • No built-in KBA or credential-analysis vendor integration.
  • No production-grade PDF placement for client signature, notary signature, seal, and certificate.
  • No final tamper-evident completed PDF generation yet.
  • RON blockchain anchoring hashes the private session manifest, but it does not yet anchor a generated final signed PDF because the final PDF workflow is not complete.
  • No built-in audio-video transport; Google Meet is used externally.
  • No automated proof that Google Meet recording was retained in a tamper-evident format.
  • Private signature/seal files are protected by access control and private storage paths, but they are not app-encrypted at rest yet.
  • The electronic journal is not yet a complete ORC 147.65 online journal implementation.
  • Production live updates require the Docker Redis service and the ASGI/Daphne web command to be deployed with the app.

Next Build Steps

  1. Add final PDF assembly: place client signature, notary signature, seal, certificate text, and date/time onto the document.
  2. Add final document hashing after the completed PDF is generated.
  3. Extend the RON anchor flow so it can anchor the final signed PDF hash after PDF assembly is complete.
  4. Expand the journal model to cover every required online journal field from ORC 147.65.
  5. Add audit logs for credential access, document upload, signature capture, notary signature/seal application, and final completion.
  6. Add encryption-at-rest for notary signature/seal files and client documents.
  7. Verify Redis-backed Channels in production after rebuilding and redeploying the Docker image.
  8. Decide whether non-known signers are out of scope or require a third-party KBA/credential-analysis integration.

Sources