Guadagna i badge di verifica GitHub e dominio.
La verifica avviene nella dashboard, non attraverso l'SDK. Completa la prova - un handshake OAuth di GitHub o un record DNS TXT - e il badge appare sul profilo pubblico dell'agente. I badge vengono ricontrollati periodicamente. Le controparti passano il mouse sul badge per vedere chi ha verificato cosa e quando, che è il segnale di fiducia che i pagatori seri cercano.
Prima di iniziare.
- Un agente esistente e accesso al dashboard per il suo spazio di lavoro (vedi la guida-add-payments-to-agent).
- Per il badge di GitHub: possibilità di autorizzare l'app Blockchain0x sull'organizzazione o sull'utente GitHub che l'agente rappresenta.
- Per il badge di dominio: controllo su DNS per il dominio principale che desideri verificare (o qualunque host il tuo fornitore DNS supporti per i record TXT).
- 10 minuti di orologio per la verifica DNS (la maggior parte si propaga in meno di un minuto, ma consenti fino a 10).
- Familiarità con il concetto di identità di pagamento dell'agente - i badge sono uno dei suoi strati.
Verifica con GitHub.
Il badge di GitHub prova che l'agente è associato a un utente o a un'organizzazione GitHub specifica. Nella scheda Verifica dell'agente nel dashboard, fai clic su Verifica con GitHub. Verrai reindirizzato alla schermata di consenso OAuth standard di GitHub, dove l'umano che possiede quell'identità concede accesso in lettura alle informazioni del profilo pubblico. Non esiste una chiamata SDK - questo è un flusso del dashboard con un clic.
Richiediamo solo accesso in lettura al profilo pubblico (nome utente, età dell'account, artefatti pubblici) - nessun accesso in scrittura, nessun repository privato. Una volta che la concessione è attiva, il badge appare sulla pagina pubblica dell'agente entro un minuto o due, mostrando il manico verificato.
Verifica un dominio.
Il badge di dominio prova il controllo su un dominio DNS registrato - il segnale più forte che una controparte può leggere. Nella scheda Verifica, scegli Dominio e inserisci il tuo dominio principale o sottodominio. Il dashboard mostra un token unico da pubblicare come record TXT. Aggiungilo presso il tuo provider DNS, quindi clicca su Verifica; interroghiamo il DNS e cambiamo il badge una volta che il token corrisponde.
Pubblica il token che il dashboard mostra come record TXT:
# The dashboard shows the exact host and token to publish.
# Most providers use a subdomain host for the verification record.
Type: TXT
Name: _blockchain0x.yourcompany.com
Value: <the token shown in the dashboard>
TTL: 300 (5 minutes is fine)Conferma che il badge è attivo.
Il dashboard mostra lo stato di ogni badge. GitHub di solito passa a verificato entro un minuto dalla concessione di OAuth; il dominio dipende dalla propagazione DNS ma di solito si completa in circa 10 minuti. Non c'è nulla da interrogare dal tuo codice - è uno stato del dashboard.
Once verified, the agent's public page (wallet.blockchain0x.com/a/<slug>) shows the badge alongside the agent's other identity claims. Hovering the badge reveals which method earned it and when. That hover popover is what counterparties read before approving a payment or allowlisting your wallet.
Quattro errori che ritardano o interrompono la verifica.
Verifica l'identità GitHub sbagliata
Se utilizzi il tuo account GitHub personale per la stretta di mano OAuth ma l'agente rappresenta un'organizzazione, il badge dirà 'verificato da @yourhandle' piuttosto che 'verificato da yourcompany'. Le controparti che si aspettano l'organizzazione guarderanno con scetticismo al badge dell'handle personale. Usa un account GitHub che corrisponda all'identità dichiarata dell'agente e preferisci la verifica a livello di organizzazione rispetto a quella a livello utente quando possibile.
Record TXT DNS pubblicati sull'host sbagliato
Alcuni host DNS accettano il record TXT all'apice (solo '@'), altri richiedono un sottodominio (tipicamente '_blockchain0x'). Se la tua verifica rimane in 'in attesa' dopo 30 minuti, il record è quasi sempre nella posizione sbagliata. La risposta del flusso include sia la posizione attesa che il valore atteso - controlla entrambi e verifica esternamente con 'dig TXT yourdomain.com' prima di assumere che l'API sia in difetto.
Dimenticare che la verifica scade
I badge di verifica vengono ricontrollati periodicamente. Se il tuo record DNS TXT viene rimosso durante una migrazione dell'host, o se rimuovi la concessione OAuth dell'agente su GitHub, il prossimo ricontrollo fallisce e il badge viene rimosso automaticamente. Le controparti se ne accorgono. Mantieni gli artefatti di verifica in posizione come parte della tua infrastruttura permanente e tratta la loro rimozione accidentale come un'interruzione.
Mostrare il badge ma non costruire fiducia attorno ad esso
I badge sono necessari ma non sufficienti. Una controparte che guarda la pagina pubblica del tuo agente peserà il badge insieme alla cronologia delle transazioni recenti, ai modelli di motivazione al pagamento dell'agente e a qualsiasi prova sociale nel tuo prodotto più ampio. Tratta il badge come la base - guadagnarlo ti rende idoneo per controparti serie, ma non fa di per sé in modo che ti fidino di te. Costruisci il resto dei segnali di fiducia attorno ad esso.
Dopo che i badge sono stati impostati.
Con l'identità verificata, completa la checklist di indurimento della produzione: una revisione della sicurezza del portafoglio stesso, controlli di spesa se l'agente effettua pagamenti e i modelli standard del webhook in modo che i pagamenti non sfuggano durante intoppi operativi.
Metti in sicurezza il tuo portafoglio agente prima di andare live
Imposta controlli di spesa per l'agente che sopravvivono all'iniezione di prompt
I modelli di webhook di cui i programmatori chiedono di più
Riferimento completo su docs.blockchain0x.com. Superficie di prodotto: Identità dell'agente.