forked from w3c/encrypted-media
-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathencrypted-media-respec.html
4673 lines (4350 loc) · 326 KB
/
encrypted-media-respec.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Encrypted Media Extensions</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c-common" class="remove"></script>
<script src="encrypted-media.js" class="remove"></script>
<script class="remove">
// The W3C diff service does not fix up relative URLs.
// To enable diffs that look better, use the files from the latest version of the spec trunk.
// Changes to the affected JS, CSS, and image files will NOT be reflected!
var diffServiceHostName = "services.w3.org";
var diffServicePathName = "/htmldiff";
var replacementOriginAndPath = "https://w3c.github.io/encrypted-media/"
var isDiffService = window.location.hostname == diffServiceHostName && window.location.pathname == diffServicePathName;
// The JS replacement file must be loaded here.
// Other resources will be replaced at the end of the file.
if (isDiffService) {
var source = replacementOriginAndPath + "encrypted-media.js"
var xhr = new XMLHttpRequest();
xhr.open("GET", source, false);
xhr.send();
var replacement = document.createElement("script");
replacement.type = "text/javascript";
replacement.className = "remove";
replacement.text = xhr.responseText;
$("head").append(replacement);
console.log("Rewrote URL as " + source);
};
</script>
<script class="remove">
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
previousMaturity: "WD",
// the specification's short name, as in https://www.w3.org/TR/short-name/
shortName: "encrypted-media",
useExperimentalStyles: true,
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://w3c.github.io/encrypted-media/",
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "David Dorwin", w3cid: "52505",
company: "Google Inc.", companyURL: "https://www.google.com/" },
{ name: "Jerry Smith", w3cid: "60176",
company: "Microsoft Corporation", companyURL: "https://www.microsoft.com/" },
{ name: "Mark Watson", url: "", w3cid: "46379",
company: "Netflix Inc.", companyURL: "https://www.netflix.com/" },
{ name: "Adrian Bateman", note: "Until May 2014", w3cid: "42763",
company: "Microsoft Corporation", companyURL: "https://www.microsoft.com/" },
],
emeDefGroupName: "encrypted-media",
emeContributors: [
"Aaron Colwell",
"Alex Russell",
"Anne van Kesteren",
"Bob Lund",
"Boris Zbarsky",
"Chris Pearce",
"David Singer",
"Domenic Denicola",
"Frank Galligan",
"Glenn Adams",
"Henri Sivonen",
"Jer Noble",
"Joe Steele",
"Joey Parrish",
"John Simmons",
"Mark Vickers",
"Pavel Pergamenshchik",
"Philip Jägenstedt",
"Pierre Lemieux",
"Robert O'Callahan",
"Ryan Sleevi",
"Steve Heffernan",
"Steven Robertson",
"Thomás Inskip",
"Travis Leithead",
"Xiaohan Wang"
],
otherLinks: [{
key: "Repository",
data: [{
value: "We are on GitHub.",
href: "https://github.com/w3c/encrypted-media/"
}, {
value: 'File a bug.',
href: 'https://github.com/w3c/encrypted-media/issues'
}, {
value: 'Commit history.',
href: 'https://github.com/w3c/encrypted-media/commits/gh-pages/encrypted-media-respec.html'
}]
}],
emeDefGroupName: "encrypted-media",
emeUnusedGroupNameExcludeList: ["eme-references-from-registry"],
// name of the WG
wg: "HTML Working Group",
// URI of the public WG page
wgURI: "https://www.w3.org/html/wg/",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-html-media",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/40318/status",
noIDLIn: true,
scheme: "https",
preProcess: [ encryptedMediaPreProcessor ],
// Empty definitions for objects declared in the document are here to
// prevent error messages from being displayed for references to these objects.
definitionMap: {},
postProcess: [ encryptedMediaPostProcessor ],
};
</script>
<!-- script to register bugs -->
<!-- Disabled unless/until it supports GitHub issues.
<script src="https://w3c.github.io/webcomponents/assets/scripts/bug-assist.js"></script>
<meta name="bug.product" content="HTML WG"/>
<meta name="bug.component" content="Encrypted Media Extensions"/>
-->
<link rel="stylesheet" href="eme.css"/>
</head>
<body>
<section id="abstract">
<p>This proposal extends <a def-id="htmlmediaelement"></a> [[!HTML5]] providing APIs to control playback of encrypted content.</p>
<p>The API supports use cases ranging from simple clear key decryption to high value video (given an appropriate user agent implementation).
License/key exchange is controlled by the application, facilitating the development of robust playback applications supporting a range of content decryption and protection technologies.</p>
<p>This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with
such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification: only the
Clear Key system is required to be implemented as a common baseline.</p>
<p>The common API supports a simple set of content encryption capabilities, leaving application functions such as authentication and authorization to page authors. This is achieved by
requiring content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication between the encryption system and a license
or other server.</p>
</section>
<section id="sotd">
<p>The working group maintains <a href="https://github.com/w3c/encrypted-media/issues">a list of all bug reports that the editors have not yet tried to address</a>; there are also open bugs in the <a href="https://www.w3.org/brief/MjY5">previous bug tracker</a>. This draft highlights some of the pending issues that are still to be discussed in the working group. No decision has been taken on the outcome of these issues including whether they are valid.</p>
<p>Implementors should be aware that this specification is not stable. <strong>Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways.</strong> Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the mailing list mentioned below and take part in the discussions.</p>
<p>The following features are <strong>at risk</strong> and may be removed:</p>
<ul>
<li><p>The <a def-id="persistent-usage-record-session"></a> session type and the related <a def-id="media-key-session-destroyed-algorithm"></a> algorithm.</p></li>
<li><p>Setting the <var>media element</var>'s <a def-id="readystate"></a> value based on key availability in the <a def-id="wait-for-key-algorithm"></a> and <a def-id="resume-playback-algorithm"></a> algorithms.</p></li>
</ul>
</section>
<section id="introduction" class="informative">
<h2>Introduction</h2>
<p>
This specification enables script to select content protection mechanisms, control license/key exchange, and
execute custom license management algorithms.
It supports a wide range of use cases without requiring client-side modifications in each user agent for each use case.
This enables content providers to develop a single application solution for all devices.
</p>
<p>
Supported content is encrypted per container-specific "common encryption" specifications, enabling use across key systems.
Supported content has an unencrypted container, enabling metadata to be provided to the application and maintaining compatibility with other <a def-id="htmlmediaelement"></a> features.
</p>
<p>
A generic stack implemented using the API is shown below.
This diagram shows an example flow; other combinations of API calls and events are possible.
</p>
<img src="stack_overview.svg" alt="A generic stack implemented using the proposed APIs" height="700"></img>
</section>
<section id="definitions">
<h2>Definitions</h2>
<dl>
<dt id="cdm">Content Decryption Module (CDM)</dt>
<dd>
<p>Content Decryption Module (CDM) is the client component that provides the functionality, including decryption, for one or more <a def-id="keysystems"></a>.</p>
<p class="note">Implementations may or may not separate the implementations of CDMs or treat them as separate from the user agent.
This is transparent to the API and application.</p>
<p>All messages and communication to and from the CDM, such as between the CDM and a license server, MUST be passed through the user agent.
The CDM MUST NOT make direct out-of band network requests.
All messages and communication other than those described in <a href="#direct-individualization">Direct Individualization</a> MUST be passed through the application via the APIs defined in this specification.
Specifically, all communication that contains application-, <a def-id="origin"></a>-, or content-specific information or is sent to a URL specified by the application or based on its origin, MUST pass through the APIs.
This includes all license exchange messages.
</p>
<p>
</p>
</dd>
<dt id="key-system">Key System</dt>
<dd>
<p>A Key System is a generic term for a decryption mechanism and/or content protection provider.
Key System strings provide unique identification of a Key System.
They are used by the user agent to select a <a def-id="cdm"></a> and identify the source of a key-related event.
User agents MUST support the <a href="#common-key-systems">Common Key Systems</a>.
User agents MAY also provide additional CDMs with corresponding Key System strings.
</p>
<p>A Key System string is always a reverse domain name.
Key System strings are compared using case-sensitive matching. It is RECOMMENDED that CDMs use simple lower-case ASCII key system strings.</p>
<p class="note">For example, "com.example.somesystem".</p>
<p class="note">
Within a given system ("somesystem" in the example), subsystems may be defined as determined by the key system provider.
For example, "com.example.somesystem.1" and "com.example.somesystem.1_5".
Key System providers should keep in mind that these will be used for comparison and discovery, so they should be easy to compare and the structure should remain reasonably simple.
</p>
</dd>
<dt id="key-session">Key Session</dt>
<dd>
<p>A Key Session, or simply Session, provides a context for message exchange with the CDM as a result of which key(s) are made available to the <a def-id="cdm"></a>.
Sessions are embodied as <a>MediaKeySession</a> objects.
Each Key session is associated with a single instance of <a def-id="initialization-data"></a> provided in the <a def-id="generateRequest"></a> call.
</p>
<p>Each Key Session is associated with a single <a>MediaKeys</a> object, and only media element(s) associated with that <a>MediaKeys</a> object may access key(s) associated with the session.
Other <a>MediaKeys</a> objects, <a def-id="cdm"></a> instances, and media elements MUST NOT access the key session or use its key(s).
Key sessions and the keys they contain are no longer <a def-id="usable-for-decryption"></a> once the session has been closed, including when the <a>MediaKeySession</a> object is destroyed.
</p>
<p>
All license(s) and key(s) associated with a Key Session which have not been explicitly stored MUST be destroyed when the Key Session is closed.
</p>
<p><a def-id="key-id">Key IDs</a> MUST be unique within a session.</p>
</dd>
<dt id="session-id">Session ID</dt>
<dd>
<p>A Session ID is a unique string identifier generated by the <a def-id="cdm"></a> that can be used by the application to identify <a>MediaKeySession</a> objects.</p>
<p>A new Session ID is generated each time the user agent and CDM successfully create a new session.</p>
<p>Each Session ID SHALL be unique within the browsing context in which it was created.
For session types for which the <a def-id="is-persistent-session-type-algorithm"></a> algorithm returns <code>true</code>, Session IDs MUST be unique within the <a def-id="origin"></a> over time, including across browsing sessions.
</p>
<p class="note">The underlying content protection protocol does not necessarily need to support Session IDs.</p>
</dd>
<dt id="decryption-key">Key</dt>
<dd>
<p>Unless otherwise stated, key refers to a decryption key that can be used to decrypt blocks within <a def-id="media-data"></a>.
Each such key is uniquely identified by a <a def-id="key-id"></a>.
A key is associated with the <a href="#key-session">session</a> used to provide it to the CDM. (The same key may be present in multiple sessions.)
Such keys MUST only be provided to the <a def-id="cdm"></a> via an <a def-id="update"></a> call. (They may later be loaded by <a def-id="load"></a> as part of the stored session data.)
</p>
<p class="note">Authors SHOULD encrypt each set of stream(s) that requires enforcement of a meaningfully different policy with a distinct key (and key ID).
For example, if policies may differ between two video resolutions, stream(s) containing one resolution should not be encrypted with the key used to encrypt stream(s) containing the other resolution.
When encrypted, audio streams SHOULD NOT use the same key as any video stream.
This is the only way to ensure enforcement and compatibility across clients.
</p>
</dd>
<dt id="usable-for-decryption">Usable For Decryption</dt>
<dd>
<p>A key is considered usable for decryption if the CDM is certain the key is currently usable to decrypt one or more blocks of <a def-id="media-data"></a>.</p>
<p class="note">For example, a key is not usable for decryption if its license has expired. Even if its license has not expired, a key is not usable for decryption if other conditions (e.g. output protection) for its use are not currently satisfied.</p>
</dd>
<dt id="decryption-key-id">Key ID</dt>
<dd>
<p>A <a href="#decryption-key">key</a> is associated with a key ID that is a sequence of octets and which uniquely identifies the key.
The container specifies the ID of the key that can decrypt a block or set of blocks within the <a def-id="media-data"></a>.
<a def-id="initialization-data"></a> MAY contain key ID(s) to identify the keys that are needed to decrypt the media data.
However, there is no requirement that Initialization Data contain any or all key IDs used in the <a def-id="media-data"></a> or <a def-id="media-resource"></a>.
<a href="#license">Licenses</a> provided to the CDM associate each key with a key ID so the <a def-id="cdm"></a> can select the appropriate key when decrypting an encrypted block of media data.
</p>
</dd>
<dt id="known-key">Known Key</dt>
<dd>
<p>A key is considered to be known to a session if the CDM's implementation of the session contains any information - specifically the <a def-id="key-id"></a> - about it, regardless of whether the actual <a href="#decryption-key">key</a> is usable or its value is known.
Known keys are exposed via the <a def-id="keyStatuses"></a> attribute.
</p>
<p>Keys are considered known even after they become unusable, such as due to expiration or if they are removed but a <a def-id="record-of-license-destruction"></a> or <a def-id="record-of-key-usage"></a> is available.
Keys only become unknown when they are explicitly removed from a session and any license release message is acknowledged.
</p>
<p class="note">For example, a key could become unknown if an <a def-id="update"></a> call provides a new license that does not include the key and includes instructions to replace the license(s) that previously contained the key.</p>
</dd>
<dt id="license">License</dt>
<dd>
<p>A license is key system-specific state information that includes one or more <a href="#decryption-key">key(s)</a> - each associated with a <a def-id="key-id"></a> - and potentially other information about key usage.</p>
</dd>
<dt id="initialization-data">Initialization Data</dt>
<dd>
<p class="note">
<a def-id="keysystems"></a> usually require a block of initialization data containing information about the stream to be decrypted before they can construct a license request message.
This block could be a simple key or content ID or a more complex structure containing such information.
It SHOULD always allow unique identification of the <a href="#decryption-key">key(s)</a> needed to decrypt the content.
This initialization information MAY be obtained in some application-specific way or provided with the <a def-id="media-data"></a>.
</p>
<p>
Initialization Data is a generic term for container-specific data that is used by a <a def-id="cdm"></a> to generate a license request.
</p>
<p>
The format of the initialization data depends upon the type of container, and containers MAY support more than one format
of initialization data. The <dfn id="initialization-data-type">Initialization Data Type</dfn> is a string that indicates the
format of the accompanying Initialization Data. Initialization Data Type strings are always matched case-sensitively. It is
RECOMMENDED that Initialization Data Type strings are lower-case ASCII strings.
</p>
<p>
The Encrypted Media Extensions Stream Format and Initialization Data Format Registry [[EME-INITDATA-REGISTRY]]
provides the mapping from <a def-id="initialization-data-type"></a> string to the specification for each format.
</p>
<p>
When the user agent encounters Initialization Data in the <a def-id="media-data"></a>, it provides that Initialization Data to the application in the <a def-id="encrypted-event-initdata-attribute"></a> attribute of the <a def-id="encrypted"></a> event.
The user agent MUST NOT store the Initialization Data or use its <em>content</em> at the time it is encountered.
The application provides Initialization Data to the <a def-id="cdm"></a> via <a def-id="generateRequest"></a>.
The user agent MUST NOT provide Initialization Data to the CDM by other means.
</p>
<p>Initialization Data MUST be a fixed value for a given set of stream(s) or <a def-id="media-data"></a>.
It MUST only contain information related to the keys required to play a given set of stream(s) or <a def-id="media-data"></a>.
It MUST NOT contain application data, client-specific data, user-specific data, or executable code.
</p>
<p>Initialization Data SHOULD NOT contain Key System-specific data or values.
Implementations MUST support the common formats defined in [[EME-INITDATA-REGISTRY]] for each <a def-id="initialization-data-type"></a> they support.
</p>
<p class="note">
Use of proprietary formats/contents is discouraged, and supporting or using <em>only</em> proprietary formats is strongly discouraged.
Proprietary formats should only be used with pre-existing content or on pre-existing client devices that do not support the common formats.
</p>
</dd>
<dt>Associable Values</dt>
<dd>
<p>
Two or more identifiers or other values are said to be <dfn id="associable">associable</dfn> if they are identical <em>or</em> it is possible - with a reasonable amount of time and effort - to correlate or associate them.
Otherwise, the values are <dfn id="non-associable">non-associable</dfn>.
</p>
<div class="note">
<p>For example, values created in the following ways are <a def-id="associable"></a>:</p>
<ul>
<li><p>Using a trivially-reversible hash function.</p></li>
<li><p>Sharing a prefix or other subset</p></li>
<li><p>Replacing random value N with N+10</p></li>
<li><p>XORing the origin with a fixed value (because it is trivially reversible)</p></li>
</ul>
<p>In contrast, two values that are completely unrelated or cryptographically distinct, such as via a cryptographically strong non-reversible hash function, are <a def-id="non-associable"></a>.</p>
</div>
<p>Two or more identifiers or other values are said to be <dfn id="associable-by-entity">associable by an entity</dfn> if it is possible - with a reasonable amount of time and effort - for the referenced entity or set of entities to correlate or associate them without participation of additional entity(ies).
Otherwise, the values are <dfn id="non-associable-by-entity">non-associable by an entity</dfn>.
</p>
<p>Two or more identifiers or other values are said to be <dfn id="non-associable-by-application">non-associable by the application</dfn> if they are <a href="#non-associable-by-entity">non-associable by an entity</a>
where the entity is set that includes the application, all other applications, and other entities such as servers that they use or with which they communicate.
Otherwise, the values would be considered <dfn id="associable-by-application">associable by the application</dfn>, which is forbidden.
</p>
</dd>
<dt id="distinctive-value">Distinctive Value</dt>
<dd>
<p>
A Distinctive Value is a value, piece of data, implication of the possession of a piece of data, or an observable behavior or timing that is <em>not</em> shared across a large population of users or client devices.
A Distinctive Value may be in memory or persisted.
</p>
<div class="note">
<p>Examples of Distinctive Values include but are not limited to:</p>
<ul>
<li><p><a def-id="distinctive-identifiers"></a></p></li>
<li><p><a def-id="distinctive-permanent-identifiers"></a></p></li>
<li><p>Other identifiers</p></li>
<li><p><a def-id="session-id">Session IDs</a></p></li>
<li><p><a href="#license">Licenses</a></p></li>
<li><p>Other session data</p></li>
</ul>
</div>
<p class="note">While a Distinctive Value is typically unique to a user or client device, a value does not need to be strictly unique to be distinctive.
For example, a value shared among a small number of users could still be distinctive.
</p>
</dd>
<dt>Permanent Identifiers</dt>
<dd>
<p>
A <dfn id="permanent-identifier">Permanent Identifier</dfn> is a value, piece of data, implication of the possession of a piece of data, or an observable behavior or timing that is indelible in some way or otherwise non-trivial for the user to remove, reset, or change.
This, includes but is not limited to:
</p>
<ul>
<li><p>A hardware or hardware-based identifier</p></li>
<li><p>A value provisioned in the hardware device in the factory</p></li>
<li><p>A value associated with or derived from the operating system installation instance</p></li>
<li><p>A value associated with or derived from the user agent installation instance</p></li>
<li><p>A value associated with or derived from the <a def-id="cdm"></a> or other software component</p></li>
<li><p>A value in a configuration file or similar semi-permanent data, even if generated on the client</p></li>
<li><p>Client or other user account values</p></li>
</ul>
<p>
A <dfn id="distinctive-permanent-identifier">Distinctive Permanent Identifier</dfn> is a <a href="#permanent-identifier">Permanent Identifier</a> that is <a href="#distinctive-value">distinctive</a>.
</p>
<p>
When exposed outside the client, Distinctive Permanent Identifiers and values derived from or otherwise related to them MUST be <a href="#encrypt-identifiers">encrypted</a>.
Distinctive Permanent Identifiers MUST NOT ever be exposed to the application, even in encrypted form.
</p>
<p class="note">While a Distinctive Permanent Identifier is typically unique to a user or client device, a Distinctive Permanent Identifier does not need to be strictly unique to be distinctive.
For example, a Distinctive Permanent Identifier shared among a small number of users could still be distinctive.
</p>
<p class="note">
A Distinctive Permanent Identifier is <em>not</em> a <a def-id="distinctive-identifier"></a> because it is not derived or generated (within the scope of this specification).
</p>
<p class="note">
<a def-id="option-distinctiveIdentifier"></a> controls whether Distinctive Permanent Identifiers may be used.
Specifically, Distinctive Permanent Identifiers may only be used when the value of the <a def-id="option-distinctiveIdentifier"></a> member of the <a>MediaKeySystemAccess</a> used to create the <a>MediaKeys</a> object is <a def-id="requirement-required"></a>.
</p>
</dd>
<dt id="distinctive-identifier">Distinctive Identifier</dt>
<dd>
<div class="note">
<p>
A Distinctive Identifier is a value, including in opaque or encrypted form, for which it is possible for any entity external to the client to correlate or associate values beyond what a user may expect on the web platform (e.g. cookies and other site data).
For example, values that are <a href="#associable-by-entity">associable by an entity other than the application</a> across
a) <a def-id="origin">origins</a>,
b) <a def-id="browsing-profile">browsing profiles</a>,
or c) browsing sessions even after the user has attempted to protect his or her privacy by clearing browsing data
or values for which it is not easy for a user to break such association.
In particular, a value is a Distinctive Identifier if it is possible for a <a href="#associable-by-entity">central server, such as an individualization server, to associate</a> values across origins, such as because the <a href="#individualization">individualization</a> requests contained a common value, or because values provided in individualization requests are <a href="#associable-by-entity">associable by such server</a> even after attempts to clear browsing data.
Possible causes of this include use of <a def-id="distinctive-permanent-identifier-maybe-plural"></a> in the individualization process.
</p>
<p>
Distinctive Identifiers exposed to the application, even in encrypted form, MUST adhere to the <a href="#identifier-requirements">identifier requirements</a>,
including being <a href="#encrypt-identifiers">encrypted</a>, <a href="#per-origin-per-profile-identifiers">unique per origin and profile</a>, and <a href="#allow-identifiers-cleared">clearable</a>.
</p>
<p>
While the instantiation or use of a Distinctive Identifier is triggered by the application's use of the APIs defined in this specification, the identifier need not be provided to the application to trigger conditions related to Distinctive Identifiers.
(The <a def-id="distinctive-permanent-identifier-maybe-plural"></a> MUST NOT ever be provided to the application, even in opaque or encrypted form.)
</p>
</div>
<p class="note">
<a def-id="option-distinctiveIdentifier"></a> controls whether Distinctive Identifiers may be used.
Specifically, Distinctive Identifiers may only be used when the value of the <a def-id="option-distinctiveIdentifier"></a> member of the <a>MediaKeySystemAccess</a> used to create the <a>MediaKeys</a> object is <a def-id="requirement-required"></a>.
</p>
<p>A Distinctive Identifier is a value, piece of data, implication of the possession of a piece of data, or an observable behavior or timing for which all of the following criteria hold:</p>
<ul>
<li>
<p>It is <a href="#distinctive-value">distinctive</a>.</p>
<p class="note">While a Distinctive Identifier is typically unique to a user or client device, an identifier does not need to be strictly unique to be distinctive.
For example, an identifier shared among a small number of users could still be distinctive.
</p>
</li>
<li>
<p>It, information about it, or values derived from or otherwise related to it are exposed, even in encrypted form, outside the client.
This includes but is not limited to providing it to the application and/or license, <a href="#individualization">individualization</a>, or other server.
</p>
</li>
<li><p>It has one or more the following properties:</p>
<ul>
<li><p>It is derived from one or more <a def-id="distinctive-permanent-identifier-maybe-plural"></a>.</p></li>
<li><p>The generation, <a href="#individualization">individualization</a>, provisioning or other process that produced the value involved, used, provided, derived from, or similarly involved one or more <a def-id="distinctive-permanent-identifier-maybe-plural"></a> or another Distinctive Identifier.</p></li>
<li>
<p>It is <a href="#allow-identifiers-cleared">clearable</a> but not <a href="#allow-persistent-data-cleared-with-cookies">along with cookies and other site data</a>.</p>
<p class="note">For example, via some mechanism external to the user agent, such as an OS-level mechanism.</p>
</li>
</ul>
<div class="note">
<p>Other properties of concern that are normatively prohibited for values exposed to the application include:</p>
<ul>
<li><p>It is a <a def-id="distinctive-permanent-identifier"></a>.</p></li>
<li><p>It is <em>not</em> <a href="#allow-identifiers-cleared">clearable</a>.</p></li>
<li><p>Value(s) created after <a href="#allow-identifiers-cleared">clearing identifier(s)</a> may be <a href="#associable-by-application">associable by the application</a> with previous value(s).</p></li>
<li><p>Values may not be <a href="#per-origin-per-profile-identifiers">unique per origin and profile</a>.</p></li>
<li><p>Values for different origins may be <a href="#associable-by-application">associable by the application</a>.</p></li>
</ul>
<p>Examples of such normatively prohibited values include but is not limited to:</p>
<ul>
<li><p>A single hardware-based value used for all origins.</p></li>
<li><p>A single random based value used for all origins.</p></li>
<li><p>A single value obtained from an <a href="#individualization">individualization</a> process that is used for all origins.</p></li>
<li><p>Values that include all or part of any of the above values.</p></li>
<li><p>A single value that is used for multiple but not all origins.</p></li>
<li><p>A single value that is used for all origins on a domain. (Identifiers must be per-<a def-id="origin"></a>.)</p></li>
<li><p>A pre-provisioned origin-specific value.</p></li>
<li><p>Values generated by trivially-reversible means, which are thus <a href="#associable-by-application">associable by the application</a>, regardless of whether generated on the client or involving an a <a href="#individualization">individualization</a> process. For example, XORing or otherwise integrating (part of) the origin with a fixed value.</p></li>
</ul>
</div>
</li>
</ul>
<p class="note">
While Distinctive Identifier are usually <a href="#associable-by-entity">associable by the entity that generated them</a> they MUST be <a def-id="non-associable-by-application"></a>.
In other words, such correlation or association is only possible by the entity, such as an <a href="#individualization">individualization</a> server, that originally generated the Distinctive Identifier values.
Entities with access to the <a def-id="distinctive-permanent-identifier-maybe-plural"></a> MUST NOT expose this capability to applications, as this would make resulting Distinctive Identifiers <a href="#associable-by-application">associable by the application</a>, and SHOULD take care to avoid exposing such correlation to other entities or third parties.
</p>
<div class="note">
<p>Examples of Distinctive Identifiers include but are not limited to:</p>
<ul>
<li><p>A series of bytes that is included in key requests, different from the series of bytes included by other client devices, and based on or was acquired directly or indirectly using a <a def-id="distinctive-permanent-identifier"></a>.</p></li>
<li><p>A public key included in key requests that is different from the public keys included in the requests by other client devices and is based on or was acquired directly or indirectly using a <a def-id="distinctive-permanent-identifier"></a>.</p></li>
<li><p>Demonstration of possession of a private key (e.g. by signing some data) that other client devices do not have and is based on or was acquired directly or indirectly using a <a def-id="distinctive-permanent-identifier"></a>.</p></li>
<li><p>An identifier for such a key.</p></li>
<li><p>Such a value used to derive another value that is exposed even though the first value is not directly exposed.</p></li>
<li><p>A value derived from another Distinctive Identifier.</p></li>
<li><p>A random value that was reported to a (i.e. <a href="#individualization">individualization</a>) server along with a <a def-id="distinctive-permanent-identifier"></a> or provided by such a server after providing a <a def-id="distinctive-permanent-identifier"></a>.</p></li>
<li><p>A value derived from a unique value provisioned in the hardware device in the factory.</p></li>
<li><p>A value derived from a unique hardware value (e.g. MAC address or serial number) or software value (e.g. operating system installation instance or operating system user account name) in the hardware device in the factory.</p></li>
<li><p>A value derived from a unique value embedded in the CDM binary or other file used by the CDM.</p></li>
</ul>
<p>Examples of things that are <em>not</em> Distinctive Identifiers:</p>
<ul>
<li><p>A public key shared among all copies of a given CDM version if the installed base is large.</p></li>
<li><p>A nonce or ephemeral key that is unique but used in only one session.</p></li>
<li><p>A value that is not exposed, even in derived or similar ways, outside the client, including via <a href="#individualization">individualization</a> or similar.</p></li>
<li><p>Device-unique keys used in attestations between, for example, the video pipeline and the CDM when the CDM does not let these attestations further flow to the application and instead makes a new attestation on its own using a key that does not constitute a Distinctive Identifier.</p></li>
<li>
<p>A value that is fully cleared/clearable along with browsing data, such as cookies, after which it will be replaced by a value that is <a def-id="non-associable"></a> (not just <a def-id="non-associable-by-application"></a>), even by a central server such as an <a href="#individualization">individualization</a> server, AND one or more of the following:</p>
<ul>
<li><p>No <a def-id="distinctive-permanent-identifier"></a> or Distinctive Identifier was involved in the generation of the value.</p></li>
<li><p>It is a random value generated <em>without</em> inputs from the system.</p></li>
<li><p>It is a value provided by a server without the use of or knowledge of another Distinctive Identifier.</p></li>
</ul>
</li>
</ul>
</div>
</dd>
<dt>Use of Distinctive Identifiers and Distinctive Permanent Identifiers</dt>
<dd>
<p>
An implementation, configuration, instance, or object <dfn id="uses-distinctive-identifiers">uses Distinctive Identifier(s)</dfn> if, at any time during its lifetime or the lifetime of related such entities,
it exposes, even in encrypted form, one or more <a def-id="distinctive-identifier-maybe-plural"></a>, information about them, or values derived from or otherwise related to them outside the client.
This includes but is not limited to providing such a value to the application and/or license, <a href="#individualization">individualization</a>, or other server.
</p>
<p>
An implementation, configuration, instance, or object <dfn id="uses-distinctive-permanent-identifiers">uses Distinctive Permanent Identifier(s)</dfn> if, at any time during its lifetime or the lifetime of related such entities,
it exposes, even in encrypted form, one or more <a def-id="distinctive-permanent-identifier-maybe-plural"></a>, information about them, or values derived from or otherwise related to them outside the client.
This includes but is not limited to providing such a value to an <a href="#individualization">individualization</a> server.
Such values MUST NOT be provided to the application.
</p>
<p>
An implementation, configuration, instance, or object <dfn id="uses-distinctive-identifiers-or-distinctive-permanent-identifiers">uses Distinctive Identifier(s) or Distinctive Permanent Identifier(s)</dfn> if it
<a href="#uses-distinctive-identifiers">uses Distinctive Identifier(s)</a> and/or <a href="#uses-distinctive-permanent-identifiers">uses Distinctive Permanent Identifier(s)</a>.
</p>
<p class="note">
<a def-id="option-distinctiveIdentifier"></a> controls whether <a def-id="distinctive-identifiers"></a> and <a def-id="distinctive-permanent-identifiers"></a> may be used.
Specifically, such identifiers may only be used when the value of the <a def-id="option-distinctiveIdentifier"></a> member of the <a>MediaKeySystemAccess</a> used to create the <a>MediaKeys</a> object is <a def-id="requirement-required"></a>.
</p>
</dd>
<dt id="cross-origin">Cross Origin Limitations</dt>
<dd>
<p>During playback, embedded media data is exposed to script in the embedding <a def-id="origin"></a>.
In order for the API to provide <a def-id="initialization-data"></a> in the <a def-id="encrypted"></a> event, <a def-id="media-data"></a> MUST be <a def-id="cors-same-origin"></a> with the embedding page.
If <a def-id="media-data"></a> is cross-origin with the embedding document, authors SHOULD use the <a def-id="media-crossorigin"></a> attribute
on the <a def-id="htmlmediaelement"></a> and CORS headers on the <a def-id="media-data"></a> response to make it <a def-id="cors-same-origin"></a>.
</p>
</dd>
<dt id="mixed-content">Mixed Content Limitations</dt>
<dd>
<p>During playback, embedded media data is exposed to script in the embedding <a def-id="origin"></a>.
In order for the API to provide <a def-id="initialization-data"></a> in the <a def-id="encrypted"></a> event, <a def-id="media-data"></a> MUST NOT be Mixed Content [[!MIXED-CONTENT]].
</p>
</dd>
<dt id="time">Time</dt>
<dd>
<p>Time represents an instant in time with millisecond accuracy. The instants in time it can represent are the same that can be represented with
<a class="external" href="https://people.mozilla.org/~jorendorff/es6-draft.html#sec-date-objects">ECMAScript <span class="estype">Date</span> objects</a> (ECMA-262, section 20.3 [[!ECMA-262]]) –
namely, every millisecond in the 200,000,000 days centered around midnight of 1 January, 1970 UTC, except for any millisecond that is part of an inserted leap second. Time does not include these added leap milliseconds.
</p>
<p>Time will equal <code>NaN</code> if no such time exists or if the time is indeterminate. It should never have the value <code>Infinity</code>.
</p>
<p>Time is intended to be consistent with Unix time.
</p>
</dd>
<dt id="browsing-profile">Browsing Profile</dt>
<dd>
<p>
A User Agent on a given machine may support execution in a variety of different contexts or modes or temporary states that are expected to behave independently
with respect to application-visible state and data.
In particular, all stored data is expected to be independent. In this specification we refer to such independent contexts or modes as "Browsing Profiles".
</p>
<p class="note">
Examples of such independent contexts include if the user agent is running in different operating system user accounts or if the user agent provides the capability to define
multiple independent profiles for a single account.
</p>
</dd>
</dl>
</section>
<section>
<h2>Obtaining Access to Key Systems</h2>
<p>This section defines the mechanism for obtaining access to a key system.
The inclusion of capabilities in the request also enables feature detection.
</p>
<p>The steps of an algorithm are always aborted when rejecting a promise.</p>
<section>
<h3><a>Navigator</a> Extension: <code>requestMediaKeySystemAccess()</code></h3>
<div><pre class="idl">partial interface Navigator {
[SecureContext] Promise<MediaKeySystemAccess> requestMediaKeySystemAccess (DOMString keySystem, sequence<MediaKeySystemConfiguration> supportedConfigurations);
};</pre><section><h2>Methods</h2><dl class="methods" data-dfn-for="Navigator" data-link-for="Navigator"><dt><dfn><code>requestMediaKeySystemAccess</code></dfn></dt><dd>
<p class="note">Calling this method may have <em>user-visible effects</em>, including requests for user consent.
This method should only be called when the author intends to create and use a <a>MediaKeys</a> object with the provided configuration.
</p>
<p>Requests access to the specified <a def-id="keysystem"></a>.
When <code>supportedConfigurations</code> is specified, the configuration specified by at least one of its elements must be supported.
The resulting <a>MediaKeySystemAccess</a> will correspond to the first such element.
</p>
<p>Any permission checks or user interaction, such as a prompt for consent, MUST be performed before resolving the promise.</p>
<p>If the <code>keySystem</code> is not supported or not allowed (in at least one of the <code>supportedConfigurations</code>, if specified), the promise is rejected.
Otherwise, it is resolved with a new <a>MediaKeySystemAccess</a> object.
</p>
<div class="note">
<p>This method is only exposed to <a href="https://www.w3.org/TR/secure-contexts/#secure-context">secure contexts</a> [[SECURE-CONTEXTS]] as indicated by the <code>[SecureContext]</code> IDL attribute.</p>
<p>
Requiring Secure Contexts is <em>not</em> a replacement for other security- and privacy-related requirements and recommendations.
Implementations MUST meet all related requirements and SHOULD follow related recommendations such that the risks on in an secure context would be similar.
</p>
</div>
<ol class="method-algorithm">
<!-- TODO: Convert all parameters to use <code>. -->
<li><p>If <var>keySystem</var> is the empty string, return a promise rejected with a newly created <a def-id="TypeError"></a>.</p></li>
<li><p>If <var>supportedConfigurations</var> is empty, return a promise rejected with a newly created <a def-id="TypeError"></a>.</p></li>
<li><p>Let <var>document</var> be the calling context's <a def-id="document-concept"></a>.</p></li>
<li><p>Let <var>origin</var> be the <a def-id="origin"></a> of <var>document</var>.</p></li>
<li><p>Let <var>promise</var> be a new promise.</p></li>
<li><p>Run the following steps in parallel:</p>
<ol>
<li><p>If <var>keySystem</var> is not one of the <a def-id="keysystems"></a> supported by the user agent, reject <var>promise</var> with a <a def-id="NotSupportedError"></a>. String comparison is case-sensitive.</p></li>
<li><p>Let <var>implementation</var> be the implementation of <var>keySystem</var>.</p></li>
<li><p>For each value in <code>supportedConfigurations</code>:</p>
<ol>
<li><p>Let <var>candidate configuration</var> be the value.</p></li>
<li><p>Let <var>supported configuration</var> be the result of executing the <a def-id="get-supported-configuration-algorithm"></a> algorithm on <var>implementation</var>, <var>candidate configuration</var>, and <var>origin</var>.</p></li>
<li><p>If <var>supported configuration</var> is not <code>NotSupported</code>, run the following steps:</p>
<ol>
<li>
<p>Let <var>access</var> be a new <a>MediaKeySystemAccess</a> object, and initialize it as follows:</p>
<ol>
<li><p>Set the <a def-id="keySystem-attribute"></a> attribute to <var>keySystem</var>.</p></li>
<li><p>Let the <var>configuration</var> value be <var>supported configuration</var>.</p></li>
<li><p>Let the <var>cdm implementation</var> value be <var>implementation</var>.</p></li>
</ol>
</li>
<li><p>Resolve <var>promise</var> with <var>access</var> and abort the parallel steps of this algorithm.</p></li>
</ol>
</li>
</ol>
</li>
<li><p>Reject <var>promise</var> with a <a def-id="NotSupportedError"></a>.</p>
<p class="note"><code>keySystem</code> was not supported/allowed or none of the configurations in <code>supportedConfigurations</code> were supported/allowed.</p>
</li>
</ol>
</li>
<li><p>Return <var>promise</var>.</p></li>
</ol>
<table class="parameters"><tbody><tr><th>Parameter</th><th>Type</th><th>Nullable</th><th>Optional</th><th>Description</th></tr><tr><td class="prmName">keySystem</td><td class="prmType"><code>DOMString</code></td><td class="prmNullFalse"><span role="img" aria-label="False">✘</span></td><td class="prmOptFalse"><span role="img" aria-label="False">✘</span></td><td class="prmDesc">
The <a def-id="keysystem"></a> for which access is being requested.
</td></tr><tr><td class="prmName">supportedConfigurations</td><td class="prmType"><code>sequence<MediaKeySystemConfiguration></code></td><td class="prmNullFalse"><span role="img" aria-label="False">✘</span></td><td class="prmOptFalse"><span role="img" aria-label="False">✘</span></td><td class="prmDesc">
A sequence of <a>MediaKeySystemConfiguration</a> configurations to try in order.
The first element with a satisfiable configuration will be used.
</td></tr></tbody></table><div><em>Return type: </em><code>Promise<MediaKeySystemAccess></code></div></dd></dl></section></div>
<section>
<h4>Algorithms</h4>
<section>
<h5>Get Supported Configuration</h5>
<p>Given a <a def-id="keysystems"></a> implementation <var>implementation</var>, <a>MediaKeySystemConfiguration</a> <var>candidate configuration</var>, and <var>origin</var>, this algorithm returns a supported configuration or <code>NotSupported</code> as appropriate.</p>
<p class="note">Unrecognized dictionary members in <var>candidate configuration</var> are ignored per [[WebIDL]] and will never reach this algorithm. Thus, they cannot be considered as part of the configuration.
</p>
<div class="note">
<p>
For certain configurations, it may be required to obtain user consent or inform the user. User Agents have some flexibility to determine
whether consent is required for a specific configuration and whether such consent may also apply to other configurations. For example,
consent to one configuration may also imply consent for less powerful, more restricted configurations. Equally, a denial of consent for
one configuration may imply denial of consent for more powerful, less restricted configurations.
</p>
<p>
Supported configurations, including supported audio and video codecs, may depend on availability of optional capabilities such as
<a def-id="distinctive-identifier-maybe-plural"></a> and persistent state. The following algorithm iteratively tries to find a configuration
that is both supported and has user consent (or does not need consent).
</p>
<p>
User Agents should reuse earlier consent responses, when appropriate, at least for the duration of the <a def-id="requestMediaKeySystemAccess"></a>
algorithm in order to avoid repeated requests to the user for similar configurations.
</p>
<p>
The variable <var>restrictions</var> in the steps below represents the configurations for which consent has been denied during the
execution of this algorithm or based on persisted consent information for the origin. It is used to determine
whether user consent for a candidate configuration or partial configuration has been denied. Consent is denied for a partial configuration
if every derived configuration has already been denied. Internal representation of <var>restrictions</var> is implementation-specific.
</p>
</div>
<ol>
<li>
<p>Let <var>supported configuration</var> be <code>ConsentDenied</code>.</p>
</li>
<li>
<p>Initialize <var>restrictions</var> to indicate that no configurations have had user consent denied.</p>
</li>
<li>
<p>Repeat the following step while <var>supported configuration</var> is <code>ConsentDenied</code>:</p>
<ol>
<li>
<p>
Let <var>supported configuration</var> and, if provided, <var>restrictions</var> be the result of executing the
<a def-id="get-supported-configuration-and-consent-algorithm"></a> algorithm
with <var>implementation</var>, <var>candidate configuration</var>, <var>restrictions</var> and <var>origin</var>.
</p>
</li>
</ol>
</li>
<li>
<p>Return <var>supported configuration</var>.</p>
</li>
</ol>
</section>
<section>
<h5>Get Supported Configuration and Consent</h5>
<p>Given a <a def-id="keysystems"></a> implementation <var>implementation</var>, <a>MediaKeySystemConfiguration</a> <var>candidate configuration</var>,
<var>restrictions</var> and <var>origin</var>, this algorithm returns a supported configuration, <code>NotSupported</code>, or <code>ConsentDenied</code> as appropriate and, in the <code>ConsentDenied</code> case, <var>restrictions</var>.
</p>
<ol>
<li><p>Let <var>accumulated configuration</var> be a new <a>MediaKeySystemConfiguration</a> dictionary.</p></li>
<li>
<p>
Set the <a def-id="option-label"></a> member of <var>accumulated configuration</var> to equal the <a def-id="option-label"></a> member of <var>candidate configuration</var>.
</p>
</li>
<li><p>If the <a def-id="option-initDataTypes"></a> member of <var>candidate configuration</var> is non-empty, run the following steps:</p>
<ol>
<li><p>Let <var>supported types</var> be an empty sequence of DOMStrings.</p></li>
<li><p>For each value in <var>candidate configuration</var>'s <a def-id="option-initDataTypes"></a> member:</p>
<ol>
<li><p>Let <var>initDataType</var> be the value.</p></li>
<li>
<p>If the <var>implementation</var> supports generating requests based on <var>initDataType</var>, add <var>initDataType</var> to <var>supported types</var>.
String comparison is case-sensitive.
The empty string is never supported.
</p>
<p class="note">The <var>initDataType</var> MUST be supported independent of content types in order to avoid unexpectedly rejecting the configuration in later steps.
Support for <var>initDataType</var> includes both license generation and, when appropriate, extraction from media data.
See <a href="#initialization-data-type-support-requirements">Initialization Data Type Support requirements</a>.
</p>
</li>
</ol>
</li>
<li><p>If <var>supported types</var> is empty, return <code>NotSupported</code>.</p></li>
<li><p>Set the <a def-id="option-initDataTypes"></a> member of <var>accumulated configuration</var> to <var>supported types</var>.</p></li>
</ol>
</li>
<!-- Table of results for MediaKeysRequirement members based on implementation capabilities:
|| Implementation Capabilities |
Input Value || Only Supported | Only Not Supported | Both |
===========================================================================================
"required" || "required" | Return null | "required" |
"optional" || "required" | "not-allowed" | Depends on combination |
"not-allowed" || Return null | "not-allowed" | "not-allowed" |
-->
<li>
<p>
Let <var>distinctive identifier requirement</var> be the value of <var>candidate configuration</var>'s <a def-id="option-distinctiveIdentifier"></a> member.
</p>
</li>
<li>
<p>
If <var>distinctive identifier requirement</var> is <a def-id="requirement-optional"></a> and
<a def-id="distinctive-identifiers"></a> are not allowed according to <var>restrictions</var>, set <var>distinctive identifier requirement</var>
to <a def-id="requirement-not-allowed"></a>.
</p>
</li>
<li>
<p>Follow the steps for <var>distinctive identifier requirement</var> from the following list:</p>
<dl class="switch">
<dt><a def-id="requirement-required"></a></dt>
<dd>
<p>If the <var>implementation</var> does not support <a href="#uses-distinctive-identifiers">use of Distinctive Identifier(s)</a> in combination with <var>accumulated configuration</var> and <var>restrictions</var>, return <code>NotSupported</code>.</p>
<!-- TODO: Find a better descriptive model for this than "combination."
See the first three comment threads starting with https://github.com/w3c/encrypted-media/pull/165#discussion_r63112757. -->
</dd>
<dt><a def-id="requirement-optional"></a></dt>
<dd>
<p>Continue with the following steps.</p>
</dd>
<dt><a def-id="requirement-not-allowed"></a></dt>
<dd>
<p>If the <var>implementation</var> requires <a href="#uses-distinctive-identifiers-or-distinctive-permanent-identifiers">use Distinctive Identifier(s) or Distinctive Permanent Identifier(s)</a> in combination with <var>accumulated configuration</var> and <var>restrictions</var>, return <code>NotSupported</code>.</p>
</dd>
</dl>
<div class="note">
<p>
The combination of <var>accumulated configuration</var> and <var>restrictions</var> means all the possible configurations that
include everything in <var>accumulated configuration</var> and that are not denied according to <var>restrictions</var>.
</p>
<p>
A feature is supported by an implementation with this combination if the implementation supports at least one of the configurations
in the combination with the feature.
</p>
<p>
A feature is required by an implementtion with this combination if all configurations in the combination that are suported by the implementation
include the feature.
</p>
</div>
</li>
<li>
<p>
Set the <a def-id="option-distinctiveIdentifier"></a> member of <var>accumulated configuration</var> to equal <var>distinctive identifier requirement</var>.
</p>
</li>
<li>
<p>
Let <var>persistent state requirement</var> be equal to the value of <var>candidate configuration</var>'s <a def-id="option-persistentState"></a> member.
</p>
</li>
<li>
<p>
If <var>persistent state requirement</var> is <a def-id="requirement-optional"></a> and persisting state is not allowed according to
<var>restrictions</var>, set <var>persistent state requirement</var> to <a def-id="requirement-not-allowed"></a>.
</p>
</li>
<li><p>Follow the steps for <var>persistent state requirement</var> from the following list:</p>
<dl class="switch">
<dt><a def-id="requirement-required"></a></dt>
<dd>
<p>If the <var>implementation</var> does not support persisting state in combination with <var>accumulated configuration</var> and <var>restrictions</var>, return <code>NotSupported</code>.</p>
</dd>
<dt><a def-id="requirement-optional"></a></dt>
<dd>
<p>
Continue with the following steps.
</p>
</dd>
<dt><a def-id="requirement-not-allowed"></a></dt>
<dd>
<p>If the <var>implementation</var> requires persisting state in combination with <var>accumulated configuration</var> and <var>restrictions</var>, return <code>NotSupported</code>.</p>
</dd>
</dl>
</li>
<li>
<p>
Set the <a def-id="option-persistentState"></a> member of <var>accumulated configuration</var> to equal the value of <var>persistent state requirement</var>.
</p>
</li>
<li><p>Follow the steps for the first matching condition from the following list:</p>
<dl class="switch">
<dt>If the <a def-id="option-sessionTypes"></a> member is <a def-id="present-dictionary-member"></a> [[!WebIDL]] in <var>candidate configuration</var></dt>
<dd>
<p>Let <var>session types</var> be <var>candidate configuration</var>'s <a def-id="option-sessionTypes"></a> member.</p>
</dd>
<dt>Otherwise</dt>
<dd>
<p>Let <var>session types</var> be <code>[ <a def-id="temporary-session"></a> ]</code>.</p>
</dd>
</dl>
</li>
<li><p>For each value in <var>session types</var>:</p>
<ol>
<li><p>Let <var>session type</var> be the value.</p></li>
<li>
<p>
If <var>accumulated configuration</var>'s <a def-id="option-persistentState"></a> value is <a def-id="requirement-not-allowed"></a> and the <a def-id="is-persistent-session-type-algorithm"></a> algorithm returns <code>true</code> for <var>session type</var> return <code>NotSupported</code>.
</p>
</li>
<li>
<p>If the <var>implementation</var> does not support <var>session type</var> in combination with <var>accumulated configuration</var> and <var>restrictions</var> for other reasons, return <code>NotSupported</code>.</p>
</li>
<li><p>If <var>accumulated configuration</var>'s <a def-id="option-persistentState"></a> value is <a def-id="requirement-optional"></a> and the result of running the <a def-id="is-persistent-session-type-algorithm"></a> algorithm on <var>session type</var> is <code>true</code>, change <var>accumulated configuration</var>'s <a def-id="option-persistentState"></a> value to <a def-id="requirement-required"></a>.</p></li>
</ol>
</li>
<li><p>Set the <a def-id="option-sessionTypes"></a> member of <var>accumulated configuration</var> to <var>session types</var>.</p></li>
<li>
<p>
If the <a def-id="option-videoCapabilities"></a> and <a def-id="option-audioCapabilities"></a> members in <var>candidate configuration</var>
are both empty, return <code>NotSupported</code>.
</p>
</li>
<li>
<dl class="switch">
<dt>If the <a def-id="option-videoCapabilities"></a> member in <var>candidate configuration</var> is non-empty:</dt>
<dd>
<ol>
<li><p>Let <var>video capabilities</var> be the result of executing the <a def-id="get-supported-capabilities-for-audio-video-type-algorithm"></a> algorithm on Video, <var>candidate configuration</var>'s <a def-id="option-videoCapabilities"></a> member, <var>accumulated configuration</var>, and <var>restrictions</var>.</p></li>
<li><p>If <var>video capabilities</var> is <code>null</code>, return <code>NotSupported</code>.</p></li><!-- Video capabilities were specified, but none were supported. -->
<li><p>Set the <a def-id="option-videoCapabilities"></a> member of <var>accumulated configuration</var> to <var>video capabilities</var>.</p></li>
</ol>
</dd>
<dt>Otherwise:</dt>
<dd><p>Set the <a def-id="option-videoCapabilities"></a> member of <var>accumulated configuration</var> to an empty sequence.</p></dd>
</dl>
</li>
<li>
<dl class="switch">
<dt>If the <a def-id="option-audioCapabilities"></a> member in <var>candidate configuration</var> is non-empty:</dt>
<dd>
<ol>
<li><p>Let <var>audio capabilities</var> be the result of executing the <a def-id="get-supported-capabilities-for-audio-video-type-algorithm"></a> algorithm on Audio, <var>candidate configuration</var>'s <a def-id="option-audioCapabilities"></a> member, <var>accumulated configuration</var>, and <var>restrictions</var>.</p></li>
<li><p>If <var>audio capabilities</var> is <code>null</code>, return <code>NotSupported</code>.</p></li><!-- Audio capabilities were specified, but none were supported. -->
<li><p>Set the <a def-id="option-audioCapabilities"></a> member of <var>accumulated configuration</var> to <var>audio capabilities</var>.</p></li>
</ol>
</dd>
<dt>Otherwise:</dt>
<dd><p>Set the <a def-id="option-audioCapabilities"></a> member of <var>accumulated configuration</var> to an empty sequence.</p></dd>
</dl>
</li>
<!-- Replace "optional" values in the combined configuration before checking permissions and for the value exposed by MediaKeySystemAccess. -->
<li><p>If <var>accumulated configuration</var>'s <a def-id="option-distinctiveIdentifier"></a> value is <a def-id="requirement-optional"></a>, follow the steps for the first matching condition from the following list:</p>
<dl class="switch">
<dt>If the <var>implementation</var> requires <a href="#uses-distinctive-identifiers-or-distinctive-permanent-identifiers">use Distinctive Identifier(s) or Distinctive Permanent Identifier(s)</a> for any of the combinations in <var>accumulated configuration</var></dt>
<dd>
<p>Change <var>accumulated configuration</var>'s <a def-id="option-distinctiveIdentifier"></a> value to <a def-id="requirement-required"></a>.</p>
</dd>
<dt>Otherwise</dt>
<dd>
<p>Change <var>accumulated configuration</var>'s <a def-id="option-distinctiveIdentifier"></a> value to <a def-id="requirement-not-allowed"></a>.</p>
</dd>
</dl>
</li>
<li><p>If <var>accumulated configuration</var>'s <a def-id="option-persistentState"></a> value is <a def-id="requirement-optional"></a>, follow the steps for the first matching condition from the following list:</p>
<dl class="switch">
<dt>If the <var>implementation</var> requires persisting state for any of the combinations in <var>accumulated configuration</var></dt>
<dd>
<p>Change <var>accumulated configuration</var>'s <a def-id="option-persistentState"></a> value to <a def-id="requirement-required"></a>.</p>
</dd>
<dt>Otherwise</dt>
<dd>
<p>Change <var>accumulated configuration</var>'s <a def-id="option-persistentState"></a> value to <a def-id="requirement-not-allowed"></a>.</p>
</dd>
</dl>
</li>
<li><p>If <var>implementation</var> in the configuration specified by the combination of the values in <var>accumulated configuration</var> is not supported or not allowed in the <var>origin</var>, return <code>NotSupported</code>.</p>
<p class="note">In this step, "supported" includes the implementation being available for use when this algorithm returns, not just user agent support for such an implementation.</p>
</li>
<li>
<p>
If <var>accumulated configuration</var>'s <a def-id="option-distinctiveIdentifier"></a> value is <a def-id="requirement-required"></a> and
the <a def-id="distinctive-identifier-maybe-plural"></a> associated with <var>accumulated configuration</var> are not <a href="#per-origin-per-profile-identifiers">unique per origin and profile</a> and
<a href="#allow-identifiers-cleared">clearable</a>:
</p>
<ol>
<li>
<p>
Update <var>restrictions</var> to reflect that all configurations described by <var>accumulated configuration</var>
do not have user consent.
</p>
</li>
<li>
<p>Return <code>ConsentDenied</code> and <var>restrictions</var>.</p>
</li>
</ol>
<div class="note">
<p>
The "unique per origin and profile" and "clearable" conditions cannot be false in a compliant implementation because implementations MUST <a href="#per-origin-per-profile-identifiers">use per-origin per-profile identifiers</a> and <a href="#allow-identifiers-cleared">allow the user to clear identifier</a>.
</p>
</div>
</li>
<li>
<p>
Let <var>consent status</var> and <var>updated restrictions</var> be the result of running the <a def-id="get-consent-status-algorithm"></a> algorithm on <var>accumulated configuration</var>, <var>restrictions</var> and <var>origin</var> and follow the steps for the value of <var>consent status</var> from the following list:
</p>