Implement Location Proof Recipe using third-party location data, authenticated with zkTLS

[johnx25bd]

Summary

Develop and document a location proof recipe for a third-party data provider strategy using zkTLS (Zero-Knowledge Transport Layer Security). This approach leverages third-party location data providers, such as Strava, Google Location History, or similar services, to generate verifiable location proofs while preserving user privacy through zero-knowledge techniques. The goal is to establish a clear and reusable pattern, with code and documentation, that can be attached to location proofs created based on the generalized Location Proof Protocol.

Purpose

• Enable location proofs based on third-party location data (e.g., fitness trackers, location logs).
• Preserve privacy by ensuring that sensitive data from the provider is not exposed, using zkTLS.
• Provide developers with a pattern and implementation for integrating this strategy into applications.
• Extend the Location Proof Protocol’s flexibility while maintaining adherence to the standardized data model.

Requirements

0. Research Prior Art

• Research and document existing use cases and implementations of zkTLS for privacy-preserving data sharing.
• Identify relevant third-party data providers that could integrate with this strategy (e.g., Strava, Google Location History, Apple Health, or others).

1. Define the third-party provider strategy using zkTLS

• Determine how third-party data will be accessed, validated, and converted into location proofs:
  • Examples:
    • Request user activity or location history from Strava or Google, validate data integrity using zkTLS.
    • Extract specific location data points (e.g., timestamps, coordinates) while shielding unnecessary details.
  • Consider user consent, provider integration, and privacy concerns.
• Define the inputs and outputs for this recipe:
  • Input: Data from third-party providers (e.g., location logs, activity records).
  • Output: Verifiable data encoded in the proof schema as an element in the recipePayload bytes array.

2. Implement the Recipe

• Integrate with at least one third-party data provider (e.g., Strava API) to retrieve location data.
• Implement a zkTLS process to validate and selectively disclose location data without revealing sensitive information.
• Create the logic to generate a location proof using the extracted and verified data.
• (Ideally) implement a smart contract function to verify location proofs with this recipe data attached (onchain verification).

3. Documentation

• Provide a detailed walkthrough in the repository:
  • Explain the strategy and how it works (inputs, outputs, logic).
  • Include setup instructions for testing or integrating this recipe.
  • Example proof data for developers to reference.
  • This should be submitted as a pull request to this repo (astralprotocol), in a directory here. See this for an example, untested(!) recipe. (This is far from defined, we want help refining exactly how proof recipes are documented.)

4. Testing

• Write unit tests for the recipe, covering:
  • Successful proof creation and validation.
  • Edge cases (e.g., incomplete data, tampered data).
  • Performance under typical and high-load conditions.
• Provide a simple front-end demo or CLI example for local testing.

5. Encourage Developer Creativity

• While the base implementation uses zkTLS with a provider like Strava, you can propose alternative approaches or integrations with other services.

Acceptance Criteria

• A description of the recipe, data collected, how it's created, plus code for creating and verifying proofs using a third-party provider strategy with zkTLS, submitted to this repository as a pull request.
• Comprehensive tests and documentation for creating and verifying location proofs using this strategy.

Tasks

• Design and define the strategy, including key interactions and schema mappings.
• Integrate with at least one third-party provider API (e.g., Strava, Google).
• Implement the zkTLS process to validate data without exposing unnecessary details.
• Implement the recipe creation + validation scripts (preferably in Typescript or Python, plus optionally a verification function in Solidity).
• Write unit tests to validate the recipe’s functionality.
• Add documentation with clear examples for using the recipe.
• Create a simple demo (e.g., CLI or web-based) to showcase the strategy.
• Submit for peer review and incorporate feedback.

---

If you have questions or ideas for alternative approaches, feel free to comment or raise a related issue in the repository.