The UID2 ecosystem includes several different API permissions that allow access to complete specific activities. This approach is part of the overall secure design of UID2.
If you're a publisher and are implementing UID2 on the client side, API permissions do not apply to you. Instead, you'll receive a different set of credentials that are specifically for generating a client-side token request. For details, see Subscription ID and Public Key.
A participant can have one or several sets of API credentials with associated permissions. In cases where you have more than one API permission, you have the option to have a separate set of credentials for each permission or have a single set of credentials for all permissions. We recommend having a separate set of credentials for each permission.
The following table lists the key permissions, the types of participants that commonly use them, and a summary of the key associated activities.
|Permission to call the POST /token/generate, POST /token/validate, and POST /token/refresh endpoints, to generate UID2 tokens from DII and to refresh them, using one of these integration methods:
|Permission to decrypt UID2 tokens coming in from the bid stream from publishers into raw UID2s for bidding purposes.
|Any participant type that takes part in UID2 sharing. For details, see UID2 Sharing: Overview.
|Permission to do both of the following:
|Permission to use the POST /identity/buckets endpoint to monitor rotated salt buckets and to use the POST /identity/map endpoint to map multiple email addresses, phone numbers, or their respective hashes to their raw UID2s and salt bucket IDs.