agentsclimarketplace

Igrantio consent records

Skill L3-iGrant/skills/consent/igrantio-consent-records

Agent Skills for EUDI Wallet and European Business Wallet integrations: credential issuance (OpenID4VCI), verification (OpenID4VP + DCQL), DC API and consent management on the iGrant.io Organisation Wallet Suite

Install
npx -y skills add L3-iGrant/skills --skill igrantio-consent-records

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 22 days oldThe repository was created 22 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Record and manage individual consents against a data agreement using the iGrant.io Consent Building Block, given a dataAgreementId and an individualId. Node/TypeScript backend for the individual Consent-Record API: create, read, list, update (allow/withdraw), history, and delete-all (GDPR right to be forgotten). Use when an application must capture and manage a user's consent decisions. Get individualId from igrantio-individuals.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.4 KB, as published. Nobody here has run it

iGrant.io consent records (Consent BB individual API)

When to use

When your app must record and manage a user's consent for a data agreement - allow, read current state, withdraw, show history, or erase (right to be forgotten). Assumes you already have the individualId (from igrantio-individuals) and the dataAgreementId you are collecting consent for.

Integrator intake

Ask one question at a time, a recommended default with each; look up facts in the project, put only decisions to the integrator:

  1. Environment - demo (https://demo-api.igrant.io), staging, or a custom Consent BB deployment (ask its base URL)? Recommend demo to start.
  2. API key - organisation API key for the Consent Building Block? Server-side only, never the browser.
  3. Data agreement(s) - which dataAgreementId(s) are consents recorded against? Listed in the iGrant.io admin console; ask the integrator to paste them.
  4. Erasure policy - expose "delete all consents" (right to be forgotten) to end users, or admin-only? Recommend admin-only unless the product requires self-service.

Prerequisites

  • individualId - the Consent BB individual for the user (see igrantio-individuals; resolve it server-side from your session/userId mapping).
  • dataAgreementId - the data agreement to record consent against.
  • Organisation API key - server-side only.

API (Consent BB individual, base /v2)

Auth on every call: Authorization: ApiKey <key> and X-ConsentBB-IndividualId: <individualId>.

MethodPathPurpose
POST/v2/service/individual/record/data-agreement/{dataAgreementId}?revisionId=Record consent (first time)
GET/v2/service/individual/record/data-agreement/{dataAgreementId}Read consent for a data agreement
GET/v2/service/individual/record/consent-record?limit=&offset=List all the individual's records
PUT/v2/service/individual/record/consent-record/{consentRecordId}?individualId=&dataAgreementId=&revisionId=Update (allow/withdraw)
GET/v2/service/individual/record/consent-record/history?limit=&offset=Consent change history
DELETE/v2/service/individual/recordDelete all records (right to be forgotten)

Consent record fields: id, dataAgreementId, individualId, optIn (true=allow, false=withdraw), state (unsigned|signed), sectorPreferences[]. Updating a signed record invalidates its signature. (Signature/draft endpoints exist for PKI flows; the reference covers the core opt-in lifecycle.)

Reference

./references:

  • src/consentClient.ts - dependency-free Consent BB client (consentRecords.*).
  • src/consent.ts - readConsent, setConsent, giveConsent, withdrawConsent (create-or-update, so callers don't juggle first-time vs update).
  • src/consentRouter.ts - Express router exposing clean endpoints; resolves individualId server-side via an IndividualIdResolver (never trusts the browser).
  • src/server.ts - example wiring.

Steps

  1. cd references && cp .env.example .env; set OWS_ENV, OWS_API_KEY.
  2. npm install.
  3. Mount the router with your own resolver (session → userId → individualId):
    const client = createConsentClient({ owsBaseUrl: config.owsBaseUrl, apiKey: config.apiKey });
    app.use("/", consentRouter(client, (req) => mappingStore.getIndividualId(req.session.userId)));
    
  4. Frontend calls PUT /consents/:dataAgreementId { optIn } to allow/withdraw, GET /consents/:dataAgreementId to read - no key or individualId in the browser.

Clean-code notes

  • individualId and the API key are injected server-side; the browser only sends the dataAgreementId and the opt-in choice.
  • setConsent hides the create-vs-update branch; the client is the only place Consent BB paths live.

Validation / done criteria

  • npm run typecheck passes.
  • giveConsent then readConsent returns optIn: true; withdrawConsent flips it to false; history shows the change.
  • No API key or raw individualId is present in the browser.

Documentation & workflows

When anything is unclear, consult the iGrant.io documentation before guessing:

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.