Resumen

  • RFC 9670 registra el destinatario de un reparto mediante un ID de Principal; el nombre, correo y descripción que ve el usuario no son por sí solos una prueba fuerte de control humano.
  • Después de identificar al destinatario, todavía hay que distinguir la asignación en shareWith, los myRights calculados, la visibilidad por suscripción, la notificación, la operación ejecutada y el alcance real de una revocación.

Dos entradas del selector decían «María Gómez». Una usaba la letra latina esperada; la otra combinaba caracteres visualmente parecidos. El propietario eligió la segunda, el servidor aceptó el cambio y el objeto pasó a un estado nuevo. El recibo técnico era impecable. El destinatario era el equivocado.

RFC 9670 anticipa este problema. Un Principal representa a una persona, grupo, sala, dispositivo u otra entidad, pero sus propiedades de presentación pueden cambiar. Si un usuario puede editar su nombre, descripción, tipo o correo, puede intentar parecerse a otro. Prohibir duplicados exactos no basta: pequeñas faltas y caracteres Unicode confundibles sobreviven a esa regla.

La primera pregunta de un sistema de reparto no es «¿se guardó shareWith?». Es «¿qué autoridad afirmó que este Principal corresponde a la persona pretendida?».

La especificación coordina identificadores, no administra el directorio

RFC 9670 define Principal y ShareNotification y añade capacidades JMAP para encontrarlos. Un Principal puede relacionarse con cero o más Accounts. Una capacidad en el Account indica el Principal propietario y dónde reside su objeto de identidad.

Sin embargo, administrar el conjunto de Principals queda fuera del alcance del RFC. La especificación espera que esa población proceda de un directorio o sistema de usuarios propio del dominio. Esa decisión protege la portabilidad, pero deja una responsabilidad local: altas, bajas, grupos, homónimos, cuentas de servicio y reasignaciones necesitan una genealogía verificable.

El dueño del Account tampoco aparece como una entrada ordinaria de shareWith; sus derechos son implícitos. Por eso una auditoría que solo enumera la tarjeta de reparto no representa toda la autoridad.

Un comprobante útil une el ID inmutable del Principal con la generación del directorio, el Account de Principals, el Account del objeto y el Principal propietario. También conserva los datos de presentación que vio el operador, para investigar una selección engañosa sin convertirlos en identidad canónica.

La tarjeta de reparto no es el derecho efectivo

Los tipos de datos que adoptan el marco deben definir shareWith, myRights e isSubscribed.

shareWith es un mapa de Principal a derechos asignados. myRights devuelve los permisos actuales del usuario que consulta. Las claves de esos derechos son específicas del tipo de datos. RFC 9670 no decide si un objeto permite leer, modificar, administrar, invitar o realizar otra acción; la especificación del objeto debe hacerlo.

La diferencia evita dos errores. Primero, una asignación solicitada puede verse limitada por la política del servidor. Segundo, un myRights verdadero para una acción no demuestra que otra acción sea posible. La comprobación termina con una operación concreta realizada como el destinatario y con el resultado del objeto correcto.

isSubscribed añade otra realidad. Tener permiso no implica querer que el recurso aparezca en la vista cotidiana. Un usuario puede descubrirlo mediante consultas de Principals y Accounts aunque no esté suscrito; el servidor incluso puede negar una suscripción manteniendo el acceso. «No lo veo» no equivale a «no tengo derecho».

El control de concurrencia impide inventar una victoria

Un editor suele enviar una nueva versión completa del mapa shareWith. Si dos personas parten del mismo estado, cada una puede borrar sin querer la modificación de la otra.

El mecanismo JMAP de RFC 8620 ofrece ifInState. Si el tipo de datos cambió, el servidor aborta con stateMismatch. Una respuesta /set separa updated de notUpdated y devuelve el estado anterior y el nuevo.

La organización debe guardar esa secuencia: estado leído, hash del mapa, precondición, resultado por ID y estado final. Un token nuevo prueba orden de sincronización; no explica qué actor estaba autorizado, por qué se eligió un Principal ni si la otra parte usó el derecho. El artículo de Estado JMAP ya cubre ese límite general; aquí importa porque una actualización perdida puede conceder o retirar acceso en silencio.

ShareNotification puede existir sin cerrar el riesgo

Cuando cambian los permisos, el servidor debería crear una ShareNotification para el usuario afectado. El objeto registra derechos antiguos y nuevos, el objeto compartido, una marca temporal y changedBy. El principalId de quien hizo el cambio puede ser nulo.

Hay excepciones operativas. Para cambios derivados de un grupo, el servidor puede omitir la notificación si generarlas todas sería abrumador. También puede agruparlas, limitar su número y eliminar las más antiguas. RFC 9670 advierte que esa última medida puede ocultar un cambio de seguridad.

Por tanto, el ID de notificación no prueba que un cliente la transportó ni que una persona la leyó. Y la ausencia de notificación no refuta necesariamente el cambio. Deben registrarse la política aplicable, la creación o supresión, la entrega al cliente y el acuse humano como eventos diferentes.

Un acceso breve puede convertirse en persistencia

El RFC describe una amenaza especialmente relevante para dirección: alguien con acceso momentáneo a un cliente desbloqueado puede añadir un Principal controlado por el atacante. La sesión termina, pero el reparto queda. Exigir autorización adicional para compartir o avisar al propietario por un canal distinto reduce ese riesgo.

La misma disciplina vale para la revocación. Quitar el Principal, releer myRights y demostrar que nuevas operaciones fallan prueba el cierre en el servicio. No borra automáticamente un archivo exportado o una copia legítima creada antes. El estándar no promete control sobre esos bytes.

La cadena completa es: identidad elegida, dueño y objeto, mapa anterior, mutación condicionada, resultado /set, lectura desde el destinatario, notificación según política, operación real y alcance de copia. Cada paso puede ser verdadero sin que el siguiente lo sea.

Fuentes