feat/read truvera api configs from data store

[maycon-mello]

No description provided.

[Copilot]

Pull request overview

Refactors delegatable revocation configuration to be provided as a single truveraApi config object (and to be read from the wallet data store in the delegation offer flow), rather than passing separate sponsor key + API URL fields around.

Changes:

• Added truveraApi to DataStoreConfigs for centralized Truvera API config storage.
• Introduced TruveraApiConfigs and updated RevocationContext to use it, updating call sites and tests accordingly.
• Wired delegation offer issuance to pass revocation context sourced from wallet.dataStore.configs.truveraApi.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
packages/data-store/src/types.ts	Adds truveraApi to persisted/constructed data store configs.
packages/core/src/delegation/delegation-revocation.ts	Refactors revocation context shape to use a truveraApiConfigs object.
packages/core/src/delegation/delegation-offer.ts	Passes revocation context from wallet.dataStore.configs.truveraApi into delegated issuance flow.
packages/core/src/delegation/delegation-issuance.ts	Makes delegated issuance optionally allocate status entries based on presence of Truvera API configs.
integration-tests/delegatable-revocation.test.ts	Updates integration test setup to the new truveraApiConfigs shape.

Comments suppressed due to low confidence (2)

packages/core/src/delegation/delegation-revocation.ts:105

• The assertion message and validation in postRevocation are outdated after the config refactor: it checks truveraApiConfigs but the error message still mentions truveraApiSponsorKey, and it doesn't validate required fields (authKey, apiUrl). This can lead to confusing errors later (e.g., building a URL with undefined).

  assert(!!ctx.truveraApiConfigs, 'truveraApiSponsorKey is required');
  const jwt = await signRevocationJWT(ctx, {registryId, ...body});

packages/core/src/delegation/delegation-offer.ts:380

• New behavior is introduced here (building revocationContext from wallet.dataStore.configs.truveraApi and passing it into delegated issuance), but there’s no test coverage asserting that the handler includes revocation context when configs are present (and omits it when absent). Adding a unit test around DELEGATION_REQUEST_HANDLER (or an integration test for the offer->issue flow) would prevent regressions in the config plumbing.

      revocationContext: {
        wallet,
        truveraApiConfigs: wallet.dataStore.configs.truveraApi,
        issuerDID: delegationOffer.issuerDID || issuerDID,
      },

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.