Consent Management

Overview

The consent management feature provides a regulatory-compliant, flexible consent management system at the identity level. This process allows customers to determine what information they permit their care providers to access, enabling users to approve or withdraw consent and create personalized experiences.

Benefits

GDPR Compliance

Support for all GDPR legal bases (consent, contract, legal obligation, vital interests, public authority, legitimate interests)
Complete audit trail of all consent actions with timestamps
Data subject rights management (deletion, correction, portability, etc.)
Processing purpose documentation for transparency

Flexible Consent Models

Declarative consents: Requested during registration/login flows
Action-based consents: Requested when specific actions are performed
Scope consents: Required for THIRD_PARTY OAuth2 clients
Claim consents: For specific user attributes/claims

User Experience

Multi-locale support for international deployments
Version management for regulatory updates
Skip limits to balance user convenience and compliance
User self-service portal to view and manage consents

Administrative Control

Consent groups for organizing multiple consents
Enable/disable consents without deletion
Required vs optional consent configuration
Integration with registration fields and clients

Key Concepts

The consent management system consists of three hierarchical entities:

┌─────────────────────────────────────────────────────────────────┐
│                      CONSENT MODEL                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌─────────────────┐                                            │
│  │  Consent Group  │                                            │
│  │  (group_name)   │                                            │
│  └─────────────────┘                                            │
│         │                                                        │
│         │ contains                                              │
│         ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ Consent Instance │                                           │
│  │ (consent_name)   │                                           │
│  └──────────────────┘                                           │
│         │                                                        │
│         │ has versions                                           │
│         ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ Consent Version  │                                           │
│  │ (version number) │                                           │
│  └──────────────────┘                                           │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Consent Group: A collection of multiple consent instances (e.g., Privacy & Terms group). Can be assigned to clients or registration fields.

Consent Instance: An individual consent item representing a specific agreement (e.g., Privacy Policy, Terms & Conditions). Each instance has a legal type, consent type, and deonticity.

Consent Version: Versioned content of a consent instance with localized text, scopes, or claims. Allows tracking of regulatory updates and changes over time.

Core Entities and Their Models

The consent management system uses three distinct entity types with different purposes:

Purpose: Defines what consent is being requested - the template/configuration.

Key Model Fields:

consent_name: Unique name of the consent (e.g., "Privacy Policy")
legalType: Legal basis (consent, contract, legal_obligation, etc.)
consentType: How consent is obtained (actionbased, declarative)
deonticity: Whether consent is required or optional
processingPurposes: Why data is collected and processed
allowedDataSubjectRights: Which GDPR rights are allowed for this consent
enabled: Whether the consent is active
show_in_registration: Whether to show during registration

Example: A "Privacy Policy" consent with legalType: consent, consentType: declarative, deonticity: required.

ConsentTracking (Audit Record)

Purpose: Records who did what and when - the audit trail of user interactions.

Key Model Fields:

sub: User identifier (who)
consent_id: Reference to ConsentInstance (what consent)
consent_version_id: Reference to ConsentVersion (which version)
client_id: Which application/service the consent was given to
status: Action taken (accepted, revoked, declined, skipped)
type: Tracking type (legalbasistrack, dataprocessing, subjectrightaction, consent)
consentStatus: Array of all status changes with timestamps
createdTime, updatedTime: When actions occurred
accepted_fields: Specific data fields user consented to share
scopes: OAuth2 scopes accepted
dataSubjectRight: Which GDPR right is being exercised (for type: subjectrightaction)

Example: User "[email protected]" accepted "Privacy Policy" consent (version 2.0) on 2024-01-15 for client "xyz".

Purpose: Defines separate GDPR rights that users can exercise - independent from consent itself.

Key Model Fields:

name: Name of the right (e.g., "Right to Deletion")
legalReference: GDPR article reference (e.g., "Art. 17 GDPR")
content: Localized content explaining the right
timeLimit: Days to respond to the request
followUpRights: Related rights that can be used together
order: Display order

Available Rights:

RevocationOfConsent (Art. 7(3) GDPR)
Information (Art. 15 GDPR)
DataCorrection (Art. 16 GDPR)
DataDeletion (Art. 17 GDPR)
RestrictionOfProcessing (Art. 18 GDPR)
DataPortability (Art. 20 GDPR)
ContradictionDataProcessing (Art. 21(1) GDPR)
ContradictionDirectAdvertising (Art. 21(2) GDPR)
NotBeSubjectToAutomatedDecision (Art. 22 GDPR)
RightToComplain (Art. 77 GDPR)

Example: "Right to Deletion" (Art. 17 GDPR) with 30-day response time limit.

Relationship Between Entities

ConsentInstance (Template)
    │
    │ defines allowedDataSubjectRights
    │
    ▼
DataSubjectRight (GDPR Rights)
    │
    │ can be exercised by users
    │
    ▼
ConsentTracking (Audit Record)
    │
    │ records: user exercised DataSubjectRight
    │          type: "subjectrightaction"
    │          dataSubjectRight: "DataDeletion"

Key Differences:

ConsentInstance = Configuration (WHAT consent is)
ConsentTracking = Audit trail (WHO did WHAT and WHEN)
DataSubjectRight = Separate GDPR rights (different from consent - these are rights users have)

Legal Types

Legal Type	GDPR Article	Description
`consent`	Art. 6(1)(a)	User has given explicit consent
`contract`	Art. 6(1)(b)	Necessary for contract performance
`legal_obligation`	Art. 6(1)(c)	Compliance with legal obligation
`vital_interests`	Art. 6(1)(d)	Protection of vital interests
`public_authority`	Art. 6(1)(e)	Public interest task
`legitimate_interests`	Art. 6(1)(f)	Legitimate interests pursued

Type	When Used	Description
`actionbased`	User actions	Consent requested when user performs specific action
`declarative`	Registration/Login	Consent requested during registration or login flow

Note: Consent type is only applicable when legal type is consent.

Deonticity

Value	Description
`required`	Consent must be accepted to proceed
`optional`	Consent can be skipped

State	Description
`accepted`	User approved the consent
`revoked`	User revoked the consent (even if previously accepted)
`declined`	User declined the consent
`skipped`	User bypassed the consent

Tracking Types

Type	Purpose
`legalbasistrack`	Track legal basis actions (accept, revoke, decline, skip)
`dataprocessing`	Track data processing activities
`subjectrightaction`	Track data subject right requests
`consent`	General consent tracking

Technical Integration

API Endpoints Overview

Management APIs (/consent-srv)

Resource	Endpoint	Method	Purpose	API Reference
Consent Groups	`/groups`	POST	Create consent group	View API
Consent Groups	`/groups`	GET	List consent groups	View API
Consent Groups	`/groups/{group_name}`	GET	Get group by name	View API
Consent Groups	`/groups/{group_name}`	PUT	Update group	View API
Consent Groups	`/groups/{group_name}`	DELETE	Delete group	View API
Consent Instances	`/consents`	POST	Create consent instance	View API
Consent Instances	`/consents`	GET	List consent instances	View API
Consent Instances	`/consents/{id}`	GET	Get instance by ID	View API
Consent Instances	`/consents/{id}`	PUT	Update instance	View API
Consent Instances	`/consents/{id}`	DELETE	Delete instance	View API
Consent Versions	`/consent/versions`	POST	Create consent version	View API
Consent Versions	`/consent/versions`	GET	Get consent versions	View API
Consent Versions	`/consent/versions/{id}`	GET	Get version by ID	View API
Consent Versions	`/consent/versions/{id}`	PUT	Update version	View API
Consent Versions	`/consents/{instanceId}/version`	GET	Get latest version for instance	View API
Data Subject Rights	`/datasubjectright`	POST	Create data subject right	View API
Data Subject Rights	`/datasubjectright`	GET	List data subject rights	View API
Data Subject Rights	`/datasubjectright/{id}`	GET	Get data subject right by ID	View API
Data Subject Rights	`/datasubjectright/{id}`	PUT	Update data subject right	View API
Data Subject Rights	`/datasubjectright/{id}`	DELETE	Delete data subject right	View API
Consent Tracking	`/actions`	POST	Track consent action	View API
Consent Tracking	`/actions`	PUT	Update tracking record	View API
Consent Tracking	`/actions/{id}`	GET	Get tracking by ID	View API
Consent Tracking	`/actions/{id}`	DELETE	Delete tracking record	View API
User Tracking	`/users/{sub}/actions`	POST	Get user consent history	View API

Public APIs (/consent-management-srv)

Resource	Endpoint	Method	Purpose	API Reference
Claim Consent	`/consent/claim/check`	POST	Check claim consent	View API
Claim Consent	`/consent/claim/accept`	POST	Accept claim consent	View API
Scope Consent	`/consent/scope/accept`	POST	Accept scope consent	View API

Required Scopes

Scope	Permission
`cidaas:consent_read`	Read consent configurations and tracking
`cidaas:consent_write`	Create/update consents and track actions
`cidaas:consent_delete`	Delete consent configurations
`profile`	Access user profile information
`cidaas:users_read`	Read user information (for admin tracking)

Integration Flow

1. Setup Phase (Admin)

1. Create Consent Group
   POST /consent-srv/groups
   
2. Create Consent Instance
   POST /consent-srv/consents
   - Set legalType, consentType, deonticity
   - Define processingPurposes
   
3. Create Consent Version
   POST /consent-srv/consent/versions
   - Add localized content
   - Configure skip limits

2. User Interaction Phase

1. User Accepts/Revokes
   POST /consent-management-srv/consent/claim/accept
   POST /consent-management-srv/consent/scope/accept
   
2. Track Action
   POST /consent-srv/actions
   - Record status: accepted, revoked, declined, skipped

3. Tracking & Compliance

1. View User Consents
   POST /consent-srv/users/{sub}/actions
   
2. Admin Query
   POST /consent-srv/graph/actions
   - Filter by user, consent, date range

Processing Purposes

Processing purposes describe why personal data is collected and processed. This is required for GDPR compliance and helps users understand data usage.

Examples:

User authentication
Service improvement
Marketing communications
Legal compliance
Fraud prevention

Profile Field Consents

Consents tracked during login and registration are recorded per consent_id, consent_version_id, and sub.

Action-Based Consents

Action-based consents are tracked per action, allowing users to accept the same consent version multiple times for different actions.

Tracking by ID

Use tracking ID in path: GET /consent-srv/actions/{id}
Or provide in request body for updates: PUT /consent-srv/actions

Webhooks

Webhooks are triggered automatically when consent status changes:

CONSENT_ACCEPTED: Triggered when a consent is accepted
CONSENT_REJECTED: Triggered when a consent is rejected

Each webhook contains the specific sub, consent_id, and consent_version_id.

The Consent User Activity log tracks all changes for a given sub, consent_version_id, and consent_id, including old and new values with timestamps. Users can view, agree to, or reject their consents and review consent versions through their profile.

Implementation Requirements

Once a consent group is created and enabled, it becomes a required field in your site schema. New users cannot register without at least viewing active policies, and privacy policy statements are mandatory for completing registration.

Support

Need Help?

For any further assistance, feel free to visit our Support Portal.

Overview​

Benefits​

Key Concepts​

Consent Hierarchy​

Core Entities and Their Models​

ConsentInstance (Consent Definition/Template)​

ConsentTracking (Audit Record)​

DataSubjectRight (GDPR Rights Definition)​

Relationship Between Entities​

Legal Types​

Consent Types​

Deonticity​

Consent States​

Tracking Types​

Technical Integration​

API Endpoints Overview​

Required Scopes​

Integration Flow​

Processing Purposes​

Consent Tracking​

Profile Field Consents​

Action-Based Consents​

Tracking by ID​

Webhooks​

Consent User Activity​

Implementation Requirements​

Need Help?​

Overview

Benefits

Key Concepts

Consent Hierarchy

Core Entities and Their Models

ConsentInstance (Consent Definition/Template)

ConsentTracking (Audit Record)

DataSubjectRight (GDPR Rights Definition)

Relationship Between Entities

Legal Types

Consent Types

Deonticity

Consent States

Tracking Types

Technical Integration

API Endpoints Overview

Required Scopes

Integration Flow

Processing Purposes

Consent Tracking

Profile Field Consents

Action-Based Consents

Tracking by ID

Webhooks

Consent User Activity

Implementation Requirements

Need Help?