# Delegation-Based Personal Data Processing Request
## 3 Delegation-Based Personal Data Processing Request Notarization Framework
### Personal Data Protection  
Transactions registered with BC for notarization contain request and response contents that may contain sensitive personal data. Owing to the characteristics of the BC network,which copies and distributes the ledger, there is a risk of the sensitive personal data of transactions being exposed to unauthorized peers. Thus, to prevent this risk, the request and response contents should be encrypted and stored, and an encryption key that can decrypt data should be provided only to entities with the authority to inquire the data, such as the creator, receiver, and auditor. As shown in Figure 7, the proposed framework generates a session key for each transaction in the application before registering the request and response in BC. The transaction ID (trxld) key and {session key (sKey), [PERSON]'s ID (dsId), [PERSON]'s url (spUrl)} value pairs are saved to the application database. Subsequently, the request and response contents are encrypted using the session key and registered in the BC.  
The transaction ID generation algorithm is identical to the transaction key generation algorithm in the BC of the proposed framework. As in (1), the request combines {ID of DS, creation timestamp}, while the response combines {SP URL of DC, creation timestamp}. Algorithm 1 is an algorithm for generating a session key.  
\[\begin{array}{l}\text{IF transaction type equal'request' THEN}\\ \text{transaction ID}=\text{[PERSON]'s ID}+\text{timestamp}\\ \text{IF transaction type equal'response' THEN}\\ \text{transaction ID}=\text{SP's URL}+\text{timestamp}\\ \end{array} \tag{1}\]  
```
INPUT: [PERSON]'s ID, SP's URL, transaction ID, transaction type, private data, timestamp OUTPUT: session key
1 IF transaction type equal'request' THEN
2 SET session key to result of SUM result of COMPUTE hash encode with transaction ID and result of COMPUTE hash encode with private data
3 SET data array with transaction ID, session key, [PERSON]'s ID, SP's URL, and timestamp
4 ADD data array made key with transaction ID into application database
5 ENDIF
6 RETURN session key
```  
**Algorithm 1** Make Session Key  
To retrieve and decrypt a transaction that is encrypted using the generated session key, the transaction session key is required, but only the creator or receiver of the transaction can inquire. Algorithm 2 is an algorithm for querying the session key.  
Figure 7: Personal data encryption process in transaction using session key.  
```
INPUT: user ID, transaction ID OUTPUT: session key
1 SET user's type to the result of READ user type of user ID
2 IF user's type is equal to 'DS' THEN
3 SET session key to the result of READ session key from application database where user ID equal DS's ID in DB and the transaction ID equals the transaction ID in DB
4 ENDIF
5 IF user's type equals 'DC' THEN
6 SET SP's URL to the result of READ SP's URL from the user information in the DC's session
7 SET session key to the result of READ session key from the application database where the SP's URL equals the SP's url in DB and the transaction ID equals the transaction ID in DB
8 ELSE
9 SET session key to null
10 ENDIF
11 RETURN session key
```  
**Algorithm 2**Inquiry Session Key