この API は、単純な Clear Key
による復号から、高価値のビデオ（適切なユーザーエージェントの実装がある場合）までのユースケースをサポートします。ライセンス/鍵交換はアプリケーション側で制御され、さまざまなコンテンツ復号および保護技術をサポートする堅牢な再生アプリケーションの開発を容易にします。
この仕様はコンテンツ保護や Digital Rights
Management（DRM）システムを定義するものではありません。代わりに、これらのシステムやより単純なコンテンツ暗号化システムを検出、選択、相互作用するために使用できる共通の API
を定義します。本仕様への準拠のために DRM の実装は必須ではありません。共通のベースラインとして実装が要求されるのは Clear Key システムのみです。
共通 API
は単純なコンテンツ暗号化機能のセットをサポートし、認証や認可などのアプリケーション機能はページ作成者に委ねます。これは、コンテンツ保護システム固有のメッセージングが暗号化システムとライセンスや他のサーバー間の帯外通信を前提とするのではなく、ページによって媒介されることを要求することで実現されます。
実装者は、本仕様で記述されているセキュリティおよびプライバシーの脅威と懸念に対する緩和策に注意を払うべきです。特に、セキュリティおよびプライバシー要件は Key System とその実装のセキュリティおよびプライバシー特性を把握していないと満たせません。8.
Implementation Requirements には基盤となる Key System
実装の統合および使用に関するセキュリティとプライバシーの条項が含まれています。10.
Security は入力データやネットワーク攻撃など外部からの脅威に焦点を当てています。11.
Privacy はユーザー固有の情報の取り扱いと、ユーザーが自身のプライバシーを適切に制御できるようにすることに焦点を当てています。
注
この仕様はメディアデータの供給元に依存しませんが、多くの実装が Media Source Extensions [MEDIA-SOURCE]
経由で提供されるメディアデータの復号のみをサポートしていることに著者は注意すべきです。
API を用いて実装された一般的なスタックの例を以下に示します。この図は一例のフローを示しており、他の API 呼び出しやイベントの組み合わせも可能です。
2.
定義
コンテンツ復号モジュール（CDM）
コンテンツ復号モジュール（CDM）は、1 つ以上の Key Systems
に対して復号を含む機能を提供するクライアント側のコンポーネントです。
注
実装は CDM の実装とユーザーエージェントの実装を分離する場合と分離しない場合があります。本仕様ではこれは API とアプリケーションに対して透過的です。
Key System
Key System は復号メカニズムおよび／またはコンテンツ保護プロバイダを指す一般的な用語です。Key System 文字列は Key System
を一意に識別します。これらはユーザーエージェントによって CDM を選択したり、鍵に関連するイベントの発生源を特定するために使用されます。ユーザーエージェントは MUST で Common Key Systems
をサポートしなければなりません。ユーザーエージェントは追加の CDMs と対応する Key System 文字列を提供してもよい（MAY）です。
Key System 文字列は常に逆ドメイン名です。Key System 文字列の比較は大文字小文字を区別して行われます。RECOMMENDED
として、CDMs は単純な小文字の ASCII キーシステム文字列を使用することが推奨されます。
key はバイト列である key ID に関連付けられ、キーを一意に識別します。コンテナは media
data 内のブロックまたはブロック集合を復号できるキーの ID を指定します。Initialization Data はメディアデータを復号するために必要なキーを識別するための key
ID を含んでいてもよい（MAY）。しかし、Initialization Data にメディアデータやメディアリソースで使用されるすべての key
ID が含まれることを要求するものではありません。Licenses が CDM に提供されると、各キーは key ID に関連付けられ、CDM が暗号化されたメディアデータのブロックを復号する際に適切なキーを選択できるようになります。
ライセンスはキーシステム固有の状態情報で、一つ以上の key(s)（各々が key
ID に関連付けられる）および鍵利用に関する他の情報を含む場合があります。
Initialization Data
注
Key Systems
は通常、ライセンス要求メッセージを構築する前に、復号対象ストリームに関する情報を含む初期化データのブロックを必要とします。このブロックは単純なキーやコンテンツ ID
であったり、より複雑な構造を含む場合があります。初期化データは 必要なキー を一意に識別できるように常にするべきです（SHOULD）。この初期化情報はアプリケーション固有の方法で取得されるか、media data
と共に提供される場合があります（MAY）。
Initialization Data は CDM がライセンス要求を生成するために使用するコンテナ固有データの総称です。
初期化データの形式はコンテナの種類に依存し、コンテナは複数の初期化データ形式をサポートしている場合があります。Initialization Data Type は、付随する Initialization Data
の形式を示す文字列です。Initialization Data Type 文字列は常に大文字小文字を区別して照合されます。Initialization Data Type 文字列は小文字 ASCII
文字列にすることが RECOMMENDED です。
Initialization Data は与えられたストリーム集合または media data
に対して固定値でなければなりません（MUST）。それは与えられたストリーム集合またはメディアデータの復号に必要な鍵に関連する情報のみを含まなければなりません（MUST）。Initialization Data
はアプリケーションデータ、クライアント固有データ、ユーザー固有データ、または実行可能なコードを含んではなりません（MUST NOT）。
二つ以上の識別子または他の値は associable by an entity（ある主体によって関連付け可能）
と言われます。これは参照された主体または主体の集合が追加の主体の参加なしにそれらを相関または関連付けることが合理的な時間と労力で可能である場合を意味します。そうでない場合、それらの値は non-associable by an entity（主体によって関連付け不可能） です。
二つ以上の識別子または他の値は non-associable by the
application（アプリケーションによって関連付け不能） と言われます。これはそれらが non-associable by an entity
であり、その主体がアプリケーション、他のすべてのアプリケーション、およびそれらが使用または通信するサーバを含む集合である場合を意味します。そうでない場合、これらの値は associable by the application（アプリケーションによって関連付け可能） と見なされ、これは禁止されます。
Distinctive Value
Distinctive Value
は、多数のユーザーまたはクライアントデバイス間で共有されない値、データの断片、その所持を示す示唆、または観測可能な振る舞いやタイミングであり、メモリ内または永続化されうるものです。
initDataType
は、後の手順で構成が予期せず拒否されるのを避けるために、コンテンツタイプに依存せずサポートされている必要があります（MUST）。initDataType
のサポートにはライセンス生成と、適切な場合はメディアデータからの抽出の両方が含まれます。詳細は Initialization
Data Type Support requirements を参照してください。
consent status と updated restrictions を、Get Consent Status アルゴリズムを
accumulated
configuration、restrictions、および origin
に対して実行した結果として得られる値とし、consent status の値に対する次のリストの手順に従います:
ライセンス（および必要に応じてセッションに関連する他のデータ）が永続化されるセッション。ライセンスとそれが含む鍵が破棄されるとき、record of license
destruction が必ず永続化されなければなりません。record of license destruction
は、そのライセンスと含まれる鍵がクライアントによって使用不能であることを示す Key System
固有の証明です。このセッションタイプのサポートは 任意 です。
反復対象となる値のペアは、すべての known keys に対して形成された (key
ID, 対応する MediaKeyStatus)
のスナップショットであり、
key ID によってソートされています。key ID の比較は次のように行われます: 長さが
m の key ID A と長さが n の B（m <= n
に割り当てられている）について、A の方が小さい (A < B) のは、A の m
オクテットが B の最初の m オクテットより辞書順で小さい場合、またはそれらが等しくかつ m < n
の場合です。
メッセージが App-Assisted
Individualization（または再個体化）の要求を含む場合です。
他のすべてのメッセージと同様に、メッセージ内の識別子は MUST origin と profile ごとに区別できるものであり、かつ
MUST NOT Distinctive Permanent Identifiers であってはなりません。
「Attempt to Resume Playback If Necessary」アルゴリズムは、メディア要素が鍵待ちでブロックされており、必要な鍵が現在 usable for decryption である場合に再生を再開します。
このアルゴリズムを実行する要求には、ターゲットの HTMLMediaElement オブジェクトが含まれます。
メディアレンダリングが UA によって行われない場合、例えばハードウェアベースのメディアパイプラインの場合、CSS トランスフォーム等の HTML のレンダリング機能のすべてが利用できないことがMAYあります。典型的な制約の一つとしては、ビデオメディアがウィンドウの辺に平行な辺を持ち、通常の向きに整った矩形領域のみに表示が制限されることがMAYあります。
Persistent Data を使用する実装は、そのデータが本仕様で定義された API 経由など外部から、またクライアントデバイス上でも回復不能になるようにユーザーがデータを消去できることをMUST 許容しなければなりません。
ユーザーエージェントは SHOULD 次のことを行うべきです:
Persistent Data をクッキー等の他のサイトデータと同様に扱う。具体的には:
クッキーとともに Persistent Data を消去できるようにすること。
閲覧履歴の消去機能の一部として Persistent Data を消去できるようにすること。
「すべてのデータを削除」機能に Persistent Data を含めること。
Persistent Data を他のサイトデータと同じ UI の場所に表示すること。
ユーザーが origin
ごと、または browsing profile ごとに Persistent Data
を消去できるようにすること（特に「このサイトを忘れる」機能の一部として、特定サイトに関連するクッキーやデータを削除できるようにすること）。
Persistent Data を消去する操作が十分に原子的であり、「クッキー復活（cookie
resurrection）」のような、新しい識別子と古いものを別の残存データにより再関連付けできる状況を防ぐこと。
これらのインターフェースを、データの不完全な消去の可能性をユーザーが理解できるように提示し、クッキーや web storage
などデータを永続化するすべての機能に関連するデータを同時に削除できるようにすること。
Key System
を無効化・再有効化するためのインターフェースを、データの不完全な消去の可能性を理解させ、すべての永続ストレージ機能におけるデータを同時に削除できるように提示すること。
ユーザーが origin
ごと、あるいはすべての origin に対して Persistent Data を特定に削除できるようにすること。
8.3.3
永続データを暗号化または難読化すること
ユーザーエージェントは Persistent Data
を潜在的に機微な情報として扱うべきです。これらの情報が流出するとユーザーのプライバシーが損なわれる可能性があります。そのため、ユーザーエージェントは Persistent Data
が安全に保存されるようにし、データを削除する際は基盤となるストレージから速やかに削除されることをSHOULD 確保すべきです。
オリジンやプロファイルをまたいだ値は、アプリケーションによって関連付け不可能（non-associable by
applications）でなければなりません。すなわち、複数のオリジンやプロファイルからの値を相互に相関させて同一のクライアントやユーザーに由来するものと特定できてはなりません。オリジン独立またはプロファイル独立の値から
per-origin 値を導出する実装は、上記の非関連付け性を保証する方法（非可逆性を持つ導出関数など）を用いなければなりません（MUST）。
8.4.2
値の消去を許可すること
Allow Persistent Data to Be Cleared
の要件の結果として、アプリケーションに公開されたすべての永続化された値は、外部（本仕様で定義された API
経由等）およびクライアントデバイス上の双方で回復不能となるようにクリア可能でなければなりません（MUST）。
このプロセスは MUST ユーザーエージェントが直接実行するdirectly by the user agent か、またはアプリケーションを通じて実行されなければなりません。両者の個体化の仕組み、フロー、および制約は以下の節で説明する通り異なります。どの方法が使用されるかは、CDM の実装と本仕様の要件（特に以下の要件）の適用によって決まります。
Direct Individualization は CDM とオリジンやアプリケーションに依存しないサーバーとの間で行われます。サーバーはオリジン非依存ですが、個体化の結果により CDM
は本仕様の他の要件に従ってオリジン固有の識別子を提供できるようになります。このプロセスはユーザーエージェントによって実行されなければならず（MUST）、本仕様で定義された API を使用してはなりません（MUST NOT）。
言い換えれば、ある Initialization Data
Type のサポートを示すことは、CDM
がライセンス要求を生成することをサポートすることと、コンテナ固有の型についてはユーザーエージェントがそのコンテナから抽出できることの両方を意味します。ただし、これは実装が任意のサポートされる
Initialization Data
を任意のサポートされるコンテンツタイプから解析できなければならない、という意味ではありません。
アクセシビリティ情報が利用可能な形で提供されることを確実にするために、インバンドのサポートコンテンツの暗号化をサポートする実装については: a) CDM は復号済みデータをユーザーエージェントに提供しなければならず（MUST）、b) ユーザーエージェントはそれを同等の非暗号化サポートコンテンツと同様に処理しなければなりません（例えば timed text tracks
として公開するなど）（MUST）。
9.
共通キーシステム
すべてのユーザーエージェントは MUST このセクションで説明される共通の キーシステム をサポートしなければなりません。
ユーザーエージェントは、ユーザーが安全にウェブを閲覧できる方法を提供する責任があります。この責任は、サードパーティ由来の機能を含む、
ユーザーエージェントが使用するあらゆる機能に適用されます。ユーザーエージェント実装者は MUST として、
Key System 実装者から十分な情報を取得し、
Key System と統合することのセキュリティ上の影響を適切に評価できるようにしなければなりません。
ユーザーエージェント実装者は MUST として、CDM
実装がユーザーエージェント側でユーザーのセキュリティを提供するために十分な制御を提供およびサポートすることを確実にする必要があります。
また、CDM 実装がセキュリティ脆弱性発生時に迅速かつ積極的に更新されることを保証しなければなりません。
サンドボックス化されていない、あるいはプラットフォーム機能を使用する CDM 実装を悪用されると、
攻撃者が OS やプラットフォーム機能にアクセスしたり、権限昇格（例: system や root として実行）を行ったり、
ドライバ、カーネル、ファームウェア、ハードウェア等へアクセスできる可能性があります。これらの機能やソフトウェア、ハードウェアは
敵対的なソフトウェアやウェブベースの攻撃に対して堅牢に設計されていない場合があり、ユーザーエージェントに比べてセキュリティ修正が提供されない、
あるいは遅い可能性があります。CDM 実装に対する修正の欠如、頻度の低さ、遅さはリスクを高めます。
そのような CDM 実装およびそれらを公開する UA は、すべてのデータ
の解析を含むあらゆるセキュリティ領域で特に慎重でなければなりません。
作者は SHOULD として、他の主体が自分のアプリケーションを iframe 内でホストすることを防止すべきです。
正当なアプリケーション設計上の理由でホストされる必要があるアプリケーションは、ホスティング文書が CDM に渡されるいかなるデータ
を提供すること（本仕様の API 経由またはメディアデータとして）を許可すべきではなく、
ホスティングフレームが本仕様で定義された API を呼び出すことを許可すべきではありません。
10.5
クロスディレクトリ攻撃
このセクションは非規範的です。
例えば geocities.com のように一つのホスト名を共有する異なる作者は、すべて一つの オリジン
を共有します。ユーザーエージェントは
パス名による API へのアクセス制限機能を提供していません。
共有ホストで本仕様の API を使用すると、ユーザーエージェントが実装するオリジンベースのセキュリティおよびプライバシー緩和策が損なわれます。
例えば、オリジンごとの Distinctive Identifiers
は一つのホスト名上のすべての作者と共有され、永続化されたデータはホスト上の任意の作者によってアクセスおよび操作され得ます。
後者は特に、例えばそのデータの変更や削除によってユーザーの特定コンテンツに対する権利が失われる可能性がある場合に重要です。
注
たとえユーザーエージェントがパス制限機能を提供していたとしても、通常の DOM スクリプトセキュリティモデルにより、その保護は簡単に回避され、任意のパスからデータにアクセスされ得ます。
したがって、共有ホストの作者は本仕様で定義された API の使用を避けることが RECOMMENDED
されます。なぜならそれによりユーザーエージェント側のオリジンベースのセキュリティおよびプライバシー緩和策が損なわれるためです。
ユーザーエージェントは MUST として、ユーザーが自身のプライバシーを適切に制御できるようにする責任を負わなければなりません。ユーザーエージェントはサードパーティの
CDM
実装と統合する可能性があるため、
CDM
実装者は、ユーザーエージェント実装者がユーザーのプライバシーを制御できるように適切な技術を実装するために十分な情報と制御手段を提供しなければなりません。以下に示す技術を含むがこれに限定されません。
11.1
EME および Key Systems によって開示される情報
EME および Key Systems によって開示される情報に関する懸念は二つのカテゴリに分かれます：(a)
ユーザーエージェントやデバイスのフィンガープリント化の可能性に寄与し得る非特定情報に関する懸念、(b) 直接的に ユーザー追跡
に使用され得るユーザー固有の情報に関する懸念。
11.2
フィンガープリンティング
悪意のあるアプリケーションは、サポートされている Key Systems
の検出や列挙、関連情報の取得によってユーザーやユーザーエージェントをフィンガープリント化できる可能性があります。適切なオリジン保護が提供されない場合、これには訪問したサイトの検出やそれらのサイトのために保存された情報の検出が含まれ得ます。特に、Key Systems は MUST として、キーやその他のデータを origins 間で共有してはなりません。
CDM から、またはこの仕様で明示的に記述されていない情報や、ユーザーの許可なしにウェブプラットフォームの他の API
を通じてページに利用可能でない情報を抽出、派生、推測することが不可能であること。これは、CDM
メッセージ中の情報を含め、クライアントデバイスまたはアプリケーションの外部に露出するあらゆる情報に適用されます。
Key Systems
は、デバイスまたはデバイスのユーザーのための永続的または準永続的な識別子をアクセスまたは作成する可能性があります。場合によっては、これらの識別子が特定のデバイスに対して安全にバインドされることがあります。これらの識別子が
Key System
メッセージ内に存在する場合、デバイスやユーザーが追跡される可能性があります。以下の緩和策が適用されない場合、これには時間を通じたユーザー／デバイスの追跡や、特定のデバイスの複数ユーザーの関連付けが含まれる可能性があります。
緩和されない場合、こうした追跡は Key System の設計に応じて三つの形式を取る可能性があります：
いずれの場合でも、こうした識別子は Key System を完全にサポートするサイトやサーバーから利用可能であり（したがって Key System
メッセージを解釈できる）、そのようなサイトによる追跡を可能にすると予想されます。
Key Systems によって公開される識別子がオリジン固有でない場合、二つのサイトやサーバーが共謀してユーザーを追跡する可能性があります。
Key System メッセージがユーザー識別子から一貫した方法で派生した情報を含む場合（例えば、特定のコンテンツ項目に対する最初の Key System
メッセージの一部が時間とともに変化せず、ユーザー識別子に依存するような場合）、その情報は任意のアプリケーションによってデバイスやユーザーを時間を通じて追跡するために使用され得ます。
さらに、Key System
がキーやその他のデータをオリジン間で保存および再利用可能にすることを許可する場合、二つのオリジンが共謀して共通のキーへアクセスできることを記録することで固有のユーザーを追跡できる可能性があります。
最後に、Key Systems のユーザー向け制御用 UI が HTTP セッションクッキー [COOKIES]
や永続ストレージ内のデータと別にデータを提示する場合、ユーザーはサイトの許可を変更したりデータを一方だけで削除したりする可能性が高くなります。これにより、サイトは各機能を互いの冗長バックアップとして使用し、ユーザーのプライバシー保護の試みを無効にすることができます。
サイトや他のサードパーティによる追跡の可能性に加えて、ユーザーエージェント実装者、CDM ベンダー、またはデバイスベンダーが、ユーザーが訪れる本仕様で定義された API
を使用するサイトなど、ユーザーの活動や興味のプロファイルを構築する可能性があります。このような追跡は、特にオリジンの隔離に関連するウェブプラットフォームのプライバシー保護を損ないます。
Distinctive Identifiers を含む Key System メッセージは、タイムスタンプまたはノンスと共に暗号化され、
常に異なる Key System メッセージになるようにしなければなりません（MUST）。
これにより、Key System メッセージを用いた追跡は、その Key System を完全にサポートするサーバーによる場合を除き防止されます。詳細は Encrypt Identifiers を参照してください。
Require site-specific whitelisting of access to each Key System
ユーザーエージェントは MAY として、サイトが各 Key
System（および/または特定の機能）を使用する前に、ユーザーが明示的にアクセスを許可することを要求することができます。ユーザーエージェントは SHOULD として、ユーザーがこの許可を一時的または恒久的に取り消せるようにすべきです。
Use shared blacklists
ユーザーエージェントは MAY として、ユーザーがオリジンや Key
Systems のブラックリストを共有できるようにすることができます。これにより、コミュニティが協力してプライバシーを保護することが可能になります。
Note
これらの提案は、本仕様で定義された API
を用いたユーザー追跡の単純な利用を防ぎますが、完全に遮断するものではありません。単一のオリジン内では、サイトはセッション中にユーザーを追跡し続け、得られたすべての情報をサイトが取得した識別情報（名前、クレジットカード番号、住所など）とともに第三者に渡すことが可能です。第三者が複数のサイトと協力してそのような情報を取得し、識別子が
オリジンおよびプロファイルごとに一意でない 場合、プロファイルは依然として作成され得ます。
11.5
ユーザーのデバイスに保存される情報
11.5.1
懸念事項
This section is non-normative.
Key Systems はユーザーのデバイス上に情報を保存する可能性があり、またユーザーエージェントが Key
Systems のために情報を保存する場合があります。潜在的には、これは同じデバイスを使用する別のユーザーに対して、特定の origins が特定の Key System（つまり訪問したサイト）を使用したこと、あるいは Key System を使って復号されたコンテンツそのものに関する情報を明らかにする可能性があります。
もしあるオリジンによって保存された情報が他のオリジンのための Key System
の動作に影響を与えるならば、あるサイトでユーザーが訪問したサイトや閲覧したコンテンツが別の（潜在的に悪意のある）サイトに明らかになる可能性があります。
ユーザーが特定の origin
のために Key System
を無効化しても、クッキーや他の永続ストレージを同時に消去しない場合、サイトは残された機能を使ってユーザーの試みを無効化できます。
ユーザーが Key System を無効化した後に再度有効化する場合、クッキーや他の永続ストレージ、Distinctive
Identifiers、および Key Systems
が保存したデータを同時に消去していなければ、サイトは無効化前のデータと再有効化後のデータや挙動を関連付けられる可能性があります。
本ドキュメント内のキーワード MAY, MUST, MUST
NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, および SHOULD NOT は、すべて大文字で表示されている場合に限り、BCP 14
[RFC2119] [RFC8174]
に記載されたとおりに解釈されます。
13.
例
このセクションは非規範的です。
この節は、提案された拡張機能を用いたさまざまなユースケースに対する例示的な解決策を含んでいます。これらが唯一の解決策というわけではありません。例では video
要素を使用していますが、同じことはすべてのメディア要素に当てはまります。同期 XHR の使用のような場合には、拡張に焦点を当てるために例を簡略化しています。
<script>var licenseUrl;
var serverCertificate;
var mediaKeys;
// See the previous example for implementations of these functions.functioncreateSupportedKeySystem() { ... }
functionmakeNewRequest(mediaKeys, initDataType, initData) { ... }
functionlicenseRequestReady(event) { ... }
functionhandleInitData(event) {
makeNewRequest(mediaKeys, event.initDataType, event.initData);
}
createSupportedKeySystem().then(
function(createdMediaKeys) {
mediaKeys = createdMediaKeys;
var video = document.getElementById("v");
video.src = 'foo.webm';
if (serverCertificate)
mediaKeys.setServerCertificate(serverCertificate);
return video.setMediaKeys(mediaKeys);
}
).catch(
console.error.bind(console, 'Failed to create and initialize a MediaKeys object')
);
</script><videoid="v"autoplayonencrypted='handleInitData(event)'></video>
13.4
すべてのイベントを使用する例
これは、すべてのイベントが使用されるより完全な例です。
handleMessage() は複数回呼び出される可能性があることに注意してください。複数往復が必要な場合の update() 呼び出しへの応答としてや、Key
System がメッセージを送信するその他の理由により呼ばれることがあります。
<script>var licenseUrl;
var serverCertificate;
var mediaKeys;
// See previous examples for implementations of these functions.// createSupportedKeySystem() additionally sets renewalUrl.functioncreateSupportedKeySystem() { ... }
functionhandleInitData(event) { ... }
// This replaces the implementation in the previous example.functionmakeNewRequest(mediaKeys, initDataType, initData) {
var keySession = mediaKeys.createSession();
keySession.addEventListener('message', handleMessage, false);
keySession.addEventListener('keystatuseschange', handlekeyStatusesChange, false);
keySession.closed.then(
function(reason) {
console.log('Session', this.sessionId, 'closed, reason', reason);
}.bind(keySession)
);
keySession.generateRequest(initDataType, initData).catch(
console.error.bind(console, 'Unable to create or initialize key session')
);
}
functionhandleMessageResponse(keySession, response) {
var license = newUint8Array(response);
keySession.update(license).catch(
function(err) {
console.error('update() failed: ' + err);
}
);
}
functionsendMessage(type, message, keySession) {
var url = licenseUrl;
if (type == "license-renewal")
url = renewalUrl;
xmlhttp = newXMLHttpRequest();
xmlhttp.keySession = keySession;
xmlhttp.open('POST', url);
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState == 4)
handleMessageResponse(xmlhttp.keySession, xmlhttp.response);
}
xmlhttp.send(message);
}
functionhandleMessage(event) {
sendMessage(event.messageType, event.message, event.target);
}
functionhandlekeyStatusesChange(event) {
// Evaluate the current state using one of the map-like methods exposed by// event.target.keyStatuses.// For example:
event.target.keyStatuses.forEach(function(status, keyId) {
switch (status) {
case"usable":
break;
case"expired":
// Report an expired key.break;
case"status-pending":
// The status is not yet known. Consider the key unusable until the status is updated.break;
default:
// Do something with |keyId| and |status|.
}
})
}
createSupportedKeySystem().then(
function(createdMediaKeys) {
mediaKeys = createdMediaKeys;
var video = document.getElementById("v");
if (serverCertificate)
mediaKeys.setServerCertificate(serverCertificate);
return video.setMediaKeys(mediaKeys);
}
).catch(
console.error.bind(console, 'Failed to create and initialize a MediaKeys object')
);
</script><videoid='v'src='foo.webm'autoplay></video>
<script>var licenseUrl;
var serverCertificate;
var mediaKeys;
// See the previous examples for implementations of these functions.// createSupportedKeySystem() additionally sets persistentState: "required" in each options dictionary.functioncreateSupportedKeySystem() { ... }
functionsendMessage(message, keySession) { ... }
functionhandleMessage(event) { ... }
// Called if the application does not have a stored sessionId for the media resource.functionmakeNewRequest(mediaKeys, initDataType, initData) {
var keySession = mediaKeys.createSession("persistent-license");
keySession.addEventListener('message', handleMessage, false);
keySession.closed.then(
function(reason) {
console.log('Session', this.sessionId, 'closed, reason', reason);
}.bind(keySession)
);
keySession.generateRequest(initDataType, initData).then(
function() {
// Store this.sessionId in the application.
}.bind(keySession)
).catch(
console.error.bind(console, 'Unable to request a persistent license')
);
}
// Called if the application has a stored sessionId for the media resource.functionloadStoredSession(mediaKeys, sessionId) {
var keySession = mediaKeys.createSession("persistent-license");
keySession.addEventListener('message', handleMessage, false);
keySession.closed.then(
function(reason) {
console.log('Session', this.sessionId, 'closed, reason', reason);
}.bind(keySession)
);
keySession.load(sessionId).then(
function(loaded) {
if (!loaded) {
console.error('No stored session with the ID ' + sessionId + ' was found.');
// The application should remove its record of |sessionId|.return;
}
}
).catch(
console.error.bind(console, 'Unable to load or initialize the stored session with the ID ' + sessionId)
);
}
// Called when the application wants to stop using the session without removing the stored license.functioncloseSession(keySession) {
keySession.close();
}
// Called when the application wants to remove the stored license.// The stored session data has not been completely removed until the promise returned by remove() is fulfilled.// The remove() call may initiate a series of messages to/from the server that must be completed before this occurs.functionremoveStoredSession(keySession) {
keySession.remove().then(
function() {
console.log('Session ' + this.sessionId + ' removed');
// The application should remove its record of this.sessionId.
}.bind(keySession)
).catch(
console.error.bind(console, 'Failed to remove the session')
);
}
// This replaces the implementation in the previous example.functionhandleMessageResponse(keySession, response) {
var license = newUint8Array(response);
keySession.update(license).then(
function() {
// If this was the last required message from the server, the license is// now stored. Update the application state as appropriate.
}
).catch(
console.error.bind(console, 'update() failed')
);
}
createSupportedKeySystem().then(
function(createdMediaKeys) {
mediaKeys = createdMediaKeys;
var video = document.getElementById("v");
if (serverCertificate)
mediaKeys.setServerCertificate(serverCertificate);
return video.setMediaKeys(mediaKeys);
}
).catch(
console.error.bind(console, 'Failed to create and initialize a MediaKeys object')
);
</script><videoid='v'src='foo.webm'autoplay></video>
