You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The objective of this feature is to develop a Consent Management Portal where users can view and manage consents, leveraging the Consent Management API. This portal will provide a user interface for admins and operators to manage, search, and monitor consents.
Core Portal Features described in the brief are as follows
Consent Listing and Filtering: The ability to list and filter consents by user, status, or purpose.
Detailed Consent Views: A feature to view the specific details of a consent, which includes the approved purposes and resources.
Consent Approval: An interface for users to approve pending consents.
Consent Revocation: A mechanism allowing users or operators to revoke existing consents.
Audit Logging: An interface to display audit logs of all actions taken to ensure compliance.
Consent History: The design and development of a feature that tracks the history of a consent.
Users
1. End-Users (Data Owners)
These are the everyday individuals, such as citizens, bank account owners, or customers, whose personal data or resources are being requested
They will use the frontend Consent Management Portal to view, manage, and revoke their explicit approvals
Depending on the scenario, an end-user might use the system to select exactly which data attributes (like an address or date of birth) they want to share with a specific application, approve a one-time banking payment, or update their marketing communication preferences (like opting out of SMS but keeping emails)
The system allows them to remain in total control of their personal data by allowing them to revoke access at any time
2. Administrators and Operators (Data Holders)
These are the internal staff members of the organization that securely store the user data, such as government agencies, banks, or enterprise organizations
They will use the portal's interface to efficiently manage, search, and monitor user consents across their organization
Administrators rely on the system's consent history to ensure the organization meets strict regulatory compliance and transparency requirements
The OpenFGC architecture consists of four primary technical components. The OpenFGC Portal and OpenFGC Portal BFF are developed under this feature. The other two components already exist.
OpenFGC Portal (Frontend Layer): The presentation layer is a ReactJS (TypeScript) web portal. It provides a user-friendly interface for users and administrators to view, manage, filter, and revoke consents within the system.
OpenFGC Portal BFF (Backend-for-Frontend): Built in Go Lang, this intermediary service connects the React portal to the backend. It consolidates data from the Open FGC engine and Data Consumer Store for the frontend. By managing OAuth2 and OIDC interactions with the Identity Server, the BFF ensures the browser does not store confidential credentials.
OpenFGC (Core Consent Engine): This is the backend Consent Management API service, built using Go Lang. This engine is the authoritative source responsible for the actual creation, retrieval, validation, and audit logging of all consent records.
Data Consumer Store: This layer manages metadata for external data consumers, such as Clients and TPPs. It provides a retrieval abstraction for the system. The store's implementation varies by data holder, as different organizations may use different identity or registry solutions. Hence, this layer serves as an extensibility point.
Activity
rashmithachamikara commentedon May 12, 2026
First iteration of portal implementation
Portal frontend - @ #36
Portal backend (bff) - #39
rashmithachamikara commentedon May 12, 2026
Core Features
Core Portal Features described in the brief are as follows
Users
1. End-Users (Data Owners)
These are the everyday individuals, such as citizens, bank account owners, or customers, whose personal data or resources are being requested
They will use the frontend Consent Management Portal to view, manage, and revoke their explicit approvals
Depending on the scenario, an end-user might use the system to select exactly which data attributes (like an address or date of birth) they want to share with a specific application, approve a one-time banking payment, or update their marketing communication preferences (like opting out of SMS but keeping emails)
The system allows them to remain in total control of their personal data by allowing them to revoke access at any time
2. Administrators and Operators (Data Holders)
These are the internal staff members of the organization that securely store the user data, such as government agencies, banks, or enterprise organizations
They will use the portal's interface to efficiently manage, search, and monitor user consents across their organization
Administrators rely on the system's consent history to ensure the organization meets strict regulatory compliance and transparency requirements
rashmithachamikara commentedon May 12, 2026
Implementation
The OpenFGC architecture consists of four primary technical components. The OpenFGC Portal and OpenFGC Portal BFF are developed under this feature. The other two components already exist.
OpenFGC Portal (Frontend Layer): The presentation layer is a ReactJS (TypeScript) web portal. It provides a user-friendly interface for users and administrators to view, manage, filter, and revoke consents within the system.
OpenFGC Portal BFF (Backend-for-Frontend): Built in Go Lang, this intermediary service connects the React portal to the backend. It consolidates data from the Open FGC engine and Data Consumer Store for the frontend. By managing OAuth2 and OIDC interactions with the Identity Server, the BFF ensures the browser does not store confidential credentials.
OpenFGC (Core Consent Engine): This is the backend Consent Management API service, built using Go Lang. This engine is the authoritative source responsible for the actual creation, retrieval, validation, and audit logging of all consent records.
Data Consumer Store: This layer manages metadata for external data consumers, such as Clients and TPPs. It provides a retrieval abstraction for the system. The store's implementation varies by data holder, as different organizations may use different identity or registry solutions. Hence, this layer serves as an extensibility point.
rashmithachamikara commentedon Jul 29, 2026
More features added
rashmithachamikara commentedon Jul 29, 2026
Related issues:
build.sh#74