Conceptos
El modelo de roles
La cadena de confianza de ISBE sigue un modelo jerárquico descendente. Cada rol está acreditado por el rol inmediatamente superior y solo puede ejercer capacidades dentro del alcance de esa acreditación.
TA (Trust Anchor — DID fijo, configurado en clientes)
└── RTAO (Root Trusted Accreditation Organisation)
└── TAO (Trusted Accreditation Organisation)
└── TI (Trusted Issuer)
La raíz de confianza (*) (TA) no tiene acreditación registrada en el TIR: su DID es conocido por los clientes verificadores a través de configuración estática. Todo lo demás en la cadena se valida contra esa raíz.
Trust Anchor (TA)
El TA es la entidad cuyo DID es el punto de partida de la validación. En ISBE, el TA y la entidad que emite las RTAOs son la misma. El DID del TA está configurado en el CLI de acreditaciones (trustAnchors) y en cualquier cliente verificador.
RTAO — Root Trusted Accreditation Organisation
El RTAO acredita a las TAOs de un dominio. Solo ISBE tiene la capacidad de emitir RTAOs. Una acreditación RTAO usa el tipo de VC VerifiableAuthorisationForTrustChain.
La acreditación RTAO contiene:
credentialSubject.id— DID de la entidad que recibe el rol de RTAO.credentialSubject.accreditedFor— array de{ schemaId, types[], limitJurisdiction? }que define qué tipos de credenciales pueden ser acreditados bajo este RTAO.credentialSubject.reservedAttributeId— identificador del atributo en el TIR (64 hex chars).
TAO — Trusted Accreditation Organisation
La TAO acredita a TIs (y puede acreditar sub-TAOs) dentro del dominio y tipos establecidos en su propia acreditación. Una acreditación TAO usa el tipo de VC VerifiableAccreditationToAccredit.
La acreditación TAO contiene los mismos campos que la RTAO, más:
termsOfUse[].id— URL de la acreditación padre (RTAO o TAO) que avala esta TAO.termsOfUse[].type—"IsbeAccreditationEntry".
TI — Trusted Issuer
El emisor de confianza (*) es la entidad con capacidad final de emitir credenciales verificables a usuarios. Una acreditación TI usa el tipo de VC VerifiableAccreditationToAttest.
La acreditación TI contiene los mismos campos que la TAO. Los tipos en accreditedFor deben ser un subconjunto de los autorizados por la TAO padre.
TV — Trusted Verifier (no implementado)
El rol TV está definido en la especificación ISBE-ART-00024 pero no está implementado en la infraestructura actual. No se usa en ningún flujo de producción.
Tipos de acreditación
| Tipo de VC | Rol que representa | Firmado por |
|---|---|---|
VerifiableAuthorisationForTrustChain | RTAO | TA de ISBE |
VerifiableAccreditationToAccredit | TAO | RTAO o TAO padre |
VerifiableAccreditationToAttest | TI | TAO padre |
Los tres tipos heredan del contexto W3C VC Data Model 2.0 (https://www.w3.org/ns/credentials/v2). El campo type del VC es un array que siempre incluye "VerifiableCredential" más el tipo específico:
{
"@context": ["https://www.w3.org/ns/credentials/v2"],
"type": ["VerifiableCredential", "VerifiableAccreditationToAttest"],
"issuer": "did:isbe:uc:z12kVar5p6bD5WCjEJcQ18Zyt8XV",
"validFrom": "2023-03-29T12:56:16Z",
"validUntil": "2090-01-09T05:40:42Z",
"credentialSubject": {
"id": "did:isbe:uc:<DID_DEL_TI>",
"accreditedFor": [
{
"schemaId": "https://raw.githubusercontent.com/alastria/isbe-identity-schemas-repository/main/use-cases/isbe/portal/lear/portalLear-schema.json",
"types": ["VerifiableCredential", "IsbePortalLearCredential"],
"limitJurisdiction": "https://publications.europa.eu/resource/authority/atu/ESP"
}
],
"reservedAttributeId": "abfc5a265e1b3aa60718619c0041e3c051686fd05d0f0954679eaa756136b343"
},
"termsOfUse": [
{
"id": "https://tir.portal.redisbe.com/trusted-issuers-registry/v1/issuers/did:isbe:uc:z12kVar5p6bD5WCjEJcQ18Zyt8XV/attributes/fad7068b8f890f20b86554be9f9d66d6b0ce08ec3b057a937e21f8a30ec545c7",
"type": "IsbeAccreditationEntry"
}
],
"credentialSchema": [
{
"id": "https://github.com/alastria/isbe-identity-schemas-repository/raw/main/commons/isbe-accreditation-schema.json",
"type": "JsonSchema"
}
]
}
El dominio de acreditación (*)
Todas las acreditaciones están vinculadas a un dominio (*): una cadena de texto que delimita el alcance operativo. El dominio "ISBE" es el dominio de producción. El dominio "ISBE-PRE" se usa en el entorno de preproducción.
El dominio sirve para que una acreditación emitida en el contexto de una red concreta no sea válida en otra red, incluso si el TIR es compartido.
El campo reservedAttributeId
El reservedAttributeId es el identificador del atributo en el contrato inteligente del TIR. Es un string de 64 caracteres hexadecimales generado aleatoriamente por quien crea la acreditación (el CLI de acreditaciones). Este mismo valor se usa como revisionId y attributeId en los métodos de la API JSON-RPC.
Ejemplo: "abfc5a265e1b3aa60718619c0041e3c051686fd05d0f0954679eaa756136b343"
El campo termsOfUse
El campo termsOfUse enlaza la acreditación con la acreditación padre que la avala. Su id es la URL pública del TIR donde reside la acreditación padre. Los verificadores siguen esta URL para validar la cadena hacia arriba.
Ciclo de vida de una acreditación
[Creación]
│
▼
[Firma del JWT] ← CLI de acreditaciones
│
▼
[Publicación en TIR] ← Operador de ISBE (vía API JSON-RPC + blockchain)
│
├── [Vigente] ← validFrom ≤ now ≤ validUntil, issuerType ≠ REVOKED
│
├── [Expirada] ← now > validUntil
│
└── [Revocada] ← issuerType = REVOKED (4)
Una acreditación no puede volver a estado vigente una vez expirada o revocada. Si una entidad necesita una nueva acreditación tras revocar la anterior, debe solicitar que se publique una nueva acreditación con un reservedAttributeId diferente.
Almacenamiento: híbrido on-chain y off-chain
El contrato inteligente TrustedIssuersRegistryFacet almacena en la blockchain los metadatos del atributo: tipo de emisor (issuerType), DID del sujeto, DID de la TAO que acredita, y el attributeId. El JWT completo de la acreditación se almacena de forma pública en el repositorio isbe-identity-accreditations-chains en GitHub.
El endpoint REST de lectura del TIR API (GET /trusted-issuers-registry/v1/issuers/{did}/attributes/{attributeId}) recupera el dato del repositorio GitHub, no directamente del contrato. Esta arquitectura reduce el coste de gas sin sacrificar la disponibilidad pública de las acreditaciones.
Revocación
La revocación se realiza publicando una nueva transacción en el TIR con issuerType = REVOKED (valor numérico 4) para el atributo que se quiere revocar. El contrato registra el cambio y a partir de ese momento cualquier verificador que consulte el TIR obtendrá el tipo REVOKED.
La revocación solo puede ser ejecutada por la entidad que publicó la acreditación o por una entidad con mayor jerarquía en la cadena. No existe un mecanismo de auto-revocación: el sujeto de la acreditación no puede revocar su propia acreditación.
Relación con credentialStatus en las VCs emitidas
Las credenciales verificables emitidas por un TI pueden incluir un campo credentialStatus que referencia el TIR para permitir comprobar si la credencial (no la acreditación del emisor) ha sido revocada. El tipo IsbeAccreditationEntry identifica una entrada del TIR. Este mecanismo aplica tanto a acreditaciones como a credenciales emitidas con soporte de revocación.