-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFP: Private Credential Standard #35
Comments
Contact InformationTeam Lead (Main Contact Person):
Team Members:
Team Overview:
Proposed Solution
Execution Plan
Additional Support and Funding
Community Engagement
|
Please find solution attached |
Proposal by zkSecurity Contact InformationTeam Lead
Team Members
Team OverviewzkSecurity brings unique qualities to this project:
Proposed solutionAt a high level, our work will result in three artifacts:
Design consideration 1: Cryptographic protocolFor 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:
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 Design consideration 2: Attestation standardAnother 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
The RFC currently leaves this aspect underspecified: Claims, which represent a list of attestations that is passed to // excerpt from https://github.com/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
Allowing attestations to be "just proofs" is nice because the result of
However, to support efficient generation of Permissioned Attestations, we propose to additionally allow attestations to be
Design consideration 3: Client-side proof generation and attestation UIA 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
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
Execution PlanStep-by-step Plan
Total timeframe: 13 weeks Critical Milestones
Additional Support and FundingSupport Requirements: None. Grant Funding:
Community EngagementI (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. |
We would like to send SmartOSC's solution via attached file, please check your email for details. |
Implementation underway #44 |
RFP: Private Credential Standard
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:
Impact Measurement
The impact of the RFP will be assessed based on:
Application Instructions
To apply for this RFP, applicants are required to:
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):
Team Members:
Team Overview:
What makes you best-suited to execute this project?
[Provide a comprehensive answer]
Proposed Solution
Execution Plan
Step-by-Step Plan:
Critical Milestones:
Additional Support and Funding
Support Requirements:
Grant Funding:
Community 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.
The text was updated successfully, but these errors were encountered: