feat: Added encrypted StatusList APIs + enhanced type safety

[Eengineer1]

• Adds encrypted / unencrypted status list distinction.
  • Enriched unencrypted.
  • Overall encrypted implementation.
  • Enhanced check APIs.
  • Performant search APIs.
• Adds intermittent payment layer on demand.
• Enhances type safety.
• Monkey patches on globalThis replace issue.
• Relevant documentation.

[ankurdotb]

Really good PR overall and a delight to read through/review!

I did make some changes:

• As discussed, I removed encrypted from the top-level response. Please cross-check I got it removed in all places (pretty sure I have, but worth a second pair of eyes).
• I have made some changes by leveraging schema reuse a lot more widely within the Credential Status API Swagger docs. This makes it shorter and less verbose (especially large, repeated example blocks). I didn't do this for any of the APIs as it might make the PR harder to read/review if there are non Credential Status APIs to review, but probably worth a pass by Abdulla from a similar lens after this is done.

Next steps:

• The only minor comment is the /check API, which asks for statusPurpose as a query parameter. This is redundant, since based on the DID, the status list name etc we already search/look it up to determine if it's got payment conditions or not. The input provided in statusPurpose therefore is already present in the resource metadata and the resource body under resourceType, in the body, and again in the metadata in body. So IMO this should be removed since user input is not required to determine the status purpose.
• For the /update actions, the statusAction should match the resource type. For example, if the chosen action is revoke, but the resourceType / type within the resource provided is StatusList2021Suspension, then this action should fail. Now, I haven't checked did-provider-cheqd to see if it's enforced there instead, but if not, we should. Regardless of did-provider-cheqd, not sure whether we want to catch/handle the same case here (e.g., did-provider-cheqd might already reject, but is there a relevant error message surfaced to the user?)

[Tweeddalex]

• The only minor comment is the /check API, which asks for statusPurpose as a query parameter. This is redundant, since based on the DID, the status list name etc we already search/look it up to determine if it's got payment conditions or not. The input provided in statusPurpose therefore is already present in the resource metadata and the resource body under resourceType, in the body, and again in the metadata in body. So IMO this should be removed since user input is not required to determine the status purpose.

Hey @ankurdotb I'm not sure this is entirely correct. In my opinion the statusPurpose is required as a query parameter because there is a scenario where:

1. I create a StatusListRevocation with the name: employee-credentials
2. I ALSO create a StatusListSuspension with the name: employee-credentials
3. I.e. there may be multiple resource types with the same resource name.
4. In this scenario, without specifying the statusPurpose as a query parameter, there will be ambiguity whether I'm trying to check the Revocation list or the Suspension list.
5. Therefore, DID, index, encrypted and statusListName are not enough on their own to specify a particular resource and status list where multiple resourceNames are the same, with different resourceTypes.

[Eengineer1]

Underlying search operations are based on user input + validated against the desired action, therefore statusPurpose is not redundant.

On underlying did-provider-cheqd functionality, it's deterministically action based + takes relevant information from the credential body, namely the credential status index section, which acts as the single source of truth. Cross-purpose validation handles edge cases.

Having that in mind, both create + update, should provide the purpose / action top-level, which is utilised for a sanity check, if a relevant status list has been found, is encrypted / unencrypted.

So I don't think we should remove either.

[Eengineer1]

I've enhanced the runtime removal of underlying encrypted property as well, pairing yesterday's conversation.

I'd scope further conversations to relevant changes / technical points required + take additional discussions elsewhere, if no objections.

[Eengineer1]

Swagger reusability type additions make sense + thanks!

[cheqd-bot]

🎉 This PR is included in version 2.9.0-develop.4 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[cheqd-bot]

🎉 This PR is included in version 2.9.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀