Embed: Route Embed Interactions through API Endpoint

User Story:

As a developer integrating the Embed solution, I want to route interactions through a dedicated API service, So that I can:

seamlessly update business logic in the background and
track usage effectively
and the service should scale independently of other backend components

Acceptance Criteria

GIVEN a partner integrates the embed component in his web app WHEN the embed component is initialised & rendered THEN dedicated embed service running on *.passport.xyz/embed/* is able to handle all requests from the embed component

Product & Design Links:

N/A

Tech Details:

develop a new NodeJS service ( located in passport/embed ) to handle all requests from the embed component (break out the current implementation which is in IAM)
- public endpoints:
- /embed/verify/{address} - to perform the 1-click flow
- /embed/stamps/metadata - to return stamp metadata that can be displayed in the UI component (not sure this is needed in the 1st version, it might only be required once we pick up the task regarding web2 stamps)
- /embed/score/{address} - to read the score (not sure that this will be needed in the 1st version)
rate limiting
- this is yet to be clarified in detail, but let's assume we will have
- global rate limiting that applies to the API key ( WAF & service level )
- per IP rate limiting that applies pr API key & IP address ( WAF ) such that we avoid exploitation of these APIs
- for in-app rate limiting:
  - we use a django package to do in-app rate limiting in python, the data however is maintained in the cache redis
  - so in theory, we could use the same strategy (read & write from cache) from the embed services if we want to apply rate limiting and share this with the API on the django side
  - if sharing with the django API is not required we can use something like https://express-rate-limit.mintlify.app/reference/configuration for the embed service only

Open Questions:

[ ] How will we ensure security and data privacy through this API?
- we shall not collect more data than compared to the IAM service, the same privacy concerns applies as to the current data that we have in the DB
- security will be provided by:
- rate limiting
- API key
- in the future potentially binding the API Key to a domain (could probably be done from the WAF)
- or switching to more complex solutions like JWT or requesting a user signature
- returned data records will be signed
- BUT verification requests for the 1-click-flow will not be signed (at least not in the 1st version)
- ALSO we will however not require a signature when the user triggers the 1-click-verification flow, which means:
- anybody could potentially trigger this flow for any address
- however, given the nature of the 1-click-flow, and that it only verifies web3 stamps, and issues the VCs to the addresses that have been verified, these credentials cannot be stolen and used by other users

Notes/Assumptions:

The system will handle increased traffic without degrading performance.

passportxyz / passport