Prototype submission for NDI's TAP

• SG Market - Server
  • Table of Contents
  • Table of Contents
  • Introduction
  • Problem Statement
  • Proposed Solution
  • Getting Started
  • Demo
  • Documentation
    • User Component
    • Model
    • Routes
      • Get User by UUID
      • Get User by ID
      • Create User
      • Update User by UUID
      • Delete User by UUID
  • Chat and Message Component
    • Chat Model
    • Message Model
    • Routes
      • Create Message
      • Get Chat by listingId (unique to user-pair and item)
      • Get Chats by UUID
      • Send Message as a buyer
      • Send Message as a seller
      • Get Messages by ListingId (Gets message history/log)
  • Listing Component
    • Listing Model
    • Routes
      • Create Listing
      • Get Listing by ID
      • Get All Listings by Seller ID
  • Reservation Component
    • Reservation Model
    • Routes
      • Create Reservation
      • Update Reservation by ID
      • Update Reservation Approval Status
      • Update Reservation Payment Status
  • SuspiciousActivityLog Component
    • SuspiciousActivityLog Model
    • Routes
      • Get Suspicious Activity Log by ID
      • Get All Suspicious Activity Logs by User UUID
      • Create Suspicious Activity Log
      • Delete Suspicious Activity Log by ID
      • Get Suspicious Activity Logs by Date Range
  • License
  • Contact

SG Market is a solution aimed at enhancing the security and integrity of Singapore's e-commerce ecosystem by integrating SingPass, NDI's Verify system, and implementing biometric authentication, specifically Identiface, into e-commerce platforms, with a particular focus on B2B platforms.

In Singapore's dynamic e-commerce landscape, preserving the integrity and trustworthiness of marketplaces, while ensuring peace of mind for all participants, is a formidable challenge. A critical concern is the need to effectively mitigate the escalating threats of fraudulent activities, including the widespread illegal resale of items such as concert tickets.

To address these challenges, we propose the following solutions:

• SingPass Integration: Simplify user registration by utilizing SingPass, a trusted digital identity platform.

• Suspicious Activity Detection: Our system will monitor user activities and flag suspicious activities.

• Biometric Authentication: Flagged users will undergo biometric verification during login using Identiface, ensuring the identity of the user.

• Transaction Security: NDI's Verify system will be used during transactions to confirm the exchange of goods before the release of payment, minimizing remote scams.

• Privacy Compliance: We adhere to strict privacy standards and won't access users' personal information. Suspicious activities can be reported to NDI for further investigation.

• Enhanced Verification Methods: We recommend expanding biometric verification options to include voice and thumbprint recognition for added security.

This solution is vital for establishing a secure and trustworthy digital marketplace, promoting the digitization of trade in Singapore.

To run this project locally, follow these steps:

1. Navigate to the project directory.
2. Run npm install to install dependencies.
3. Run npm run start to start the server.
4. The server can be accessed locally at http://localhost:8080/.

Alternatively, you can access a deployed version of the project at https://sgmarket-api.onrender.com/.

A Postman collection and environments have also been provided for ease of testing (located in documentation folder).

Do note that the default routes are url.com/api/...

For a live demo of SG Market, visit https://sgmarket-api.onrender.com/.

For more detailed documentation for the planning process, please refer to the documentation. Do note that this planning document is not entirely accurate to the prototype implementation as it was a pre-implementation draft.

The server component includes several key components:

As there is restricted access to NDI products for actual use, please imagine that the uuid, email should come from the singpass api along with MyInfo authorisation.

The biometricVerified will be marked as true as new users are required to go through on round of NDI's biometric's facial verification. However, if user has failed, it will add a count into their initial flag attribute. It will also automically log a suspicious activity report that is System Generated.

At any point of time during usage of the system, if the user has any suspicious/inappropriate behaviour, the system will also log a suspicious activity report. Users can also make reports. These will add onto the flag for the reported user. When users have accumulated a certain number of flags, we will automatically trigger the biometric verification and submit a report to NDI (not done).

• Schema Fields:
  • username: A unique user identifier
  • uuid: A unique user identifier.
  • email: User's email address.
  • biometricVerified: Indicates whether the user's biometric data is verified.
  • flags: Count of suspicious activity flags.
  • createdAt: Timestamp of user registration.
  • updatedAt: Timestamp of the last update to user data.

• Route: /user/view/uuid/:uuid
• Controller: getUserByUuid
• Required Parameters: uuid (User's unique identifier).

• Route: /user/view/id/:userId
• Controller: getUserById
• Required Parameters: userId (MongoDB user ID).

• Route: /user/onboard
• Controller: createUser
• Required Body Fields:
  • username: A unique user identifier.
  • email: User's email address.
  • uuid: A unique user identifier.
• Optional Body Fields:
  • biometricVerified: Indicates whether the user's biometric data is verified. (Defaults to true on registration -- following the flow)
  • flags: Count of suspicious activity flags. (defaults to 0)

• Route: /user/update/:uuid
• Controller: updateUserByUuid
• Required Parameters: uuid (User's unique identifier).

• Route: /user/delete/:uuid
• Controller: deleteUserByUuid
• Required Parameters: uuid (User's unique identifier).

• Schema Fields:
  • participants: An array of user IDs participating in the chat.
  • listingId: The ID of the listing associated with the chat.
  • createdAt: Timestamp of chat creation.

• Schema Fields:
  • chatId: The ID of the chat associated with the message.
  • senderId: The ID of the message sender.
  • content: The message content.
  • timestamp: Timestamp of the message.

• Route: /chats/create
• Controller: createChat
• Required Body Fields:
  • participants: An array of user IDs participating in the chat.
  • listingId: The ID of the listing associated with the chat.

• Route: /chats/view/:listingId
• Controller: getChatForListing
• Required Parameters: listingId (Listing ID), uuid (user's, in req query)

• Route: /chats/view/all/:uuid
• Controller: getChatsForUser
• Required Parameters: uuid (user UUID)

• Route: /messages/buy/:listingId
• Controller: messageSeller
• Required Parameters: listingId (Listing ID).
• Required Body Fields:
  • content: The message content.
  • uuid: The UUID of that a buyer (NOT listing owner)
• Optional Body Fields
• chatId: The ID of that unique chat

• Route: /messages/buy/:listingId
• Controller: messageBuyer
• Required Parameters: listingId (Listing ID).
• Required Body Fields:
  • content: The message content.
  • chatId: The ID of that unique chat (unqiue to item-chat participant pair) [OPTIONAL if buyerUUID specified]
  • buyerUUID: The UUID of that a unique buyer (not listing owner) [OPTIONAL if chatId specified]
• Optional Body Fields
  • sellerUUID: The UUID of the message sender.

• Route: /messages/view/:listingId
• Controller: getMessagesInChatForListing
• Required Parameters:
  • uuid : can be buyer or seller's UUID (in query)
  • listingId (Listing ID)

• Schema Fields:
  • seller: The ID of the user selling the item.
  • title: The title of the listing.
  • description: The description of the listing.
  • price: The price of the item.
  • status: The status of the listing (e.g., "available," "reserved," "sold").
  • createdAt: Timestamp of listing creation.

• Route: /listing/create
• Controller: createListing
• Required Body Fields:
  • seller: The ID of the user selling the item.
  • title: The title of the listing.
  • description: The description of the listing.
  • price: The price of the item.

• Route: /listing/view/:listingId
• Controller: getListingById
• Required Parameters: listingId (Listing ID).

• Route: /listing/view/seller/:sellerId
• Controller: getListingsBySellerId
• Required Parameters: sellerId (Seller's User ID).

On successful reservation (seller approved and buyer paid), we will generate a QR code using NDI's Verify system for the user and upon receiving the item successfully, the buyer will have to scan the QR code to verify that they've received it.

On top of that, during meet ups, they will have to scan the one on the seller's mobile/device. Upon succcesful verification, we will mark the reservation as isReceived = true and the respective item to be status = sold.

Payment will automatically be released to the seller upon this success of this process.

• Schema Fields:
  • listingId: The ID of the listing associated with the reservation.
  • buyer: The ID of the user making the reservation.
  • approvalStatus: The approval status of the reservation (e.g., "pending," "approved," "rejected").
  • isMailing: Indicates whether the item will be mailed.
  • meetupLocation: The location for a meetup (required if isMailing is false).
  • paymentStatus: The payment status of the reservation (e.g., "pending," "completed").
  • priceOffer: The price offered for the item.
  • isReceived: Indicates whether the item has been received.

• Route: /reservation/reserve/:listingId
• Controller: createReservation
• Required Parameters: listingId (Listing ID).
• Required Body Fields:
  • isMailing: Indicates whether the item will be mailed.
  • meetupLocation: The location for a meetup (required if isMailing is false).
  • priceOffer: The price offered for the item.

• Route: /reservation/update/:reservationId
• Controller: updateReservationById
• Required Parameters: reservationId (Reservation ID).
• Required Body Fields:
  • Fields to be updated (e.g., isMailing, meetupLocation, priceOffer).

• Route: /reservation/update/approval/:reservationId
• Controller: updateApprovalStatus
• Required Parameters: reservationId (Reservation ID).
• Required Body Fields:
  • approvalStatus (e.g., "approved").

• Route: /reservation/update/payment/:reservationId
• Controller: updatePaymentStatus
• Required Parameters: reservationId (Reservation ID).
• Required Body Fields:
  • paymentStatus (e.g., "completed").

• Schema Fields:
  • user: The ID of the user associated with the suspicious activity.
  • reportedBy: The entity that reported the suspicious activity.
  • reason: A description of the suspicious activity.
  • reportedOn: Timestamp of when the suspicious activity was reported.

• Route: /report/view/:logId
• Controller: getSuspiciousActivityLogById
• Required Parameters: logId (Log ID).

• Route: /report/view/all/user/:uuid
• Controller: getAllSuspiciousActivityLogsByUserId
• Required Parameters: uuid (User's unique identifier).

• Route: /report/create/log
• Controller: createSuspiciousActivityLog
• Required Body Fields:
  • uuid: The UUID of the user associated with the suspicious activity.
  • reason: A description of the suspicious activity.
• Query Parameter:
  • reportedBy: The entity reporting the suspicious activity (optional).

• Route: /report/delete/:logId
• Controller: deleteSuspiciousActivityLogById
• Required Parameters: logId (Log ID).

• Route: /report/view/range/user/:uuid
• Controller: getSuspiciousActivityLogsByDateRange
• Required Parameters: uuid (User's unique identifier).
• Query Parameters:
  • startDate: The start date of the date range.
  • endDate: The end date of the date range.

This project is licensed under the MIT License.

For questions or inquiries, please contact Rachel Gina Abelarde.