Identification
Introduced references
Entity, Public key, Private key, Compromised key, Witness, Identifying attribute.
Entity, Public key, Private key, Compromised key, Witness, Identifying attribute.
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.
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.
Example of implementation:
Encryption algorithm code = SHA2 (256). Allowed ID code = Hash (“Public Code” & ”Consent Code”). Authorized identifier = (Hash (“Public Code” & ”Consent Code”; SHA2 (256))
Now we can define Entity’s identification as a number of consisting of records of the form (Public key of the CS; Identification attribute; Allowed Identifier), signed by the keys of the corresponding CSS.
Entity’s Will.
For entry into most legal relations the Entity's Will is required to be explicitly expressed.
Encryption algorithm code = SHA2 (256). Allowed ID code = Hash (“Public Code” & ”Consent Code”). Authorized identifier = (Hash (“Public Code” & ”Consent Code”; SHA2 (256))
Now we can define Entity’s identification as a number of consisting of records of the form (Public key of the CS; Identification attribute; Allowed Identifier), signed by the keys of the corresponding CSS.
Entity’s Will.
For entry into most legal relations the Entity's Will is required to be explicitly expressed.
We use the electronic digital signature (EDS) method, which is widely used in business circulation, to record the Will. Each transaction sent by the user to the network is signed by EDS. The user can utilize any standard of the encryption standards supported by the system, which allows the use of local national EDS standards. Therefore, a transaction sent to the network and signed by the User's EDS uniquely determines his Will.
In any transaction there is a field (“witnessGroupId”) defining a group of Validators (Consilium) authorized by the User to process this transaction. This group of Validators acts in accordance with the Rules, which are a public contract with the algorithmic part (user consensus).
The completed witnessGroupId field of the signed User's EDS uniquely identifies the will of the User to enter into legal relations in accordance with the Rules corresponding to this witnessGroupId value.
In any transaction there is a field (“witnessGroupId”) defining a group of Validators (Consilium) authorized by the User to process this transaction. This group of Validators acts in accordance with the Rules, which are a public contract with the algorithmic part (user consensus).
The completed witnessGroupId field of the signed User's EDS uniquely identifies the will of the User to enter into legal relations in accordance with the Rules corresponding to this witnessGroupId value.