Registration & Lookup

# Registration & Lookup ## Registration Flow The process of creating an attestation mapping: ``` ┌──────┐ ┌────────┐ ┌──────┐ ┌──────────────┐ │ User │ │ Issuer │ │ ODIS │ │ Blockchain │ └───┬──┘ └───┬────┘ └───┬──┘ └──────┬───────┘ │ │ │ │ │ 1. Request Verification│ │ │ ├──────────────────────>│ │ │ │ │ │ │ │ 2. Verify Ownership │ │ │ │ (SMS, OAuth, etc.) │ │ │ │<─────────────────────>│ │ │ │ │ │ │ │ │ 3. Query for Pepper │ │ │ ├──────────────────────>│ │ │ │ │ │ │ │ 4. Return Pepper │ │ │ │<──────────────────────┤ │ │ │ │ │ │ │ 5. Register Attestation │ │ ├───────────────────────────────────────────────>│ │ │ │ │ │ │ 6. Attestation Registered │ │ │<───────────────────────────────────────────────┤ │ │ │ │ │ 7. Confirmation │ │ │ │<──────────────────────┤ │ │ ``` **Detailed Steps:** 1. **User Requests Verification** * User provides their identifier and wallet address to an issuer * User indicates they want to create an attestation 2. **Issuer Verifies Ownership** * Phone: Send SMS with verification code * Twitter: OAuth flow * Email: Verification link * Custom: Any verification method the issuer chooses 3. **Issuer Queries ODIS** * Issuer sends blinded identifier to ODIS * Consumes issuer's ODIS quota * Receives pepper for obfuscation 4. **Issuer Computes Obfuscated Identifier** * Combines hashed identifier with pepper * Creates the final obfuscated identifier 5. **Register Attestation On-Chain** * Issuer calls `registerAttestationAsIssuer` on the FederatedAttestations contract with the obfuscated identifier, the user's account address, and the verification timestamp 6. **Gas Payment Options** * **Issuer Pays:** Issuer executes transaction with their gas * **User Pays:** Issuer signs attestation, user submits transaction ## Lookup Flow The process of finding addresses from identifiers: ``` ┌─────────────┐ ┌──────┐ ┌──────────────┐ │ Application │ │ ODIS │ │ Blockchain │ └──────┬──────┘ └───┬──┘ └──────┬───────┘ │ │ │ │ 1. Query for Pepper │ │ ├────────────────────>│ │ │ │ │ │ 2. Return Pepper │ │ │<────────────────────┤ │ │ │ │ │ 3. Lookup Attestations │ ├─────────────────────────────────────────>│ │ │ │ │ 4. Return Addresses │ │ │<─────────────────────────────────────────┤ ``` **Detailed Steps:** 1. **Get Obfuscated Identifier:** query ODIS via `getObfuscatedIdentifier` 2. **Query FederatedAttestations Contract:** call `lookupAttestations` with the obfuscated identifier and the list of trusted issuers 3. **Process Results:** the contract returns the number of attestations per issuer (`countsPerIssuer`) plus the matching accounts, signers, and issued/published timestamps Working code for both flows is in [SDK Integration with Viem](/docs/self-connect/sdk-integration/). ## Multi-Issuer Lookup `lookupAttestations` accepts multiple trusted issuers in a single call. The returned arrays are ordered by the input issuer list: `countsPerIssuer[i]` tells you how many of the returned accounts belong to `trustedIssuers[i]`. ## Trust Model Applications must decide which issuers to trust: **Single Issuer Trust:** * Trust only attestations from your own issuer * Maximum control over verification quality * Limited to your own user base **Multiple Issuer Trust:** * Trust attestations from multiple issuers * Broader coverage and interoperability * Must evaluate each issuer's verification quality **Consensus-Based Trust:** * Require attestations from multiple issuers * Higher confidence in verification * Reduced coverage (fewer users will have multiple attestations)