Managing consent mapping

The consented scopes are stored and can be managed, see Managing privacy consents. Furthermore, the consented scope can be associated to a privacy purpose. See Managing privacy purposes.

Authorization details represents a fine-grained permission, so user consented authorization details are also stored and can be managed. Similar to scopes, consented authorization details can also be associated to a privacy purpose.

However, unlike scopes that are strings, authorization details are JSON objects. Evaluating equality between two JSON objects is complex. The default implementation supports only limited comparison methods.
  • The first approach is full hash, where a hash value is generated from the serialized JSON object and used to compare two authorization detail JSON objects of the same type.
  • The second approach is common fields hash. In this approach, the hash value is computed from the common data fields in the JSON object. The common data fields are locations, actions, datatypes, identifier and privileges. Use this approach only if your authorization details JSON object are using these fields.
  • The last approach is advanced. This approach use CELx script to define comparison logic. For example, when the authorization detail represents a transaction and includes a unique transactionID property, this property can be used instead of the approaches previously described.
Note: The JSON object can be access in the script using requestContext.ad key. If you want to return the transactionID property of the JSON object, you can use requestContext.ad.transactionID in the script. The general structure and use of requestContext is described in the HTTP Request Context section of Attribute functions.

Custom consent mapping

You may choose not to use the default implementation for various reasons, such as:

  • You can associate privacy policy to the requested authorization details.
  • You can associate additional properties to the requested consent item. For example, the consent should be auto granted or required. The following table shows the properties that can be associated with the consent item.
You can choose to specify custom consent mapping and specify CELx script to return a JSON object. The JSON object can have the following properties:
Property Type Required? Description
purpose string Yes Managing privacy purposes
attribute string Depends on purpose Managing attributes
accessType string Depends on purpose Access type is configured with the data privacy purpose. If not provided, thedefault value is used.
value string No Indicates a more specific consent request. For example, consent for a specific email.
custom JSON object. JSON property value type is string. No Any additional context information to be added to the consent. This is available to be displayed in the consent page in the form of template macros.
claims JSON object. JSON property value can be of any type. No If the request is authorized, corresponding claims are added to the ID token issued.
required boolean No If required is set to true, then the user must respond with an assent. This assent is not required, if the privacy policy decision indicates that the consent can never be accepted.
autoGrant boolean No If autoGrant is set to true, then the user is not prompted to consent and the consent item is automatically authorized.
global boolean No If global is set to true, then the recorded consent is global across all applications. This setting is relevant for consent items, such as Terms documents that are only accepted once by the user.
audience string No If the request is authorized, this value is added to the granted audiences along with the list of audiences that is configured in the application, and the default client ID.
Here is the example of the JSON returned by the custom consent mapping:
	{
    "purpose": "marketing",
    "attribute": "email",
    "accessType": "read",
    "value": "jhill@ibm.com",
    "custom": {
        "type": "personal"
    },
    "autoGrant": true,
    "required": false
}