RFP: Private Credential Standard

[chad11111]

RFP: Private Credential Standard

• Intent: The purpose of this RFP is to extend the wallet provider API for Mina wallets to enable attestations beyond the current features, focusing on composable privacy and secure proof storage, as outlined in the original RFC.
• Reference RFC: RFC-0009
• Submit by: 2024-06-28
• Selection by: 2024-07-12

Background

The original RFC introduces an extension to the wallet provider API for Mina wallets, focusing on enabling attestations beyond the current features of attesting to knowledge of private keys. The proposal aims to expand this feature to allow wallets to attest to a broader range of private data, such as credentials. Composable privacy is a central concept, offering users and developers discretion in selecting which data remains private and which becomes public, ensuring that sensitive data is not exposed to the browser context.

Objectives and Desired Artifacts

This RFP seeks to implement the extended wallet provider API, focusing on:

1. Standardized Attestation Construction API: Allow users to attest to any data.
2. Attestation Composition API: Enable users to compose local and remote proofs.
3. Nullifier and Expiration Support for Proofs: Integrate nullifier mechanisms to prevent proof reuse.
4. Secure Proof Storage: Ensure proofs are stored securely and are tamper-proof.
5. Example Implementations: Provide example implementations demonstrating the API usage.

Impact Measurement

The impact of the RFP will be assessed based on:

1. API Usability: Ease of use and integration of the extended API for developers.
2. Security and Privacy: Effectiveness of composable privacy and secure proof storage.
3. Community Adoption: Adoption rate of the extended API by Mina wallet developers and zkApp developers.
4. Compliance with Specifications: Adherence to the requirements and specifications outlined in the original RFC.

Application Instructions

To apply for this RFP, applicants are required to:

1. Thoroughly review all listed requirements and deliverables to ensure a complete understanding of the RFP's scope and objectives.
2. Complete the application form provided at [link to form], including all requested information and any preliminary ideas or proposals.
3. Submit their detailed proposal in the specified format to [email protected]. Proposals should be structured and clear, with an emphasis on how the applicant intends to achieve the RFP's objectives.
4. Engage with the Mina community through the designated discussion channels, sharing initial ideas and seeking feedback to refine the proposal before submission.

Applicants are encouraged to ask questions and seek clarifications as needed to fully comprehend the expectations and objectives of this RFP.

Submission Form Template

Application Form

Ensure that all information provided is accurate and complete to best represent your proposal.

Contact Information

Team Lead (Main Contact Person):

• Name:
• Position/Role:
• Email:
• GitHub Username:
• Telegram/Discord Handle:
• Mina Recipient Address (for potential funding):

Team Members:

• Member 1:
  • Name:
  • Role:
  • Relevant Experience/Previous Work (with links):
  • (Add more members as needed)

Team Overview:

What makes you best-suited to execute this project?

[Provide a comprehensive answer]

Proposed Solution

• Proposed Solution Description:
  • Please describe your proposed solution based on the requirements and core features outlined in the RFP:
  • [Provide a detailed explanation]

Execution Plan

• Step-by-Step Plan:

  • Please outline your step-by-step plan to execute this project, including expected deadlines for each piece of work:
  • [Provide a timeline with milestones]

• Critical Milestones:

  • Please define the critical milestones that should be used to determine whether you’ve executed on this proposal:
  • [List and explain the milestones]

Additional Support and Funding

• Support Requirements:

  • Please list any additional support your team would require to execute this project (financial, technical, etc.):
  • [Specify the support needed]

• Grant Funding:

  • [Explain your financial needs and conditions]

Community Engagement

• Engagement with Mina Community:
  • How have you engaged with the Mina community to refine your proposal before submission?
  • How does your experience with Mina and the community increase the likelihood of success?
  • [Describe the engagement]

Please ensure that you have reviewed all listed requirements, deliverables, and the provided resources to ensure a complete understanding of the RFP's scope and objectives.

[wjdfx]

Contact Information

Team Lead (Main Contact Person):

• Name: Jale Lau
• Position/Role: Director
• Email: [email protected]
• GitHub Username: wjdfx
• Telegram/Discord Handle: Discord@niu8
• Mina Recipient Address (for potential funding): TBD

Team Members:

• Member 1:

  • Name: Jale Lau
  • Role: Product manager and developer
  • Relevant Experience/Previous Work (with links):
    Senior blockchain industry background, head of Auro Wallet. https:/wjdfx

• Member 2:

  • Name: Buling Lyu
  • Role: Full stack engineer
  • Relevant Experience/Previous Work (with links): EX. iToken and Halo Core Engineer. https:/lvshaoping007

• Member 3:

  • Name: Remever Lee
  • Role: Back-end Engineer
  • Relevant Experience/Previous Work (with links): Proficient in Java and Golang. Back-end experience with well-known wallets and explorer products. https:/romever

Team Overview:

• Our team is Auro Wallet. A simple yet powerful
  Mina Protocol Wallet. Since the first day that Mina Mainnet went live, it has been operational. Right now, Auro Wallet is the most widely used and well-liked wallet on the Mina Protocol. There are nearly 100,000 installations.

• Our team members have developed wallets and explorers in the past and have many years of blockchain experience. To learn more, visit https://www.aurowallet.com.

Proposed Solution

• Proposed Solution Description:

  We plan to introduce a standardized proof construction API that allows users to prove various data types, leveraging Mina’s privacy features. The proof combination API supports the combination of local and remote proofs, enhancing composable privacy. Nullifiers and expiration support can prevent proof reuse and ensure proof expiration, thereby maintaining integrity and security. Secure proof storage guarantees the tamper-proof integrity of proofs.

  Additionally, third-party privacy providers will be introduced to offer proof data from third-party data sources. The proof data returned by third parties will be merged with local data and returned to the data request end, ensuring user privacy.

Execution Plan

• Step-by-Step Plan:

  • Define API Specifications: 0.5 weeks
    Draft, review, refine, and finalize the API specifications for proof construction, combination, nullifier support, and secure proof storage.

  • Develop Core Library: 1 week
    Create libraries for proof construction, proof combination, nullifier mechanisms, and secure proof storage.

  • Integrate Library with Wallet: 1 week
    Integrate the developed libraries into the Auro wallet, including necessary UI/UX updates, and conduct initial testing.

  • Develop and Test zkApp Examples: 1 week
    Develop example zkApps to demonstrate API usage, create tutorials and documentation, and gather developer feedback for further refinement.

  • Community Feedback and Iteration: 1 week
    Release a pre-release version of the wallet and documentation, collect feedback, iterate on implementation, and finalize the polished version.

• Critical Milestones:

  • Completion of API specification documentation
  • Completion of core library development
  • Wallet integration and initial testing
  • Release of example zkApps to demonstrate API usage and wallet interaction
  • Release of core libraries and integration documentation for wallet and zkApp development

Additional Support and Funding

• Support Requirements:

  • Technical communication with the o1js team, zkApp developers, and other wallet developers to develop a credential standard that better aligns with the Mina protocol.
  • Technical communication with third-party privacy teams to facilitate easier use of third-party data source proof data.

• Grant Funding:

  • API Specification Documentation: $2,500
  • Core Library Development: $10,000
  • Wallet Integration and Example zkApps: $10,000
  • Wallet and zkApp Development and Integration Documentation: $2,500
  • Total: $25,000

Community Engagement

• How does your experience with Mina and the community increase the likelihood of success?
  • The mina provider we deployed has been verified for 2 years. test-zkApp provides all API examples of mina provider. These are the results of the joint efforts with Mina and the community. Based on the above work, we believe that the interaction between the provider and zkApp will be more convenient.

[tmkec]

Please find solution attached

Mina Foundation - Proposals for issues 35.pdf

[mitschabaude]

Proposal by zkSecurity

Contact Information

Team Lead

• Gregor Mitscha-Baude
• crypto engineer, co-founder zkSecurity
• [email protected], @mitschabaude

Team Members

• Marton Moro
  • crypto engineer, will help develop the TS library / integrations
• Mathias Hall-Andersen
  • co-founder, crypto expert, will assist with research and protocol design
• We are flexible to add 1-2 more engineers if necessary to deliver milestones

Team Overview

zkSecurity brings unique qualities to this project:

• Expertise in analyzing and designing cryptographic protocols
• Deep understanding of the Mina stack thanks to many years of working at its heart
• Experienced developers that can execute quickly, without any need for support

Proposed solution

At a high level, our work will result in three artifacts:

• A TS library that implements the Wallet Attestation API
  • including the proposed DSL for combining attestations
  • which can be integrated with browser wallets
  • and comes with at least one actual integration
    • we propose to integrate with Pallad but are open to other suggestions
• A full demo (code, docs, video) of using at least one interesting real-life attestation
  • Possible examples: zkEmail, zkPassport (if usable in time; we can help), JWT for a zkLogin-like system (if doable quickly), private set inclusion a la Worldcoin/Semaphore, Ethereum-related attestation like wallet balance (if usable in time; we can help)
  • Includes a demo of the consuming service and how it validates the credential sent to it by a user
• A formal spec of the attestation API
  • that extends and fleshes out the existing RFC
  • and describes a secure, practical protocol

Design consideration 1: Cryptographic protocol

For background, there is a well-developed literature on "anonymous credentials", see 1, 2, 3. In large parts, the grant boils down to an implementation of this cryptographic concept.

As part of our work, we will take care that the protocol satisfies the security properties required by anonymous credentials literature, such as:

• unforgability of the credential
• unlinkability of two different credentials

Side note: some of the terminology used in this RFP differs from established terms in academia. E.g., a "credential" would usually be called a "presentation". TBD if there should be an effort to standardize the API language.

Regarding nullifiers, we propose to build on existing nullifier support in o1js (see RFC, PR, further discussion) that has recently undergone an audit; and to extend that support as necessary for our use case.

To support secure proof storage, we plan to use the persistent storage API accessible from browser extensions, and to encrypt the data using a key derived from a wallet-defined seed.

Design consideration 2: Attestation standard

Another design goal on top of the existing RFC is to standardize an interface for third-party attestations (also called claims in the RFC), so that

• our library clearly describes which types of attestations it can process
• it becomes easy to fit a new type of attestation into our framework

The RFC currently leaves this aspect underspecified: Claims, which represent a list of attestations that is passed to Credentials.create(), are typed as any:

// excerpt from https:/MinaFoundation/Core-Grants/pull/34

interface LocalCredentialParams {
    claims: { [key: string]: any }; // Claims about the subject
}

One compelling idea is to standardize attestations around the universal interface of recursive proofs: an attestation could be modeled as

• public input:
  • the attested data (arbitrary type)
  • public key of the owner
• proof + verification key

Allowing attestations to be "just proofs" is nice because the result of Credential.create() (the "credential" / "presentation") can itself be used as a Local Attestation again, so attestations gain (even more) composability.

Note: The owner's public key is part of the public input to bind the attestation to its owner. This prevents misuse of the attestation by non-owners.

However, to support efficient generation of Permissioned Attestations, we propose to additionally allow attestations to be

• arbitrary signed data. We will define a list of supported signature schemes that reflects o1js capabilities
• (TBD) Merkle inclusion and non-inclusion proofs

Design consideration 3: Client-side proof generation and attestation UI

A known technical limitation is that o1js currently does not work in browser extensions and can't be used from mobile wallets on Android (see o1-labs/o1js#1787).

Meanwhile, wallets need to store private user data and their attestations, and have to initiate proof creation with sensible inputs.

To solve this challenge, we propose to launch a web page from the wallet that receives the proof inputs, creates the proof and sends it back to the wallet. We will carefully design this process to keep the web page isolated and not be exposed to (for example) third-party JS execution.

The same web page can also serve as a UI hub

• for users to browse through their existing, locally stored attestations, and
• to present UI dialogs for consenting to create credentials for third-party apps.

We propose to implement this web page, which serves as a secure extension of the wallet UI, as part of the grant. Our goal is that the attestation library can be integrated into wallets with very low lift from wallet maintainers: they don't need to implement custom UI inside the extension before attestations can be used (such a custom UI can still be added though, if wallets want to offer a more integrated experience).

Other considerations

• The Operations DSL could be implemented either as a single, universal interpreter circuit (i.e. a sort of mini-zkVM; this is hinted at in the RFC), or as a custom circuit that depends on the described operations.
  • We propose a custom circuit, as it is far easier to implement, will incur lower proof generation time (smaller circuit) and will be more robust against changes to the library / o1js
• Presumably, our library should also be used by the verifier side: by services that consume and check credentials
  • This will usually involve a mix of library methods and custom logic; guidance will be needed for services to do this integration correctly
  • Notably, this includes methods for storing and handling nullifiers
  • Are we interested in the case where verifiers are zkApps? This slightly increases the scope as e.g. nullifier storage becomes more involved. The current proposal does not include a full demo of this use case, but the protocol and library will be designed to support it.

Execution Plan

Step-by-step Plan

• Create credentials for the two basic attestation types: Mina-compatible signatures, recursive proofs: 3 weeks
  • According to Credentials.create() spec
  • Includes nullifier generation
  • Includes basic validation methods
• Research cryptographic requirements: 2 weeks
  • Done in parallel with first point, to finalize the core protocol design
• Attestation Composition: 1.5 weeks
  • Includes DSL
• Wallet integration, storage, UI extension: 2.5 weeks
  • Includes browser proving in separate web page
  • Includes basic web UI for managing attestations
• Full verifier example: 1 week
  • Includes adding methods for nullifier storage/validation
  • Includes full validation of credentials
• Real-life attestation example: 2 weeks
  • Includes adding more supported attestation types
  • Probably involves additional app-specific infra on the user and verifier side
  • Results in an e2e demo
• Polish / bug fix / iteration phase: 3 weeks
  • This could be streched out over a longer time frame
  • The idea is that any library needs to go through an extended period where it is battle-tested by the community before being stable
  • We expect this phase to result in a stable release that stays useful for a long time with light maintenance
  • Furthermore, at this stage we want to finalize a detailed spec of the protocol
• Internal audit: 1 week
  • In parallel to iteration phase, before first stable release
  • Performed by zkSecurity team members other than the core developers, to get more eyes and brain cells on critical components

Total timeframe: 13 weeks

Critical Milestones

• Completion of the core library and protocol design, with local tests demonstrating its functionality
  • ETA: 5 weeks into the project
• Fully working end-to-end flow with toy attestation example
  • ETA: 8 weeks into the project
• Fully working end-to-end demo with real-life attestation example
  • ETA: 10 weeks into the project
• Stable, production-ready release, accompanied by docs and a detailed spec
  • ETA: 13 weeks into the project

Additional Support and Funding

Support Requirements: None.

Grant Funding:

• 13 weeks of TS/crypto engineering by 2 engineers: $162,500 @ $2,500/day
• 3 weeks of crypto research and audit by 1 engineer: $37,500 @ $2,500/day
• Total: $200,000

Community Engagement

I (Gregor) am active and well-known in the Mina community, which increases the success chance of this project because people will have trust that our solution is well-designed and can be relied on.

We commit to collecting feedback early and to work closely with any projects interested in using the attestation API.

[Duong5983]

We would like to send SmartOSC's solution via attached file, please check your email for details.
SmartOSC-MinasFoundation-Private Credential Standard_Proposal.docx.pdf

[TyrellCorp2020]

Implementation underway #44