OPEN PLATFORM INITIATIVE
for
MULTIMEDIA ACCESS
(OPIMA)
Call for Proposals for Technologies
| Please note that proposers
should: • Notify their intention to submit a proposal on or before close of business of 24 August 1998 to leonardo.chiariglione@cselt.it • Send their contribution by email on or before close of business of 31 August 1998 to leonardo.chiariglione@cselt.it. The contribution must be in Word 6, HTML or PDF format. |
When submitting a proposal, authors must acknowledge that in case part or all of their proposal is included in OPIMA specifications and the included part contains patented items which are necessary for the implementation of OPIMA specifications, the IPR owners will accept the IEC/ISO/ITU practice for patented items in international standards. This amounts to either giving free use of the patented items, or giving licence on fair and reasonable terms and on a non-discriminatory basis.
Model for Intellectual Property Rights Statement
The following model holds the key language of the IEC/ISO/ITU Intellectual property rights statement. It may be used as a basis to provide the required IPR statement:
<Company Name> hereby declares that it is prepared to license its IPR, both granted and pending, which is necessary to manufacture, sell and operate implementations of OPIMA specifications.
<Company Name> also declares that it is willing to grant a licence to an unlimited number of applications throughout the world under reasonable terms and under conditions that are demonstrably free of any unfair competition.
<Signature>
<Name and function of responsible company representative>
This Call for Proposals is an invitation to submit proposals for platform technologies needed to realise the OPIMA goal of a system where the consumer is able to obtain a terminal and begin to consume and pay for multimedia services, without having prior knowledge of which services would be consumed, in a simple way such as by operating a remote control device.
These proposed technologies are intended to be utilised in the development of a specification that may be used by content and service providers, and by manufacturers to enable services satisfying the definition above. The time scale of specification development is 1999.
Those intending to submit a proposal(s) should consult Section 6 of this Call for Proposals.
Recent developments in digital techniques have stimulated the deployment of digital services that are attractive to users by virtue of their ability to offer improved functionalities compared to those of analogue technologies.
Protection of content is of paramount importance for the success of these new services. The current environment is one in which content protection systems are designed and deployed on a proprietary basis. While this satisfies the concerns of individual service providers, it often discourages consumers because devices employed to decrypt signals can perform their function only for one or a reduced number of service providers. Therefore users can access different service providers only by acquiring multiple terminal devices.
The Open Platform Initiative for Multimedia Access (OPIMA) is based on the belief that the multimedia market would see a faster development if a standardised technology existed that would allow a user to consume and pay for services, without having prior knowledge of which services would be consumed, in a simple way such as by operating a remote control device. Fig. 1 below graphically depicts the goal of the OPIMA initiative in which the consumer is able to use a single terminal to access a multiplicity of services from multiple providers.
Fig. 1 - Graphical representation of the OPIMA goal
Even though the technology required to make possible the ideas described above exists, it is necessary to standardise some aspect of it in order to make the system work in an open manner. The international multi-industry OPIMA initiative has been established with the goal of achieving this standardisation. In this document "standardisation" is used to mean reaching industry agreement. It is envisaged that the OPIMA specification may be submitted to appropriate formal standards bodies for ratification.
This document has been developed by a group of industry representatives from different countries and different components of the multimedia industry. It contains a list of possible applications and a list of requirements that it is believed need to be satisfied if the listed applications are to be supported. A very general reference model is given along with an analysis of how some of the existing solutions map onto the reference model.
The list of applications provided in this document is not necessarily exhaustive, and proposers may submit further applications if they feel that these would extend and improve the value of the specification. In this case proposers are invited to draw the attention to any additional requirements which arise from the additional applications.
The reference model has been kept at a very general level in order to minimise constraints placed upon any technology that a proposer may think appropriate. On the other hand proposers are invited to make the model more specific by providing further levels of detail of any technological components which would be appropriate for the attainment of the OPIMA goal.
This Call for Proposals is being widely disseminated to industry representatives and a wide range of responses is anticipated. At the September 1998 meeting the responses will be analysed and the technical work to develop the specifications will start. Current plans are that specifications will be frozen in September 1999.
While participants in the OPIMA initiative believe in the positive effect of the specifications on the development of the multimedia market, it is appreciated that different business models may require the use of proprietary systems. OPIMA has no intention of taking any action which would lead to the specifications becoming mandatory.
Participants in the OPIMA initiative are aware of the challenging nature of the current undertaking and invite all industry representatives sharing the OPIMA goal to join in this exciting technical development.
An electronic copy of this Call for Proposals can be found at
http://www.cselt.it/ufv/leonardo/opima
There is currently no plan to have a further call on the specific subject of this document. Therefore proposers should ensure that their contributions are submitted during this opportunity and comply with the deadlines specified.
The services mentioned in this section serve as examples from which the requirements for the platform are derived. The specifications that OPIMA develops are targeted at supporting these services.
Note that while these examples imply certain business models, they do not make any assumption on the method of payment.
Support for the following services and service models is required:
Additional services exist, which form an extension of the services mentioned under ‘Required’, and can be called ‘Optional’. The following can be noted about these ‘optionally supported services’:
These optionally supported services include:
Currently a consumer who wants to access services from multiple providers is forced to have multiple terminals with different interfaces. This is an expensive and confusing situation, which slows down the adoption of digital services. The OPIMA initiative was launched to address this problem.
The OPIMA platform is primarily targeted to benefit consumers and service providers. Other players in the value network like rights holders, infrastructure and hardware providers may benefit from the platform as well, however always bearing in mind the benefits for the primary targets.
To encourage the provision of a greater selection of content to the consumer, the platform should guarantee the content providers’ interests also through secure content management and protection and assurance of payment.
For a consumer it is of great benefit to have access to a platform that allows consumption of and easy payment for services, without having prior knowledge which services he would like to consume. For ease of use, these services should be provided on a single piece of equipment that is future-proof, following a consistent approach, controlled in a simple way such as by operating a remote control device. This consistent approach to services also relieves the consumer of complicated interaction concerning matters like authentication and payment.
For the service provider there is a standard interface to interact with all the terminals for all issues that deal with authentication, transaction processing and the like. Further, service providers could benefit from functionality like audits, polling, etc.
For the hardware manufacturers the OPIMA proposal offers the benefits of an open non-proprietary platform allowing fair competition. This of course also benefits the consumer.
It is recognised that the existence of such a platform would maximise the willingness of end users to consume content. This in turn would maximise content provisioning and globally enhance the role of all legitimate actors in the value network. The example of the GSM (Global System for Mobile) network and terminals has shown how standardisation can lead to economy of scale and enhanced service provision. It should be kept in mind, however, that the solution must be commercially viable and acceptable to the essential players in the network whose interests are impacted by any such solution.
It is important to note that OPIMA will propose specifications that interested parties are free to adopt. OPIMA does not intend to take any action which would lead to the specifications becoming mandatory.
This section provides the requirements that guide the development of the OPIMA specifications. At the same time, it gives requirements for responses to this Call for Proposals (CfP). Sometimes a distinction is made between required support (usually denoted by the word ‘shall’) and optional support (usually expressed by using ‘may’).
The platform shall be as open as possible. In particular, the platform:
The proposed platform needs to be secure and trustworthy. This means that:
If different levels of security and robustness against piracy are allowed, systems with lower security levels shall never be able to compromise systems with higher security levels.
The platform shall support access control by
The platform shall support service models in which the user’s identity is not disclosed to the service provider and/or to other parties.
This section lists requirements in the area of the type of connection and the form of interaction. Like before, there are requirements that must be supported, and extensions that, while they do not address the immediate focus of this Call for Proposals, do increase the value of the proposal.
The following types of connection shall be supported:
a. Broadcast, with the following return channel characterisations:
b. Interactive, with the following return channel characterisations:
It is understood that these models and their sub-categories are not mutually exclusive.
Along a slightly different axis describing the connection, the platform shall be able to support:
Along the same axis, proposals may also support:
1. Many-to-many, like in multi-party games, in which value is at stake.
The platform shall at least support:
In addition, it may also support:
The platform shall allow a wide range of transaction models. At least the following types of transactions shall be supported:
Both on-line and off-line connection modes are foreseen with these types of transactions. Please indicate which types of transactions are supported for each of the connection modes.
Note: again it is recognised that these transaction models are not mutually exclusive.
A device is a system that is used to access and consume information. In principle, the platform shall support any device that can be used to consume multimedia services. At least the following devices need to be supported:
Support for other (future) multimedia devices may also be considered.
The platform shall support mobility. In particular, it shall:
While user mobility could be provided through ‘personalisation’ and the usage of ‘user profiles’, this issue is considered to be outside the scope of this Call.
The focus of OPIMA is currently on the relationship between
OPIMA recognises that many other roles exist in the value network. The platform shall not exclude the interests of these parties from being served.
While this Call for Proposals is not focused on these other parties, proposers are asked to state how their proposal affects the position of these other parties. Also, OPIMA asks proposers to assess how silent OPIMA and the proposed solution can be about the existence of these parties.
These parties include:
It is understood that several of these roles can be unified in one entity.
The figure below is a representation of the system addressed by OPIMA specifications. It comprises four entities: the Service Provider System (SP), the Service Provider Support (SP') as seen from the end-terminal perspective, the trusted middleware (TMW); and the Smart Card (SC). In principle, OPIMA specifications can address any subsystem in a similar context.
Fig. 2 - OPIMA Reference Model
Notes to the picture:
Relocation of tools. Because OPIMA specifications have to satisfy business and service models of multiple industries, OPIMA tools need not only to be usable in a variety of different systems but also in different parts of the same systems. OPIMA defines its tools in such a way that they can be relocated, whenever this relocation is technically possible and practically meaningful.
OPIMA specifies the minimum. If the OPIMA reference model is mapped onto a particular application, the boundaries shown in the diagram may not be identifiable. As OPIMA addresses a multi-industry environment, it can only produce specifications of tools with the minimum of detail needed for interoperability.
The OPIMA architecture is intended to have longevity. The technologies used by OPIMA systems are targets for attack by illegal operators and interests. Therefore, the technology and the nature of the tools that will be used by OPIMA conformant systems require flexibility and the ability to replace components as they are compromised or when better technology becomes available.
The following assumptions reflect a basic rationale behind the elements of the OPIMA reference architecture:
| Assumptions | Benefits |
| 1. A secure and trusted environment in which all implementations are based | Service provider confidence |
| 2. Intellectual property is protected | Content owner confidence |
| 3. No predefined location and implementation of API’s and hardware interfaces | Multiple instantiations of the architecture with a variety of exposed interfaces |
| 4. Existence of user identification module | Unique identification of users whilst protecting privacy |
| 5. Existence of a secure dynamic (distributed) registry for hardware and software interfaces | Uniform manufacturing; Local configuration and personalisation |
Smart Card (SC)
The smart card is viewed as the user identification and service enabling module. The smart card may be provided to a consumer by a Service Provider or an independent vendor. It should not be limited to enabling access to a single service provider or to a single application. The smart card should be a secure environment in which the consumer is confident of its integrity. The currently known interface for smart card technology is given in ISO 7816 and its subchapters.
Service Provider System (SP) and Service Provider Support (SP')
The service provider is an entity which presents a unified image to a consumer who wishes to consume the services or products offered by the service provider. A service provider may have unique and proprietary applications requirements and interfaces. These are made transparent to the consumer by a secure download technology enabled by an OPIMA compliant terminal. This is accomplished by the presence of a generic (and secure) service provider support function (SP') in combination with a trusted middleware component (TMW) that is resident in each OPIMA compliant terminal at the time of manufacture.
Legitimate Third Party
A legitimate third party (LTP) is an entity whose presence in the system is authorised. This excludes unauthorised third parties such as pirates. The presence of an LTP is optional.
Trusted Middleware (TMW)
Trusted Middleware (TMW) is the core element in the system’s ability to provide secure and trusted services. Only a certified middleware component has the ability to incorporate and certify additional or replacement functionalities including replacing itself in a trusted manner.
The trusted middleware component is capable of communicating with the smart card and the service provider support functions. The trusted middleware component manufactured within each OPIMA terminal contains the necessary functions to facilitate the addition of the Service Provider elements of the TMW. This can be achieved via secure download or other trusted methodology. The basic TMW, without any additional elements, will allow the operation of the basic functions for which the terminal is intended. For example, a digital television without these additional elements can receive and display free TV services.
Functions that are specific to individual Service Providers may be added to the basic TMW. This allows one or more service providers to offer available services on an OPIMA terminal. Security and application protection and management are required when additional service enabling is provided.
The SP' and TMW functionality may be combined in a single entity. If they are not, an interface such as IEEE 1394 may be used.
For the interfaces depicted in the diagram above, the following interfaces are known:
| OPH1 | IEEE 1394 (CPT WG-1) |
| OPH0 | ISO 7816 |
In this section we show how two different implementations can be mapped onto the reference model above.
This section describes the application of a GSM-like Challenge/Response Scenario to the OPIMA Reference Model.
The security services provided by GSM are:
The use of a SIM (Subscriber Identity Module) card is central to the security model of GSM. The GSM system goes through a number of steps to ensure secure use of services:
1. Equipment Authentication
As each GSM Mobile Terminal has a unique identity (IMEI, International Mobile Equipment Identifier); the first step after connection to the service network is to check the terminal is not blacklisted.
2. SIM Verification
The purpose of this step is to increase probability that the SIM is in the hands of the correct user. This is done by prompting the user for a secret code (PIN), which is checked locally on the SIM.
3. SIM Authentication
Authentication involves two functional entities: The SIM card in the Mobile Terminal and the Authentication database of the service provider. Each subscriber is given a secret key, a copy of which is stored in the SIM card and in the Authentication database. During the authentication process, the service provider generates a random number to the terminal. Both the mobile terminal and the service provider then use the random number and the secret key to compute, through a commonly agreed ciphering algorithm a so called Signed Response (SRES), which the mobile terminal sends back to the service provider. If the two computed numbers are the same, the subscriber is authenticated.
For authentication of Internet access over dial-up links where the PPP is used, a similar mechanism is used as defined in RFC 1994.
4. Secure Payload Exchange
The same SRES is then used to compute, using a second algorithm, a ciphering key that will be used for payload encryption / decryption, using a third algorithm.
The process is illustrated by the following diagram:
| GSM | OPIMA |
| SIM | Smart Card / User Identification Module |
| Mobile Terminal (MT) | Consumer Device |
| MT Implementation | Trusted Middleware (TMW) |
| Currently no downloading - SIM Toolkit (future) | SP’ (download) |
GSM’s Subscriber Identity Module corresponds to OPIMA’s Smart Card, or, more generally, a OPIMA User Identification Module.
The OPIMA consumer device, including the software in it, corresponds to the GSM mobile terminal. The essential difference is that GSM terminals currently do not support software download from the service provider (although this is an ongoing development), which is on the other hand a crucial capability of the OPIMA consumer device.
For that reason, the TMW (Trusted Middleware) is mapped to the Mobile Terminal implementation, whereas the SP' element currently has no direct correspondence on the GSM model.
The user authentication procedure allowed by the OPIMA reference model is as follows:
In the following interaction diagram, system elements which only pass information through such as the delivery network and the SP' component, are omitted.
Another possible scenario for use of the OPIMA Reference Model is in providing protection and management of intellectual property, both in content and, potentially algorithms and other components of the environment.
Such uses highlight the potential diversity of the applications, as some intellectual property owners may wish to use only the most rudimentary protection schemes, whilst others may wish to employ much more complex approaches involving both management and protection.
OPIMA User Environment: This could represent, for example, the user’s home appliances, interconnected by a 1394-like bus, as being considered by the Multimedia Home Platform activity of the DVB project.
"1394" bus: Allows establishing of secure point-to-point channels (by performing authenticated key exchange (AKE) and encryption/decryption). [IEEE 1394]
Source: Is a device which receives content from outside the environment (e.g. by broadcast, internet, phone or physical media such as DVD disc). It could be, for example, a receiver or an Integrated Receiver/Decrypter (IRD).
Target: Is a device which is the final destination of the content where the content is consumed. It could be a digital television display or a recording device, such as DVD-RAM.
Decision Module: Is a device responsible for deciding whether the transmission of the content from the source to the target is permitted. In particular the decision module might verify the credentials of the other modules and the proper matching of authorizations to these credentials. These authorizations may come with the content over any of the available channels and must somehow be securely associated with the content. One possible implementation of the decision module is a tamper-resistant smart card which allows periodic upgrades.
Any of the components above could be a software module in a PC.
How does intellectual property management and protection (IPMP) operate in this scenario? In the extreme case (referred to by some as "You Play, You Pay"), used mainly for illustration, the content may come entirely unencrypted, but the decision module may refuse transmission from source to target unless it receives also proper authorisations for this transmission (e.g. a receipt of purchase, which could have been received offline from a retail store or over the phone or stored on a user’s personal smart credit card).
The above scenario can, in principle, be generalized to an arbitrarily complex, dynamic, distributed architecture.
In this architecture the necessary components could be specified by authorizations and/or other modules received from any source, thereby supporting dynamically re-configurable webs of trust. In particular some of the components could be implemented and delivered as software which is then run on trusted virtual machines. In this way the overall system security and flexibility can be increased, forcing the prospective pirate to compromise multiple and possibly dynamic points of the system. The architecture could even support secure intelligent agents e.g. performing negotiations etc. This approach also allows decisions about the optimal configurations of the system to be decided dynamically by market forces.
The Source receives Content (Intellectual Property) from the Delivery cloud in the OPIMA Reference Model (RM). The relevant parts of Source and Target (in this case the IEEE 1394 interface) are part of the Trusted MW which must be integrated into components outside of the OPIMA RM (e.g. a digital TV display). Both Source and Target could be either the SP’ or part of the Trusted MW or a combination of these two. The Decision Module maps to the Smart Card component. In this example the Trusted MW component of the RM is distributed in a number of interconnected Consumer Electronics components.
Parties interested in proposing technology to OPIMA should:
Submissions will be posted on a password protected Web page for access by OPIMA participants. Those who do not wish to have their submission posted should state so in their submission but still need to send an electronic copy to the address above. In this case proposers shall bring 100 paper copies to the meeting place.
Evaluation of the proposals will take place during the next meeting of OPIMA, from 9-11 September, in the USA. The exact place is still to be determined. It is advisable that proposers attend this next OPIMA meeting, as they will be invited to present their proposal and take part in the subsequent discussions. Please contact Leonardo Chiariglione for details on attending the meeting.
Experts participating in OPIMA will evaluate the proposals against the application scenarios mentioned in Section 2 and the Requirements listed in Section 3. An assessment will be made of how well each proposal fits the essential requirements (denoted by "shall" in the sections above) and the optional requirements (denoted by "may"), in that order of importance. The evaluation will be accounted for in an ‘assessment document’.
The evaluation of the proposals will mark the beginning of the collaborative process that will lead to the final OPIMA specifications. This process will start from the technologies submitted in the proposals. Based on the evaluation, this process may involve taking the best proposal ‘as is’ or using elements from different proposals and combining them. In addition, possible missing elements may be developed by OPIMA, if necessary through publishing new Calls for Proposals for these missing elements. As OPIMA is an open forum, proposers are welcome to join OPIMA and take part in the development of these specifications.
The time schedule, leading to the final specifications, is as follows:
| Year | Month | Days | Place | Purpose |
| 98 | 03 | 05-06 | Torino (CSELT) | Kick off meeting |
| 98 | 05 | 11-13 | Paris (Alcatel) | Production of CfP |
| 98 | 09 | 9-11 | US | Evaluation of submissions |
| 98 | 11 | ? | ? | Specification Version 0.1 |
| 99 | ? | ? | ? | technical meetings as required |
| 99 | 09 | ? | ? | Approval of specification |
You are visitor # since 14 May 1998
