Si l'OT requereix totes dues, es combinen en una sola prova, un únic gest al mòbil.
Mateix canal DIDCommja obert, cap QR nou per a l'operari
cred_def_id com a restricciórebutja atributs d'un emissor no autoritzat
06 · IMPLEMENTACIÓ · PRIVACITAT
El verificador no rep la credencial, rep una Verifiable Presentation
GENERANT VP
ATEX
Certificat ATEX
al wallet
VPProva de possessió d'una credencial vàlida (signatura CL + link secret, sense revelar-la)
zonaZona-1-Gasrevelat
nivell_atexII 2G Ex ia IIC T4revelat
data_expiracio≥ avui ✓predicat ZKP
id_certno viatjano sol·licitat
treballadorno viatjano sol·licitat
El valor de data_expiracio no surt mai: el verificador només rep la prova que la condició es compleix.
06 · IMPLEMENTACIÓ · REVOCACIÓ
✕
Sistema natiu d'AnonCredsRevRegs + tails files
El titular ha de descarregar un fitxer al mòbil
Depèn de connexió i alenteix el flux
La meva solució: Bitstring signada, servida per HTTP
OTEmissor OT
00100010
0 vàlida1 revocada
16.384 bits · GZIP · una per OT
status-list.json
signat Ed25519
GET · públic
VVerificador
Verifica la signatura amb la clau pública
Llegeix el bit de l'índex de l'OT
Bit 1 → DENEGAT
06 · IMPLEMENTACIÓ · PANELL
La cara visible: un QR d'accés, veredicte en temps real
CONTROL D'ACCÉS
✓ CONCEDIT✕ DENEGAT
QR d'invitació a la pantallaL'operari l'escaneja i s'obre la connexió DIDComm segura
Veredicte a la pantallaVerd si es concedeix, vermell si es denega
Un QR per intentEs regenera després de cada verificació o timeout: cada operari estrena invitació neta
07 · RESULTATS
Validació casos i rendiment
Cas
Resultat
OT vàlida sense riscos
CONCEDIT
OT + ATEX + Soldador
CONCEDIT
OT d'un altre dia
DENEGAT
Credencial revocada
DENEGAT
40–60s
flux complet, cas més exigent
BCovrin Testnet
Túnel Cloudflare
Codi + criptografia
El coll d'ampolla és l'entorn, no l'arquitectura. Amb una xarxa Indy pròpia es reduiria dràsticament.
08 · DEMO
Demo en viu
09 · CONCLUSIONS
Un cicle complet, tres propietats garantides
EmissióRecepció al walletVerificacióRevocació
IDENTITAT SOBIRANA
Les credencials viuen al mòbil; el verificador rep proves, no atributs en clar
AUTENTICITAT I INTEGRITAT
Signatura AnonCreds validada contra la CredDef; qualsevol alteració invalida la prova
REVOCACIÓ EN TEMPS REAL
El verificador comprova l'estat sense dependre de l'emissor. Validat en concessió i denegació
09 · CONCLUSIONS · LIMITACIONS
Decisions de prototip, no de l'arquitectura
01
Persistència de la status listExclosa del control de versions: un entorn nou arrenca amb la llista buida
02
Dependència de BCovrin TestnetXarxa pública sense garanties: punt de fallada únic de la demo
03
Sense multi-tenancyCada emissor és un procés independent amb el seu wallet i port
04
Directori d'operaris en JSONNo transaccional: emissions simultànies podrien causar condicions de cursa
Cap és una limitació de la SSI. Totes són simplificacions conscients amb un camí de solució clar.
09 · CONCLUSIONS · FUTUR
Dues vies: madurar el sistema i extrapolar l'arquitectura
Cap a producció
Xarxa Hyperledger Indy pròpia, gestionada per un consorci
Protegir la clau de signatura fora del disc
Status list en infraestructura dedicada i replicada
Directori d'operaris sobre base de dades transaccional
Cap a entorns digitals
Control d'accés a serveis regulats per edat
Majoria d'edat via ZKP, sense revelar la data
Sancions lligades a la identitat, no al compte
Anonimat davant el servei, complint el RGPD
FI
Una demostració rigorosa de viabilitat, no un producte de producció
Substituir una carpeta de papers que algú revisa a mà per una credencial digital que el treballador controla i que la porta verifica sola.
github.com/angeljoan1/TFG-SSI
Gràcies. Quedo a la vostra disposició.
Q&A · BACKUP A
AnonCreds vs JWT / SAML
Criteri
JWT / SAML
AnonCreds
Revelació selectiva
NO
SÍ
Proves ZKP (predicats)
NO
SÍ
Clau pública
SERVIDOR
LEDGER
Revocació interoperable
FEBLE
STATUS LIST
Correlació entre verificadors
ALTA
BAIXA
Q&A · BACKUP B
Bitstring Status List vs RevRegs natius
Criteri
RevRegs natius
Bitstring Status List
Compatibilitat Credo-TS v0.5
TRENCADA
OK
Descàrrega de fitxer pel titular
TAILS FILE
CAP
Dependència de connectivitat
ALTA
BAIXA
Publicació a blockchain per revocar
SÍ
NO
Interoperabilitat W3C
PARCIAL
SÍ
Complexitat
ALTA
BAIXA
Q&A · BACKUP C
La clau Ed25519: del disc a HSM / KMS
ARA
Clau privada en JSON al discQui accedeix al filesystem pot signar status lists falses
01
Variable d'entorn / secret manager
02
HSM o KMSLa clau mai surt del mòdul
L'arquitectura no canvia: només l'origen de la signatura de la Status List.
Q&A · BACKUP D
Peer-to-peer? Transport vs xifratge
XARXA
Túnel Cloudflare + HTTP
Mòbil→Cloudflare→Agent
Hi ha un intermediari de transport. NO és peer-to-peer.
HTTP
Petició POST a l'adreça pública de l'agent
El túnel només fa arribar els paquets al port local.
DIDComm
Xifratge d'extrem a extrem
Mòbil🔒 xifrat 🔒Agent
Cloudflare no pot llegir res. La seguretat és extrem a extrem.
El terme peer-to-peer descrivia la propietat de seguretat (ningú al mig llegeix), no la topologia de xarxa. El correcte: canal xifrat d'extrem a extrem sobre transport HTTP.