Tema
Identidad digital y credenciales
Dentro de la faceta Tema, la inteligencia temática Identidad digital y credenciales conecta artículos que comparten un tema específico, un enfoque en señales o una temática de seguimiento. La página ofrece a los lectores un recorrido más completo a través de informes relacionados, evidencia de fuentes, actores del mercado e implicaciones de infraestructura, con el contexto suficiente para entender por qué el tema es relevante en los movimientos corporativos, las decisiones de gobernanza, la exposición regional y el riesgo operativo. Los lectores pueden comparar señales recurrentes, organizaciones implicadas, evidencia pública, contexto de mercado, continuidad del servicio, contratación, competencia, cumplimiento y cuestiones de planificación estratégica que subyacen al tema, en lugar de quedarse en una lista escueta de artículos relacionados. Explica de qué trata el tema, qué actores o políticas de infraestructura están implicados, qué evidencia respalda la cobertura y por qué puede ser relevante para operadores, clientes, inversores y lectores interesados en las políticas.
Historia de Internet
El servidor no necesitaba el texto claro. Aun así controlaba la disponibilidad: RFC 3157
Una caja fuerte no tiene que leer un documento para decidir si su dueño volverá a verlo. En agosto de 2001, RFC 3157 llevó esa diferencia al problema de trasladar credenciales criptográficas entre ordenadores, portátiles, teléfonos y routers. El cifrado podía impedir que un…
Historias
RIPE NCC renueva las credenciales RPKI; el límite de poder sigue siendo la prueba decisiva
Un identificador integrado con SSO puede mejorar la trazabilidad y la revocación. No demuestra, por sí solo, que una automatización solo pueda cambiar los prefijos que le corresponden. El plan de RIPE NCC ofrece ambas mitades del problema: una migración a OIDC en curso y una API…
Historia de Internet
El servidor necesitaba un tercer desafío: RFC 3163
En el modo mutuo de RFC 3163, el tercer valor aleatorio no era un adorno. Respondía a una asimetría de orden: cuando el cliente elegía su propio valor, ya había visto el primer desafío del servidor. La solución era concreta, y también lo eran sus límites.
IETF
El sobre estaba firmado. El texto cifrado separado quedó fuera de la firma.
El fallo no se ve al verificar la firma, sino al preguntar qué archivo estaba unido a ella en ese instante. COSE permite separar los bytes cifrados de la estructura de control; desde entonces, la seguridad depende tanto de la custodia del objeto externo como del algoritmo que…
IETF
El calendario lo llamó propietario. Aún no le había concedido control.
Un registro de calendario puede llamar propietario a un participante sin convertirlo en editor autorizado. La etiqueta describe un papel; el protocolo de intercambio todavía debe decidir quién puede mover el evento, cambiar a los asistentes o distribuir una actualización.
IETF
La redirección funcionó. La credencial ya había viajado en claro.
El monitor enseñó una URL HTTPS y la operación terminó bien. Esa imagen final no incluye el dato decisivo: el cliente había enviado la credencial dentro de la primera petición HTTP, antes de que el servidor pudiera contestar con una redirección.
IETF
La cadena validó el ancla que traía. La parte verificadora aún no había confiado en ella.
did:x509 permite demostrar que una cadena y un identificador encajan sin convertir ese encaje en permiso. El problema aparece cuando una aplicación confunde el ancla usada para cerrar el cálculo con el ancla que su propia organización decidió aceptar.
Historia de Internet
La prueba duradera tenía que sobrevivir a la clave: RFC 3126
RFC 3126 entendió la firma antigua como un problema de custodia. Un cálculo correcto en 2001 no podría explicarse años después si habían desaparecido certificados, estados de revocación, bytes exactos o algoritmos confiables. La respuesta fue una cadena renovable de evidencia, no…
IETF
El servicio abrió el handshake, pero aún no podía autenticar al remitente
En MLS, descifrar el mismo Commit o Proposal que reciben los miembros no entrega automáticamente la memoria necesaria para verificar quién lo envió. Esa memoria vive en el GroupContext: época, hoja, credencial y lista acordada de receptores externos.
Historia de Internet
Una firma válida todavía necesitaba una política: RFC 3125
RFC 3125 quiso convertir las reglas que rodeaban una firma electrónica en una referencia precisa y procesable. La operación criptográfica era solo la primera comprobación: todavía había que saber qué política exacta, compromiso, periodo y conjunto de confianza gobernaban la…
IETF
La clave vigente firmó a su sucesora. Ahí empezó el problema.
Una cadena de firmas puede explicar cómo se llegó a un estado de claves. No demuestra que la clave sospechosa tuviera derecho a convertir su control presente en autoridad futura.
IETF
La huella coincidió; faltaba autorizar a qué socio representaba
Confirmar una huella por teléfono parece un gesto pequeño. En AS2 puede ser el único momento en que una organización demuestra que una clave válida pertenece a la relación comercial correcta, y no sólo que alguien logró instalarla.
Instituciones de Asia-Pacífico
TrueMoney frente a sus propias cifras: qué automatizan sus raíles de pago y qué affirmaciones de escala resisten la evidencia
Truemoney Company PLC es la entidad que opera la cartera digital TrueMoney bajo Ascend Money, la fintech del grupo CP. Sus páginas corporativas repiten tres cifras — 50 millones de usuarios y clientes, 21 millones de usuarios de cartera electrónica y 88.000 agentes — pero ninguna…
IETF
El Voucher prometía otro. La renovación aún no había ocurrido.
`last-renewal-date` parece una fecha operativa, pero el borrador ANIMA la define como una proyección informativa que el Pledge ni siquiera procesa. La revisión 36 aclara la transacción posterior: solicitud nueva, clave de Dominio, certificado, política y emisión siguen separando…
IETF
El nuevo núcleo termina en `0x01`. La deuda de compatibilidad no.
El borrador que aspira a sustituir RFC 9180 deja Base y PSK en el núcleo de HPKE y reserva los dos valores antes usados por Auth y AuthPSK. Ese cambio ordena la especificación futura, pero no liquida por sí solo binarios antiguos, excepciones, objetos cifrados ni acuerdos con…
IETF
El servidor respondió 200. Ninguna trama había llegado todavía
En CONNECT-ETHERNET, una respuesta satisfactoria puede ser exacta y, a la vez, insuficiente para la afirmación que más importa a operaciones. El `2xx` confirma que existe un túnel de capa 2 y que el proxy está dispuesto a transportar tramas; no confirma qué trama entrará, qué…
IETF
El servidor devolvió el objeto antiguo, no una pista de auditoría
JMAP Entidad History propone recuperar versiones anteriores y destruidas de un objeto. Sus propias reglas explican por qué esas copias conservadas no prueban cada cambio, su autor, su autorización ni su resultado.
IETF
El segundo intento corrige la selección, no concede confianza
Cuando un cliente TLS rechaza la cadena que el servidor eligió siguiendo su propia pista, una nueva conexión puede pedir una única ancla concreta. Esa recuperación parece cerrar el círculo, pero no corrige ni amplía la política de confianza: solo vuelve a ejecutar la selección…
IETF
El exportador produjo 128 bytes. No vinculaban al portador del token con el túnel
La revisión 04 de EAP-PPT elimina una salida que parecía material criptográfico aportado por el método interior. Un exportador TLS puede producir bytes propios de una sesión sin demostrar que quien porta el token es también quien termina el túnel.
Historia de Internet
La contraseña no tenía una entrada que cambiar: RFC 3062
En 2001, la operación de modificación habitual de LDAP no podía alcanzar todas las contraseñas. RFC 3062 añadió una solicitud independiente para cambiarlas, ligada a la identidad de la sesión o a otra que no tenía por qué ser un DN, aunque la credencial se guardara fuera del…