Identidad descentralizada (DID) en SaluData
Diseño híbrido eficiente: bytes32 on‑chain para claves y string para DID legible y resolución.
¿Qué es un DID?
Un Decentralized Identifier (DID) es un identificador estandarizado por W3C para referenciar de forma verificable a personas, organizaciones, dispositivos o servicios, sin una autoridad central. Ejemplos: did:ethr:0xabc…, did:key:z6Mk…, did:web:ejemplo.com.
Un DID resuelve a un DID Document (JSON) con verification methods (claves), service endpoints (por ejemplo, tu endpoint FHIR) y metadatos.
Patrón usado en SaluData
- On‑chain:
bytes32 didKey(clave compacta para mapas/eventos). - Off‑chain:
string didStringy su DID Document para resolución. - Directorio: relación didKey ↔ didString ↔ endpoints FHIR y claves rotables.
Representaciones: string vs bytes32
string: legible y portable (método DID completo). Contras: mayor gas y comparaciones costosas.
bytes32: huella compacta (hash o fingerprint). Pros: comparaciones baratas y eventos livianos. Contras: no legible directo.
Recomendación: usar bytes32 como clave on‑chain y mantener el DID completo fuera de cadena o en un directorio, con reglas claras de canonicidad.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
interface IIdentityRegistry {
enum Role { NONE, REGULATOR, MACRO_NETWORK, PROVIDER, PROFESSIONAL, PATIENT }
struct Entity {
bytes32 didKey; // clave compacta (bytes32)
Role role;
bool active;
bytes32 meta; // hash a metadatos (p.ej. endpoint FHIR, especialidad)
}
event Registered(bytes32 indexed didKey, address indexed account, Role role);
event Revoked(bytes32 indexed didKey, address indexed account);
event MetaUpdated(bytes32 indexed didKey, bytes32 meta);
function register(bytes32 didKey, address account, Role role, bytes32 meta) external;
function revoke(bytes32 didKey, address account) external;
function setMeta(bytes32 didKey, bytes32 meta) external;
function resolve(address account) external view returns (Entity memory);
}
Canonicalización & hashing (off‑chain)
Para derivar didKey estable y comparar sin fricción, aplica reglas de canonicidad al didString antes de hashear (minúsculas, sin slashes finales, etc.):
// JS (Node) — derivar didKey = keccak256("DID:" + didCanonical)
import { keccak256 } from "ethers";
function canonicalize(did) {
return did.trim().toLowerCase().replace(/\/+$/,"");
}
function didKeyFromString(didString) {
const didCanonical = canonicalize(didString);
return keccak256(new TextEncoder().encode("DID:" + didCanonical));
}
Usa un prefijo tipo "DID:" (domain separation) para evitar colisiones con otros hashes.
// Solidity — verificación rápida (ejemplo conceptual)
pragma solidity ^0.8.24;
library DidLib {
function toKey(string memory canonicalDid) internal pure returns (bytes32) {
return keccak256(abi.encodePacked("DID:", canonicalDid));
}
}
En el ProviderDirectory puedes mantener didKey → endpoint FHIR y rotación de claves cifradas:
// setEndpoint / rotateKey (simplificado)
interface IProviderDirectory {
event EndpointUpdated(bytes32 indexed didKey, bytes32 fhirEndpoint);
event KeyRotated(bytes32 indexed didKey, bytes newPubKey);
function setEndpoint(bytes32 didKey, bytes32 fhirEndpoint) external;
function rotateKey(bytes32 didKey, bytes calldata newPubKey) external;
}
¿Implementamos tu directorio DID + FHIR?
Te ayudamos a publicar DID Documents y endpoints FHIR con rotación de claves y auditoría.
🔐 Prueba la identidad descentralizada
Experimenta con los perfiles de usuario y la gestión de identidad en nuestra demo.
Probar Demo de IdentidadEmail especializado
Envíanos tu consulta sobre identidad descentralizada y te responderemos con información técnica detallada.
Enviar emailWhatsApp especializado
Chatea con nuestro equipo especializado en identidad descentralizada y blockchain.
Abrir WhatsApp