Provable verification of JWT in o1js

This topic is to discuss the proposal submitted by @0xStruct .
Please see below for the details of the proposal and discussion.

14th June,2024
Current status: Funded
Funding Note: We see this proposal to introduce a package/tooling that could be very useful to build several applications in the ecosystem and thus has a high impact. This also forms basis for further zk based credential systems. The builder is part of the ecosystem and has delivered successfully in the past, so the risk is classified as low. Budget is inline with the work proposed.

2nd June, 2024
Current status: Under Consideration.
Opened for community discussion on : 02 June, 2024.

1 Like

Title

JSON Web Tokens (JWT) verification and a showcase zkApp

Proposal Overview

This project will add support for provable verification of JWT. In addition, there will be a showcase zkApp, leveraging the JWT verification building block, to highlight use of privacy-preserving proof together with web2 identities for end-users.

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

It is used as auth tokens in OAuth 2.0 and OpenID Connect (OIDC) standards to enable end users’ account information to be used by 3rd-party services without exposing the users’ account credentials.

Since these are widely used in popular web2 platforms (Apple, Facebook, Github, Google, LinkedIn, etc), support for JWT verification could “bridge” web2 to web3 and onboard web2 users to Mina/web3 ecosystem.

Problem:

There are over 5 billions internet users (web2) while number of web3 users is, at best, estimated to be 300 millions. That is for 1 web3 user, there are 16 web2 users.

Internet users use passwords, along with emails, to login to access their accounts. Whereas, for web3, users need to have wallets to login, sign and manage their assets.

This difference is a critical UX friction to get more users into Mina ecosystem.

Below are the questions (problem areas) this project is addressing:

  • How might we reach and onboard these non-web3 users into Mina ecosystem?

  • How might we enable Mina to be integrated as a ZK layer inside web2 apps?

Solution:

In web2, one of commonly supported authentication/authorization system is OAuth/OpenID. Most widely used internet platforms such as Apple, Facebook, Github, Google, LinkedIn, etc support OAuth/OpenID.

When a web2 a user login with an OAuth provider, upon successful authentication, a JWT is returned. With JWT, its signature is verified and its payload is used to get user information as shared by the OAuth provider.

Then proofs can be generated to be used in zkApps and web2 apps.

  • in zkApps, for instance, a web2 user can play a ZkNoid game without a wallet, as proof can be used for authentication or as a ZK identifier.

  • in web2 apps, proofs can be verified off-chain and can be coupled with other app logics, incorporating the powerful ZK capabilities of Mina/o1js.

Impact:

This project will serve as user on-boarding and activation “bridge” to Mina from web2 ecosystem. It could add values and exposure to existing ecosystem projects such as MinAuth, Mina-anons and ZkNoid by allowing web2 users (logged in through OAuth providers such as Facebook and Google) to access these projects. It could also unlock creative designs and approaches for zkApps with focus on web2 users.

With the consumer-facing showcase zkApp …

  • For devs: it would be a reference codebase and an inspiration for potential zkApps that could be built with this primitive

  • For end-users: it would show how they could login with their web2 accounts, how JWTs are used in generating ZK proofs client-side in privacy-preserving and trustless manner unlike similar web2 apps

Audience:

ZK developers (primary), web2 users (secondary)

Architecture & Design

Detailed Design/Architecture:

Verification of JWT signed according to RS256 would require RSA, SHA256, Base64 and JSON parsing.

Token, with format header.payload.signature, needs to be Base64 decoded. Then header needs to be checked for alg signature algorithm of RS256. Then payload needs to be verified for claims of the authenticated identity. Then signature needs to be verified if it is properly signed by the token issuer.

The verification logic will be implemented as ZkProgram so that it can be utilized by other projects as a primitive.

It will also be utilized in :ninja: Mina-anons as one of Signature/authentication schemes. Hence, web2 accounts will be able to access features of :ninja: Mina-anons.

Vision:

To provide secure and efficient provable verification of JWT to catalyze on-boarding of web2 users and use-cases to Mina protocol.

And to support developers to reach beyond web3 users.

Existing Work : Idea is initiated as part of the Mina-anons signature/auth schemes

  • Production Timeline : 6 weeks

Budget & milestones

  • Deliverables:

    • ZkProgram for JWT verification
    • Test coverage
    • UI for testing authentication and verification
    • Documentation
    • Showcase zkApp for anonymous message board sorted by membership (i.e: yikyak, blind, nozee)
  • Mid-Point milestones:

    • ZkProgram for JWT verification
    • Test coverage (partial)
    • UI for testing authentication and verification (partial)
  • Project Timeline : 1.5M (6 weeks)

  • Budget Requested : 11,000 MINA

  • Budget Breakdown:

    • Inital research (1,000)
    • ZkProgram for JWT verification (4,000)
    • Test coverage (1,000)
    • UI for testing (1,000)
    • Documentation (1,000)
    • Showcase zkApp (3,000)

Wallet Address: B62qjXnYKzBHisNhBtd7ZewjFi8jWCSLcbZ5tJbPKQMZvHa1mfkNYq8

Team Info

  • Proposer Github: 0xStruct
  • Proposer Experience:

I have worked on these fullstack zkApps :jigsaw: Mina-puzzles and :ninja: Mina-anons as part of :sailboat: Mina Navigator Season #1

In terms of consumer-facing dApps, these projects are relevant: :peach: Fruit Bowl, :mailbox_with_mail: Email as Verified Credentials, :zipper_mouth_face: Flow Zips, :popcorn: Popcorn wallet

  • Team Members: 0xStruct
  • Achievements: above 4 projects have won prizes at various hackathons

Risks & Mitigations

  • Risks and mitigations
    • based64 decoding and encoding would need to be URL safe.
      • low difficulty
    • JSON parsing and verification of key-value pairs
    • retrieval of trusted server’s public keys
      • zkOracle could be used to verify
    • exceeding circuit size limits
      • use linear proof recursion

Great idea! Will your ZkProgram’s public input or output have a time field for verifying the JWT expiry date on L1?

2 Likes

Yes, thank you. If JWT has exp in its claim, it should be in the output of the ZkProgram to attest it validity constraint.

Other details such as rotating signing keys of an OAuth provider also need to be taken into account in the ZkProgram logic for verification.

1 Like

Very interesting! Two thoughts:

  • For token-based authentication in the technical sense, verification needs to happen very fast and often (e.g. with every request). Would be interesting to get some performance estimations for a ZK verification scheme.
  • JWTs are often signed and then also encrypted (JWEs), to shield the payload contents. Would be great if this could still be possible
2 Likes

Btw, similar to exp there is also a standard nbf claim“not valid before”.

1 Like

Thank you for sharing your thoughts.

  • Regarding verification (and proof generation), I have not done for JWT yet. For Ethereum signature and address verification, it is around a minute. But with recent updates of o1js, there are a lot of performance optimizations that I could make use of.

  • After proof generation, it is up to developers on how they would use it. For instance, if it is for use in web app context, it could generate another JWT token based on the proof (as implemented in MinAuth). Whereas, if it is for use in on-chain context, then an on-chain attestation can be made.

  • Thanks for pointing out about JWEs. I was not looking into it but I will explore more about it as it offers security benefits. As it relies on RSA, it could be supported easily.

1 Like

This application is approved for Funding.

Funding Note: We see this proposal to introduce a package/tooling that could be very useful to build several applications in the ecosystem and thus has a high impact. This also forms basis for further zk based credential systems. The builder is part of the ecosystem and has delivered successfully in the past, so the risk is classified as low. Budget is inline with the work proposed.