-
Notifications
You must be signed in to change notification settings - Fork 4
/
draft-ietf-secevent-http-push.html
1329 lines (1225 loc) · 66.8 KB
/
draft-ietf-secevent-http-push.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 PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>Push-Based Security Event Token (SET) Delivery Using HTTP</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction and Overview">
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Notational Conventions">
<link href="#rfc.section.1.2" rel="Chapter" title="1.2 Definitions">
<link href="#rfc.section.2" rel="Chapter" title="2 SET Delivery">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Transmitting a SET">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Success Response">
<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Failure Response">
<link href="#rfc.section.2.4" rel="Chapter" title="2.4 Security Event Token Delivery Error Codes">
<link href="#rfc.section.3" rel="Chapter" title="3 Authentication and Authorization">
<link href="#rfc.section.4" rel="Chapter" title="4 Delivery Reliability">
<link href="#rfc.section.5" rel="Chapter" title="5 Security Considerations">
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Authentication Using Signed SETs">
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 HTTP Considerations">
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Confidentiality of SETs">
<link href="#rfc.section.5.4" rel="Chapter" title="5.4 Denial of Service">
<link href="#rfc.section.5.5" rel="Chapter" title="5.5 Authenticating Persisted SETs">
<link href="#rfc.section.6" rel="Chapter" title="6 Privacy Considerations">
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations">
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 Security Event Token Delivery Error Codes">
<link href="#rfc.section.7.1.1" rel="Chapter" title="7.1.1 Registration Template">
<link href="#rfc.section.7.1.2" rel="Chapter" title="7.1.2 Initial Registry Contents">
<link href="#rfc.references" rel="Chapter" title="8 References">
<link href="#rfc.references.1" rel="Chapter" title="8.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="8.2 Informative References">
<link href="#rfc.appendix.A" rel="Chapter" title="A Unencrypted Transport Considerations">
<link href="#rfc.appendix.B" rel="Chapter" title="B Other Streaming Specifications">
<link href="#rfc.appendix.C" rel="Chapter" title="C Acknowledgments">
<link href="#rfc.appendix.D" rel="Chapter" title="D Change Log">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.46.0 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin" />
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-secevent-http-push-14" />
<meta name="dct.issued" scheme="ISO8601" content="2020-06-26" />
<meta name="dct.abstract" content="This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. " />
<meta name="description" content="This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Security Events Working Group</td>
<td class="right">A. Backman, Ed.</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Amazon</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">M. Jones, Ed.</td>
</tr>
<tr>
<td class="left">Expires: December 28, 2020</td>
<td class="right">Microsoft</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">M. Scurtescu</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Coinbase</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">M. Ansari</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Cisco</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">A. Nadalin</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Microsoft</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">June 26, 2020</td>
</tr>
</tbody>
</table>
<p class="title">Push-Based Security Event Token (SET) Delivery Using HTTP<br />
<span class="filename">draft-ietf-secevent-http-push-14</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. </p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on December 28, 2020.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction and Overview</a>
</li>
<ul><li>1.1. <a href="#rfc.section.1.1">Notational Conventions</a>
</li>
<li>1.2. <a href="#rfc.section.1.2">Definitions</a>
</li>
</ul><li>2. <a href="#rfc.section.2">SET Delivery</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Transmitting a SET</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Success Response</a>
</li>
<li>2.3. <a href="#rfc.section.2.3">Failure Response</a>
</li>
<li>2.4. <a href="#rfc.section.2.4">Security Event Token Delivery Error Codes</a>
</li>
</ul><li>3. <a href="#rfc.section.3">Authentication and Authorization</a>
</li>
<li>4. <a href="#rfc.section.4">Delivery Reliability</a>
</li>
<li>5. <a href="#rfc.section.5">Security Considerations</a>
</li>
<ul><li>5.1. <a href="#rfc.section.5.1">Authentication Using Signed SETs</a>
</li>
<li>5.2. <a href="#rfc.section.5.2">HTTP Considerations</a>
</li>
<li>5.3. <a href="#rfc.section.5.3">Confidentiality of SETs</a>
</li>
<li>5.4. <a href="#rfc.section.5.4">Denial of Service</a>
</li>
<li>5.5. <a href="#rfc.section.5.5">Authenticating Persisted SETs</a>
</li>
</ul><li>6. <a href="#rfc.section.6">Privacy Considerations</a>
</li>
<li>7. <a href="#rfc.section.7">IANA Considerations</a>
</li>
<ul><li>7.1. <a href="#rfc.section.7.1">Security Event Token Delivery Error Codes</a>
</li>
<ul><li>7.1.1. <a href="#rfc.section.7.1.1">Registration Template</a>
</li>
<li>7.1.2. <a href="#rfc.section.7.1.2">Initial Registry Contents</a>
</li>
</ul></ul><li>8. <a href="#rfc.references">References</a>
</li>
<ul><li>8.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>8.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Unencrypted Transport Considerations</a>
</li>
<li>Appendix B. <a href="#rfc.appendix.B">Other Streaming Specifications</a>
</li>
<li>Appendix C. <a href="#rfc.appendix.C">Acknowledgments</a>
</li>
<li>Appendix D. <a href="#rfc.appendix.D">Change Log</a>
</li>
<li><a href="#rfc.authors">Authors' Addresses</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#intro" id="intro">Introduction and Overview</a>
</h1>
<p id="rfc.section.1.p.1">This specification defines a mechanism by which a transmitter of a <a href="#RFC8417" class="xref">Security Event Token (SET)</a> can deliver the SET to an intended SET Recipient via <a href="#RFC7231" class="xref">HTTP POST</a> over TLS. This is an alternative SET delivery method to the one defined in <a href="#I-D.ietf-secevent-http-poll" class="xref">[I-D.ietf-secevent-http-poll]</a>. </p>
<p id="rfc.section.1.p.2">Push-based SET delivery over HTTP POST is intended for scenarios where all of the following apply: </p>
<ul>
<li>The transmitter of the SET is capable of making outbound HTTP requests.</li>
<li>The recipient is capable of hosting a TLS-enabled HTTP endpoint that is accessible to the transmitter. </li>
<li>The transmitter and recipient are willing to exchange data with one another. </li>
</ul>
<p> In some scenarios, either push-based or poll-based delivery could be used, and in others, only one of them would be applicable. </p>
<p id="rfc.section.1.p.3">A mechanism for exchanging configuration metadata such as endpoint URLs, cryptographic keys, and possible implementation constraints such as buffer size limitations between the transmitter and recipient is out of scope for this specification. How SETs are defined and the process by which security events are identified for SET Recipients are specified in <a href="#RFC8417" class="xref">[RFC8417]</a>. </p>
<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> <a href="#notat" id="notat">Notational Conventions</a>
</h1>
<p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <a href="#RFC2119" class="xref">[RFC2119]</a> <a href="#RFC8174" class="xref">[RFC8174]</a> when, and only when, they appear in all capitals, as shown here. </p>
<p id="rfc.section.1.1.p.2">Throughout this document, all figures may contain spaces and extra line wrapping for readability and due to space limitations. </p>
<h1 id="rfc.section.1.2">
<a href="#rfc.section.1.2">1.2.</a> <a href="#defs" id="defs">Definitions</a>
</h1>
<p id="rfc.section.1.2.p.1">This specification utilizes the following terms defined in <a href="#RFC8417" class="xref">[RFC8417]</a>: "Security Event Token (SET)", "SET Issuer", "SET Recipient", and "Event Payload", as well as the term defined below: </p>
<p></p>
<dl>
<dt>SET Transmitter</dt>
<dd style="margin-left: 8">An entity that delivers SETs in its possession to one or more SET Recipients. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#Delivery" id="Delivery">SET Delivery</a>
</h1>
<p id="rfc.section.2.p.1">To deliver a SET to a given SET Recipient, the SET Transmitter makes a SET transmission request to the SET Recipient, with the SET itself contained within the request. The SET Recipient replies to this request with a response either acknowledging successful transmission of the SET or indicating that an error occurred while receiving, parsing, and/or validating the SET. </p>
<p id="rfc.section.2.p.2">Upon receipt of a SET, the SET Recipient SHALL validate that all of the following are true: </p>
<ul>
<li>The SET Recipient can parse the SET.</li>
<li>The SET is authentic (i.e., it was issued by the issuer specified within the SET, and if signed, was signed by a key belonging to the issuer). </li>
<li>The SET Recipient is identified as an intended audience of the SET. </li>
<li>The SET Issuer is recognized as an issuer that the SET Recipient is willing to receive SETs from (e.g., the issuer is listed as allowed by the SET Recipient). </li>
<li>The SET Recipient is willing to accept this SET from this SET Transmitter (e.g., the SET Transmitter is expected to send SETs with the issuer and subject of the SET in question). </li>
</ul>
<p> </p>
<p id="rfc.section.2.p.3">The mechanisms by which the SET Recipient performs this validation are out of scope for this document. SET parsing, issuer identification, and audience identification are defined in <a href="#RFC8417" class="xref">[RFC8417]</a>. The mechanism for validating the authenticity of a SET is deployment specific, and may vary depending on the authentication mechanisms in use, and whether the SET is signed and/or encrypted (See <a href="#aa" class="xref">Section 3</a>). </p>
<p id="rfc.section.2.p.4">SET Transmitters MAY transmit SETs issued by another entity. The SET Recipient may accept or reject (i.e., return an error response such as <samp>access_denied</samp>) a SET at its own discretion. </p>
<p id="rfc.section.2.p.5">The SET Recipient persists the SET in a way that is sufficient to meet the SET Recipient's own reliability requirements. The level and method of retention of SETs by SET Recipients is out of scope of this specification. Once the SET has been validated and persisted, the SET Recipient SHOULD immediately return a response indicating that the SET was successfully delivered. The SET Recipient SHOULD NOT perform further processing of the SET beyond the required validation steps prior to sending this response. Any additional steps SHOULD be executed asynchronously from delivery to minimize the time the SET Transmitter is waiting for a response. </p>
<p id="rfc.section.2.p.6">The SET Transmitter MAY transmit the same SET to the SET Recipient multiple times, regardless of the response from the SET Recipient. The SET Recipient MUST respond as it would if the SET had not been previously received by the SET Recipient. The SET Recipient MUST NOT expect or depend on a SET Transmitter to re-transmit a SET or otherwise make a SET available to the SET Recipient once the SET Recipient acknowledges that it was received successfully. </p>
<p id="rfc.section.2.p.7">The SET Transmitter should not re-transmit a SET unless the SET Transmitter suspects that previous transmissions may have failed due to potentially recoverable errors (such as network outage or temporary service interruption at either the SET Transmitter or SET Recipient). In all other cases, the SET Transmitter SHOULD NOT re-transmit a SET. The SET Transmitter SHOULD delay retransmission for an appropriate amount of time to avoid overwhelming the SET Recipient (see <a href="#reliability" class="xref">Section 4</a>). </p>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#httpPost" id="httpPost">Transmitting a SET</a>
</h1>
<p id="rfc.section.2.1.p.1">To transmit a SET to a SET Recipient, the SET Transmitter makes an HTTP POST request to a TLS-enabled HTTP endpoint provided by the SET Recipient. The <samp>Content-Type</samp> header field of this request MUST be <samp>application/secevent+jwt</samp> as defined in Sections 2.3 and 7.2 of <a href="#RFC8417" class="xref">[RFC8417]</a>, and the <samp>Accept</samp> header field MUST be <samp>application/json</samp>. The request body MUST consist of the SET itself, represented as a <a href="#RFC7519" class="xref">JWT</a>. </p>
<p id="rfc.section.2.1.p.2">The SET Transmitter MAY include in the request an <samp>Accept-Language</samp> header field to indicate to the SET Recipient the preferred language(s) in which to receive error messages. </p>
<p id="rfc.section.2.1.p.3">The mechanisms by which the SET Transmitter determines the HTTP endpoint to use when transmitting a SET to a given SET Recipient are not defined by this specification and are deployment specific. </p>
<div id="rfc.figure.1"></div>
<div id="postSet"></div>
<p>The following is a non-normative example of a SET transmission request: </p>
<pre>
POST /Events HTTP/1.1
Host: notify.rp.example.com
Accept: application/json
Accept-Language: en-US, en;q=0.5
Content-Type: application/secevent+jwt
eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJIUzI1NiJ9Cg
.
eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iLCJqdGkiOiI3NTZFNjk
3MTc1NjUyMDY5NjQ2NTZFNzQ2OTY2Njk2NTcyIiwiaWF0IjoxNTA4MTg0ODQ1LC
JhdWQiOiI2MzZDNjk2NTZFNzQ1RjY5NjQiLCJldmVudHMiOnsiaHR0cHM6Ly9zY
2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291
bnQtZGlzYWJsZWQiOnsic3ViamVjdCI6eyJzdWJqZWN0X3R5cGUiOiJpc3Mtc3V
iIiwiaXNzIjoiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vIiwic3ViIjoiNzM3NT
YyNkE2NTYzNzQifSwicmVhc29uIjoiaGlqYWNraW5nIn19fQ
.
Y4rXxMD406P2edv00cr9Wf3_XwNtLjB9n-jTqN1_lLc
</pre>
<p class="figure">Figure 1: Example SET Transmission Request</p>
<h1 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#successResponse" id="successResponse">Success Response</a>
</h1>
<p id="rfc.section.2.2.p.1">If the SET is determined to be valid, the SET Recipient SHALL acknowledge successful transmission by responding with HTTP Response Status Code 202 (Accepted) (see Section 6.3.3 of <a href="#RFC7231" class="xref">[RFC7231]</a>). The body of the response MUST be empty. </p>
<div id="rfc.figure.2"></div>
<div id="goodPostResponse"></div>
<p>The following is a non-normative example of a successful receipt of a SET.</p>
<pre>
HTTP/1.1 202 Accepted
</pre>
<p class="figure">Figure 2: Example Successful Delivery Response</p>
<h1 id="rfc.section.2.3">
<a href="#rfc.section.2.3">2.3.</a> <a href="#failureResponse" id="failureResponse">Failure Response</a>
</h1>
<p id="rfc.section.2.3.p.1">In the event of a general HTTP error condition, the SET Recipient responds with the applicable HTTP Status Code, as defined in Section 6 of <a href="#RFC7231" class="xref">[RFC7231]</a>.</p>
<p id="rfc.section.2.3.p.2">When the SET Recipient detects an error parsing, validating, or authenticating a SET transmitted in a SET Transmission Request, the SET Recipient SHALL respond with an HTTP Response Status Code of 400 (Bad Request). The <samp>Content-Type</samp> header field of this response MUST be "application/json", and the body MUST be a UTF-8 encoded <a href="#RFC8259" class="xref">JSON</a> object containing the following name/value pairs: </p>
<dl>
<dt>err</dt>
<dd style="margin-left: 8">A Security Event Token Error Code (see <a href="#error_codes" class="xref">Section 2.4</a>). </dd>
<dt>description</dt>
<dd style="margin-left: 8">A UTF-8 string containing a human-readable description of the error that may provide additional diagnostic information. The exact content of this field is implementation specific. </dd>
</dl>
<p> </p>
<p id="rfc.section.2.3.p.3">The response MUST include a <samp>Content-Language</samp> header field, whose value indicates the language of the error descriptions included in the response body. If the SET Recipient can provide error descriptions in multiple languages, they SHOULD choose the language to use according to the value of the <samp>Accept-Language</samp> header field sent by the SET Transmitter in the transmission request, as described in Section 5.3.5 of <a href="#RFC7231" class="xref">[RFC7231]</a>. If the SET Transmitter did not send an <samp>Accept-Language</samp> header field, or if the SET Recipient does not support any of the languages included in the header field, the SET Recipient MUST respond with messages that are understandable by an English-speaking person, as described in Section 4.5 of <a href="#RFC2277" class="xref">[RFC2277]</a>. </p>
<div id="rfc.figure.3"></div>
<div id="errorResponseInvalidKey"></div>
<p>The following is a non-normative example error response indicating that the key used to encrypt the SET has been revoked.</p>
<pre>
HTTP/1.1 400 Bad Request
Content-Language: en-US
Content-Type: application/json
{
"err": "invalid_key",
"description": "Key ID 12345 has been revoked."
}
</pre>
<p class="figure">Figure 3: Example Error Response (invalid_key)</p>
<div id="rfc.figure.4"></div>
<div id="errorResponseExpiredToken"></div>
<p>The following is a non-normative example error response indicating that the access token included in the request is expired.</p>
<pre>
HTTP/1.1 400 Bad Request
Content-Language: en-US
Content-Type: application/json
{
"err": "authentication_failed",
"description": "Access token has expired."
}
</pre>
<p class="figure">Figure 4: Example Error Response (authentication_failed)</p>
<div id="rfc.figure.5"></div>
<div id="errorResponseBadIssuer"></div>
<p>The following is a non-normative example error response indicating that the SET Receiver is not willing to accept SETs issued by the specified issuer from this particular SET Transmitter.</p>
<pre>
HTTP/1.1 400 Bad Request
Content-Language: en-US
Content-Type: application/json
{
"err": "invalid_issuer",
"description": "Not authorized for issuer https://iss.example.com/."
}
</pre>
<p class="figure">Figure 5: Example Error Response (access_denied)</p>
<h1 id="rfc.section.2.4">
<a href="#rfc.section.2.4">2.4.</a> <a href="#error_codes" id="error_codes">Security Event Token Delivery Error Codes</a>
</h1>
<p id="rfc.section.2.4.p.1">Security Event Token Delivery Error Codes are strings that identify a specific category of error that may occur when parsing or validating a SET. Every Security Event Token Delivery Error Code MUST have a unique name registered in the IANA "Security Event Token Delivery Error Codes" registry established by <a href="#iana_set_errors" class="xref">Section 7.1</a>.</p>
<p id="rfc.section.2.4.p.2">The following table presents the initial set of Error Codes that are registered in the IANA "Security Event Token Delivery Error Codes" registry:</p>
<div id="rfc.table.1"></div>
<div id="reqErrors"></div>
<table cellpadding="3" cellspacing="0" class="tt full center">
<caption>SET Delivery Error Codes</caption>
<thead><tr>
<th class="left">Error Code</th>
<th class="left">Description</th>
</tr></thead>
<tbody>
<tr>
<td class="left">invalid_request</td>
<td class="left">The request body cannot be parsed as a SET, or the Event Payload within the SET does not conform to the event's definition.</td>
</tr>
<tr>
<td class="left">invalid_key</td>
<td class="left">One or more keys used to encrypt or sign the SET is invalid or otherwise unacceptable to the SET Recipient (expired, revoked, failed certificate validation, etc.).</td>
</tr>
<tr>
<td class="left">invalid_issuer</td>
<td class="left">The SET issuer is invalid for the SET Recipient.</td>
</tr>
<tr>
<td class="left">invalid_audience</td>
<td class="left">The SET audience does not correspond to the SET Recipient.</td>
</tr>
<tr>
<td class="left">authentication_failed</td>
<td class="left">The SET Recipient could not authenticate the SET Transmitter.</td>
</tr>
<tr>
<td class="left">access_denied</td>
<td class="left">The SET Transmitter is not authorized to transmit the SET to the SET Recipient.</td>
</tr>
</tbody>
</table>
<p id="rfc.section.2.4.p.3">Other Error Codes may also be received, as the set of Error Codes is extensible via the IANA "Security Event Token Delivery Error Codes" registry established in <a href="#iana_set_errors" class="xref">Section 7.1</a>. </p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#aa" id="aa">Authentication and Authorization</a>
</h1>
<p id="rfc.section.3.p.1">The SET delivery method described in this specification is based upon HTTP over TLS <a href="#RFC2818" class="xref">[RFC2818]</a> and standard HTTP authentication and authorization schemes, as per <a href="#RFC7235" class="xref">[RFC7235]</a>. The TLS server certificate MUST be validated using DNS-ID <a href="#RFC6125" class="xref">[RFC6125]</a> and/or DANE <a href="#RFC6698" class="xref">[RFC6698]</a>. </p>
<p id="rfc.section.3.p.2">Authorization for the eligibility to provide actionable SETs can be determined by using the identity of the SET Issuer, the identity of the SET Transmitter, perhaps using mutual TLS, or via other employed authentication methods. Because SETs are not commands, SET Recipients are free to ignore SETs that are not of interest. </p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#reliability" id="reliability">Delivery Reliability</a>
</h1>
<p id="rfc.section.4.p.1">Delivery reliability requirements may vary depending upon the use cases. This specification defines the response from the SET Recipient in such a way as to provide the SET Transmitter with the information necessary to determine what further action is required, if any, in order to meet their requirements. SET Transmitters with high reliability requirements may be tempted to always retry failed transmissions. However, it should be noted that for many types of SET delivery errors, a retry is extremely unlikely to be successful. For example, <samp>invalid_request</samp> indicates a structural error in the content of the request body that is likely to remain when re-transmitting the same SET. Others such as <samp>access_denied</samp> may be transient, for example if the SET Transmitter refreshes expired credentials prior to re-transmission. </p>
<p id="rfc.section.4.p.2">The SET Transmitter may be unaware of whether or not a SET has been delivered to a SET Recipient. For example, a network interruption could prevent the SET Transmitter from receiving the success response, or a service outage could prevent the SET Transmitter from recording the fact that the SET was delivered. It is left to the implementer to decide how to handle such cases, based on their requirements. For example, it may be appropriate for the SET Transmitter to re-transmit the SET to the SET Recipient, erring on the side of guaranteeing delivery, or it may be appropriate to assume delivery was successful, erring on the side of not spending resources re-transmitting previously delivered SETs. Other options, such as sending the SET to a "dead letter queue" for manual examination may also be appropriate. </p>
<p id="rfc.section.4.p.3">Implementers SHOULD evaluate the reliability requirements of their use cases and the impact of various retry mechanisms and re-transmission policies on the performance of their systems to determine an appropriate strategy for handling various error conditions. </p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#Security" id="Security">Security Considerations</a>
</h1>
<h1 id="rfc.section.5.1">
<a href="#rfc.section.5.1">5.1.</a> <a href="#payloadAuthentication" id="payloadAuthentication">Authentication Using Signed SETs</a>
</h1>
<p id="rfc.section.5.1.p.1">JWS signed SETs can be used (see <a href="#RFC7515" class="xref">[RFC7515]</a> and Section 5 of <a href="#RFC8417" class="xref">[RFC8417]</a>) to enable the SET Recipient to validate that the SET Issuer is authorized to provide actionable SETs. </p>
<h1 id="rfc.section.5.2">
<a href="#rfc.section.5.2">5.2.</a> <a href="#HTTP" id="HTTP">HTTP Considerations</a>
</h1>
<p id="rfc.section.5.2.p.1">SET delivery depends on the use of Hypertext Transfer Protocol and is thus subject to the security considerations of HTTP Section 9 of <a href="#RFC7230" class="xref">[RFC7230]</a> and its related specifications.</p>
<h1 id="rfc.section.5.3">
<a href="#rfc.section.5.3">5.3.</a> <a href="#Confidentiality" id="Confidentiality">Confidentiality of SETs</a>
</h1>
<p id="rfc.section.5.3.p.1">SETs may contain sensitive information, including Personally Identifiable Information (PII), or be distributed through third parties. In such cases, SET Transmitters and SET Recipients MUST protect the confidentiality of the SET contents. TLS MUST be used to secure the transmitted SETs. In some use cases, encrypting the SET as described in <a href="#RFC7516" class="xref">JWE</a> will also be required. The Event delivery endpoint MUST support at least TLS version 1.2 <a href="#RFC5246" class="xref">[RFC5246]</a> and SHOULD support the newest version of TLS that meets its security requirements, which as of the time of this publication is TLS 1.3 <a href="#RFC8446" class="xref">[RFC8446]</a>. The client MUST perform a TLS/SSL server certificate check using DNS-ID <a href="#RFC6125" class="xref">[RFC6125]</a> and/or DANE <a href="#RFC6698" class="xref">[RFC6698]</a>. How a SET Transmitter determines the expected service identity to match the SET Recipient's server certificate against is out of scope for this document. The implementation security considerations for TLS in "Recommendations for Secure Use of TLS and DTLS" <a href="#RFC7525" class="xref">[RFC7525]</a> MUST be followed. </p>
<h1 id="rfc.section.5.4">
<a href="#rfc.section.5.4">5.4.</a> <a href="#DoS" id="DoS">Denial of Service</a>
</h1>
<p id="rfc.section.5.4.p.1">The SET Recipient may be vulnerable to a denial-of-service attack where a malicious party makes a high volume of requests containing invalid SETs, causing the endpoint to expend significant resources on cryptographic operations that are bound to fail. This may be mitigated by authenticating SET Transmitters with a mechanism such as mutual TLS. Rate-limiting problematic transmitters is also a possible means of mitigation. </p>
<h1 id="rfc.section.5.5">
<a href="#rfc.section.5.5">5.5.</a> <a href="#Persisted" id="Persisted">Authenticating Persisted SETs</a>
</h1>
<p id="rfc.section.5.5.p.1">At the time of receipt, the SET Recipient can rely upon TLS mechanisms, HTTP authentication methods, and/or other context from the transmission request to authenticate the SET Transmitter and validate the authenticity of the SET. However, this context is typically unavailable to systems to which the SET Recipient forwards the SET, or to systems that retrieve the SET from storage. If the SET Recipient requires the ability to validate SET authenticity outside of the context of the transmission request, then the SET Recipient SHOULD ensure that such SETs have been signed in accordance with <a href="#RFC7515" class="xref">[RFC7515]</a>. Needed context could also be stored with the SET and retrieved with it. </p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#Privacy" id="Privacy">Privacy Considerations</a>
</h1>
<p id="rfc.section.6.p.1">SET Transmitters should attempt to deliver SETs that are targeted to the specific business and protocol needs of subscribers. </p>
<p id="rfc.section.6.p.2">When sharing personally identifiable information or information that is otherwise considered confidential to affected users, SET Transmitters and Recipients MUST have the appropriate legal agreements and user consent or terms of service in place. Furthermore, data that needs confidentiality protection MUST be encrypted, at least with TLS and sometimes also using JSON Web Encryption (JWE) <a href="#RFC7516" class="xref">[RFC7516]</a>. </p>
<p id="rfc.section.6.p.3">In some cases, subject identifiers themselves may be considered sensitive information, such that their inclusion within a SET may be considered a violation of privacy. SET Issuers and SET Transmitters should consider the ramifications of sharing a particular subject identifier with a SET Recipient (e.g., whether doing so could enable correlation and/or de-anonymization of data) and choose appropriate subject identifiers for their use cases. </p>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#IANA" id="IANA">IANA Considerations</a>
</h1>
<h1 id="rfc.section.7.1">
<a href="#rfc.section.7.1">7.1.</a> <a href="#iana_set_errors" id="iana_set_errors">Security Event Token Delivery Error Codes</a>
</h1>
<p id="rfc.section.7.1.p.1">This document defines Security Event Token Delivery Error Codes, for which IANA is asked to create and maintain a new registry titled "Security Event Token Delivery Error Codes". Initial values for the Security Event Token Delivery Error Codes registry are defined in <a href="#reqErrors" class="xref">Table 1</a> and registered below. Future assignments are to be made through the Specification Required registration policy (<a href="#RFC8126" class="xref">[RFC8126]</a>) and shall follow the template below. </p>
<p id="rfc.section.7.1.p.2">Error Codes are intended to be interpreted by automated systems, and therefore SHOULD identify classes of errors to which an automated system could respond in a meaningfully distinct way (e.g., by refreshing authentication credentials and retrying the request). </p>
<p id="rfc.section.7.1.p.3">Error Code names are case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. </p>
<p id="rfc.section.7.1.p.4">Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration description is clear. </p>
<p id="rfc.section.7.1.p.5">It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts. </p>
<h1 id="rfc.section.7.1.1">
<a href="#rfc.section.7.1.1">7.1.1.</a> <a href="#iana_set_errors_template" id="iana_set_errors_template">Registration Template</a>
</h1>
<p></p>
<dl>
<dt>Error Code</dt>
<dd style="margin-left: 8">
<br> The name of the Security Event Token Delivery Error Code, as described in <a href="#error_codes" class="xref">Section 2.4</a>. The name MUST be a case-sensitive ASCII string consisting only of letters, digits, and underscore; these are the characters whose codes fall within the inclusive ranges 0x30-39, 0x41-5A, 0x5F and 0x61-7A. </dd>
<dt>Description</dt>
<dd style="margin-left: 8">
<br> A brief human-readable description of the Security Event Token Delivery Error Code. </dd>
<dt>Change Controller</dt>
<dd style="margin-left: 8">
<br> For error codes registered by the IETF or its working groups, list "IETF". For all other error codes, list the name of the party responsible for the registration. Contact information such as mailing address, email address, or phone number may also be provided. </dd>
<dt>Defining Document(s)</dt>
<dd style="margin-left: 8">
<br> A reference to the document or documents that define the Security Event Token Delivery Error Code. The definition MUST specify the name and description of the error code and explain under what circumstances the error code may be used. URIs that can be used to retrieve copies of each document at no cost SHOULD be included. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.7.1.2">
<a href="#rfc.section.7.1.2">7.1.2.</a> <a href="#InitialContents" id="InitialContents">Initial Registry Contents</a>
</h1>
<p></p>
<dl>
<dt></dt>
<dd style="margin-left: 8">Error Code: invalid_request</dd>
<dt></dt>
<dd style="margin-left: 8">Description: The request body cannot be parsed as a SET or the event payload within the SET does not conform to the event's definition.</dd>
<dt></dt>
<dd style="margin-left: 8">Change Controller: IETF</dd>
<dt></dt>
<dd style="margin-left: 8">Defining Document(s): <a href="#error_codes" class="xref">Section 2.4</a> of [[ this specification ]] </dd>
</dl>
<p> </p>
<p></p>
<dl>
<dt></dt>
<dd style="margin-left: 8">Error Code: invalid_key</dd>
<dt></dt>
<dd style="margin-left: 8">Description: One or more keys used to encrypt or sign the SET is invalid or otherwise unacceptable to the SET Recipient (expired, revoked, failed certificate validation, etc.).</dd>
<dt></dt>
<dd style="margin-left: 8">Change Controller: IETF</dd>
<dt></dt>
<dd style="margin-left: 8">Defining Document(s): <a href="#error_codes" class="xref">Section 2.4</a> of [[ this specification ]] </dd>
</dl>
<p> </p>
<p></p>
<dl>
<dt></dt>
<dd style="margin-left: 8">Error Code: invalid_issuer</dd>
<dt></dt>
<dd style="margin-left: 8">Description: The SET issuer is invalid for the SET Recipient.</dd>
<dt></dt>
<dd style="margin-left: 8">Change Controller: IETF</dd>
<dt></dt>
<dd style="margin-left: 8">Defining Document(s): <a href="#error_codes" class="xref">Section 2.4</a> of [[ this specification ]] </dd>
</dl>
<p> </p>
<p></p>
<dl>
<dt></dt>
<dd style="margin-left: 8">Error Code: invalid_audience</dd>
<dt></dt>
<dd style="margin-left: 8">Description: The SET audience does not correspond to the SET Recipient.</dd>
<dt></dt>
<dd style="margin-left: 8">Change Controller: IETF</dd>
<dt></dt>
<dd style="margin-left: 8">Defining Document(s): <a href="#error_codes" class="xref">Section 2.4</a> of [[ this specification ]] </dd>
</dl>
<p> </p>
<p></p>
<dl>
<dt></dt>
<dd style="margin-left: 8">Error Code: authentication_failed</dd>
<dt></dt>
<dd style="margin-left: 8">Description: The SET Recipient could not authenticate the SET Transmitter.</dd>
<dt></dt>
<dd style="margin-left: 8">Change Controller: IETF</dd>
<dt></dt>
<dd style="margin-left: 8">Defining Document(s): <a href="#error_codes" class="xref">Section 2.4</a> of [[ this specification ]] </dd>
</dl>
<p> </p>
<p></p>
<dl>
<dt></dt>
<dd style="margin-left: 8">Error Code: access_denied</dd>
<dt></dt>
<dd style="margin-left: 8">Description: The SET Transmitter is not authorized to transmit the SET to the SET Recipient.</dd>
<dt></dt>
<dd style="margin-left: 8">Change Controller: IETF</dd>
<dt></dt>
<dd style="margin-left: 8">Defining Document(s): <a href="#error_codes" class="xref">Section 2.4</a> of [[ this specification ]] </dd>
</dl>
<p> </p>
<h1 id="rfc.references">
<a href="#rfc.references">8.</a> References</h1>
<h1 id="rfc.references.1">
<a href="#rfc.references.1">8.1.</a> Normative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2277">[RFC2277]</b></td>
<td class="top">
<a>Alvestrand, H.</a>, "<a href="https://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>", BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2818">[RFC2818]</b></td>
<td class="top">
<a>Rescorla, E.</a>, "<a href="https://tools.ietf.org/html/rfc2818">HTTP Over TLS</a>", RFC 2818, DOI 10.17487/RFC2818, May 2000.</td>
</tr>
<tr>
<td class="reference"><b id="RFC5246">[RFC5246]</b></td>
<td class="top">
<a>Dierks, T.</a> and <a>E. Rescorla</a>, "<a href="https://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>", RFC 5246, DOI 10.17487/RFC5246, August 2008.</td>
</tr>
<tr>
<td class="reference"><b id="RFC6125">[RFC6125]</b></td>
<td class="top">
<a>Saint-Andre, P.</a> and <a>J. Hodges</a>, "<a href="https://tools.ietf.org/html/rfc6125">Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</a>", RFC 6125, DOI 10.17487/RFC6125, March 2011.</td>
</tr>
<tr>
<td class="reference"><b id="RFC6698">[RFC6698]</b></td>
<td class="top">
<a>Hoffman, P.</a> and <a>J. Schlyter</a>, "<a href="https://tools.ietf.org/html/rfc6698">The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</a>", RFC 6698, DOI 10.17487/RFC6698, August 2012.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7230">[RFC7230]</b></td>
<td class="top">
<a>Fielding, R.</a> and <a>J. Reschke</a>, "<a href="https://tools.ietf.org/html/rfc7230">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>", RFC 7230, DOI 10.17487/RFC7230, June 2014.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7231">[RFC7231]</b></td>
<td class="top">
<a>Fielding, R.</a> and <a>J. Reschke</a>, "<a href="https://tools.ietf.org/html/rfc7231">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>", RFC 7231, DOI 10.17487/RFC7231, June 2014.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7515">[RFC7515]</b></td>
<td class="top">
<a>Jones, M.</a>, <a>Bradley, J.</a> and <a>N. Sakimura</a>, "<a href="https://tools.ietf.org/html/rfc7515">JSON Web Signature (JWS)</a>", RFC 7515, DOI 10.17487/RFC7515, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7516">[RFC7516]</b></td>
<td class="top">
<a>Jones, M.</a> and <a>J. Hildebrand</a>, "<a href="https://tools.ietf.org/html/rfc7516">JSON Web Encryption (JWE)</a>", RFC 7516, DOI 10.17487/RFC7516, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7519">[RFC7519]</b></td>
<td class="top">
<a>Jones, M.</a>, <a>Bradley, J.</a> and <a>N. Sakimura</a>, "<a href="https://tools.ietf.org/html/rfc7519">JSON Web Token (JWT)</a>", RFC 7519, DOI 10.17487/RFC7519, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7525">[RFC7525]</b></td>
<td class="top">
<a>Sheffer, Y.</a>, <a>Holz, R.</a> and <a>P. Saint-Andre</a>, "<a href="https://tools.ietf.org/html/rfc7525">Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</a>", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8126">[RFC8126]</b></td>
<td class="top">
<a>Cotton, M.</a>, <a>Leiba, B.</a> and <a>T. Narten</a>, "<a href="https://tools.ietf.org/html/rfc8126">Guidelines for Writing an IANA Considerations Section in RFCs</a>", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8174">[RFC8174]</b></td>
<td class="top">
<a>Leiba, B.</a>, "<a href="https://tools.ietf.org/html/rfc8174">Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</a>", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8259">[RFC8259]</b></td>
<td class="top">
<a>Bray, T.</a>, "<a href="https://tools.ietf.org/html/rfc8259">The JavaScript Object Notation (JSON) Data Interchange Format</a>", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8417">[RFC8417]</b></td>
<td class="top">
<a>Hunt, P.</a>, <a>Jones, M.</a>, <a>Denniss, W.</a> and <a>M. Ansari</a>, "<a href="https://tools.ietf.org/html/rfc8417">Security Event Token (SET)</a>", RFC 8417, DOI 10.17487/RFC8417, July 2018.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8446">[RFC8446]</b></td>
<td class="top">
<a>Rescorla, E.</a>, "<a href="https://tools.ietf.org/html/rfc8446">The Transport Layer Security (TLS) Protocol Version 1.3</a>", RFC 8446, DOI 10.17487/RFC8446, August 2018.</td>
</tr>
</tbody></table>
<h1 id="rfc.references.2">
<a href="#rfc.references.2">8.2.</a> Informative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="I-D.ietf-secevent-http-poll">[I-D.ietf-secevent-http-poll]</b></td>
<td class="top">
<a>Backman, A.</a>, <a>Jones, M.</a>, <a>Scurtescu, M.</a>, <a>Ansari, M.</a> and <a>A. Nadalin</a>, "<a href="https://tools.ietf.org/html/draft-ietf-secevent-http-poll-12">Poll-Based Security Event Token (SET) Delivery Using HTTP</a>", Internet-Draft draft-ietf-secevent-http-poll-12, June 2020.</td>
</tr>