Кратко

  • RFC 5344 описывает сценарии междоменного peering для presence и мгновенных сообщений, но не задаёт новый протокол и не доказывает безопасность конкретной федерации.
  • Перенос фильтрации на удалённого peer уменьшает число копий, но создаёт распределённую транзакцию: полная версия документа, privacy policy, watcher identity и результат преобразования должны относиться к одному решению.
  • Подлинность каждого объекта по отдельности не доказывает правильность раскрытия; нужна связь версий, времени, исполнителя и отзыва.

Оптимизация превратилась в распределённую транзакцию

В исходном сценарии Alice из одной Peer Network подписывается на присутствие Bob в другой. Сеть Bob принимает запросы только от своих пользователей или доверенных сетей. Сеть Alice передаёт subscription, а сеть Bob возвращает notifications. Это создаёт административный путь, но не отменяет правила Bob.

Если в удалённой сети много watchers одного presentity, домашняя сеть может отправлять каждому отдельную отфильтрованную копию. RFC 5344 предлагает экономию: передать полную presence-запись и privacy-информацию один раз, а удалённой сети поручить формировать правильные представления.

В локальном варианте сервер видит policy и document в одном контуре. В делегированном они могут обновляться раздельно. Политика может идти через конфигурационный канал, документ — через subscription/notification; identity map — обновляться третьей системой. У каждого объекта свой retry, cache и clock.

Поэтому решение должно быть атомарным логически, даже если транспорт физически раздельный. Квитанция связывает document version, policy version, watcher identity, matched rules, transformations и output fields. Без неё два валидных объекта могут образовать невалидное раскрытие.

Отзыв — это не запись в одной базе

Presentity меняет правило: удаляет человека из разрешённой группы или скрывает location. В домашней системе обновление завершено. Для федерации работа только началась. Новая версия должна дойти до peer, заменить cache, пересчитать текущие subscriptions и прекратить выдачу прежнего view.

Если новый документ опережает политику, peer раскрывает лишнее. Если политика опережает документ, результат может быть разрешён, но устаревшим. Если revoke-сообщение повторяется или приходит после failover, система должна понимать его idempotency и порядок.

RFC 6271 требует явного согласия пользователя на передачу privacy settings другой community. Согласие также должно быть версионируемым и отзывным. Оно не даёт peer бессрочного права хранить полный документ или использовать правила для иной цели.

Практический receipt отзыва содержит время решения пользователя, policy version, подтверждение приёма каждым peer, время последней выдачи старого view, пересчёт активных subscriptions и удаление чувствительного cache. Статус synced без этих границ слишком широк.

Identity тоже меняется отдельно

RFC 4745 строит policy из conditions, actions и transformations. Authenticated requestor identity может быть условием. RFC 5025 определяет, какие данные person, device, service, activity, mood, place, relationship и note может увидеть watcher.

Удалённая сеть может быть правильно аутентифицирована, а пользователь сопоставлен неверно. Alias меняется, SIP URI и tel URI не совпадают автоматически, аккаунты объединяются, один provider утверждает несколько идентификаторов. Политика может идеально исполниться для неправильного principal.

Поэтому peer certificate, federation membership и watcher identity — разные поля. Следует сохранять issuer утверждения, способ проверки, исходное значение, нормализацию и значение, использованное для matching. Иначе расследование увидит доверенный домен, но не человека, для которого возник view.

RFC 5344 прямо отделяет эти опасения: нужно проверять подлинность peer network, конфиденциальность каналов, способность peer не раскрывать и не искажать данные, безопасность Clearing House. Одно свойство не является доказательством другого.

Полный документ существует только ради фильтра

Делегированная схема создаёт чувствительный промежуточный объект. Полный presence-документ может содержать место, устройство, деятельность, отношения и временные привычки — больше, чем разрешено любому обычному watcher.

TLS или SIPS защищает участок передачи при заданных предпосылках. Он не доказывает правильную внутреннюю фильтрацию, отсутствие доступа администратора, срок хранения или удаление после revoke. Защищённый путь может доставить чувствительный объект системе, которая исполняет неверную версию правил.

Инвентаризация должна учитывать полный документ отдельно: источник, версия, freshness, получатель, encryption context, retention и deletion receipt. Для производного view сохраняются watcher, правила и раскрытые поля. Необязательно бессрочно хранить plaintext; можно сохранять защищённые hashes и версии, если система позволяет воспроизвести решение под контролем.

RFC 5344 предупреждает, что утечка policy способна показать человеку, что он включён в block list близкого друга. Значит, и сами правила являются персональными данными, а не безобидной конфигурацией.

Связка «документ плюс список» тоже может разойтись

Вместо передачи policy можно сформировать несколько views и связать каждый со списком watchers. Такой вариант уменьшает доступ peer к правилам, но создаёт другую пару объектов. View и authorized-watcher list должны использовать одну версию.

Если список пришёл позже документа, потерял часть участников или расширился по новой snapshot, правильный view попадёт неправильному набору. Нужны общий transaction ID, membership digest, временное окно и правило поведения при неполной паре: не раскрывать, а не угадывать.

Списки бывают персональными, публичными и ad hoc. RFC 5363 отмечает, что URI-list service превращает один request во множество и требует контроля integrity, confidentiality, authorization и amplification. RFC 5360 рассматривает такую трансляцию как consent-проблему.

Адрес списка не доказывает согласие всех его участников. После expansion каждая связь watcher-presentity должна пройти свою проверку. Лог хранит версию состава и индивидуальные результаты, не только общий success.

Центральный hub добавляет ещё одни часы

Clearing House может аутентифицировать peer networks, вести logging, поддерживать group chat и lawful interception. Централизация уменьшает количество двусторонних соглашений, но добавляет промежуточный storage, очередь и clock.

Лог hub подтверждает только его наблюдение. Он может видеть вход, но не поздний отказ назначения; URI списка, но не удалённую expansion; полный документ, но не view после filtering. Retries могут быть deduplicated и потерять последовательность.

Нужен reconciliation: origin сообщает отправленные операции, hub — принятые, преобразованные и переданные, destination — полученные и обработанные. Разница объясняется retry, expiry, deduplication и policy rejection. Центральность не делает одну запись окончательной.

Успех протокола имеет конечную область

RFC 5344 включает pager-mode SIP MESSAGE и session-based MSRP. SIP response — квитанция компонента, не человека. MSRP имеет session и собственные transaction/report semantics. Их нельзя сводить к одному delivered.

Полезная лестница: routed to peer, accepted by remote service, delivered to client, displayed или acknowledged, human response. Для presence: publish, subscription admission, policy decision, view generation, NOTIFY, client state. Неизвестные ступени не наследуют зелёный статус канала.

Даже доставленная запись может поменять смысл. RFC 6271 приводит отображение “Do Not Disturb” в “Busy” между proprietary systems. Следует фиксировать input, mapping version и output; корректный PIDF syntax не удостоверяет semantic fidelity.

Граница исследования

Источники определяют модели, требования и механизмы IETF. Они не доказывают текущее поведение конкретного продукта, peer, hub или аккаунта. Сценарии — проверки архитектуры, а не сообщения об инцидентах. RFC 5344 является Informational и оставляет security solutions за рамками.

Стандарт показывает, какие связи надо измерить. Факт deployment подтверждают только его receipts.