International organisation for standardisation organisation internationale de normalisation

M16577:

WD 1.1. accepted but with the modifications of the contribution above.

M16644:

MPEG-U Howto, for inclusion as an informative annex

- Downloadable UI: Retrieval by a TV of a widget package from either a DLNA device or a web server. This use case should be improved to show the advantage/added-value of MPEG-U. It could be using MPEG-4 LASeR or BIFS scene.

- Remote UI: Widget transfer between devices. This use case should be improved to show more the added value of MPEG-U. For example, using the context information or by giving more details on how the images are transfered.

- Distributed UI: A widget is made of 2 parts and one part is moved to a remote device while the other part stays on the initial device. Some sentences to be improved but the implementation should describe better the communication and use of messages between devices.

- Widget Personalization

- Widget Adaptation: this example uses a lot of metadata to detect. Some sentences comparing MPEG-U with other solutions could be improved.
One of the use cases should include how to use the context information or a new use case should be added.
If the standard is public, it would be fine to have it as an informative annex. If not, we should not duplicate text to avoid desynchronization. If we have two documents, then it would be complicated to maintain, we would prefer one public document.
A video should cover these use cases.
m16726:

MPEG-U improvements for widget security

The contribution presents network and application security considerations and then discusses some specific use cases.

Following these use case, we understand that we may want to indicate that the widget needs a secure saving of some sensitive context information.

We also see that exchanging secured data between widgets is a difficult issue. It involves trusting widgets or trusting widget managers.
We agree that they are use cases for secure communication between widgets without relying on trusted widget managers. To implement such use case, we don't know if there is a need for tools in our spec.
There may be use cases where we want to trust widget managers and let them handle the secured communication. In that case, we need to investigate whether we need to indicate at the interface level, or at the message level, or at the output level, that the data sent by the widget should be communicated through secured channel.
The contribution presents requirements that authors should be able to prevent a widget to be aggregated or to be further distributed, or the opposite that widgets can be trusted for aggregation or distribution. This needs further investigation.
The contribution recommends using the W3C Widget 1.0: Digital signatures spec when security is need. This is accepted. We will add a section in the spec to describe how people can use Digital Signature for widget auhtenticy and integrriy and that the current spec does not provide tools for secured data communication and therefore it should be handled at the widget level or it may be implementation specific.