AUTH ENTICATING ONLI NE CURRICULUM VITAE USING BLOCKCHAI N DISTRI BUTED LEDGER TECHNOLOGY

DESCRIPTION

BACKGROUND

This invention is in the field of digital data communication involving identification, verification and proof of authentication.

Nowadays many documents are exchanged almost exclusively in digital format by email and/or through public and/or private online networks such as curriculum vitae (CV), endorsement among multiple forms of testimonial assertions.

There are many uses for this method in connection with many industries and sectors facing the need to rely on unadulterated validated online testimonial assertions applying a strong authentication process.

DEFINITIONS

The invention involves a classical client-server platform architecture where users connect to the platform from any compatible smart device including a large range of mobile devices and/or multiple kind of workstations running appropriate software allowing to establish a connection with a public and/or a private network of application server possibly inter-connected to other private and/or public networks of application servers. The connection to the platform is effective once the platform has validated the user's login credentials which can involve N factor(s) authentication, where N is an integer superior or equal to 1. Platforms implementing the invention support basic data management operations such as upload, download, editing and publishing common features.

DESCRIPTION OF THE DRAWINGS

FIG. 1 DIGITAL TESTIMONIAL BLOCK illustrates the logic and programmatic flow associated with the generic definition of "Assertion Block (i)". The invention structures any digital document into a collection of indexed "Assertion Block(i)". A Curriculum Vitae (CV) for example is a list of successive and distinct "Assertion Block(i)" representing each a specific experience. Each "Assertion block (i)"is depicted by:

1 .1 a HOLDER'S ID. Two different users obtain within the system two distinct IDs, and the ID for any given user at any time is reputed unique. A user is either a natural person or a legal person and the generic system rules identically apply to all users. It is possible to apply the invention method to the platform itself to create the unique ID for each user in considering this unique ID as being based on the "Assertion Block (i)" that includes - in the DESCRIPTION section below 1 .2 - the user's birth certificate information if a natural person or the registration number with company house information if a legal person. By design, it can be impossible to modify the HOLDER'S ID information after validation (except in exceptional cases for legal update) or to be obliged to delete the whole account.

1 .2 a DESCRIPTION can be structured into 3 sub parts as follows:

1 .2.1 CATEGORY such as Experience, Diploma, Endorsement, ID, Miscellaneous Statement.

1 .2.2 TIMEFRAME to describe the period where the testimony applies.

1 .2.3 BODY to describe the testimony.

1 .3 ATTACHEMENT(s) where it can be possible to embed any binary document format related to the testimony.

1 .4 the testimonial VALIDATOR'S ID where the validator is a user like the "Assertion Block (i)" holder and is either a natural person or a legal person. The "Assertion Block (i)" is in edit mode to be modified and/or completed as long as this field is void and contains no VALIDATOR'S ID. The Testimonial "Assertion Block (i)" validation is the confirmation operation first characterized by the record of a VALIDATOR'S ID in this specific field then triggering the chain of secure signature operations sealing the given "Assertion Block (i)" delivering the BLOCKCHAIN STAMP 1 .5 information described below.

1 .5 This field is void as long as the "Assertion Block (i)" is not confirmed yet by a given VALIDATOR.

Once an "Assertion Block (i)" is properly validated then it is by design automatically and instantly sealed using Distributed Ledger Technology (DLT) as described below in the VALIDATION process description. The BLOCKCHAIN STAMP field 1 .5 then stores the "transaction identifier" and "timestamp" information bound to the "Assertion Block (i)" validation what can later be used to prove whether or not the "Assertion Block (i)" has been adulterated since the testimonial validation by the VALIDATOR indicated into the "Assertion Block (i)".

DETAILED DESCRIPTIONS OF THE INVENTION

Fig. 2 VALIDATION PROCESS. The "Assertion Block (i)" is editable until confirmation by a VALIDATOR. By design the confirmation action by a VALIDATOR sends 2.6 the "Assertion Block (i)" content including the VALIDATOR'S ID 2.4 to a SHA (Secure Hash Algorithm) function 2.7 producing a unique HASH (also called FINGERPRINT) 2.8 corresponding to a signature for the given "Assertion Block (i)" used as input data in the SHA function 2.7. The HASH 2.8 resulting value has a limited size, a SHA-256 function for example produces a unique 64 hex characters hash value. A hash function is considered practically impossible to reverse to recreate the input data that generates the given hash. This one-way hash function mechanism is an essential part of the blockchain. A cryptographic hash function has four important properties: (A) it is easy to compute the hash value for any binary data (source) in input; (B) it is infeasible to reverse the hash to deduct its source; (C) it is infeasible to modify the input source without changing the resulting hash; and (D) it is infeasible to find two different input sources with the same resulting hash. All good reasons why cryptographic hash functions have many security applications including in digital signatures and other forms of authentication. By design the HASH 2.8 is then stored into a blockchain in using the DLT architecture. A blockchain is a peer to peer decentralized open ledger - like the "bitcoin" or any other cryptocurrency architecture - relying on a distributed network shared between its users— everyone holds a public ledger of every transaction carried out using the architecture, which are then checked against one another to ensure accuracy. This ledger is called the "blockchain". Blockchain is used instead of a centralized third party auditing and being responsible for transactions.

One way to store the HASH 2.8 into a blockchain network consists in converting appropriately this HASH 2.8 value into cryptocurrency addresses (e.g. base58 for bitcoin) then to trigger a transaction with them so that exists a tracking evidence characterized by the transaction identifier and timestamp (from the DISTRIBUTED LEDGER 2.9), transaction information saved into the BLOCKCHAIN STAMP field 2.5 bound to the validated "Assertion Block (i)".

Tampering with transactions on the blockchain becomes exponentially harder as time progresses and requires extreme quantities of computing power to attempt. Data stored in the blockchain is included in integrity checks— transactions are assembled into a transaction Merkle tree and hashed to produce a block header. Any alteration to transactions in a blockchain database would become apparent as the block would be invalid when indexed. Rewriting blocks requires a network forking attack and even read-write access to every peer on the network would not provide sufficient resources to alter a transaction included into the blockchain. As such, the blockchain of consensus allows an "Assertion block (i)" hash to be published to the blockchain as irrefutable proof that the "Assertion block (i)" existed at a given time in the past. Both the timestamp and the hash are unalterable barring attacks of extreme cost against the entire network.

AUTHENTICATION / VERIFICATION

When a BLOCKCHAIN STAMP field 1 .5 indicates - by design - that the bound "Assertion Block (i)" is validated, it is easy at any time to verify whether the "assertion Block (i)" has been adulterated since the validation in retrieving the HASH 2.5 value stored in the blockchain during the validation process and corresponding to the transaction identifier information stored in 1.5 - HASH 2.5 value to compare with the most recent hash value obtained for the same "Assertion Block (i)" to authenticate. The hash fingerprint values comparison is different only if in the meantime the "Assertion Block (i)" has been modified even slightly on a single bit within its whole binary structure.