Entity is considered to have a private key set. Each private key has its own unique public key. Therefore, Entity can be put in a one-to-one correspondence with some set of public keys.
However, some of the private keys may be compromised: they may become known to third parties and the Subject must be able to exclude these keys from circulation. Thus, each key has its own period of validity: from the moment of its creation until the moment of compromise (or the deletion from the registry by the Entity).
Accounting for compromised keys is made by creating public registries, with the involvement of specially authorized subjects—witnesses certifying this compromise. Thus, the set of compromised keys is defined as the set of records of the form (Public key; Certifying Entity; Compromise Time).
Each Entity has infinite content in the real world. To identify it, we use some easily verifiable features—identifying information. Thus, Identification can be represented as a set consisting of pairs (Entity’s Public key; Identification attribute).
But, since the identification is subjective, namely, with the involvement of an identifying Entity
(Certifying Witness—US), the design is complicated: a set consisting of records of the form signed with a private US key (US Public Key; Identifying Character; Entity’s Public Key).
The next feature is the fact that the Entity owns his personal data, which is expressed in a number of national laws, for example, GDPR. The general approach is to determine the right of the Entity to conceal such data and the need for the explicit Entity’s will to provide this data to third parties.
Although the identifying information may be encrypted, it may be the case that the set of attributes associated with the same Entity’s Public key will allow its identification. Thus, it is required to bind identifying features not directly to the Entity’s Public key, but to the Permitted Entity Identifier, i.e. to the secondary key generated from the original Public key. To generate such keys, various algorithms for creating temporary keys can be used.
In general, such an algorithm requires a special code to decrypt the value of the Public key. We call such a code “Consent to access to personal data” (in short—the Code of Consent). This code can be valid for a certain time, or be indefinite.
Essentially, the Allowed Identifier looks like a record of the form (Allowed Identifier Code, Encryption Algorithm Code). Entity’s accidence to get access to his data can now be defined as (Permitted Identifier, Consent Code, Entity Public Code), transmitted to the receiving party via a secure communication channel, excluding third party access.