Feature Overview

The goal is to establish a proof-of-humanity mechanism that ties a unique identity to a node, using cryptographic signatures, physical interaction, and decentralized validation.

• Purpose: Establishes a unique identity tied to a node using cryptographic signatures, physical interaction, and decentralized validation, enhanced for institutional security and compliance.
• Key Components:
  1. Generation:
     • Combines MAC address and wallet signature to create an identity_key.
     • Incorporates multi-factor authentication (MFA) with QR scan and biometric input (e.g., FaceID/TouchID).
     • Signs with HSM/Ledger hardware keys via the /sign-transaction endpoint.
     • Stores PoA on IPFS with a CID for offline resilience.
  2. Logging on OTR Chain:
     • Processed by the OTR network using a custom ABCIApplication class.
     • Broadcasts validated PoA via otrnet.broadcast_tx_sync for consensus.
     • Includes institutional validation against a MAC whitelist and signature checks.
  3. Consensus Validation:
     • Other OTR nodes (including institutional validators) verify PoA using local MAC whitelists and signature validation.
     • Requires MFA level ≥ 2 for institutional acceptance.
  4. IPFS Logging with Audit Trails:
     • Stores PoA with audit metadata (e.g., institution, compliance ID).
     • Locally caches audit logs for compliance.
• Endpoints:
  • POST /prove-humanity: Generates and logs PoA with MFA and hardware signing.
  • POST /revoke-identity: Revokes an identity from audit logs.
  • GET /audit-log/:identityKey: Retrieves audit data for compliance.
• Institutional Enhancements:
  • Security: Encrypts PoA data with AES-256, uses HSM/Ledger for key management, and enforces MAC whitelisting.
  • Scalability: Employs a hierarchical validation model to reduce LoRa traffic, with IPFS caching.
  • Compliance: Supports GDPR/KYC with revocable identities and auditable logs.
  • Integration: Extends to printer nodes, requiring PoA for job submission via /printer/job/send.

This PoA feature supports secure, scalable, and compliant identity verification for institutional use, building on the OTR network’s MAC-authenticated mesh.

Steps to Implement

1. Generate PoA with Node Identity:
   • Use the MAC address and wallet signature, as before, to create a PoA.
   • Example in App.js: javascriptCollapseWrapRunCopyconst proveHumanity = async () => { const wallet = await edgeCore.createWallet('ethereum', { network: 'base' }); const macAddress = await getMacAddress(); // Native method const identityKey = `${macAddress}-${wallet.address}`; const qrCode = generateQRCode(identityKey); Alert.alert('Scan QR', 'Scan the QR code to prove you’re human.'); const confirmation = await detectPhysicalInput(); // Native QR/button detection const poa = { type: 'poa', identity_key: identityKey, timestamp: Math.floor(Date.now() / 1000), confirmation: confirmation, signature: await wallet.signMessage(identityKey + confirmation), }; return poa; };
2. Log PoA on the OTR Chain:
   • POA is processed by otrnet for consensus.import json from otr_custom import otrnet # Custom OTR chain implementation class ABCIApplication: def __init__(self): self.otrnet = otrnet('http://localhost:26657') # OTR node endpoint def deliver_tx(self, tx): payload = json.loads(tx.decode('utf-8')) if payload.get('type') == 'poa': # Validate PoA (e.g., signature, MAC whitelist) if self.validate_poa(payload): self.otrnet.broadcast_tx_sync(tx) # Broadcast for consensus return {'code': 0, 'log': 'PoA logged on OTR chain'} return {'code': 1, 'log': 'Invalid PoA'} return super().deliver_tx(tx) def validate_poa(self, poa): # Placeholder validation logic mac = poa['identity_key'].split('-')[0] signature = poa['signature'] # Check MAC whitelist and signature (implement actual verification) return True # Replace with real validation
3. Consensus Validation by Other Nodes:
   • Other OTR nodes, running instances , will receive the broadcasted PoA via otrnet.broadcast_tx_sync.
   • Each node validates the PoA against its local MAC whitelist and signature verification, contributing to consensus.
4. Optional IPFS Logging:
   • For offline resilience, stores the PoA in IPFS,

Considerations

• Security: Encrypt PoA data to prevent spoofing.
• Scalability: Limit validation requests to trusted peers to reduce traffic.
• Legal: Ensure compliance with identity laws if deployed widely.