xGov-119: Zorkin - Social Login for Self-Custodial Account Authentication with ZK-SNARKs

[altaro]

This is the official discussion thread for xGov-119: Zorkin - Social Login for Self-Custodial Account Authentication with ZK-SNARKs

Id: 119
Period: 3
Title: Zorkin - Social Login for Self-Custodial Account Authentication with ZK-SNARKs
Author: Winton Nathan-Roberts (@mangoplane)
Company Name: Helium Labs
Category: dApps
Focus Area: User Onboarding
Open Source: Yes
Amount Requested: 100000
Status: Final

Abstract

Zorkin aims to implement a ZK-SNARK based OpenIDConnect authentication solution that runs natively on Algorand, allowing Social Login like Facebook to authenticate access to an application specific self-custodial Algorand Account.

A fiat on-ramp will be integrated into the solution to enable regulatory-compliant blockchain asset purchases using major payment methods such as credit card.

Team

• Winton Nathan-Roberts as Research, Design & Software Engineering lead

• Skilled independent contractors for auxiliary tasks spanning software engineering, legal consultation, and financial services

Contractor involvement in core system design and implementation will be minimal and subject to rigorous validation checks.

Experience with Algorand

Winton Nathan-Roberts is a Machine Learning PhD dropout with over 4 years of industry experience in Software Engineering working for various Startups & Blue Chip companies like Wargaming.

Over the last two years, he has been working largely in silence on an Algorand-based Web3 gaming venture. His current focus is on enhancing user onboarding for Web3 dApps and games, with a specific emphasis on regulatory-compliant authentication and fiat on-ramping. Helium Labs on GitHub represents some of this work, with many of its repositories private.

Present Proposal

Zorkin aims to implement a ZK-SNARK based OpenIDConnect (OIDC) authentication solution, allowing Social Login like Facebook to authenticate access to an application specific self-custodial Algorand Account. A variant has been implemented by Mysten Labs for their Sui blockchain called ZK-Login, which is only usable with Sui. Zorkin will attempt to improve upon ZK-Login, if possible. Some of Algorand’s user experience (UX) challenges, like the need for explicit consent for asset Opt-In, will be mitigated by possibly leveraging ARC-56 whose development is proposed by XGov-117.

Multiple system designs are being explored, with one variant and its MVP implementation detailed at this Github repository. However, the final deliverables will differ, as development is expected to lead to an enhanced design and implementation.

Zorkin will be integrated with a 3rd Party Fiat On-Ramp to allow users to buy approved crypto assets using major payment methods like credit card, taking care of relevant compliance. A Fiat On-Ramp such as MoonPay will be considered for integration.

Deliverables

The deliverables of this proposal are the success criteria, against which the proposal can be considered delivered on should they be met, and are enumerated below.

ZorkinInfra is defined as a ZK-SNARK based OpenIDConnect authentication solution that authenticates access to a Self-Custodial Algorand Account, that’s local to a specific tenant. A tenant is an application interface to ZorkinInfra, through which users can authenticate access with ZorkinInfra to self-custodial Algorand accounts that are local to the tenant. PaymentInfra is defined as payment infrastructure that allows billing of tenants for their usage of ZorkinInfra to cover related operating expenses (e.g. cloud hosting costs) and a pre-determined profit margin. The Dashboard is an area where customers can configure their tenants, and manage their billing via PaymentInfra. LegalConsult refers to consulting with a relevant legal professional to ensure the deliverables comply with relevant laws, and to assist in drafting necessary legal documents such as terms of service.

In chronological order, the deliverables are:

0. Development of ZorkinInfra

1. Development of Dashboard

2. Development of PaymentInfra

3. Testnet Deployment of ZorkinInfra, with a tenant configurable via Dashboard and billed via PaymentInfra

4. Integration of at least one 3rd Party Fiat On-Ramp

5. Initiation and completion of LegalConsult

6. Refinements of ZorkinInfra, Dashboard & PaymentInfra against feedback on their testnet deployments & legal consultation (LegalConsult)

7. Mainnet Deployment of ZorkinInfra, with a tenant configurable via Dashboard and billed via PaymentInfra

The delivery timeline is deliberately open-ended to prioritize legal compliance and consumer safety. The deliverables will be available for public access only in jurisdictions where they fully adhere to local laws. The deliverables will be adjusted against feedback from legal consultation to ensure legal feasibility. These services will be offered as long as they are financially viable and legally permissible, with a planned legal sunsetting and exit strategy to be devised and communicated to consumers through the terms of service.

Minimum-Viable Product Demo

The following video showcases an early-stage design of Zorkin, featuring a demo of the Minimum Viable Product for this variant. Please be aware that the described variant is in its early stages; the final deliverables may differ significantly as the design will be refined throughout development.

Benefits for the community

If implemented, developers in supported countries can provide users with a ZK-SNARK based OpenIdConnect authentication solution to access an application-specific self-custodial Algorand account linked to their OAuth credentials. The integrated 3rd party Fiat On-Ramp will enable users to buy approved crypto assets using major payment methods, including credit cards. Some of Algorand’s UX challenges, like the need for explicit consent for asset Opt-In, will be mitigated by possibly leveraging ARC-56. Estimates of operating expenses like cloud hosting suggest it may have competitive pricing to competitors in the space.

Additional information

Open Source Clarification

The proposal’s metadata suggests it will be Open Source, but this applies only to solution components chosen at our discretion such as certain frontend application clients. Each open-source component will be subject to a separate license with respective terms and conditions that must be adhered to.

Ownership of Deliverables & Intellectual Property

The deliverables and related intellectual property (IP) will be fully owned by Winton Nathan-Roberts, who reserves the right to do anything with the property as permitted by law. To the best of our knowledge, the current IP isn’t conflicting with any patents. The intellectual property and deliverables might undergo ownership transfers, leading to possible rebranding or integration with other companies or products. For instance, Zorkin could be renamed and associated with a different product the author is affiliated with under similar ownership changes. Zorkin, described by the proposal, is a commercial endeavour with the aim to profit.

Self-Custodial Definition

The proposal’s Self-Custody aspect means that Zorkin or its affiliates do not hold users’ sensitive account access keys, such as private keys, whose possession would allow the holder access to the users’ account. Account access is restricted to the user, their OAuth account provider, and potentially frontend application clients.

Disclaimers

To the fullest extent permitted by law, this proposal and Zorkin are subject to the following legal disclaimers:

• NO WARRANTIES: We offer no warranties or guarantees, explicit or implied.

• NO LIABILITY: We are not liable for any damages from using or inability to use this content.

• INDEPENDENCE: We do not necessarily have a direct affiliation with any party mentioned or implied besides Zorkin.

• INDEMNIFICATION: You must defend and indemnify us against all claims and damages from your use of the content.

• NOT PRODUCTION READY: The content may have vulnerabilities and is not for production use.

• USE AT YOUR OWN RISK: You are solely responsible for using the content and ensuring its legal compliance.

• UNVERIFIED CLAIMS: Claims in the content are not independently verified; do your own research before relying on them.

• IMPORTANT NOTICE: This document, including all disclaimers, should not be considered as legal or investment advice. The information provided is for general informational purposes only.

Due to the research heavy nature of the proposal, all claims are subject to change.

Link to the full proposal on GitHub:

xgov-119 - Zorkin - Social Login for Self-Custodial Account Authentication with ZK-SNARKs

Please see the disclaimers and additional information in the proposal for context and clarification around the terms such as “Open Source” (which applies only to components chosen at our discretion).

[altaro]

Feedback is welcomed.

[altaro]

I believe we have until the 6th of February to make updates to our proposals

[altaro]

So why do we even need another social login method? Here’s why I think it’s worth pursuing, subject to proposal disclaimers:

• Current estimates indicate pricing will likely be cheaper than competitors such as Web3Auth, especially for applications where few users transact, such as Free-To-Play games where only 2-5% of users make purchases. A pricing model being considered is one that charges for authorized session creation as the billable usage metric. Session creation can be deferred to the first transaction and is often includable in the session-authorizing group transaction, providing sybil-resistance
• To mitigate vendor lock-in risk
• By being Algorand first, many Algorand specific UX issues can be addressed in a single cohesive solution. For instance, we could streamline Asset Opt-In if the Minimum Balance Requirement (MBR) is covered and potentially enable cross-chain asset interoperability
• To attract developers to Algorand

Note, pricing is variable based on the Algo/USD exchange rate. Algorand has expressed that it will adjust fees to keep them relatively low.

[DragMZ]

What are the supported countries?

[altaro]

Most countries are possible in theory, as evidenced by comparison with similar services like Magic Link. However legal advice is required to give definite answers.

[GhostOfMcAfee]

I really like this idea. However, I worry if this may be duplicative of things already planned by the Algorand Foundation.

During a recent interview with John Woods (CTO Algorand Foundation) mentioned that AF was developing a product like ZKLogin that would be out “very soon.” (see this link, relevant discussion starts at around the 55 min mark in case time stamp doesn’t work).

Are you familiar with this planned product? If so, can you describe how what you propose is different?

Also, while I can appreciate the need for a flexible delivery timeline, can you put a rough approximation on things?

[joe-p]

I believe what John was referring to was the research we have been doing with FIDO. First for authentication with websites (ie. login with wallet) and then txn approval. @altaro’s proposal is very different from what we’ve been researching as far as I know. Even if that wasn’t the case, something like ZK-based login is incredibly complex and different implementations will have different tradeoffs and UX so it’s always good to have more options, especially with “bleeding edge” stuff like this.

[GhostOfMcAfee]

Perfect. Thanks for clarifying.

[altaro]

Thanks for the question. Algorand Foundation (AF) is developing a FIDO2-based auth mechanism that’s significantly different to Zorkin’s OIDC based-solution. As @joe-p outlines, AF’s solution currently only supports user authentication. It’s unclear the extent to which AF will enhance the user experience, such as including an integrated Fiat on-ramp which Zorkin intends to do.

Below I compare the self-custodial FIDO2 authorization mechanism I’m familiar with to Zorkin. Although AF might use a different method, all FIDO2 mechanisms I’ve seen are similar, primarily leveraging the challenge-signing phase of the FIDO2 auth ceremony. Since both methods are still in development, the details provided below may differ to their final forms. Unintentional inaccuracies may be present.

Zorkin based Transaction Authorization:

• Zorkin enables OIDC-based authentication through social login providers (e.g., Google) to gain access to a linked application-specific Algorand account, leveraging the privacy-preserving nature of ZK-SNARKs to keep sensitive access keys within the frontend

• A user must authenticate with the same mechanism they normally use with their OIDC provider such as multi-factor authentication (MFA), Passkeys, FIDO2 & password. Often the experience is one-click using session information from cookie storage

• Zorkin will provide a recovery mechanism should the interfacing application (e.g. website) become inaccessible. The OAuth account itself can be recovered via any recovery mechanism the user has with their provider

• It’s compatible with any OIDC provider that allows customization of at least one OAuth claim in the initial request, including Firebase, Google, Github & more

FIDO2 based Transaction Authorization:

• FIDO2 can be used to prove access to a FIDO2 credential stored on an authenticator device to authorize transactions from a linked Algorand account, inheriting FIDO2’s properties like passwordless & phishing resistance

• Unlike OIDC, which offers a complete authentication solution, FIDO2 lacks essential account management features. For instance, it does not provide a recovery option for lost authenticators, session revocation, or the ability to update authentication factors, such as adding multi-factor authentication (MFA). Additionally, even with OIDC based authorization methods, managing an associated Algorand account requires extra logic

From now on, this method will be referred to as “FIDO2.”

Some Similarities:

• Both methods are self-custodial means of transaction authorization, in the sense accounts are accessible to interfacing frontend clients. OIDC based methods also provide access to OAuth providers, inherent in its centralized nature

Some Differences:

• FIDO2 has weaker browser and mobile authenticator support compared to the well-established OIDC flow, which supports a broader range of authentication factors like Magic Link, Password & Username, FIDO2, and more

• Applications can seamlessly integrate Zorkin with their existing OIDC auth solution, provided it’s compatible. In contrast, FIDO2 would require retrofitting to existing user profiles through some linking process

• FIDO2, lacking comprehensive features such as account recovery that OIDC offers, is not a complete authentication solution by itself. Zorkin aims to provide many of these additional account management features

In conclusion, they have distinct advantages and disadvantages. Depending on IP ownership, FIDO2 auth might be added to Zorkin as an alternative option. A developer may wish to offer social login, which people are familiar with, alongside FIDO2 via Zorkin.

[altaro]

I intend to make a few updates to my proposal. Apparently we have until the 6th of February to do so.

[Algomania]

This is interesting, I will be honest I am not a coder so whenever i see ZK-SNARKS i think privacy and transactions , I think Zcash & shielded TXs but I understand there would be MANY different types of applications you could use ZK-SNARKS for. Sorry if this is off -topic Might be a dumb question sorry but I was curious if this would make it possible to create shielded TXs in future or does Algorand already have the ability to do this in its core code. Maybe im thinking about the most popular use case for ZK-SNARKS i would think the addition off this will give algorand an edge over other chains.

[altaro]

Thanks for your interest in Zorkin. For this proposal, the scope is being limited to authentication & transaction authorization. I will consider privacy extensions in the future, possibly as a separate XGov proposal.

ZK-SNARKs have a wide range of applications outside private transactions. Effectively they can be used to prove a fact to a verifier with a proof generated off-chain that consumes private input not seen by the verifier, using the prover. Example applications include off-chain transaction verification (e.g. zkSync), private transactions (e.g. zCash), and using OIDC authentication/authorization on-chain without exposing the sensitive JWT access token involved on-chain (e.g. Zorkin).

[altaro]

Hey, just letting you know that I updated the proposal. The updated proposal can be viewed at xGov119’s PR on Github.

The latest commit, bbd49ad97a25e536b099bc0d742d0e190170b7df, is at the head of this update.

The main changes are in the clarity of explanation, and a couple clarifying terms.

[altaro]

Update: The proposal has been committed with a status of final.

[altaro]

I look forward to the upcoming voting session

[altaro]

The proposal you’ll be voting on is whatever appears in the voting session after recently being snapshotted and merged. The scope of that proposal is self-contained, and doesn’t include whatever is said outside the proposal.

I’m currently attempting to revise my prototype to use a superior method, as permitted by the proposal. Note the proposal allows refinement.

By the start of voting I’m hoping to have a revised method, with a video demo, although this isn’t guaranteed.

[altaro]

The proposal explains in plain English to expect the delivered method to be significantly different to the current prototype, as it naturally evolves over the course of development.

From delivery, expect a paid service that’s available only in supported countries, with these outcomes: access to a self-custodial Algorand account using OAuth/OIDC, presence of ZK-SNARKs, partial reduction of UX friction associated with Algorand (such as explicit asset opt-in), and integration of a fiat on-ramp. The definition of self-custodial is in the proposal. The specific system design & implementation that achieves these outcomes is flexible & in my control, with the proposal presenting a working prototype of one approach!

[altaro]

In the proposal, “Helium Labs” is a placeholder for a company I’m about to create. I’ll specify the registered company before voting commences, which the proposal will reference.

[altaro]

Hello everyone,

Exciting update: I have applied to register “VERSEWARE PTY LTD” (not yet a registered company) as a Proprietary Limited Company and have secured verseware.io as its domain. The name is currently undergoing manual review. It’s important to emphasize that the registration is still pending and could be rejected. I’ll keep you updated on its progress.

The name “Verseware” is a blend of ‘Metaverse’ and ‘Software’, and I have confirmed the absence of conflicting trademarks to the best of my knowledge.

Additionally, I have not yet documented an alternative variant as previously mentioned. I will provide an update on this as soon as possible, though I cannot specify a timeframe and I’m in no rush.

Cheers,
Winton