autenticação e assinatura

Este documento define como criadores autenticam manifestos no protocolo Aevia e como verificadores os validam. A autenticação usa EIP-712 typed-data signing sobre o hash canônico do manifesto (RFC-1). A chave de assinatura é uma chave privada Ethereum secp256k1 operada pelo criador diretamente ou via Privy embedded wallet.

MUST, SHOULD, MAY seguem RFC 2119.

• curva: secp256k1 (mesma do Ethereum).
• formato de chave pública: endereço Ethereum EIP-55 (20 bytes, checksum casing).
• formato de assinatura: compacto 0x{r}{s}{v}, 65 bytes totais (32+32+1), com v ∈ {27, 28}.
• criadores MAY possuir a chave privada diretamente (software wallet, hardware wallet) ou delegar via Privy (§7).

O domínio EIP-712 da Aevia é fixo:

chainId MUST ser o chain ID da rede alvo (Base Sepolia = 84532, Base Mainnet = 8453). verifyingContract MUST ser o endereço do Content Registry deployado naquela chain.

O domain separator MUST ser incluído no digest EIP-712. Manifestos assinados com domínio errado MUST ser rejeitados.

O tipo primário assinado é Manifest:

• manifestHash = SHA-256 da canonical encoding do manifesto com campos cid e signature removidos (RFC-1 §5).
• creator = endereço do signer (MUST coincidir com manifest.creator).
• createdAt = timestamp Unix em segundos (MUST coincidir com parse de manifest.created_at).

Para produzir a assinatura, o criador:

1. computa manifestHash conforme RFC-1 §5;
2. constrói a struct Manifest (§4);
3. computa domainSeparator = hashStruct(EIP712Domain);
4. computa digest = keccak256(0x1901 || domainSeparator || hashStruct(Manifest));
5. assina com secp256k1: signature = sign(privateKey, digest).

A assinatura resultante MUST ser colocada no campo manifest.signature em forma hex-encoded com prefixo 0x.

Verificação é determinística e offline. Dado um manifesto M, um verificador MUST:

1. extrair M.signature;
2. computar manifestHash (RFC-1 §5);
3. reconstruir o digest EIP-712 (§5.4);
4. recuperar o signer: recovered = ecrecover(digest, M.signature);
5. verificar que recovered == M.creator;
6. (quando relevante) verificar que createdAt typed-data coincide com parse de M.created_at.

Qualquer mismatch MUST resultar em rejeição. Nenhum round-trip de rede é requerido.

Privy embedded wallet opera como custody-layer delegada: o usuário autentica via email/social login, Privy gera e custodia secp256k1 keys em MPC e expõe uma API de assinatura. Do ponto de vista do protocolo Aevia, a chave Privy é indistinguível de uma chave software local — o endereço resultante é registrado normalmente no Content Registry e a assinatura EIP-712 é válida pela §6.

Clientes que usam Privy MUST solicitar assinatura typed-data via signTypedData, não personal_sign. Clientes SHOULD mostrar ao usuário os campos typed-data antes da confirmação, para conformidade com boas práticas EIP-712.

• replay entre chains: domain separator inclui chainId e verifyingContract, impedindo reuso de assinaturas entre Base Sepolia e Mainnet.
• malleability secp256k1: verificadores MUST usar ECDSA com s-value baixo (EIP-2) para evitar assinaturas maleáveis equivalentes.
• key loss: perda de acesso à wallet significa perda de capacidade de assinar futuros manifestos. Manifestos prévios permanecem válidos pois a assinatura já está no Registry.
• Privy social recovery: Privy MAY rotacionar chaves via social recovery; cada rotação produz novo endereço, que MUST ser explicitamente reconhecido como identidade do mesmo criador via assinatura cruzada.