RE: tvapi-ACTION-38: Propose an api spec for conditional access systems

Hello Sunk Hei

I’ve had a chance to look at this again after your explanation during todays call, and would like to make the following points.


·         The CA_system_ID is sufficient on its own to indicate which conditional access system is used by the content/channel and which is supported by a CI card. I don’t believe the CA_PID (from ISO 13818-1 definition of the conditional access descriptor) needs to be exposed to the WebApp.

o   As you said in the call, there is already an isFree<http://w3c.github.io/tvapi/spec/#widl-TVChannel-isFree> attribute in the TVChannel<http://w3c.github.io/tvapi/spec/#tvchannel-interface>. This is a Boolean defined as “MUST indicate whether the TV channel is free to watch.” however it may be best defined as “MUST indicate whether the TV channel is currently free to watch.” It could be that a channel shows some free promotional material prior to paid/scrambled content being presented.

·         Knowing what CA Systems are supported by installed CA cards is useful (also helps to know some state information for each CA card).

o    Perhaps your definition of getCICard is intended to do this, in which case I would suggest it being defined as Promise<sequence<TVCICard>> getCICards ();

o   There would be as many elements in the sequence as there are CI card “slots” in the system

o   The TVCICard interface (at a system level) should include the following (these things are good for user level debugging/troubleshooting – see attached screen shots from my US CableCard based STB)

§  CA_system_ID : as presently defined/used

§  Card_State : one of { inserted, accepted, connected, removed, error }

§  Num_Sessions : the number of concurrent sessions supported by the card

§  System_Name : human readable string for the CA card

§  Software_Version : human readable string of the software version on the CA card

§  Region : string representing the country or region the CA is configured for.

§  Pairing_State : one of { unknown, none, in-progress, ok, bad }

§  There is a lot of other “diagnostic” information that the CA Card could supply to the content source (again see those screen shots). So an opaque JSONified string may be useful to carry it all to the provider (the WebApp need not decipher this)

·         Informing the WebApp that the scrambling state of a channel has changed is certainly important, and I presume that is what your [Proposal 2] around onCIcardchanged; is for.

o   On a channel level there are two types of events that should be reported to the WebApp

§  The content in the channel has transitioned from unscrambled to scrambled and the terminal has no permission to unscramble it

§  The content in the channel has transitioned from unscrambled to scrambled and the terminal has no resource to unscramble it

o   You may optionally want to inform the WebApp that the content has transitioned from scrambled (whether you have permission/resource to descramble or not) to unscrambled. I say optionally because there would be no user impact of this transition and no WebApp action to be taken.


Paul

From: 김성혜 [mailto:shkim@etri.re.kr]
Sent: Tuesday, September 01, 2015 6:41 AM
To: TV Control API Community Group
Cc: 구한승; 박주영
Subject: RE: tvapi-ACTION-38: Propose an api spec for conditional access systems


Dear All,

[Background]
I have studied the CAS requirements.
I have looked at two references, i.e., ATSC CAS for terrestrial broadcast, ISO 13818-1.
ATSC[1] from 4.1.3.5.1 (page 10) defines ATSC_CA_descriptor () as follows:
ATSC_CA_descriptor() {
descriptor_tag (8bits, value= 0x88)
descriptor_length (8bits, uimsbf)
CA_System_ID (16bits, uimsbf)
for ( i = 0 ; i < descriptor_length - 2 ; i++ ) {
private_data_byte 8 bslbf
}
}
The CA_System_ID is defined as This 16-bit unsigned integer indicates the type of CA system applicable for the information conveyed in this descriptor.
So “meta information” regarding CAS is CA_System_ID, which is usually identifies vendor of the CAS system which is used for encrypting/decrypting channels.

ISO[2] from 2.6.16 (page 69) defines Conditional access descriptor as follows:
CA_descriptor() {
descriptor_tag (8bits, uimsbf)
 descriptor_length (8bits, uimsbf)
CA_system_ID (16bits, uimsbf)
reserved (3bits, bslbf)
CA_PID 13 uimsbf
for (i = 0; i < N; i++) {
private_data_byte (8bits, uimsbf)
}
}

CA_system_ID – This is a 16-bit field indicating the type of CA system applicable for either the associated ECM and/or EMM streams. The coding of this is privately defined and is not specified by ITU-T | ISO/IEC.
CA_PID – This is a 13-bit field indicating the PID of the Transport Stream packets which shall contain either ECM or EMM information for the CA systems as specified with the associated CA_system_ID. The contents (ECM or EMM) of the packets indicated by the CA_PID is determined from the context in which the CA_PID is found, i.e. a TS_program_map_section or the CA table in the Transport Stream, or the stream_id field in the Program Stream.

So “meta information” regarding CAS is can be CA_System_ID and CA_PID.

Also there is an important CAS related meta-information in the field of PES (Packetized Elementary Stream) which is called PES_scrambling_control (indicate the scrambling mode of the PES packet payload).
If “ PES_scrambling_control = 0x00 “ indicated not scrambled. Other value are user-defined which means the packet is scrambled.

[Reference]
[ATSC] ATSC Standard: Conditional Access System for Terrestrial Broadcast (A/70 Part 1:2010)
[ISO] ISO 13818-1, Information technology — Generic coding of moving pictures and associated audio information: Systems, 2000

Through this analysis, it is possible to define the APIs for CAS requirements.
The followings are the proposals for the APIs.

[Proposal 1] Meta information for CI Card
Proposal for “Meta information” for CAS CI card is as follows.
The TVCICardInformation dictionary contains the information on the CI Card used to decrypt the encrypted TV channel.
dictionary TVCICardInformation  {
readonly    attribute Boolean          isScrambled;
readonly    attribute DOMString?            casSystemId;
readonly    attribute DOMString?            casPId;
};

isScrambled of type Boolean, readonly
   MUST indicate whether the stream from this TV channel is encrypted(or scrambled).
casSystemId of type DOMString, readonly, nullable
   MUST return the CAS system ID used to decrypt stream from the encrypted TV channel. Note, the value is null, if the value of isScrambled is false.
casPID of type DOMString, readonly, nullable
MUST return the CAS PID of ECM or EMM information for CA System. Note, the value is null, if the value of isScrambled is false or if the system does not support casPID.

Note) isScambled is equivalent to the isFree attribute in the TVchannel.


[Proposal 2] APIs for CAS Requirements
To support [cas], [cas.descrypt] [cas.notifications.change] requirements, it can be defined under TVChannel Interface, since CAS are applied for each TV channel.
But we need to discuss where the methods to support CAS requirements should be defined under TVSource interface or TVChannel interface.
Anyway, proposed methods are as follows.
Interface TVChannel: EventTarget {
:
TVCICardInformation   getCICard();
void    applyCICard (TVCICardInformation card);
attribute EventHandler onCIcardchanged;
   :
}

[New Methods]
getCICard
returns a dictionary of TVCICardInformation which provides meta information of the CI cards used in decrypting encrypted TV channel as long as the information are available.
No parameters
   Return type: TVCICardInformation

applyCICard
   request the tuner to apply CI card with the card parameter.
   Parameter (card)
      Type: TVCICardInformation, Nullable(X), Optional(X)
       Description: Specifies information of CI Card to be applied to the encrypted TV channel.
Return type: void

[Memo from Sung Hei Kim] I am not sure if the system (settop) can use(apply) the specified CI card from the webapp. Normally, CI card that can be used for decryption are already included in the TV stream.

[New Event]
Event Handler: onCIcardchanged
Event name: CI_CHANGE
Event type: TVCICardChangedEvent
Description: Handles the information for the dynamically added/removed common interface (CI) cards.


XX. TVCICardChangedEvent Interface
The TVCICardChangedEvent interface represents the event related to the changes to the CI cards, which can be occur with the add or removal of the CI cards.

Interface TVCICardChangedEvent : Event  {
    readonly attribute TVCICardState    state;
readonly attribute DOMString?            casSystemId;
}

23. Enumerations
Enum TVCICardState  {
     “CIcard-added”,
     “CIcard-removed”
};

Regards,
Sung Hei Kim (ETRI)


[Note Requirements]
[cas] This API SHALL be able to provide the webapps with the meta information of the CI cards as long as those meta information is available. For example, the CAS standards such as DVB-CI, ARIB-CAS... etc.
[cas.decrypt] This API SHALL be able to enable the webapps to apply the CI cards to decrypt the encrypted channel.
[cas.notifications] This API SHALL be able to notify the webapps of the dynamically added/removed Common Interface (CI) cards.
The following event SHALL be supported
[cas.notifications.change] CI_CHANGE

________________________________
보낸 사람 : "TV Control API Community Group Issue Tracker" <sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>>
보낸 날짜 : 2015-07-07 22:54:12 ( +09:00 )
받는 사람 : public-tvapi@w3.org<mailto:public-tvapi@w3.org> <public-tvapi@w3.org<mailto:public-tvapi@w3.org>>
참조 :
제목 : tvapi-ACTION-38: Propose an api spec for conditional access systems

tvapi-ACTION-38: Propose an api spec for conditional access systems

http://www.w3.org/community/tvapi/track/actions/38


Assigned to: Sung Hei Kim