EUID Sharing

In the context of EUID, sharing is a process for distributing raw EUIDs from one EUID sharing participant to another.

For EUID, a sharing participant is a company that takes part in sharing, either as a sender or a receiver.

Security Requirements for EUID Sharing

All EUID participants have a core responsibility to ensure that the EUID ecosystem is safe. The following are standard security practices for all EUID participants and their sharing recipients. If you are sharing raw EUIDs with recipients the below security requirements are required and must all be met consistently.

The security requirements are as follows:

• Authentication
• Authorization
• Accounting
• Secure Transport

For an implementation example, see 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, an 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.

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 EUIDs) 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 EUIDs 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 EUID data from me?"

4. 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.

5. 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.

6. 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.