Decide how the `Notarization` flow works in terms of doc requirements etc

[ashishkarki]

How to bring real-world trust and compliance into the Digital Notarization (DN) process. The flow of notarization in the real world is subjective, based on both the document and the identity verification of the individual. Replicating this digitally can definitely go one of two ways:

Option 1: Simple, Randomized Approval

This approach keeps things streamlined:

• Customers upload documents directly.
• You randomly approve or reject documents for notarization without much verification.

This would be easy to implement, and it simplifies the user journey. However, the downside is that it doesn’t add any real-world relevance or credibility to the process. It also raises security and trust concerns, especially if someone could use fake documents without proper identity verification. The lack of oversight might make it hard to market as a true "notarization" platform.

Option 2: Real-World-Like Flow with Identity Verification

This approach mimics a real-world notary experience by adding identity verification and subjective approval:

1. Account Creation: Users first need to create an account.

   • During the account creation, they provide personal details like:
     • Name
     • Date of Birth (DOB)
     • Citizenship
     • Passport or National ID number
   • They must also upload at least two forms of ID with a photo (e.g., passport, driver's license).

2. Manual Identity Verification:

   • A notary (or an admin) would manually cross-check the provided ID details (name, DOB, document numbers) to ensure they match.
   • You could automate part of this in the future using ID verification APIs like Jumio, Onfido, or other KYC services.

3. Document Upload for Notarization:

   • Only after the user’s account is verified would they be able to upload documents for notarization.

4. Document Approval/Rejection:

   • A notary or reviewer can manually check the documents for notarization.
   • Documents could be rejected if they don’t meet certain criteria, if the identity is questionable, or for other reasons.

5. Platform and Communication:

   • Status Updates: When the document is approved or rejected, the platform updates the document status for the customer.
   • Email Notifications: The customer receives an email notification when the status changes, e.g., "Your document has been notarized" or "Your document has been rejected."

This approach adds a layer of real-world authenticity, providing a more legally sound and credible digital notarization service.

Which Approach is Better?

• If you're aiming to build a real-world service that is recognized and trusted, the second option with identity verification and manual review is far superior.

  • It mimics real-world notarization closely, builds user trust, and reduces the risk of fraud.
  • It also adds a sense of legitimacy, since notaries are known to verify both identity and document validity.
• If you’re looking to build a MVP (Minimum Viable Product) to test quickly, you can start with the first approach (randomized approval) and gradually evolve to add identity checks and manual reviews as features.

Additional Considerations

• Automation: While identity verification and document checks may initially be manual, adding automation through APIs for identity verification and document validation could save time in the long run.
• Legal Compliance: Depending on the jurisdiction where you operate, certain laws or regulations might require proper identity checks and document validation for notarization.
• User Experience: The second flow would be more secure but slightly more complex for the user. However, for a serious service like notarization, customers would likely expect some friction in exchange for legitimacy.

Implementation Steps for Option 2

1. User Registration and Identity Upload:

   • Set up a user registration flow where the customer provides their details and uploads ID documents.

2. Manual Review Interface for Notaries:

   • Create an admin panel for notaries or reviewers to approve/reject accounts and later approve/reject documents for notarization.

3. Document Notarization Submission:

   • After account verification, users are allowed to upload documents for notarization.
   • Notaries can approve/reject documents and update statuses accordingly.

4. Communication Layer:

   • Integrate an email service (e.g., SendGrid) to notify users when their account is verified or when a document’s status changes.

5. Tracking and History:

   • Keep track of all uploaded documents, their statuses, and the reason for rejections in a history log visible to the user.

This flow should give the platform a more serious and trustworthy feel, aligning it closely with how notarization works in the physical world.

[ashishkarki]

implementing the second option is definitely the way to go if you want to provide a sense of authenticity for the project. Even though you'll use fake PDFs for testing, having the system in place for manual verification gives you the flexibility to easily transition to real-world use later.

Key Elements of the Flow with Some Simplifications

1. Restricting Uploads to PDFs:

   • This is simple to implement and makes sense since notarization is most commonly done on documents. You can easily restrict file uploads to PDF format by validating the file type at both the frontend (Next.js) and backend (NestJS). This will prevent users from uploading other file types like images or Word documents.

2. Manual Cross-Check of Profile Data and ID Documents: Since you're aiming for a manual process (and avoiding the complexity of OCR/PDF scanning for now), the notary can manually review the profile details and uploaded ID documents. Here's how it could work:

   • Notary Workflow:

     1. Access User Profile: The notary logs into the admin panel or a designated review interface where they can access user profiles. The profile would contain key details like:
        • Name
        • Date of Birth (DOB)
        • Citizenship
        • Passport Number or National ID number
     2. View Uploaded ID Documents:
        • The user would have uploaded at least two forms of ID (e.g., passport, driver's license) during registration. The notary can view these documents as PDF files, and to keep it simple:
        • The notary can print the PDFs for comparison, if necessary.
        • Alternatively, they could open the PDF files in a separate tab or window on their computer and visually cross-check the information.
     3. Manual Cross-Check:
        • The notary would manually check the key fields (like name, DOB, passport number, etc.) in the uploaded ID documents against the profile information.
        • Once they confirm that the IDs match the profile details, they can mark the account as "Verified".

   • Profile Verification Status:

     • After the manual cross-check, the notary/admin can update the user profile status to "Verified" or "Rejected" within the admin panel, depending on the results.
     • If rejected, an optional rejection reason could be provided to the user (e.g., “ID mismatch”).

   You won’t need to implement complex PDF scanning at this stage, so this approach keeps things manual but straightforward. Later, you can add OCR functionality to automate the cross-checking process.

Steps for Implementation

Here’s a breakdown of how to implement this flow:

1. User Registration with ID Document Upload

• The user creates an account by entering basic information:
  • Name, DOB, citizenship, passport number, etc.
• They upload at least two forms of ID (PDF files).
• This registration form can be implemented in Next.js on the frontend.
• The files will be stored in your MinIO instance (or AWS S3 equivalent).

2. Admin/Notary Panel for Profile Review

• Implement an admin panel using NestJS where the notary can log in to view pending profiles.
• Profiles will have details like Name, DOB, passport number, and links to the uploaded ID documents (PDFs).
• Add actions for the notary to mark the profile as "Verified" or "Rejected" based on manual inspection.

3. Cross-Checking Workflow

• Notary opens the user's profile to view the details (name, DOB, citizenship, passport number).
• They open the uploaded ID documents (PDFs) either by downloading or viewing them in the browser.
• They visually cross-check the profile data with the information on the ID documents.
• Based on this manual review, they approve or reject the user.

4. Status Update and Notification

• Once the notary verifies or rejects the profile:
  • The user’s profile status is updated (e.g., status: "Verified").
  • An email notification is sent to the user informing them of their verification status. This can be done using services like SendGrid or Nodemailer.
  • If rejected, include a reason like "ID documents do not match the profile."

5. Allow Document Upload After Verification

• Only after the user’s profile is verified should they be able to upload additional documents for notarization.
• This step ensures that only authenticated users are able to submit documents for notarization.
• Uploaded documents will go through a similar process where a notary manually checks and approves/rejects them.

Backend Structure to Support This Flow

• User Schema:

  • Extend the user schema/model to include fields like:
    • isVerified: Boolean flag indicating whether the user has passed the identity verification step.
    • verificationStatus: Enum (e.g., PENDING, VERIFIED, REJECTED) to track verification progress.
    • rejectionReason: If a user's profile is rejected, provide a reason.

• Document Schema:

  • Extend your document model to include:
    • uploadedBy: References the user who uploaded the document.
    • status: Enum (PENDING, APPROVED, REJECTED) to track notarization status.
    • rejectionReason: Optional reason for rejecting a document.

Frontend and Backend Communication

• Frontend:

  • Build out the Next.js user dashboard where users can track the status of their profile verification and see the status of documents they've uploaded for notarization.
  • Provide clear feedback to users about why their documents were approved or rejected.

• Backend:

  • Use NestJS to implement the verification and notarization APIs. The notary/admin panel can call these APIs to update statuses and send notifications to users.

Example Flow

1. User Registration:

   • The user submits their details and ID documents for verification.
   • The profile goes into a PENDING state, awaiting verification by the notary.

2. Notary Cross-Checks Profile:

   • The notary manually views the user's profile and ID documents.
   • After cross-checking, the notary updates the user’s profile to either VERIFIED or REJECTED.

3. Document Upload and Notarization:

   • Once the user is verified, they can upload documents for notarization.
   • The notary then manually reviews the documents and approves/rejects them, updating the status in the system.

Conclusion

This approach keeps the project simple and manageable while introducing real-world-like identity verification. You're not overcomplicating things by adding OCR or automatic document checks for now, but you’re laying a solid foundation for scalability and adding those features later.

[ashishkarki]

We think more about the storage and api infrastructure/patterns. A few things i was thinking: => the user's ID documents—where will we store them S3? if yes, how will we separate one user's documents with another's? is S3 perfect for this use case since I want to showcase the usage of lot of common AWS services like S3, lambda, SNS, etc, whichever is possible for this project? => When and how will we generate unique IDs for our users? => Should there be an email verification by sending OTP when creating the account, giving the platform more credibility? => the user name, dob, etc. profile info would be saved in Postgres (neon) with Prisma perhaps? or how else?

[ashishkarki]

We think more about the storage and api infrastructure/patterns. A few things i was thinking: => the user's ID documents—where will we store them S3? if yes, how will we separate one user's documents with another's? is S3 perfect for this use case since I want to showcase the usage of lot of common AWS services like S3, lambda, SNS, etc, whichever is possible for this project? => When and how will we generate unique IDs for our users? => Should there be an email verification by sending OTP when creating the account, giving the platform more credibility? => the user name, dob, etc. profile info would be saved in Postgres (neon) with Prisma perhaps? or how else?

step back and think about the storage and API infrastructure patterns. Let's address your questions and suggest an approach that incorporates free, budget-friendly alternatives while still mimicking an AWS-like ecosystem.

1. Storing User ID Documents (S3-like Storage)

Since you want to showcase common AWS services like S3, storing documents in S3 (or its alternative) is a good choice. However, since you're not using AWS directly due to budget constraints, here's a solution that aligns with your goals:

• MinIO: Since you’ve already set up MinIO, it can serve as a perfect drop-in replacement for AWS S3. MinIO has the same API as S3, so you can interact with it using the same AWS SDK.

• How to Organize User ID Documents in MinIO (or S3):

  • Each user can have their own unique directory structure within the bucket. For example:

    `/users/{userID}/id-documents/{documentID}.pdf

    /users/{userID}/notarized-documents/{documentID}.pdf`

  • UserID will be a unique identifier for the user, and this structure keeps documents well-organized and easy to retrieve.

  • You can also prefix the files with unique IDs or timestamps to prevent conflicts if multiple users upload similarly named files (e.g., "passport.pdf").

  • Example:

    `/users/12345/id-documents/passport-2024.pdf

    /users/12345/notarized-documents/contract-2024.pdf`

2. Storing Notarized Documents

• Same Bucket but Different Folder**:

  • You can store the notarized documents in the same bucket but in a separate folder like /notarized-documents/. Keeping all user-related data (both ID and notarized documents) together under a user's folder helps with permissions, audit logging, and easy retrieval.

• Example of folder structure for user 12345:

  `/users/12345/id-documents/passport-2024.pdf

  /users/12345/notarized-documents/legal-contract-2024.pdf`

3. Generating Unique User IDs

• For generating unique IDs for users, you can rely on:
  • UUIDs (Universally Unique Identifiers) using libraries like uuid (for Node.js) or PostgreSQL’s uuid type.
  • Sequential IDs in PostgreSQL: Prisma, for example, can auto-generate primary keys, and you can configure this with a UUID strategy.
  • When to Generate: The unique ID for a user should be generated at the time of account creation and saved in your PostgreSQL database as part of their profile.

4. Email Verification Using OTP

Adding email verification with OTP (One-Time Password) for credibility is a great idea:

• Fake AWS SES alternative: Use an email provider like SendGrid (free for small usage) or Mailgun to send verification emails. These are popular drop-in replacements for AWS SES.
• Workflow:
  1. When a user signs up, generate an OTP and send it to their email.
  2. Save the OTP and timestamp in PostgreSQL.
  3. The user has to verify the OTP before completing the registration.

This adds a layer of trust and ensures valid email addresses.

5. Storing User Profile Information (PostgreSQL with Prisma)

• PostgreSQL and Prisma: Using PostgreSQL (such as Neon for serverless Postgres) with Prisma is a perfect choice to store user profiles. Prisma simplifies interactions with the database, and its ORM can map the relationships (e.g., users and their documents).

• What to Store in PostgreSQL:

  • User ID (UUID or sequential ID)
  • Name, DOB, citizenship, passport number, etc.
  • Email address and OTP for verification
  • Verification status (whether email is verified, ID verified, etc.)
  • Relationship to the documents stored in MinIO (you could store the S3-like object key of the documents in the DB for easy retrieval)

6. Leveraging Fake AWS Services (IAM, SNS, Lambda Alternatives)

Here’s how you can mimic common AWS services:

• IAM (Access Control):

  • You could implement a simple role-based access control (RBAC) system in your NestJS app.
  • Each user (e.g., notaries, admins, regular users) can be assigned roles, and you can enforce access controls based on roles in your service layer.

• SNS for Notifications:

  • SNS-like behavior can be simulated using Redis (for pub/sub) or email systems like SendGrid or Mailgun for email-based notifications.
  • Alternatively, you could set up a simple notification queue within your database, where notifications (e.g., email reminders or updates) are queued and sent asynchronously.

• Lambda (Serverless Functions):

  • Use OpenFaaS, which you’ve mentioned in your setup, as a drop-in replacement for AWS Lambda. OpenFaaS allows you to deploy serverless functions locally for document processing, notifications, etc.

Suggested Flow and API Infrastructure

1. User Registration API:

• Endpoint: POST /api/users/register
• Actions:
  1. Generate a UUID for the user.
  2. Save user data (name, email, DOB, etc.) in PostgreSQL.
  3. Generate an OTP and send a verification email.
  4. Save the OTP in the DB and return the user ID and email verification status (pending).

2. OTP Verification API:

• Endpoint: POST /api/users/verify-email
• Actions:
  1. Accept the OTP and user ID.
  2. Verify the OTP against what was saved in the database.
  3. Update the user’s email verification status to verified if the OTP is correct.

3. Document Upload API:

• Endpoint: POST /api/documents/upload
• Actions:
  1. Verify if the user is email verified and profile ID verified.
  2. Allow the user to upload documents (restricted to PDFs).
  3. Save the document in MinIO/S3 under the /users/{userID}/... path.
  4. Store the document reference (e.g., the S3 object key) in PostgreSQL under the user's record.

4. Notarization Status API:

• Endpoint: GET /api/notarizations/:userID
• Actions:
  1. Return the status of all documents for a specific user (pending approval, approved, or rejected).

5. Admin Panel for Notaries:

• The notary or admin can access a panel where they can review:
  • User profiles (to verify ID documents manually).
  • Notarization requests.
• The notary can approve or reject a document, which triggers an email to the user with the updated status.

Summary of Storage and API Considerations

• MinIO (S3-like) stores all user ID documents and notarized documents, separated by user ID in folder paths.
• PostgreSQL with Prisma handles all user profile data, email verification status, and stores metadata about document uploads.
• SendGrid or Mailgun can handle email notifications (e.g., OTP verification, status updates).
• OpenFaaS serves as a local alternative for Lambda, allowing you to offload certain tasks in a serverless manner.

[ashishkarki]

start with the User Registration Flow as the foundation, and it's perfectly fine to focus on building the backend first. Backend-first development allows you to set up the core infrastructure, database, and logic without worrying about the frontend initially. Once the backend is functional, you can easily plug in the frontend, allowing Next.js to interact with the backend APIs.

That said, here’s a proposed approach for starting with 1. User Registration Flow in the backend, and then we can layer the frontend functionality afterward.

Steps for User Registration Flow (Backend First)

1. Define the Database Schema (PostgreSQL + Prisma)

2. Set Up the User Registration API in NestJS

Create User Registration DTO (Data Transfer Object)

3. OTP Verification API

Once a user receives their OTP via email, they can submit it to verify their account.

4. Integrating SendGrid (for Email Verification)

To send the OTP email, you can use SendGrid, which has a free tier

---

Frontend Integration (Next.js)

Once the backend is ready and working:

• The Next.js frontend can call these APIs during the registration flow.
• The frontend would show forms for:
  1. Registration
  2. OTP Verification
• The Next.js components can use fetch or axios to make API calls to the NestJS backend.