IA Attestation (Kind 35522)

A Kind 35522 (IA Attestation) is the cryptographic proof generated by an Identity Authority (IA) stating: "I have verified that Nostr Public Key X owns LIDP Account Y."

This event is generated by the IA server immediately upon completing a successful verification flow (like OAuth or OTP) and is published to the IA's own relays.

Event Structure

{
  "kind": 35522,
  "content": "{\"privacy\": \"public\"}",
  "tags": [
    ["d", "<identifier_hash>"],
    ["lidp", "<lidp_name>"],
    ["p", "<user_pubkey>"],
    ["expiration", "<unix_timestamp>"],
    ["evidence", "<nip44_encrypted_payload>"]
  ],
  "pubkey": "<ia_pubkey>",
  "created_at": 1709424020,
  "id": "...",
  "sig": "..."
}

Required Tags

Tag	Format	Description
d	["d", "<sh256_hash>"]	The ConnectionKey. Exactly matches the d tag in the user's Kind 35521.
lidp	["lidp", "<string>"]	The name of the Legacy Identity Provider.
p	["p", "<hex>"]	The target Nostr public key that proved ownership.
expiration	["expiration", "<int>"]	NIP-40 expiration timestamp. When the underlying OAuth token or OTP verification expires.
evidence	["evidence", "<string>"]	A NIP-44 string containing the verification payload.

The evidence Tag and Cryptographic Portability

The evidence tag allows for Evidence Sharing.

When an IA successfully verifies an OAuth Identity (e.g., Discord), it receives an Access Token. The IA constructs a JSON object containing this token and encrypts it using NIP-44 directed at the user's Nostr pubkey.

Because only the user holds the private key to decrypt this payload, the user now possesses cryptographic, portable proof of their OAuth session.

If the user wants to be attested by a different IA, they do not need to log into Discord again. They simply decrypt the evidence payload, re-encrypt it targeting the new IA's public key, and submit it. The new IA decrypts it, uses the token to query Discord's API independently, and if valid, issues its own Kind 35522.

Note: The evidence tag is only useful for OAuth-based LIDPs. OTP-based LIDPs (like Email and Phone) do not produce shareable access tokens.

Event Lifecycle

1. Creation: User verifies identity with the IA. IA signs Kind 35522.
2. Publishing: IA publishes the event to its designated relays.
3. Embedding: The IA returns the raw JSON to the user's client. The client embeds it in the s tag of their own Kind 35521 event.
4. Revocation: If a user disconnects their account, the IA publishes a Kind 5 (Event Deletion) targeting the Kind 35522 ID. This instantly invalidates the attestation during a Deep Check.