Saltar al contenido principal

Troubleshooting

CLI de acreditaciones​

El CLI devuelve "Invalid DID format"​

Síntoma: el CLI rechaza el DID indicado con un mensaje de formato inválido.

Causa: el DID no tiene el prefijo correcto para el entorno. El prefijo debe coincidir con el valor DID_PREFIX del servidor TIR de destino (did:isbe:uc para producción, did:isbe:uc-pre para preproducción, ).

Solución: comprueba que el DID que usas en --sub y en issuerDid de isbe-config.json tiene el prefijo correcto para el entorno en el que estás operando.

El JWT generado por el CLI es rechazado por ISBE al intentar publicarlo​

Síntoma: ISBE devuelve un error al intentar registrar la acreditación en la blockchain.

Causa más común: el campo kid de la clave de firma no coincide exactamente con el verificationMethod registrado en el DID. El kid debe tener la forma <DID>#<thumbprint_JWK>.

Solución: verifica que el fichero key.json tiene el campo kid correcto consultando el DID en el resolver y copiando el id del verificationMethod correspondiente.

El CLI no encuentra el fichero de configuración​

Síntoma: error al ejecutar cualquier comando del CLI.

Causa: el directorio isbe-data/ no existe o isbe-config.json no está en la ruta esperada.

Solución: ejecuta ./isbe-accreditation-cli.sh config --show para generar la configuración por defecto. Luego edita isbe-data/isbe-config.json con los valores de tu entorno.

API JSON-RPC del TIR​

Error -32600 Unauthorized: Invalid API Key​

Síntoma: la llamada a POST /trusted-issuers-registry/v1/jsonrpc devuelve código HTTP 401 con el error JSON-RPC -32600.

Causa: el header x-api-key no está presente o la API Key no es válida.

Solución: contacta con el equipo de ISBE para obtener una API Key válida para el entorno correspondiente.

Error -32601 Method not found​

Síntoma: la llamada devuelve el error JSON-RPC -32601.

Causa: el campo method del cuerpo de la petición no corresponde a ninguno de los tres métodos soportados: setAttributeMetadata, setAttributeData, sendSignedTransaction.

Solución: verifica la ortografía exacta del nombre del método (distingue mayúsculas y minúsculas).

Error -32602 Invalid params: Missing parameter: ...​

Síntoma: la llamada devuelve el error JSON-RPC -32602 indicando un parámetro faltante.

Causa: el objeto de parámetros en params[0] no incluye todos los campos requeridos para el método invocado.

Solución: revisa la referencia de la API (Métodos JSON-RPC) y asegúrate de incluir todos los campos obligatorios con el tipo correcto.

Error -32602 Invalid Ethereum address for parameter from​

Síntoma: error de validación en el campo from.

Causa: el campo from no es una dirección Ethereum válida (debe ser 0x seguido de 40 caracteres hexadecimales).

Solución: usa la dirección Ethereum de la clave que va a firmar la transacción, no el DID.

Error -32602 Invalid issuerType for parameter issuerType​

Síntoma: error de validación en el campo issuerType.

Causa: el valor de issuerType no está entre los valores válidos del enum: NONE, ROOT_TAO, TAO, TI, REVOKED.

Solución: usa el nombre de la constante ("TI", "TAO", etc.), no el valor numérico, en la petición JSON-RPC.

La transacción enviada con sendSignedTransaction no aparece en el TIR​

Síntoma: sendSignedTransaction devuelve un hash de transacción, pero la acreditación no es consultable en el endpoint REST.

Causa: la transacción ha sido enviada a la mempool pero aún no ha sido incluida en un bloque, o la transacción falló (status 0x0 en el recibo).

Solución: consulta el recibo de la transacción con eth_getTransactionReceipt usando el hash devuelto. Espera hasta que el recibo esté disponible (puede tardar varios segundos). Si status = 0x0, revisa el campo revertReason del recibo para obtener más detalles del fallo.

Validación de la cadena de confianza​

El verificador rechaza una credencial emitida por mi entidad​

Síntoma: el verificador devuelve un error indicando que el emisor no es de confianza.

Diagnóstico paso a paso:

  1. Consulta el TIR con el DID de tu entidad:

    curl "<tir-url>/v1/issuers/<TU_DID>/attributes/<ATTRIBUTE_ID>"

    Comprueba que el issuerType es TI (no REVOKED) y que validUntil no ha pasado.

  2. Sigue la URL en termsOfUse[0].id y comprueba el estado de la TAO que te acreditó. Si la TAO está revocada o expirada, las credenciales que tú emitas también son inválidas.

  3. Comprueba que el tipo de credencial que has emitido está en accreditedFor de tu acreditación TI.

  4. Verifica que el DID del firmante de tu acreditación TI coincide con el DID de la TAO que aparece en termsOfUse.

El CLI devuelve "trust anchor not found in chain"​

Síntoma: la validación de la cadena falla porque no se llega al trust anchor configurado.

Causa: la cadena de acreditaciones no remonta hasta el DID configurado en trustAnchors del CLI, o el DID configurado es incorrecto para el entorno.

Solución: verifica que el trust anchor en isbe-config.json corresponde al del entorno (ver Entornos → Trust anchors). Comprueba que la URL en --accreditedBy de cada acreditación apunta al TIR del entorno correcto.

La URL de la acreditación devuelve 404​

Síntoma: al consultar <tir-url>/v1/issuers/{did}/attributes/{attributeId} se obtiene un 404.

Causa más probable: el attributeId en la URL no coincide exactamente con el registrado en el TIR. Recuerda que el endpoint REST espera el attributeId sin el prefijo 0x.

Solución: usa el attributeId de 64 caracteres hexadecimales sin el prefijo 0x. Si el problema persiste, contacta con ISBE para confirmar que la acreditación fue registrada en la blockchain.