The problem deLinZK solves

💡 Problem Statement

The problem with the current networking platforms are that there is no surety in the work experience which users claim to have. The users can also fake their way through, having forged certificates or even having certificates from pseudo-companies, which do not even exist. This is why recruiters resort to using different B2B credential verifiers, which not only charge an absurd amount of money, but also extract a lot of PII (Personal Identifiable Information) from the applicants who apply to these organizations.

So, there was a need to find a platform which could have credential-verification in-built, and take as less PII from the applicants.

🥁🥁 Drumroll, please...enter deLinZK 🔥🔥

deLinZK is a Zero-Knowledge solution to the above problem, providing a platform both for organizations and employees or users of the platform, to accurately issue Verifiable Credentials which serve as Proof-of-Employments, and for employees it also serves as a proof of work experience after they finish tenure in their current company. deLinZK also provides a comprehensive job board which allows organizations to post jobs, and the employees to apply to them. The organizations do not need to spend additional time verifying the work experience of the applicants, since all of them are already verified by deLinZK through a ZKP way.

Challenges we ran into

💪 Challenges Faced (and WAGMI!)

• One of the main challenges we faced was the novelty of the implementation, and the experimental phase of the technologies it uses:
  • The current users are being issued Polygon ID proprietary schemas, but after the update they will be provided with W3C Verifiable Credentials, which won't be compatible with the current claims. The Iden3 circuits have also changed their specifications, which also changes the query structure which the newer versions of the PolygonID mobile app have, but the older ones cannot.
• Due to the nature of verification, we had to incorporate complicated Websocket and REST API logic in the same server. In order to maintain the request state between the different callback requests, Redis caching was implemented.
• Since, no PII is shared in the application, but we needed to authenticate different users of the application, we resorted to scrap traditional JWTs for much more advanced JWEs having JWSs inside their payload.
• One of the most interesting challenges we faced was while building the Proof-of-Employment schema:
  • We wanted to pass the data in the format to the claim schema:

  Format suggested: <STARTDATE><ENDDATE><ORGID>
  Example format: YYYYMMDDYYYYMMYYYYORGID
  Example value: 2000123120230526125
  

  • The issue was the number generated with this method, was exceeding the limit imposed by the PolygonID platform. The maximum it could parse was a 15-digit integer.
  • The initial search started with finding hash algorithms which returned decimals as outputs, which we quickly realized was not possible directly. So the 'bit calculation' game started. Idea was to get some Hexadecimal string, and then converting it to decimal, but we needed something less than 50-bits.
  • Hence, we came across SHAKE-128, which could give us a 48-bit Hexadecimal string.
  • So we hashed the PoE value, converted the Hash into Hexadecimal, and then change the radix of the bits to 10.