Starting with Apache Unomi 1.3 (still in development), a new API for consent management is now available. This APIis designed to be able to store/retrieve/update visitor consents in order to comply with newprivacy regulations such as the GDPR.

7.1.1. Profiles with consents

Visitor profiles now contain a new Consent object that contains the following information:

  • a scope

  • a type identifier for the consent. This can be any key to reference a consent. Note that Unomi does not manage consentdefinitions, it only stores/retrieves consents for each profile based on this type

  • a status : GRANT, DENY or REVOKED

  • a status date (the date at which the status was updated)

  • a revocation date, in order to comply with GDPR this is usually set at two years

Here is an example of a Profile with a consent attached to it:

  1. {
  2. "profileId": "8cbe380f-57bb-419d-97bf-24bf30178550",
  3. "sessionId": "0d755f4e-154a-45c8-9169-e852e1d706d9",
  4. "consents": {
  5. "example/newsletter": {
  6. "scope": "example",
  7. "typeIdentifier": "newsletter",
  8. "status": "GRANTED",
  9. "statusDate": "2018-05-22T09:44:33Z",
  10. "revokeDate": "2020-05-21T09:44:33Z"
  11. }
  12. }
  13. }

It is of course possible to have multiple consents defined for a single visitor profile.

Apache Unomi does not manage consent definitions, it leaves that to an external system (for example a CMS) so that itcan handle user-facing UIs to create, update, internationalize and present consent definitions to end users.

The only thing that is import to Apache Unomi to manage visitor consents is a globally unique key, that is called theconsent type.

A new built-in event type called "modifyConsent" can be sent to Apache Unomi to update a consent for the currentprofile.

Here is an example of such an event:

  1. {
  2. "events": [
  3. {
  4. "scope": "example",
  5. "eventType": "modifyConsent",
  6. "source": {
  7. "itemType": "page",
  8. "scope": "example",
  9. "itemId": "anItemId"
  10. },
  11. "target": {
  12. "itemType": "anyType",
  13. "scope": "example",
  14. "itemId": "anyItemId"
  15. },
  16. "properties": {
  17. "consent": {
  18. "typeIdentifier": "newsletter",
  19. "scope": "example",
  20. "status": "GRANTED",
  21. "statusDate": "2018-05-22T09:27:09.473Z",
  22. "revokeDate": "2020-05-21T09:27:09.473Z"
  23. }
  24. }
  25. }
  26. ]
  27. }

You could send it using the following curl request:

  1. curl -H "Content-Type: application/json" -X POST -d '{"source":{"itemId":"homepage","itemType":"page","scope":"example"},"events":[{"scope":"example","eventType":"modifyConsent","source":{"itemType":"page","scope":"example","itemId":"anItemId"},"target":{"itemType":"anyType","scope":"example","itemId":"anyItemId"},"properties":{"consent":{"typeIdentifier":"newsletter","scope":"example","status":"GRANTED","statusDate":"2018-05-22T09:27:09.473Z","revokeDate":"2020-05-21T09:27:09.473Z"}}}]}' http://localhost:8181/context.json?sessionId=1234

7.1.4. How it works (internally)

Upon receiving this event, Apache Unomi will trigger the modifyAnyConsent rule that has the following definition:

  1. {
  2. "metadata" : {
  3. "id": "modifyAnyConsent",
  4. "name": "Modify any consent",
  5. "description" : "Modify any consent and sets the consent in the profile",
  6. "readOnly":true
  7. },
  8. "condition" : {
  9. "type": "modifyAnyConsentEventCondition",
  10. "parameterValues": {
  11. }
  12. },
  13. "actions" : [
  14. {
  15. "type": "modifyConsentAction",
  16. "parameterValues": {
  17. }
  18. }
  19. ]
  20. }

As we can see this rule is pretty simple it will simply execute the modifyConsentAction that is implemented by theModifyConsentAction Java class

This class will update the current visitor profile to add/update/revoke any consents that are included in the event.== Developers