-
OpenAC consisteix en proves criptogràfiques que demostren la informació sense revelar dades sensibles.
-
Utilitzant proves de coneixement zero (ZK), va demostrar temps de verificació de “0,129 segons”.
PSE, l’equip de la Fundació Ethereum (EF) que desenvolupa eines centrades en la privadesa, va presentar OpenAC, un disseny criptogràfic de codi obert per emetre proves que representen credencials digitals “anònimes, transparents i lleugeres”.
El sistema, compartit a X el 29 de novembre, ja està operatiu perquè els desenvolupadors ho implementin en els seus projectes.
OpenAC és una proposta de documents digitals que certifiquen condicions o permisos de l’usuari (com ser major d’edat), però que es poden presentar mitjançant proves criptogràfiques que no revelen dades personals.
A més, ho aconseguiria sense deixar rastres que permetin seguir les accions dels usuaris.
L’equip del PSE va destacar el següent sobre OpenAC a l’anunci:
OpenAC descriu una construcció d’identitat basada en proves de coneixement zero (ZK) dissenyada per funcionar amb les piles d’identitats existents i construïda deliberadament per ser compatible amb el marc de referència i l’arquitectura d’identitat digital europea (EUDI ARF).
Equip del PSE a X.
Això vol dir que OpenAC està dissenyat per integrar-se amb sistemes d’identitat ja desplegats, tant públics com privats.
Un disseny dissenyat per integrar-se amb les identitats existents
El seu llibre blanc explica que OpenAC utilitza proves de coneixement zero (ZK, proves de coneixement zero), un mètode criptogràfic que permet demostrar que un atribut és vàlid sense revelar les dades originals que ho demostren.
En el context de la identitat digital, això ho permet un usuari mostra una credencial sense exposar tot el document o permetre que un tercer faci el seguiment del teu historial d’ús.
El funcionament d’OpenAC s’organitza en tres rols que intervenen en el cicle d’emissió i ús d’una credencial:
- Emissor: l’entitat que crea i signa la credencial: pot ser una empresa, una agència estatal, una universitat o qualsevol institució que tingui autoritat per certificar dades.
- Usuari: desa aquesta credencial i produeix la prova ZK quan se sol·licita.
- Checker: aplicació o entitat que necessita confirmar que la prova és vàlida, però sense accedir al contingut real del document ni obtenir informació addicional sobre la identitat de l’usuari.
Perquè aquest esquema funcioni, l’emissor ha de gestionar de manera segura les seves claus criptogràfiques i signar només els atributs correctes.
OpenAC part d’això hipòtesi de confiança inicial– Si l’emissor certifica informació falsa o si la seva clau privada està compromesa, totes les credencials que va emetre no seran vàlides.
El document també aclareix que OpenAC no incorpora el seu propi mecanisme de revocació. Per tant, si un emissor necessita invalidar una credencial per error o caducitat, ha de dependre de sistemes externs.
Aquest requisit introdueix un punt de dependència en el model, ja que la gestió de la revocació està en mans d’un tercer.
Segons el PSE, aquestes eines han de ser llistes criptogràfiques que permeten verificar si una credencial encara és vàlida sense revelar la identitat del titular ni fer el seguiment de les seves activitats.
Possibles implicacions per a Ethereum
OpenAC posicionaria Ethereum com una plataforma adequada per gestionar identitats digitals sense sacrificar la privadesa, encara que el disseny requereix components fora de cadena i depèn d’emissors fiables.
La possibilitat d’emetre documents digitals que no es poden rastrejar i que funcionin amb estàndards internacionals podria obrir espai per a sol·licituds com ara expedients educatius, permisos administratius, certificacions professionals o accés a serveis que requereixen validació sense exposar la identitat.
Com impedeix OpenAC que es rastregi una credencial?
Perquè no es pugui enllaçar una credencial entre diferents usos, cada vegada que l’usuari la presenti ha de generar una prova completament diferent.
Si dues proves repeteixen algun valor, un verificador podria adonar-se que totes dues provenen de la mateixa persona, encara que no sàpiga qui és.
Per evitar aquest possible enllaç, OpenAC obliga l’usuari o l’aplicació que gestiona la credencial incorporar llavors aleatòries a cada presentació. Aquesta aleatorització garantiria que dues proves del mateix atribut semblin completament diferents.
Implementació i límits pràctics d’OpenAC
La generació de proves OpenAC es produeix fora de la cadena (fora de cadena).
Això vol dir tota la informàtica pesada (crear la prova criptogràfica que demostra un atribut sense revelar dades) es fa al dispositiu de l’usuari o en una aplicació externai no dins d’Ethereum.
Evitant executar aquest procés a la xarxa, es redueix el cost i s’evita la saturació de la cadena.
La verificació de la prova, en canvi, es pot fer qualsevol fora de la cadena com dins a contracte intel·ligent. És per això que PSE descriu aquestes credencials com a “lleugeres”: l’equip va informar d’un temps de verificació de “0,129 segons”, fent que el sistema sigui manejable per a aplicacions que requereixen respostes ràpides.
De totes maneres, el rendiment dependrà del maquinari. En dispositius amb menys capacitat o en escenaris molt carregats, els temps poden augmentar.
El disseny pretén minimitzar la informació que arriba a Ethereum, però OpenAC encara necessita components addicionals per funcionar en entorns reals.
Els emissors han de gestionar les claus, les carteres per admetre el format de credencials i els sistemes externs per gestionar mecanismes com ara la revocació.
Sense aquesta infraestructura, l’esquema no es pot desplegar a escala.
