KittyTreats Lab

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 reviewed final PDF hashes.

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, encrypted private digital signature, and encrypted private digital seal/stamp.
  • Private credential previews: signature and seal previews are decrypted by Django only for authorized previews and are not exposed as public media URLs.
  • Private file audit logs: authorized previews of notary credentials, RON client documents, and RON client signatures write a private access log row with actor, owner, file type, IP address, user agent, and timestamp.
  • 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 an encrypted 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. Captured signature images are encrypted at rest.
  • 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 after the final PDF exists and the Final PDF Review checklist is saved. Completed cards render with a different color.
  • Verification receipt: each RON session has a stable receipt ID such as FTF-RON-2026-000018. The generated final PDF includes that ID, and a tokenized receipt page shows the final PDF hash, session metadata, BSV transaction link when available, and an upload checker that re-hashes a PDF in memory without saving it.
  • RON blockchain anchor: completed RON sessions can create a linked NotaryRecord after the final PDF hash exists and the Final PDF Review checklist is complete. The anchor uses the final PDF SHA-256 hash.

BSV Anchoring

Completed RON sessions can create a blockchain anchor record. The action appears only after a session is marked Completed and the Final PDF Review checklist is saved. It also builds a private, deterministic JSON manifest of the RON session and hashes that manifest with SHA-256 for internal traceability. The current anchor gate requires a final signed PDF hash, then uses that final PDF SHA-256 as the public proof hash. The app then creates or reuses a NotaryRecord and 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:<anchor_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 final signed PDF hash. It is 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, final signed PDF, 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 final PDF is later needed for audit or verification, the receipt page can hash an uploaded copy of that PDF again in memory and compare it to the receipt's final PDF SHA-256 hash. This works like checking a downloaded Debian ISO against a published SHA256SUMS file: the file can be private, but its fingerprint must match. A match proves that the final PDF matches the receipt and the anchor record created for it.

The generated final PDF also receives a small visible footer with the Face to Face verification ID. The receipt page uses the same ID so the notary, client, final PDF, local journal/session record, and blockchain anchor can be matched later if an audit or legal request asks for proof.

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.

Private File Encryption

Notary credentials, RON client documents, and captured client signature images are stored through PrivateNotaryCredentialStorage. New private files are encrypted before being written to private_media/notary_credentials and decrypted only when Django serves an authorized private preview.

The app reads NOTARY_PRIVATE_FILE_KEY when it is configured. If that setting is blank, it derives a Fernet key from SECRET_KEY so the app can continue running. Production should use a dedicated NOTARY_PRIVATE_FILE_KEY and keep it outside Git.

Existing plaintext private files remain readable for backward compatibility. To find legacy files without changing them, run: 

python manage.py encrypt_private_notary_files

To encrypt existing legacy private files in place after verifying backups and the production key, run: 

python manage.py encrypt_private_notary_files --apply

Blockchain anchors should store only hashes or manifest hashes for these files, never the raw signature, seal, client document, or decrypted private content.

Successful authorized private previews also create PrivateFileAccessLog rows. Staff can review those logs in Django admin to see who opened a private notary credential, RON client document, or RON client signature preview.

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, previewed, and placed on the generated final PDF.
  • 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, captured signatures, and generated final PDFs are hashed. Completed RON sessions can create a BSV anchor for the reviewed final PDF hash.
  • Certificate language: the app includes a certificate helper and can place certificate text into the final PDF. The notary must still review the wording before relying on it.

Current Gaps

  • No built-in KBA or credential-analysis vendor integration.
  • PDF placement for client signature, notary signature, seal, and certificate is available as a pilot workflow, but it still needs more mobile, browser, and print-size testing before being treated as production-grade.
  • Final PDF generation exists, but the final-document review process still needs broader legal/template review before paid RON use.
  • RON blockchain anchoring now requires the generated final signed PDF hash and saved Final PDF Review checklist.
  • 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.
  • 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. Test final PDF assembly across more document templates, mobile screens, browsers, and printed pages.
  2. Test the Final PDF Review gate across older completed sessions and new sessions before paid use.
  3. Add downloadable verification receipts and optional signed receipt exports for clients and auditors.
  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 audit reporting dashboards and key-rotation planning for encrypted private file access.
  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