Sense Verificació de Trucada a Casa: Per Què el Futur Permís Internacional de Conduir Digital No Ha de Contactar l'Emissor en Cada Ús

La revocació és el problema més difícil en qualsevol futur Permís Internacional de Conduir (PIC) digital. La manera més fàcil de resoldre-ho és també la més perillosa: fer de l’emissor un participant en cada presentació. Una credencial de conducció transfronterera moderna hauria de rebutjar aquesta drecera per defecte.

Gairebé totes les propostes d’identitat digital contenen la mateixa frase tranquil·litzadora:

“La credencial es pot verificar instantàniament.”

De vegades aquesta frase descriu un progrés genuí. De vegades descriu vigilància amb una interfície d’usuari més amigable.

Els estàndards publicats avui ja deixen clar que un verificador no necessita contactar l’emissor cada vegada que es presenta una credencial:

• L’arquitectura mDL actual del NIST estableix que un verificador pot validar l’autenticitat i la integritat confiant en la signatura i les claus públiques de l’emissor, sense cap contacte directe amb l’emissor.
• AAMVA confirma que la norma ISO/IEC 18013-5 requereix suport per a la recuperació des del dispositiu i només opcionalment permet la recuperació des del servidor.
• AAMVA també adverteix que, en la recuperació des del servidor, l’autoritat emissora participa en temps real en cada ús — la qual cosa significa que tècnicament pot registrar quan s’utilitza la credencial, quines dades es comparteixen, i fins i tot inferir la ubicació a partir de l’anàlisi de l’adreça IP.

Això no és una nota al peu menor. És la pregunta central de disseny per a la pròxima generació de credencials de conducció transfrontereres.

La Drecera Perillosa: Col·lapsar Quatre Preguntes en Una Sola Trucada de Xarxa

Les arquitectures deficients agrupen quatre preguntes molt diferents en una sola trucada en viu a l’emissor:

1. Aquesta credencial és autèntica?
2. La persona que la presenta és el titular legítim?
3. La credencial en si mateixa continua sent vàlida?
4. El dret nacional de conduir subjacent continua vigent?

Un sistema mal dissenyat respon les quatre trucant a casa en temps real. Un sistema ben dissenyat les separa — perquè no són el mateix problema i no haurien de compartir un mecanisme.

L’Autenticitat S’Ha de Verificar Localment, No a Través de la Xarxa

Una credencial pot ser criptogràficament genuïna sense que l’emissor observi mai la transacció.

• El model de confiança mDL del NIST indica que l’autenticitat i la integritat es validen a partir de la signatura i les claus públiques de l’emissor — sense necessitat de contacte en viu amb l’emissor.
• El Servei de Confiança Digital d’AAMVA existeix precisament per donar als verificadors accés a les claus públiques vàlides de l’emissor sense devolucions de trucada per transacció.

Principi de Disseny 1: No utilitzeu connectivitat en viu per resoldre un problema que les signatures ja resolen.

Si un verificador disposa de claus d’emissor de confiança i rep una presentació conforme als estàndards, l’autenticitat és una verificació criptogràfica local, no una dependència de xarxa.

La Vinculació del Titular S’Ha de Demostrar Localment, No Notificar Globalment

La segona pregunta — és aquest el titular legítim? — també té una resposta sense xarxa.

L’arquitectura EUDI actual imposa la vinculació al dispositiu per als PIDs i les atestacions ISO/IEC 18013-5. El verificador demana a la cartera que signi un repte nou amb la clau privada que correspon a la clau pública incorporada a la credencial:

• A la norma ISO/IEC 18013-5, això s’anomena autenticació mdoc.
• A SD-JWT VC s’anomena vinculació de clau.

En ambdós casos, la possessió es demostra localment i criptogràficament. Cap dada personal no necessita arribar mai a l’emissor.

Principi de Disseny 2: Demostreu la possessió localment. No demostreu la identitat globalment.

Un futur PIC hauria d’exhaurir la vinculació al dispositiu, l’autenticació local del titular i el desafiament-resposta del verificador abans de considerar qualsevol mecanisme del costat de l’emissor.

L’Estat de la Credencial i l’Estat del Dret de Conduir Són Dues Coses Diferents

Molts dissenys d’identitat digital difuminen aquesta distinció, i és aquí on s’equivoquen.

L’especificació Bitstring Status List del W3C ho deixa clar: la informació d’estat adjunta a una credencial verificable s’aplica a la credencial verificable en si mateixa — no necessàriament al dret real del món real subjacent. Una credencial digital podria ser revocada perquè el seu mecanisme de signatura estava compromès, mentre que el dret de conduir subjacent continua sent perfectament vàlid.

Un futur PIC necessita, per tant, dues capes d’estat diferenciades:

• Capa d’estat de la credencial — per a la credencial digital o el canal de presentació en si.
• Capa del dret de conduir — per al dret nacional subjacent a conduir.

De vegades canvien juntes. Sovint no ho fan. Un sistema que les confon reaccionarà de manera excessiva, exposarà més dades de les necessàries, o totes dues coses.

El Compromís de la Cartera Ha de Propagar-se a Través de l’Estat — No Activar Devolucions de Trucada al Verificador

Un futur PIC també necessita una resposta clara per al que passa quan una cartera es veu compromesa.

L’arquitectura EUDI en proporciona una:

• El proveïdor de cartera emet Atestacions d’Unitat de Cartera que contenen informació de revocació.
• La integritat de la cartera es reverifica periòdicament; si una cartera ja no és segura, la seva atestació es revoca.
• Els proveïdors de PID han de comprovar regularment si la cartera ha estat revocada. Si és així, revoquen el PID.
• En verificar l’estat del PID, la part que depèn implícitament verifica l’estat de la cartera.

Aquesta és l’estratificació que hauria d’adoptar un futur PIC. No demaneu a cada verificador que comprovi independentment el proveïdor de cartera. Deixeu que el compromís de la cartera es propagui a través del canal de estat de credencial existent, i deixeu que els verificadors consultin aquest únic canal que preserva la privacitat.

Tres Patrons de Revocació Viables (Sense Necessitat de Devolucions de Trucada)

EUDI requereix que els proveïdors utilitzin un dels tres mètodes de revocació:

• Atestacions de curta durada — vàlides durant 24 hores o menys, de manera que la revocació esdevé innecessària.
• Llista d’estat d’atestació — una llista publicada que els verificadors poden consultar.
• Llista de revocació d’atestació — una llista explícita de credencials revocades.

Per a les atestacions vàlides durant més de 24 hores, EUDI requereix incorporar informació de revocació que inclogui:

• Una URL on les parts que depenen puguin obtenir la llista d’estat.
• Un identificador que localitzi la credencial dins d’aquesta llista.

Si la informació de revocació fiable no està disponible — per exemple, quan la part que depèn està fora de línia — EUDI dirigeix la part que depèn a realitzar una anàlisi de riscos abans d’acceptar o rebutjar la credencial.

La conclusió: la revocació no és un mecanisme únic, i certament no és una justificació per a les devolucions de trucada obligatòries a l’emissor.

De Curta Durada per Defecte, de Llarga Durada Només On Sigui Necessari

Una de les mesures de privacitat més eficaces de tota la pila és també la més senzilla: manteniu el que es presenta de curta durada.

• EUDI estableix que les atestacions vàlides durant 24 hores o menys no requereixen infraestructura de revocació — caduquen abans que la revocació sigui rellevant.
• El W3C estableix que les presentacions verificables solen ser de curta durada i no estan dissenyades per a l’emmagatzematge a llarg termini.
• El NIST adverteix explícitament contra la transmissió repetida d’identificadors reutilitzables per a l’ús quotidià. L’autenticació diària hauria de recolzar-se en tecnologies construïdes per a aquest propòsit, com les passkeys, no en la presentació repetida d’una credencial rica en identitat.
• El NIST també va triar l’autenticació local al dispositiu per sobre de la coincidència biomètrica al servidor específicament perquè l’autenticació local preserva la privacitat i és operativament més eficient.

Principi de Disseny 3: La credencial base pot tenir un període de validesa mitjà, però la presentació en si ha de ser de curta durada, específica del verificador i no reutilitzable.

Les Llistes d’Estat Són el Mecanisme Predeterminat Correcte

Quan no podeu fer-ho tot de curta durada, necessiteu infraestructura d’estat — i la llista d’estat és la predeterminada correcta.

La Bitstring Status List v1.0 del W3C descriu un mecanisme que preserva la privacitat, és eficient en espai i d’alt rendiment per publicar dades d’estat com ara la suspensió o la revocació. Les propietats clau inclouen:

• Cada emissor gestiona una llista per a les credencials que ha emès.
• El format es comprimeix bé, ja que la majoria de credencials romanen sense revocar.
• La mida de llista predeterminada és de 131.072 entrades, que el W3C indica que proporciona una privacitat de grup adequada en el cas mitjà.
• Es poden utilitzar llistes més grans on es necessiti una privacitat de grup més forta.

Això desplaça la pregunta de:

“Puc preguntar a l’emissor sobre aquest usuari ara mateix?”

a:

“Ja tinc una llista d’estat que preserva la privacitat prou recent per decidir localment?”

Aquesta és una pregunta molt millor — tant tècnicament com políticament.

“Sense Trucada a Casa” És un Patró de Descàrrega, No un Eslògan

La regla més important de la guia de privacitat d’EUDI és procedimental, no filosòfica.

Les parts que depenen no han de sol·licitar la llista d’estat cada vegada que es presenta una credencial. En comptes d’això, han de:

• Descarregar cada nova versió de la llista una vegada.
• Fer-ho en un moment i des d’una ubicació sense relació amb cap presentació d’usuari.
• Distribuir la llista internament dins de l’organització de la part que depèn.
• Obtenir la llista sense autenticar la part que depèn.

Aquest és el nucli operatiu de la verificació sense trucada a casa: actualitzeu l’estat separadament de les presentacions d’usuari — mai per persona, mai per transacció.

Aquesta única elecció de disseny evita que l’emissor o el proveïdor d’estat sàpiga quin verificador va comprovar quina credencial en quin moment.

Privacitat de Grup: El Requisit que la Majoria dels Dissenys Oblida

Molts sistemes fan publicitat de la divulgació selectiva dins de la presentació mateixa, i llavors ignoren silenciosament la privacitat de les consultes d’estat. Aquesta és una bretxa important.

Els requisits de privacitat d’EUDI especifiquen que:

• Els índexs de les llistes d’estat han d’estar assignats aleatòriament, de manera que l’índex en si mai no es converteixi en un senyal de seguiment.
• Cada llista ha de cobrir un nombre suficientment gran de credencials per garantir la privacitat de grup.
• Si una llista fos massa petita, els proveïdors haurien d’afegir entrades no usades per dissimular el nombre real de credencials.

Un futur PIC no pot pretendre preservar la privacitat únicament en virtut de la divulgació selectiva. Si el mecanisme de revocació filtra l’esdeveniment de presentació, el disseny de privacitat és incomplet.

El Funcionament Fora de Línia No és un Cas Excepcional — És un Requisit Bàsic

Tot sistema de viatges que assumeixi una connectivitat perfecta està mal dissenyat.

• AAMVA confirma que la recuperació des del dispositiu funciona sense connectivitat exterior tant per al dispositiu del titular com per al lector, i que la norma ISO/IEC 18013-5 requereix que els mDL admetin la recuperació des del dispositiu.
• EUDI accepta que les parts que depenen poden estar fora de línia i no disposar d’una llista d’estat en memòria cau; en aquest cas, recomana una anàlisi de riscos abans de decidir.

Accepteu aquest compromís aviat:

No podeu tenir un funcionament fora de línia perfecte i una frescor en temps real perfecta al mateix temps.

Qualsevol arquitectura que prometi totes dues coses sense compromís o bé és imprecisa o bé reintrodueix silenciosament la vigilància. La resposta correcta és fer de la frescor una entrada de política, no una dependència de xarxa universal.

Els Registres Són On la Privacitat Falla Silenciosament

Fins i tot una excel·lent arquitectura d’estat pot ser desfeta per un registre descurat.

• EUDI requereix que les instàncies de la part que depèn descartin els elements únics i les marques de temps tan aviat com ja no siguin necessaris, i en prohibeix el reenviament.
• AAMVA prohibeix als interessats fer el seguiment dels titulars de mDL o de l’ús de mDL excepte quan ho requereixi la llei, requereix que les autoritats emissores minimitzin la compartició de metadades estàtiques o de llarga durada, i restringeix l’accés als registres d’activitat al titular.
• AAMVA també requereix que l’eliminació al dispositiu elimini la informació de registre i les metadades que podrien revelar l’historial d’ús — i que aquesta eliminació sigui possible fora de línia.

Això és comportament de protocol, no gestió administrativa. Un futur PIC ha de tractar els identificadors de llarga durada, les marques de temps i els registres com a eines potencials de seguiment llevat que es demostri explícitament el contrari.

Una Arquitectura Concreta Sense Trucada a Casa per al Futur PIC

Reunint els principis, aquí teniu el que hauria de fer el sistema en realitat:

1. Emetre una credencial base vinculada al dispositiu. Vinculeu la credencial a claus protegides a l’entorn segur de la cartera — obligatori sota EUDI per als PIDs i les atestacions ISO/IEC 18013-5.
2. Sol·liciteu només el que és necessari, amb un repte nou. En una transacció OpenID4VP, una consulta DCQL permet a la cartera mostrar al titular quins atributs s’estan sol·licitant, i el verificador emet un repte per evitar la reproducció (per l’arquitectura mDL actual del NIST).
3. Genereu una presentació de curta durada, no un identificador reutilitzable. Cada presentació ha de ser específica del verificador, de la sol·licitud i del moment.
4. Verifiqueu l’autenticitat localment. Valideu les signatures de l’emissor i les claus públiques fora de línia; el servei de confiança d’AAMVA està construït exactament per a això.
5. Comproveu l’estat a partir de llistes en memòria cau actualitzades per separat. On les credencials siguin massa de llarga durada per ometre la revocació, useu llistes d’estat en memòria cau local actualitzades en un calendari sense relació amb les presentacions d’usuari.
6. Apliqueu una política de riscos quan la frescor no estigui disponible. Feu que les decisions fora de línia siguin una política explícita del verificador, no una especulació no estructurada.
7. Elimineu les dades de seguiment de manera agressiva. Descarteu els elements únics de transacció i les marques de temps quan ja no siguin necessaris; no conserveu registres que puguin reconstruir l’historial de moviments.

Així és com sembla una arquitectura seriosa sense trucada a casa — estratificada, que preserva la privacitat, criptogràficament local i operativament honesta sobre la realitat fora de línia.

Tres Patrons que Haurien d’Estar Prohibits pel Disseny

Un ecosistema madur de futur PIC hauria de tractar aquests com a fallades arquitectòniques, no com a opcions d’optimització:

• Devolucions de trucada obligatòries a l’emissor en cada presentació. La pròpia guia de privacitat d’AAMVA explica per què això és perjudicial.
• Usar la credencial de conducció com a inici de sessió rutinari. El NIST adverteix explícitament contra la presentació repetida de credencials que contenen identitat per a l’autenticació diària.
• Retenir identificadors, marques de temps i registres que puguin reconstruir l’historial de presentació. Tant EUDI com AAMVA requereixen el contrari.

L’Argument Central en Una Frase

La verificació instantània no ha de convertir-se en un permís per a la vigilància del costat de l’emissor.

Un futur PIC hauria de poder:

• Demostrar l’autenticitat localment.
• Demostrar la possessió localment.
• Comprovar la frescor de manera privada.
• Tolerar la realitat fora de línia.
• Funcionar amb gràcia quan la informació perfecta no estigui disponible.

Res d’això fa el sistema més feble. El fa digne de ser desplegat a escala.

En el moment en què una credencial de conducció es converteix en una eina per registrar qui va mostrar què, on i quan, deixa de ser una versió més segura del paper. Es converteix en infraestructura d’observació.

Això és exactament el que el futur PIC hauria de negar-se a ser.

Preguntes Freqüents

Què és la “verificació de trucada a casa”?
És qualsevol disseny en el qual un verificador contacta l’emissor en temps real per validar una credencial. Tot i que resol simultàniament l’autenticitat i la revocació, també permet a l’emissor observar cada esdeveniment de presentació.

La norma ISO/IEC 18013-5 requereix contacte en línia amb l’emissor?
No. AAMVA confirma que la norma ISO/IEC 18013-5 requereix suport per a la recuperació des del dispositiu i només permet opcionalment la recuperació des del servidor.

Com pot funcionar la revocació sense contactar l’emissor?
Mitjançant credencials de curta durada, llistes d’estat d’atestació o llistes de revocació d’atestació — idealment amb la part que depèn descarregant les dades d’estat separadament de les presentacions d’usuari.

Per què és important la “privacitat de grup” per a les llistes d’estat?
Si una llista d’estat és massa petita o els seus índexs són predictibles, una sol·licitud d’estat pot revelar quina credencial específica s’acaba de presentar. Els índexs aleatoris i les llistes grans ho eviten.

La verificació fora de línia és realment pràctica?
Sí — i els organismes de normalització, inclosos AAMVA i EUDI, ho requereixen explícitament. El compromís és que la frescor perfecta en temps real és incompatible amb el funcionament fora de línia perfecte, de manera que la frescor ha de convertir-se en una decisió de política, no en una dependència estricta.