Skip to main content
AIP defines protocol-level security invariants for message authenticity, integrity, and replay protection. AIP does not define how operators implement key management, storage models, or audit infrastructure. Operators may use different security architectures as long as protocol guarantees are met.

​
1. TL;DR

AIP requires that messages are authenticated and integrity-protected, with replay protection mechanisms. Operators implement their own cryptographic systems, key management, and verification logic to enforce these constraints.

​
2. Why it matters

In digital advertising, fraud and data tampering are common:
  • Fake clicks and impressions
  • Replay or duplicate requests
  • Manipulated billing data
AIP is designed to reduce these risks by requiring signature-based verification for every message in the protocol. Operators implement their own security systems to enforce these requirements.

​
3. Core security guarantees

The protocol defines the following security invariants:
GuaranteeDescription
AuthenticityMessages must be authenticated to verify their origin.
IntegrityMessages must be tamper-evident — data cannot be silently altered after signing.
Non-repudiationMessage authentication mechanisms must enable non-repudiation.
Replay protectionUnique nonces and timestamps must prevent reused requests within operator-defined validity windows.
ConfidentialityTransport must use encrypted channels (e.g., HTTPS or gRPC).
Operators implement their own cryptographic systems to enforce these guarantees.

​
4. Signature Model

Each message — from ContextRequest to EventPacket — must provide a verifiable signature or equivalent authentication mechanism.

​
Example signature approach

The following is an example of how messages may be signed. Operators may use different algorithms, header formats, or authentication mechanisms: 
X-AIP-Signature: HMAC(method + path + body + timestamp + nonce)
X-AIP-Version: 0.1

​
Verification steps (example)

  1. Receiver verifies the signature using the appropriate authentication mechanism.
  2. If verification succeeds, the message is considered authentic.
  3. If verification fails, the message is rejected.
Operators define their own signature algorithms, timestamp formats, and verification logic. The protocol only requires that messages are authenticated and integrity-protected.

​
5. Key Management

Participants manage keys according to their own security policies. Each participant (Platform, Operator, Brand Agent) must:
  • Maintain authentication credentials for signing outgoing messages
  • Verify signatures on incoming messages
  • Implement key rotation and management according to their security requirements
Operators define their own key management policies, rotation schedules, and storage mechanisms.

​
6. Replay and Duplication Defense

AIP requires replay protection mechanisms. Operators implement their own nonce tracking and timestamp validation:
  • Nonces must be unique within operator-defined validity windows
  • Timestamps must be validated to prevent replay attacks
  • Duplicate requests must be detectable and rejectable
Operators define their own validity windows, nonce storage mechanisms, and rejection policies.

​
7. Secure Event Verification

Operators are the verification authority for all events. Each event (cpx_exposure, cpc_click, cpa_conversion) must be verified by the Operator using:
  • Authentication and integrity verification of the event message
  • Serve token validation
  • Timestamp checks within operator-defined windows
Platforms and Brand Agents may provide signals or data, but verification responsibility rests with the Operator. Operators implement their own verification logic and may use different approaches (e.g., hash validation, signature verification, or other integrity checks).

​
8. Audit and Compliance

Operators may expose security artifacts for audit or compliance purposes. The protocol does not mandate specific audit ledgers, compliance frameworks, or audit infrastructure. Operators implement their own audit and compliance systems according to their requirements.

​
9. Guarantees

The protocol guarantees:
  • Message authenticity: Messages cannot be silently altered without detection
  • Replay detection: Replayed messages can be detected within operator-defined validity windows
  • Message origin authentication: Message origin can be authenticated through operator-defined mechanisms
The protocol does not guarantee specific outcomes related to money, payouts, or ledger systems. Operators implement their own security systems to enforce these protocol-level guarantees.

​
Summary

AIP defines protocol-level security invariants that ensure messages are authenticated, tamper-evident, and protected against replay attacks. Operators implement their own cryptographic systems, key management, and verification logic to enforce these constraints.
Next: Compliance