ГОСТ Р 57872-2017 Телевидение вещательное цифровое. Система TV-Anytime. Передача метаданных по двунаправленной сети. Технология замены персонального профиля. Основные параметры

ГОСТ Р 57872-2017

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ

Система TV-Anytime. Передача метаданных по двунаправленной сети. Технология замены персонального профиля

Основные параметры

Digital video broadcasting. System TV-Anytime. Delivery of metadata over a bi-directional network. The technology of changing the personal profile. Basic parameters

ОКС 33.170
ОКП 657400

Дата введения 2018-08-01

Предисловие

Предисловие

1 РАЗРАБОТАН Автономной некоммерческой организацией "Научно-технический центр информатики" (АНО "НТЦИ")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 "Связь"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 31 октября 2017 г. N 1586-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 102 822-6-3 V1.6.1 (2012-12)* "Широковещательные и on-line услуги: поиск, выбор и правильное использование контента на персональных системах хранения ("TV-Anytime"); Часть 6: Доставка метаданных по двунаправленной сети; Подраздел 3: Фаза 2 - замена персонального профиля" [ETSI TS 102 822-6-3 V1.6.1 (2012-12) "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 6: Delivery of metadata over a bi-directional network; Sub-part 3: Phase 2 - Exchange of Personal Profile", NEQ]
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

5 ВВЕДЕН ВПЕРВЫЕ


Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

1 Область применения

Настоящий стандарт определяет технологии запросов метаданных и представления данных о персональном профиле клиента на основе IP и web-служб. Настоящий стандарт специфицирует параметры процесса инициации средств для запроса метаданных TV-Anytime из служб метаданных, базирующихся на IP, а также предоставляет сценарии обслуживания.

2 Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий стандарт:

ГОСТ Р 56454 Телевидение вещательное цифровое. Система TV-Anytime. Управление правами и защита информации. Основные параметры

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины, определения, обозначения и сокращения

3.1 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1.1 агрегатор контента (aggregator): Объект (организация), собирающий и обрабатывающий информацию о контенте, службах и их поставщиках.

3.1.2 аттрактор (attractor): Элемент метаданных, который доступен клиенту для помощи в процессе выбора контента с целью привлечения клиента к предлагаемому контенту. Аттрактор может включать в себя заголовок программы и имя актера.

3.1.3 аутентификация (authentication): Процедура надежного подтверждения, что сервер или клиент имеет подлинный сертификат и что сертификат не был отменен, а также средство надежного подтверждения, что сообщение получено из доверяемого источника.

3.1.4 контент (content): Видео- и аудиофайлы, к которым клиент хотел бы получить доступ и которые могут быть сохранены на персональном цифровом рекордере (PDR).

3.1.5 метаданные (metadata): Данные о контенте, такие как название, жанр и резюме телевизионной программы.

Примечание - В контексте TV-Anytime метаданные также включают в себя данные профиля и истории клиента.

3.1.6 персональный (личный) профиль (personal profile): Данные, представляющие интересы и предпочтения клиента.

3.1.7 политика (policy): Логически определенный, исполнимый и тестируемый ряд правил поведения.

3.1.8 принципал (principal): Объект, который идентифицирован провайдером идентификации и который может принимать решения и выполнять операции, связанные с аутентификацией от его имени.

Примечание - Принципалами могут быть отдельные клиенты, группы лиц, корпорации или другие юридические лица.

3.1.9 провайдер атрибутов (attribute provider): Объект, который предоставляет атрибуты, связанные с принципалами, например служба персонализированного профиля.

3.1.10 провайдер (поставщик) (provider): Объект, который поставляет контент или службы в PDR.

3.1.11 провайдер идентификации: Объект, который создает, поддерживает и управляет идентификационными данными для принципалов и обеспечивает аутентификацию другим провайдерам служб в пределах круга доверия.

3.1.12 протокол Диффи-Хеллмана: Криптографический протокол, который дает возможность двум сторонам получить общий ключ шифрования при использовании незащищенного от перехвата канала связи. Полученный ключ используется для шифрования обмена данными с помощью алгоритмов симметричного шифрования.

3.1.13 разрешение местоположения (location resolution): Процесс установления адреса (местонахождения и времени) конкретного экземпляра контента по его CRID.

3.1.14 синтаксис (syntax): Часть языка программирования, которая описывает структуру программ как набор символов.

3.1.15 служба метаданных (metadata service): Служба, которая предоставляет данные TV-Anytime, используя сервер в двунаправленной сети.

Примечание - Форматы данных и протоколов, используемых для доставки сведений, определяются настоящим стандартом.

3.1.16 служба обнаружения (discovery service): Web-служба для поиска поставщиков (провайдеров) атрибутов.

3.1.17 ссылка контента (content reference): Указатель на конкретный элемент контента.

3.1.18 схема метаданных (metadata schema): Идентификатор, ассоциированный с набором схем расширяемого языка разметки (extensible Markup Language), которые в глобальном масштабе идентифицируют эти схемы.

Примечание - Глобальное уникальное пространство имен гарантирует, что имена типов определенных схем в этом пространстве имен не конфликтуют с такими же именами в других местах.

3.1.19 управление доступом (access control): Акт опосредования запрошенного доступа к ресурсу, основанный на знаниях привилегий запрашивающей стороной и атрибутах управления запрашиваемым ресурсом.

3.1.20 хеширование (hashing): Преобразование входного массива данных произвольной длины в выходную битовую строку фиксированной длины.

3.2 Обозначения

В настоящем стандарте применены следующие обозначения:

<EncryptedResourcelD> - зашифрованный элемент идентификации, содержащий зашифрованный ключ;

<TargetNamespace> - абстрактное описание целевого пространства имен WSDL;

<Encryptedkey> - ключ шифрования;

<EncryptedResourcelD> - зашифрованный элемент идентификации, содержащий зашифрованный ключ;

<ExtendedUserDescription> - часть метаданных TV-Anytime;

<Modify> - элемент запроса ресурса;

<Modification> - составная часть элемента <Modify>;

<Query> - элемент запроса ресурса;

<Queryltem> - элемент запроса данных, указывающий, какие данные нужны от ресурса;

<QueryResponse> - элемент ответа на запрос;

<ResourcelD> - элемент идентификации конкретного ресурса;

<Select> - элемент в составе элементов <Query> и <Modify>;

<ServiceType> - элемент идентификации службы профилей клиентов TV-Anytime;

<Status> - элемент, указывающий состояние результата обработки запроса;

<StatusDescription> - элемент, предоставляющий подробную информацию о статусе возврата;

<TVAMain> - элемент, являющийся корневым узлом структуры данных;

<urn: tva:metadata:profile:2007> - целевое пространство имен.

3.3 Сокращения

В настоящем стандарте применены следующие сокращения:

ТВ - телевидение;

CRID - идентификатор ссылки (адреса) контента;

EPG - электронный путеводитель по программам ТВ;

HTTP - протокол передачи гипертекста;

IP - межсетевой протокол.

Примечание - Общее наименование сетевых протоколов, применяемых в сети Интернет;


SOAP - протокол обмена структурированными сообщениями в распределенной вычислительной среде (простой протокол доступа к объектам);

TLS - безопасность транспортного уровня;

URI - универсальный идентификатор информационного ресурса;

URL - унифицированный указатель ресурса (адреса ресурса в сети Интернет);

Web - "мировая паутина" (гипертекстовая система в сети Интернет);

WSDL - язык описания web-служб;

XML - расширяемый язык разметки;

XPath - язык запросов к элементам документов XML;

XSD - описание схемы XML.

4 Тип службы профиля пользователя TV-Anytime

4.1 Определение типа службы

Служба профиля пользователя TV-Anytime - это web-служба, которая обращается к некоторому ресурсу для получения информации о пользователе, обновления этой информации о пользователе или выполняет какие-либо действия в интересах пользователя. Информацией о пользователе могут быть его предпочтения и местоположение. Изменения этой информации ведут к замене профиля пользователя TV-Anytime.

Типы, используемые в службе профиля пользователя TV-Anytime, определены в целевом пространстве имен <urn: tva:metadata:profile:2007>.

Это позволяет средствам, поддерживающим схему XML, проверять достоверность сообщений. На типы, определенные в ГОСТ Р 56476, можно ссылаться в пространстве имен транспорта (с использованием механизмов использования схем XML согласно [1], [2]). Схема и классификация схемы должны быть в соответствии с приложением А. Схема ("Schema") XML должна быть в соответствии с А.1 (приложение А). Она содержит механизмы импорта схемы XML, которые позволяют выполнять ссылки в пространстве имен транспорта для определения необходимых типов и фрагментов схемы XML.

Фрагменты схемы, определенные в этом пространстве имен, специфицированы в 5.1-5.3. Элемент <ServiceType> используется для идентификации службы профиля пользователя TV-Anytime. Должно обеспечиваться постоянство этого URI во всех реализациях службы профилей пользователей TV-Anytime. Рекомендуется обеспечивать соответствие этого URI пространству имен <TargetNamespace> абстрактного описания WSDL для службы.

Экземпляр службы - это физический экземпляр конкретного типа службы профиля пользователя TV-Anytime. Каждый экземпляр службы размещается провайдером, который идентифицируется URI.

Пример экземпляра службы - это "конечная точка" SOAP поверх HTTP, предлагающая персонализированную службу EPG. Экземпляр службы предоставляет интерфейс протокола для набора ресурсов. Ресурсом являются данные, относящиеся к пользователю, или служба, действующая в интересах пользователя. Запрос в сообщении от пользователя к экземпляру службы включает в себя идентификатор ресурса (т.е. URI), с которым должен взаимодействовать экземпляр службы. Ресурс имеет доступ к связанным с ним политиками управления. Политики управления доступом, как правило, находятся в компетенции объектов, связанных с ресурсом. Политика управления доступа к ресурсу должна выполняться экземпляром службы.

4.2 Обнаружение местоположения службы идентификации

Провайдер службы использует службу обнаружения для установления местоположения конкретной службы идентификации пользователя. Служба обнаружения позволяет оперативно и безопасно обнаруживать объекты службы идентификации пользователя и реагировать на основе разрешения с описанием службы требуемой службы идентификации. Таким образом, провайдер служб может получить доступ к частям идентификационной информации пользователя, которая может быть в распоряжении нескольких провайдеров и которые могут предлагать пользователю службы, используя его профиль.

Настоящий стандарт параметры службы обнаружения не устанавливает.

4.3 Модель данных TV-Anytime

В модели данных TV-Anytime профиль пользователя определяется в соответствии с изложенным в настоящем подразделе.

Метаданные пользователя формируются на основе истории использования, содержащей список действий, выполненных пользователем за период наблюдений. Указанный список может впоследствии использоваться для формирования пользовательского предпочтения.

Сбор и представление информации истории использования выполняются в стандартизованном формате, актуальном для нескольких областей применения и сценариев использования, представленных ниже:

- отслеживание и контроль контента, просмотренного пользователем;

- создание персонализированного телегида путем отслеживания привычек просмотра пользователя;

- продажа рекламодателям истории просмотра;

- отслеживание и мониторинг использования контента для более эффективного развития (усовершенствования) контента;

- продажа провайдеру служб данных статистики;

- вознаграждение пользователя за его согласие на передачу данных его истории использования провайдерам контента.

Схема истории использования TV-Anytime основана на схеме описания UsageHistory. UsageHistory описывает историю потребления аудиовизуального контента в виде списков действий, выполняемых пользователем за период наблюдения.

Семантика схемы описания UsageHistory представлена в таблице 1.


Таблица 1 - Семантика схемы описания UsageHistory

Семантика схемы описания UserActionHistory представлена в таблице 2.


Таблица 2 - Семантика схемы описания UserActionHistory

Схема описания UserActionList нормирует список элементов действий пользователя, структурированный в соответствии с конкретным типом действия. Каждый UserAction связан только с одной программой или объектом контента.

Схема описания UserActionList описывает несколько списков действий пользователей, каждый из которых является журналом конкретных действий пользователя, например "Запись" или "Воспроизведение", относящихся к аудиовизуальному контенту.

Схема описания UserAction предоставляет подробную информацию об отдельных действиях пользователя, включая время появления, продолжительность, связанный CRID программы, расположение программы и ссылки на соответствующие описания и материалы контента.

Семантика дополнительного элемента схемы описания UserAction представлена в таблице 3.

Схема XML, определенная таким образом, указывает данные, которые служба может использовать. Модель данных определяет данные и структуру данных. Как правило, эта структура является иерархической и имеет корневой узел <TVAMain>. Частью метаданных TV-Anytime, имеющих отношение к службе изменения профиля пользователя TV-Anytime, является <ExtendedUserDescription>.


Таблица 3 - Семантика дополнительного элемента схемы описания UserAction

5 Интерфейс сообщения профиля клиента TV-Anytime

5.1 Общие вопросы

Настоящий раздел определяет параметры двух протоколов: для запроса данных и изменения данных.

Оба эти протокола используют шаблон обмена сообщениями "запрос/ответ". Сообщения, указанные в настоящем стандарте, переносятся в теле SOAP.

5.1.1 Ресурсы

Протоколы для выполнения запросов и изменений данных имеют определенную иерархию для доступа к данным.

На первом уровне иерархии выбираются необходимые ресурсы. Например, ресурсом может быть личный профиль определенной персоны. Множественные ресурсы могут быть доступны в одном запросе, но запросы и изменения не могут смешиваться в одном сообщении запроса.

В сообщении запроса каждого ресурса должен быть элемент <Query> (запрашивать) или элемент <Modify> (изменять) ресурс. Элементом ресурса является элемент <ResourcelD> или элемент <EncryptedResourcelD>. Листинг декларации "ResourcelDGroup" показан на рисунке 1.

Рисунок 1 - Листинг декларации "ResourcelDGroup"

Рисунок 1 - Листинг декларации "ResourcelDGroup"

В таблице 4 представлены определения типов и атрибутов.


Таблица 4 - Определения типов и атрибутов

Если элемент <ResourcelD> принимает значение "urn:liberty:isf:implied-resource", этот элемент может быть исключен из элемента, содержащего <Query> или <Modify>. Во всех остальных случаях должен присутствовать элемент <ResourcelD> или элемент <EncryptedResourcelD>.

Схема определяет элемент "EncryptedResourcelD", предназначенный для транспортировки идентификатора закодированного ресурса.

"EncryptedResourcelD" содержит "ResourcelD", который был зашифрован, и зашифрованный ключ, использованный для шифрования "ResourcelD". Использование "EncryptedResourcelD" необходимо по соображениям конфиденциальности. Если для элемента "Encryptedkey" используют непредсказуемый код, то каждое открытие службы пользователя позволит получить другой идентификатор.

Примечание - Ключ должен быть уникальным для каждого пользователя.

5.1.2 Элемент <Select>

Второй уровень иерархии отбора ресурсов находится внутри элементов <Query> и <Modify>. Сообщение содержит запрос более подробного описания того, что предполагается получить при доступе в указанном ресурсе. Это указано в элементе <Select>. В качестве примера, когда ресурс является личным профилем, в элементе <Select> можно указать "UserPreferences". При запросе <Query> запрашиваются все "UserPreferences", в случае запроса <Modify> запрашивается изменение "UserPreferences".

Когда запрашивается или изменяется только часть "UserPreferences", элемент <Select> должен быть направлен только на эту часть. Части, которые не должны изменяться, должны быть переписаны с использованием существующих значений, когда передана полная "UserPreferences". Элементы <Query> и <Modify> могут содержать в собственной субструктуре несколько элементов <Select>. Поэтому при использовании одного и того же элемента <Query> или <Modify> могут быть доступны разные части ресурса.

Элемент <Select> указывает на места в описании метаданных пользователя TV-Anytime, при этом для элемента <Select> рекомендуется использовать строку, содержащую выражение XPath. Это правило не требует поддержки полного документа XPath. Каждый профиль службы обмена TV-Anytime следует ограничивать необходимым набором выражений XPath (при отсутствии необходимости в применении полного XPath).

Предопределенный набор аббревиатур выражений "Select Path", который будет использоваться вместо полных выражений XPath, приведен в таблице 5.


Таблица 5 - Предопределенный набор аббревиатур выражений "Select Path"

Успешно выполненные запросы (далее - успешные запросы) всегда содержат элемент <TVAMain>, при возврате они содержат данные, определенные параметрами в элементе <Select>.

Листинг схемы элемента "SelectType" представлен на рисунке 2.

Рисунок 2 - Листинг схемы элемента "SelectType"

Рисунок 2 - Листинг схемы элемента "SelectType"

Семантика схемы элемента "SelectType" представлена в таблице 6.


Таблица 6 - Семантика схемы элемента "SelectType"

5.1.3 Ключевые слова обнаружения

Ключевые слова обнаружения используются (опционально) для обозначения вариантов служб профиля пользователя TV-Anytime. Определения ключевых слов обнаружения представлены в таблице 7.


Таблица 7 - Определения ключевых слов обнаружения (опционально)

5.1.4 Элемент <Status>

Сообщение, переданное в ответ на запрос (далее - ответное сообщение), содержит один или несколько элементов <Status>, указывающих состояние результата обработки запроса. Элемент <Status> имеет атрибут кода, который содержит статус возврата в виде строки. В таблице 8 определены коды статуса, которые будут использоваться в качестве значений атрибута кода. Схема классификации элемента <Status> должна быть в соответствии с А.2 (приложение А).


Таблица 8 - Определения кодов статуса

Атрибут кода верхнего уровня внутри элемента <Status> содержит значение "ОK" или "Failed". Элемент <Status> может содержать элемент "StatusDescription", предоставляя более подробную информацию о статусе возврата. В таблице 9 приведены более подробные сведения о статусе возврата. Если запрос по какой-то причине не выполняется, то атрибут "requestlDRef" элемента <StatusDescription> содержит значение "requestlDRef" атрибута проблемного элемента в сообщении запроса.

На рисунке 3 приведен листинг элементов "Status" и "StatusDescription".

Рисунок 3 - Листинг элементов "Status" и "StatusDescription

Рисунок 3 - Листинг элементов "Status" и "StatusDescription"

В таблице 9 приведена семантика элементов "Status" и "StatusDescription".


Таблица 9 - Семантика элементов "Status" и "StatusDescription"

5.1.5 Идентификаторы связи запросов и ответов

Для связывания запросов и ответов используются различные типы атрибутов идентификаторов. Ответные сообщения связаны с запросами, использующими атрибуты "MessagelD" и "inResponseToMessageld", которые присутствуют в заголовке SOAP [1], [2]. Службы должны включать в себя атрибуты "MessagelD" и "inResponseToMessageld" во всех сообщениях запроса и ответа, определенных в настоящем стандарте. Внутренние сообщения, атрибуты "ItemId" и "itemlDRef" используются для связывания информации внутри ответных сообщений на детали сообщений запроса.

Образцы объектов приведены в приложении Б. Образец заголовка SOAP приведен в Б.1 (приложение Б).

Примечание - Oтвeтныe cooбщeния нe coдepжaт элeмeнты <RESOURCEID> или <EncryptedResourcelD>, поэтому они не могут быть использованы для этого. См. определения и правила обработки элементов <Query> и <Modify> для получения более подробной информации.

5.1.6 Атрибут метки времени "timestamp"

Ответное сообщение может содержать метку времени "timestamp".

Метка выполнена так, что запрашивающая сторона может проверить наличие каких-либо изменений после получения ответа или внести изменения, которые будут успешными, если не было никаких других изменений, сделанных после того, как метка времени была получена.

5.2 Параметры процессов запросов данных

Поддерживаются два типа запросов данных: один для получения текущих данных, а другой для запроса только измененных данных. Эти два типа запросов могут присутствовать вместе в одном и том же сообщении. Ответ может содержать данные с общими техническими характеристиками или без общих технических характеристик, в зависимости от запроса. Для некоторых элементов некоторые общие атрибуты возвращаются всегда.

5.2.1 Параметры схемы запроса <Query>

Листинг схемы запроса данных <Query> представлен на рисунке 4.

Рисунок 4 - Листинг схемы запроса данных <Query>

Рисунок 4 - Листинг схемы запроса данных <Query>

Схема запроса данных <Query> представлена в таблице 10.


Таблица 10 - Семантика схемы запроса данных <Query>

Пример схемы "Query" приведен в Б.2 (приложении Б).

5.2.2 Параметры схемы ответа на запрос <QueryResponse>

Листинг схемы ответа на запрос <QueryResponse> представлен на рисунке 5.

Рисунок 5 - Листинг схемы ответа на запрос <QueryResponse>

Рисунок 5 - Листинг схемы ответа на запрос <QueryResponse>

Семантика схемы ответа на запрос <QueryResponse> представлена в таблице 11.


Таблица 11 - Семантика схемы ответа на запрос <QueryResponse>

Возвращаемый экземпляр документа должен быть схемой XML и действительным по отношению к схемам метаданных, агрегированным в файлы:

- tva_mpeg21_tva.xsd;

- tva_metadata_3-3_v131.xsd.

Расширенная схема метаданных импортирует следующие файлы:

- tva_mpeg7.xsd;

- tva_metadata_3-1_v151.xsd;

- tva_interstitial_3-4_v131.xsd;

- xml.xsd;

- tva_rmpi_5-1_v141.xsd.

Файлы схемы замены профиля пользователя TV-Anytime должны быть в соответствии с приложением В.

Кроме того, каждый экземпляр документа должен содержать соответствующий "TVAIDType", чтобы обеспечить полное разыменование всех узлов "TVAIDRefType" внутри экземпляра документа. В случае успеха элемент данных "Data" содержит информацию, указанную в элементе "Select". Сообщение запроса может содержать несколько элементов <Query>.

Пример схемы "QueryResponse" приведен в Б.3 (приложение Б).

5.3 Параметры процессов изменения данных

В общем случае данные, сохраненные с помощью службы данных, могут получить начальные значения, существующие значения могут быть заменены новыми значениями и, кроме того, данные могут быть удалены. Принципал может выполнять эти изменения непосредственно в службе данных, используя предоставленный интерфейс клиента, но эти модификации могут быть сделаны и другими провайдерами служб. Элемент <Modify> поддерживает все эти операции для провайдеров служб, которые хотят изменить данные, хранящиеся в службах данных.

5.3.1 Параметры схемы <Modify>

Листинг схемы <Modify> представлен на рисунке 6.

Рисунок 6 - Листинг схемы <Modify>

Рисунок 6 - Листинг схемы <Modify>

Семантика схемы <Modify> представлена в таблице 12.


Таблица 12 - Семантика схемы <Modify>

5.3.2 Ответ об изменении

Элемент <ModifyResponse> содержит элемент <Status>, который описывает состояние результата обработки запроса <Modify>. Атрибут метки времени "timestamp" дает значение времени, которое может использоваться для проверки наличия изменений с момента этого изменения, и атрибут "itemlDRef" для сопоставления элементов <ModifyResponse> и <Modify> в запросе.

Листинг схемы <ModifyResponse> представлен на рисунке 7.

Рисунок 7 - Синтаксис схемы <ModifyResponse>

Рисунок 7 - Синтаксис схемы <ModifyResponse>

Семантика схемы <ModifyResponse> представлена в таблице 13.


Таблица 13 - Семантика схемы <ModifyResponse>

Сообщение запроса может содержать несколько элементов <Modify>.

6 Конфиденциальность и безопасность

6.1 Требования конфиденциальности

6.1.1 Введение

Информация о демографии, о личных предпочтениях и об истории просмотров является особенным инструментом. Простое указание личного вкуса позволяет наблюдателю иметь представление о личных качествах клиента. Когда детализированный статус и детализированная информация о местоположении добавляются к личному профилю, ошибки управления такой персональной информацией становятся критичными.

6.1.2 Авторизация наблюдателей

Клиент должен иметь возможность определять, кто может запросить его личный профиль. Следствием этому является необходимость проверки входящих запросов профиля, чтобы гарантировать, что запрашивающий их объект был уполномочен принципалом получать информацию личного профиля. Реализация и обслуживание любых списков авторизации нормированы для отдельных протоколов. В 6.1.3-6.1.5 описаны механизмы, определяющие возможности доступа запрашивающего пользователя к данным службы замены профиля и возможности их использования.

6.1.3 <Consent>

Блок с заголовком <Consent> позволяет пользователю службы замены профиля информировать провайдера этой службы, что они получили согласие принципала на получение данных.

6.1.4 <UsageDirective>

Блок с заголовком <UsageDirective> позволяет принципалу указывать ограничения возможности использования представленных данных. Семантика этого блока будет включать URL, специфицированным в блоке <UsageDirective> в представляемом ответе. Указанный URL будет ссылаться на описание набора обязательств, запрашивающего пользователя службы замены профиля, которые должны выполняться.

6.1.5 "Options"

Провайдер служб профиля пользователя имеет возможность указывать информацию, содержащуюся в метаданных пользователя, которую можно заменять и, в частности, определять возможность совместного использования идентификатора пользователя. Это выполняется определением параметров в предлагаемых ресурсах, которые публикуются во время обмена сообщениями SOAP. В этом смысле элемент "Options" может быть принят в качестве выражения возможностей (вариантов) предоставления ресурса, которое обеспечивает подсказки для запрашивающей стороны о доступности, определенных данных или операций ресурса, например о доступности идентификатора пользователя.

6.2 Требования безопасности

Должны поддерживаться механизмы безопасности транспортного уровня (TLS), обеспечивающие защиту сеанса связи при условии поддержки клиентом и сервером механизма TLS.

Должны поддерживаться следующие основные процедуры механизма безопасности:

- согласование доступных для применения алгоритмов шифрования и хеширования между сервером и клиентом;

- инициализация безопасного канала аутентификации между сервером и клиентом;

- взаимная аутентификация сервера и клиента;

- формирование секретного сеансового ключа по протоколу Диффи-Хеллмана;

- шифрование и дешифрование передаваемых данных служб TV-Anytime.

Рекомендуется обеспечивать возможность поддержки безопасности web-служб и, в частности, безопасности сообщений SOAP применением нескольких моделей с несколькими:

- форматами безопасности;

- доменами доверия при аутентификации;

- форматами подписи;

- форматами технологии шифрования.

Приложение А (обязательное). Схема и классификация схемы

Приложение А
(обязательное)

А.1 Схема ("Schema") XML

Листинг схемы ("Schema") XML представлен на рисунке А1.

Рисунок A.1 - Листинг схемы "Schema"

Рисунок A.1 - Листинг схемы "Schema", лист 1

Рисунок A.1, лист 2

Рисунок A.1, лист 3

А.2 Схема классификации элемента <Status>

Листинг схемы классификации элемента <Status> представлен на рисунке А.2.

Рисунок А.2 - Листинг схемы классификации элемента <Status>

Рисунок А.2 - Листинг схемы классификации элемента <Status>

Рисунок А.2, лист 2

Приложение Б (справочное). Образцы объектов

Приложение Б
(справочное)

Б.1 Образец заголовка SOAP

Листинг образца заголовка SOAP представлен на рисунке Б.1.

Рисунок Б.1 - Листинг образца заголовка SOAP

Рисунок Б.1 - Листинг образца заголовка SOAP

Рисунок Б.1, лист 2

Б.2 Пример схемы "Query"

Пример листинга схемы "Query" представлен на рисунке Б.2.

Рисунок Б.2 - Пример листинга схемы "Query"

Рисунок Б.2 - Пример листинга схемы "Query"

Б.3 Пример схемы "QueryResponse"

Пример листинга схемы "QueryResponse" представлен на рисунке Б.3.

Рисунок Б.3 - Пример листинга схемы "QueryResponse" (ответа на запрос)

Рисунок Б.3 - Пример листинга схемы "QueryResponse" (ответа на запрос)

Приложение В (обязательное). Файлы схемы замены профиля пользователя TV-Anytime

Приложение В
(обязательное)

Схемы замены профиля пользователя TV-Anytime, перечисленные в настоящем стандарте, были агрегированы в серии файлов xsd:

- tva_profile_exchange_6-3_v161.xsd;

- xenc-schema.xsd;

- xmldsig-core-schema.xsd.

Схема метаданных замены профиля пользователя TV-Anytime импортирует другие файлы, которые должны присутствовать для того, чтобы схема могла быть правомочной:

- xml.xsd;

- tva_mpeg7_2008.xsd;

- tva_metadata_3-1_v181.xsd.

Библиография

Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2017