Security Requirements for UID2 Sharing

All UID2 participants have a core responsibility to ensure that the UID2 ecosystem is safe. The following are standard security practices for all UID2 participants. If you are sharing raw UID2s between authorized sharing participants they are required and must all be met consistently; if you are sharing UID2 tokens they are recommended.

The security requirements are as follows:

• Authentication
• Authorization
• Accounting
• Secure Transport
• Example Workflow

Authentication

Authenticating involves verifying the identity of an entity using various methods to ensure that they are who they claim to be. Online, this is commonly accomplished through email verification, and in person this would often be accomplished using a government-issued form of identification.

Issuing a username and password, API key, or other credentials convenient for the purpose of the authentication check allows the issuer of those credentials to identify the entity for subsequent authentication checks.

A multi-layered approach, known as multi-factor authentication (MFA), significantly enhances security by requiring multiple forms of verification, which makes unauthorized access much more challenging. MFA might include two-factor authentication (2FA), where users must provide a second form of identification such as a code sent to their mobile device or generated by an authentication app at the time of transfer.

Security questions, email verification links, or SMS verification codes are also commonly used to strengthen online authentication processes.

Authorization

Authorization online determines what resources a user can access and what actions they can perform after they have been authenticated. This process involves:

• Setting permissions and restrictions based on the user's role or account details.
• Ensuring that users can only access information and functionality relevant to their privileges. In addition, sharing participants must have an executed contract in place with UID2, and must have signed the UID2 Participation Policy, in order to be authorized to send or receive raw UID2s or UID2 tokens, with the exception of the two cases specified in Exceptions in the UID2 Sharing Getting Started document.

To verify that your authenticated recipient is an authorized UID2 sharing participant, one option is to ask your UID2 contact.

Accounting

Accounting means that there is a record of the transaction, so that activity can be reviewed or audited if necessary. To ensure a comprehensive and attributable transaction log for data transfers between two sharing participants, it's important to record specific fields that capture the details and context of each transaction.

The following table shows the key fields you should consider including in the transaction log.

Data	Explanation
Timestamp	The exact date and time when the data transfer occurred.
Data recipient ID	The identifier of the participant who is receiving the data.
Transaction ID	A unique identifier for each transaction. This ID can be used to track and reference specific transactions in the log.
Data volume	The amount of data transferred, typically measured in terms of lines (number of distinct UID2s) or file size (for example, megabytes or gigabytes).
Transfer method	The method or protocol used for the data transfer, such as HTTPS, SFTP, or an S3 presigned URL.
Status of transfer	The outcome of the transfer, such as successful, failed, or partial.
Error codes/logs	If the transfer fails or encounters issues, recording error codes or a brief log of the error can assist in diagnosing and resolving the problem.
Authorization details	Information about who authorized the transfer, including relevant permissions or approvals.
Checksum or hash value	A checksum or hash value to verify the integrity of the data after the transfer. This helps in ensuring that the data was not altered during the transfer.

Additional logs, such as network logs, application logs, and cloud audit logs, can also help by providing additional information such as source and destination IP addresses or cloud platform account IDs.

Secure Transport

Secure transport helps protect raw UID2s from being accessible or modifiable by an onlooker during the transition of data from sender to receiver, end to end. Examples of secure transport include:

• HTTPS or TLS
• Message-based encryption

Example Workflow

The following is an example workflow for an online AAA (Authentication, Authorization, and Accounting) flow, with an additional human verification step for contract validation.

1. Pre-Authentication:

   • A sharing participant verifies the identity of an intended recipient (sharing receiver) and then issues a set of credentials, such as a username and password or an API key, to the recipient.

2. Authentication:

   • The intended recipient begins by providing their credentials, such as a username and password.
   • To further secure the process, two-factor authentication might be required. The user would receive a code via SMS, email, or an authentication app, and must enter the code to proceed.

3. Pre-Authorization:

   • When authentication is complete, the system checks the user's role and permissions to determine whether they have initial clearance to access the requested resources or services.

     This step involves checking a database or directory service to confirm the user’s access rights based on the authenticated identity. It answers the question, "Is this person authorized to receive UID2 data from me?"

4. UID2 Participant Authorization:

   • A designated verifier verifies that a valid, signed contract, including the UID2 Participation Policy, exists between the recipient (or their organization) and UID2.

     For help with this step, one option is to ask your UID2 contact.

5. Post-Verification Authorization:

   • When the verifier has confirmed the existence and validity of the contract, the sharing participant has permission to grant access to the data to be shared.
   • The sender's system updates the recipient's access status to reflect this authorization, allowing the recipient to access the requested resources.

6. Accounting:

   • During the session, the system logs all transactions and access details for future auditing and monitoring. This includes logging the initial authentication, the authorization details, and any instances of human intervention.

     The system also logs usage metrics such as access times, duration, and resource usage, to ensure compliance with the contract terms and for billing purposes if applicable.

7. Feedback and Notification:

   • Upon completion of the authorization process, the recipient receives a notification about their access status. If access is granted, they are notified and can proceed. If access is denied, they receive an explanation or steps for further action. For example, the sharing receiver might get an email notification that the download is ready.

   • The verifier might also receive a notification confirming that their intervention has been successfully recorded and acted upon.

important

Before sharing raw UID2s or UID2 tokens you must validate that the participant you are sharing with has signed the UID2 Participation Policy. If you are unsure whether the sharing receiver has signed, one option is to ask your UID2 contact.