Threshold Access Control (TACo)
  • Getting Started
    • Introduction to TACo
    • How TACo Works
    • Quickstart (Testnet)
  • For Developers
    • Integrate TACo Into Apps
      • Testnets
      • Mainnet Access
      • Mainnet Deployment
    • Ecosystem Integrations
      • OrbisDB
      • Waku
      • Irys
      • ComposeDB
      • Turbo
    • API
      • Encryptor Allowlist
      • Encrypt & Decrypt
      • Authentication
        • Condition Context
      • Access Control
        • TimeCondition
        • RpcCondition
        • ContractCondition
          • Use custom contract calls
          • Implement access revocation via smart contract
        • JSON Endpoint Conditions
          • JsonApiCondition
          • JsonRpcCondition
        • JWT Conditions
        • Logical Conditions
          • CompoundCondition
          • IfThenElseCondition
          • SequentialCondition
        • WIP / Feature Requests
          • Any (Major) EVM Chain Condition Support
    • Blueprints & Inspiration
      • Seed phrase recovery & transfer
      • Digital Rights Management for on-chain assets
      • Trustless channels for journalists, archivists & whistleblowers
      • Crowdsourcing real-world data with trustless contribution
  • For Product Leads
    • Value Propositions
    • Capabilities & Extensions
    • Use cases
      • Seed phrase recovery & transfer
      • Digital Rights Management for on-chain assets
      • Trustless channels for journalists, archivists & whistleblowers
      • Crowdsourcing real-world data with trustless contribution
    • Mainnet Fees
    • Trust Assumptions
      • Mainnet Trust Disclosure (Provider Answers)
      • Mainnet Trust Model Foundation
      • Trust levers & parameter packages
  • Reference
    • Contract Addresses
    • Architecture
      • Porter
    • Github
    • TACo Playground
    • TACo Scan
  • For Node Operators
    • Getting Set Up
      • Minimum System Requirements
      • Run a TACo Node with Docker
    • Operations
      • TACo Node Management
      • TACo Node Recovery
      • Stake Authorization
    • Duties, Compensation & Penalties
    • Run a Porter Instance
Powered by GitBook
On this page
  • Authorization
  • Special Considerations
  1. For Developers
  2. API
  3. Access Control

JSON Endpoint Conditions

PreviousImplement access revocation via smart contractNextJsonApiCondition

Last updated 1 month ago

JSON conditions are useful when a data consumer's request for access is validated, in full or in part, based on data retrieved from an external HTTPS JSON endpoint ( or ) that returns data in JSON format. They can be leveraged to integrate external off-chain data into your access control policies, ensuring access decisions are based on dynamic, real-time data retrieved from JSON endpoints.

Authorization

Some JSON endpoints require bearer tokens to verify authorization. Because an authorization token is specific to the requester, the authorizationToken value must always be provided as a - a placeholder within conditions to be specified at encryption time, and whose value is provided at decryption time via the .

Where applicable, authorization tokens must be provided as context variables for the following reasons:

  • Security: Hardcoding the token would expose it in the plaintext condition associated with the encrypted data.

  • Flexibility: Hardcoding ties the token to a specific user rather than the requester.

  • Expiry: Tokens typically expire, so hard coding would lead to eventual invalidation.

For these reasons, only custom context variables are allowed for the optional authorizationToken property.

Special Considerations

  • Immutable Endpoint URLs: JSON conditions rely on hardcoded HTTPS endpoints as part of the condition definition. Once a condition is associated with a piece of ciphertext, the endpoint URL becomes fixed and cannot be modified. This immutability ensures the integrity of the condition but introduces challenges if the endpoint URL becomes unavailable, deprecated, or requires updates.

  • Dependency on External Systems: Since JSON conditions depend on external HTTPS endpoints, the availability and reliability of these endpoints directly impact the functionality of the condition. If the endpoint experiences downtime, latency issues, or is retired, access control decisions relying on it may fail.

  • Versioning and Compatibility: Endpoint URLs often correspond to specific API versions or specifications. If the endpoint provider introduces breaking changes, conditions that depend on the outdated version may no longer function correctly.

  • Security Risks: Hardcoding the endpoint URL makes the system reliant on the endpoint's continued security and trustworthiness. If the endpoint is compromised or ownership changes, the system could be exposed to potential risks.

The above may not be a concern for some situations, so it is important to evaluate your use case carefully.

API
RPC
Condition Context
user-defined custom context variable