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
npx -y skills add L3-iGrant/skills --skill igrantio-consent-recordsAssembled 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:
- Environment - demo (
https://demo-api.igrant.io), staging, or a custom Consent BB deployment (ask its base URL)? Recommend demo to start. - API key - organisation API key for the Consent Building Block? Server-side only, never the browser.
- Data agreement(s) - which
dataAgreementId(s) are consents recorded against? Listed in the iGrant.io admin console; ask the integrator to paste them. - 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 (seeigrantio-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>.
| Method | Path | Purpose |
|---|---|---|
| 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/record | Delete 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
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; resolvesindividualIdserver-side via anIndividualIdResolver(never trusts the browser).src/server.ts- example wiring.
Steps
cd references && cp .env.example .env; setOWS_ENV,OWS_API_KEY.npm install.- 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))); - Frontend calls
PUT /consents/:dataAgreementId { optIn }to allow/withdraw,GET /consents/:dataAgreementIdto read - no key or individualId in the browser.
Clean-code notes
individualIdand the API key are injected server-side; the browser only sends the dataAgreementId and the opt-in choice.setConsenthides the create-vs-update branch; the client is the only place Consent BB paths live.
Validation / done criteria
npm run typecheckpasses.giveConsentthenreadConsentreturnsoptIn: true;withdrawConsentflips it tofalse;historyshows 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:
- iGrant.io developer APIs (index): https://docs.igrant.io/docs/developer-apis
- Getting started: https://docs.igrant.io/docs/get-started/
- Consent management - individual API: https://docs.igrant.io/docs/category/consent-management-individual-api/organisation
- Consent management - admin API: https://docs.igrant.io/docs/category/consent-management-admin-api/data-agreement