Skip to content

docs(adr): add private access threat model and Stellar feasibility ADR - #21

Open
Tobiloba0 wants to merge 1 commit into
Stellar-AgentVerse:mainfrom
Tobiloba0:docs/adr-private-access-threat-model
Open

docs(adr): add private access threat model and Stellar feasibility ADR#21
Tobiloba0 wants to merge 1 commit into
Stellar-AgentVerse:mainfrom
Tobiloba0:docs/adr-private-access-threat-model

Conversation

@Tobiloba0

Copy link
Copy Markdown

Closes #19
Adds a new Architectural Decision Record at 0001-private-access-threat-model.md
Defines private access goals and attacker capabilities for the current Soroban marketplace
Documents leakage vectors across arguments, auth entries, storage, events, token activity, metadata, and timing
Evaluates candidate approaches: encrypted off-chain delivery, opaque access records, relayers, and zero-knowledge proofs
Recommends delaying any private-access registry until this ADR is reviewed and approved
Includes anti-replay, key lifecycle, delivery, migration, and test evidence guidance

Closes #19

@Joaco2603 Joaco2603 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Buen trabajo cubriendo los adversarios y las alternativas pedidas en #19. Antes de aprobar necesito que ajustes el ADR:

  1. Aclará el límite de garantía del enfoque recomendado: mientras buy_prompt(buyer, prompt_id) y has_access(user, prompt_id) mantengan sus argumentos, storage y evento públicos, la entrega cifrada off-chain NO puede preservar una verificación de entitlement on-chain que oculte el vínculo buyer↔prompt. Esa frase de la recomendación debe reemplazarse por una limitación explícita; la unlinkability on-chain queda fuera de alcance hasta diseñar commitments/proofs.
  2. Convertí el ciclo de claves en un protocolo verificable: definí cómo se obtiene y autentica una clave pública de cifrado distinta de la clave de firma Stellar, quién puede ver plaintext y claves de contenido, y cómo re-encriptación/revocación/migración funcionan cuando se rota una clave. “wallet-controlled secrets” y “backend does not store plaintext long-term” hoy no fijan esa frontera de confianza.
  3. Agregá criterios de aceptación verificables para la opción recomendada (por ejemplo: campos/logs prohibidos, pruebas de replay y la evidencia concreta que debe aportar Backend #8).

Además, por favor agregá el label type:docs; el workflow actual no se dispara para cambios bajo docs/**, así que el ADR debe ser suficientemente preciso para una revisión manual.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ADR: private access threat model and Stellar feasibility

2 participants