Credentials V2

[karntrehan]

Requirements:

• Uploading template (in html format)
• Generate certificates following templates
• Save certificates (& print link to share with holders)
• Verify certificates
• Delete certificates
• Auto-gen certificates on events in community v2

To do:

• [ ] Define APIs for the above tasks
• [ ] Cleanup & Deploy credentialing on the C4GT Server (currently on multiple systems)
  • RCW is on jenkins and ansible scripts
  • We are also using Konnect's FusionAuth - Needs to be checked.
  • Using puppetier to render PDFs. New HTML formats usually leads to issues. Template tweaking might be required.
• [ ] Create a collection (preferably swagger) to manage credentials.
• [ ] Integrate into community v2.

[KDwevedi]

Service Design

DB Requirement: To map templates to verified templates. Since this is expected to be an extremely small dataset, a minimal db for this can be discussed.

API Design

/schema APIs

• GET /schema/?{schemaId}
  • Description: Retrieve all schema, or optionally pass schemaID to retrieve a specific schema

/template APIs

• GET /template

  • Description: Retrieve a template by ID or schemaID.
  • Action: Fetches a specific template based on its unique ID or schemaID.

• POST /template

  • Description: Create a new template.
  • Action: Adds a new template with specified metadata and HTML content.

• DELETE /template

  • Description: Delete an existing template.
  • Action: Removes the specified template from the system.

• PUT /template

  • Description: Edit the entire template, including both metadata and HTML content.
  • Action: Fully updates the specified template with new metadata and HTML content.

/certificate APIs

• GET /certificate

  • Description: Retrieve certificates by certID, templateID, or schemaID.
  • Action: Returns a list of certificate objects that contain links to each certificate.

• PATCH /certificate

  • Description: Update the status of a certificate (enable or disable) by id.
  • Request Body:
  • id (required) - The ID of the certificate to update.
  • status (required) - The new status of the certificate. Acceptable values are "enable" or "disable".
  • Action: Updates the status of the specified certificate based on the provided status value.

• POST /certificate

  • Description: Render and save a certificate using a templateId, returning a link for sharing.
  • Request Body:
  • templateId (required) - The ID of the template to use for rendering.
  • puppeteerConfig (optional) - Configuration object to override the default PDF rendering settings.
  • Action: Renders a certificate as a PDF with optional custom rendering settings, saves it, and provides a shareable link.

• POST /certificate/preview

  • Description: Render a certificate PDF without saving it.
  • Request Body:
  • templateId (required) - The ID of the template to use for rendering.
  • puppeteerConfig (optional) - Configuration object to override the default PDF rendering settings.
  • Action: Generates and returns a rendered PDF file for the certificate without storing it, allowing for quick previewing during iteration.

Example of puppeteerConfig:

{
  "height": 1130.67,
  "width": 760,
  "scale": 1.33,
  "landscape": true,
  "displayHeaderFooter": false,
  "printBackground": true
}

Note: The puppeteerConfig parameter allows overriding default settings, such as height, width, scale, landscape orientation, and more, giving flexibility for fine-tuning during template iteration.

• DELETE /certificate
  • Description: Delete a certificate record and its saved PDF file.
  • Action: Removes the specified certificate record from the system, along with its associated PDF file.

/rcw/verify/{credentialID} API

• GET /rcw/verify/{credentialID}
  • Description: Returns the certificate rendered in a verified format as an HTML page.
  • Path Parameter:
  • credentialID (required) - The unique ID of the credential to verify and render.
  • Action: Displays the verified certificate in an HTML format. This is a legacy endpoint used for all historical certificates accessed via QR codes, so the external interface should not be modified, though internal logic can be updated as needed.

[karntrehan]

Great work @KDwevedi !

Just some suggestions:

• How easy or hard is it to show the variables you can pass to a template in GET /template?
• certificate/disable & certificate/enable should be a PATCH? Preferably passing the status in body.
• In POST /certificate we would have to pass the template ID as well I guess?
• There was a macro concern about anyone being able to generate certificates. No auth there. Is that something we are fixing right now?

Also, what would be the ETA of this implementation? Would be good to have visibility on that as well.

[KDwevedi]

• Fairly easy, we're using handlebar js for templating, can simply import a parser.
• Got it, making the edit
• Yes, we'll have to pass template ID as well, editing
• Hadn't planned for auth yet, but valid callout. In increasing order of sophistication we can have:
  • Username/Password as headers in the swagger
  • Leverage fusion auth to generate temp sign in tokens or OTPs
  • User OAuth 2.0, with google auth or something like that for signing in

Since we're aiming for swagger to be our UI, we can do basic auth using a password, other methods would require the user to juggle API responses with various auth tokens

• Additionally adding an optional puppeteer-config param in the POST APIs for rendering, to optionally override the default rendering config for PDF generation, since this is something I usually do while iterating on a new template

[KDwevedi]

@karntrehan I should be able to deliver on the updated APIs in 2 days time, having a PR ready for review with code modifications, swagger setup, and basic tests by Thursday noon.

[jaanbaaz]

@KDwevedi can you pls share an update here?

[AbhimanyuSamagra]

@KDwevedi to finish this by 22nd November - @MohitNSamagra to check with him again

[AbhimanyuSamagra]

Ready by 22nd November - update to be given on the 22nd standup