FideX (AS5): el futuro de las transmisiones certificadas de EDI
Qué es FideX (AS5) explicado simple: la propuesta de nueva generación del correo certificado digital —de AS2 y AS4 a REST + JSON— con firma para no repudio, cifrado de punta a punta y acuse J-MDN firmado por webhook. Qué propone el borrador, en qué estado está y por qué le interesa a una PyME venezolana.
En el artículo del correo certificado digital contamos cómo AS2 y AS4 mataron la discusión más cara de la logística: el “ese archivo nunca me llegó”. Cifrado, firma, acuse de recibo. Problema resuelto… para quien puede pagarlo.
Porque esa es la parte que no contamos: montar AS2 sigue siendo un pequeño calvario. Certificados que se intercambian por correo y vencen sin avisar, software especializado de los 2000, tecnologías (S/MIME, y en AS4, SOAP) que ningún desarrollador menor de cuarenta años ha tocado. Para una multinacional es un trámite; para una distribuidora mediana en Valencia o Barquisimeto, es una barrera. Y las barreras de veinte años son exactamente el tipo de cosa que internet termina derribando.
Hoy le presentamos al candidato a derribarla: FideX, también conocido como AS5.
¿Qué es FideX, en una frase?
FideX (Fast Integration for Digital Enterprises eXchange) es una especificación propuesta para la siguiente generación del transporte certificado de documentos B2B: las mismas garantías de AS2 —nadie lo lee en el camino, se sabe quién lo envió, nadie puede negar que lo recibió— pero construidas con las tecnologías que cualquier desarrollador web usa hoy: REST, JSON y HTTPS.
Transparencia primero: FideX es un borrador (versión 1.0, febrero de 2026), impulsado por un grupo de trabajo en el que el equipo de Greicodex/Kontext participa en su diseño. Es una propuesta abierta, no un estándar ratificado por un organismo internacional. Se lo contamos con esa honestidad porque este blog se llama “EDI sin misterio”, y el misterio incluye no disfrazar propuestas de hechos consumados.
La genealogía: por qué “AS5”
La familia “AS” (Applicability Statement) es la del correo certificado digital, y cada generación se reescribió en la tecnología de su época:
| AS2 (2005) | AS4 (2013) | FideX / AS5 (2026, borrador) | |
|---|---|---|---|
| Base técnica | MIME/S-MIME sobre HTTP (RFC 4130) | SOAP + WS-Security (OASIS ebMS 3.0) | REST + JSON + JOSE sobre HTTPS |
| El acuse | MDN (estilo correo electrónico) | Recibo ebMS | J-MDN: JSON firmado, por webhook |
| Intercambio de claves | Manual, por correo | Manual | Descubrimiento automático |
| ¿Quién sabe operarlo? | Especialistas EDI | Especialistas de integración | Cualquier desarrollador web |
| Curva de aprendizaje | Semanas | Semanas | Horas |
AS2 habla el idioma del correo electrónico de los 90. AS4 habla el idioma de los servicios web corporativos de los 2000. FideX habla el idioma en que están construidos los sistemas de 2026: el mismo REST + JSON de cualquier pasarela de pagos o API bancaria.
Qué propone el borrador (lo esencial)
- Un sobre JSON de dos partes. Cada mensaje lleva un
routing_headeren claro —remitente, destinatario, tipo de documento, fecha: lo que el “cartero” necesita para enrutar— y unencrypted_payload: el documento comercial, cifrado. El cartero lee la etiqueta; jamás la carta. - Primero se firma, luego se cifra. El documento se firma digitalmente (eso da el no repudio: el emisor no puede negar que lo envió) y después se cifra (eso da la confidencialidad: solo el destinatario puede abrirlo). En la jerga técnica: JWE(JWS), usando JOSE, el estándar de firma y cifrado en JSON que ya protege millones de inicios de sesión cada día.
- El J-MDN: el “recibido y firmado” moderno. Cuando el mensaje llega y se verifica, el nodo receptor envía de vuelta —de forma asíncrona, a un webhook del emisor— un acuse en JSON firmado por el receptor, con la huella digital del mensaje original. Es el nieto directo del MDN de AS2: prueba técnica de entrega, con firma y hora.
- Direcciones GLN. Cada empresa se identifica con su GLN (Global Location Number, el número global de ubicación de GS1 — la misma familia del SSCC), en forma de URN:
urn:gln:0614141000012. Una cédula de empresa, global y sin ambigüedad. - Payload-agnóstico. A FideX no le importa qué idioma viaja adentro del sobre: puede ser X12, EDIFACT o GS1 XML. Cambia el sobre, no la carta.
- Socios que se conectan en minutos. En lugar del intercambio manual de certificados de AS2, el borrador define descubrimiento automático: cada nodo publica su configuración y sus claves públicas en URLs estándar, y registrar un socio puede ser tan simple como escanear un código QR.
La frase que resume la propuesta: si usted sabe llamar un API, sabe usar FideX. Sin S/MIME, sin SOAP, sin software arqueológico.
FideX (AS5): se firma, se cifra, se envía por HTTPS — y el acuse J-MDN vuelve por webhook
El ángulo venezolano
Piense en quién quedó fuera del EDI certificado durante veinte años: la distribuidora mediana, el fabricante regional, la farmacia con diez sucursales. No porque no lo necesitaran —el “nunca me llegó” les cuesta igual que a Walmart— sino porque el peaje eran los VAN (redes privadas de valor agregado que cobran por documento) o una infraestructura AS2 con su especialista incluido. La promesa de FideX es que la garantía del correo certificado corra sobre lo que esa empresa ya tiene: HTTPS, un desarrollador web y un servidor cualquiera. EDI certificado sin cuota de club.
Honestidad sobre el presente
- ¿Puedo usarlo hoy con mi cadena? Todavía no: ninguna cadena lo exige, porque es un borrador. Las especificaciones B2B se adoptan cuando los grandes compradores las exigen — así fue con AS2 y Walmart en 2002.
- ¿Entonces por qué me importa? Porque los estándares se cocinan años antes de servirse, y quien entiende el menú temprano decide mejor. Además, como aprendimos con TRADACOMS, lo viejo no desaparece: AS2 convivirá con lo que venga por décadas.
- ¿Y Kontext qué gana contándome esto? Participamos en el diseño de FideX y lo decimos sin rodeos. Nuestra apuesta es la misma de toda esta serie: que el EDI deje de ser un club cerrado. Un estándar abierto y auditable —sin cajas negras— es la versión en protocolo de esa apuesta.
El sobre certificado se está reinventando en el idioma de la web, y esta vez la puerta de entrada mide lo que mide un API. Si quiere que su operación esté lista para hablar con el EDI de hoy —y con el de mañana—, revise nuestras soluciones o conversemos.