-
Notifications
You must be signed in to change notification settings - Fork 11
/
sp800-63c.html
3831 lines (2274 loc) · 352 KB
/
sp800-63c.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 charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="theme-color" media="(prefers-color-scheme: light)" content="white">
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="black">
<link rel="canonical" href="/800-63-4/sp800-63c.html">
<!-- Google Analytics -->
<!--<script type="text/javascript" id="_fed_an_js_tag" src="http://www.nist.gov/js/federated-analytics.all.min.js?agency=NIST&subagency=mml&pua=UA-66610693-1&yt=true&exts=ppsx,pps,f90,sch,rtf,wrl,txz,m1v,xlsm,msi,xsd,f,tif,eps,mpg,xml,pl,xlt,c"></script> -->
<!-- DAP Analytics -->
<script type="text/javascript" id="_fed_an_ua_tag"
src="https://dap.digitalgov.gov/Universal-Federated-Analytics-Min.js?agency=DOC&subagency=NIST&pua=UA-66610693-1&yt=true&exts=ppsx,pps,f90,sch,rtf,wrl,txz,m1v,xlsm,msi,xsd,f,tif,eps,mpg,xml,pl,xlt,c"></script>
<link rel="stylesheet" href="https://pages.nist.gov/nist-header-footer/css/nist-combined.css">
<script src="https://code.jquery.com/jquery-3.6.2.min.js" type="text/javascript"></script>
<script src="https://pages.nist.gov/nist-header-footer/js/nist-header-footer.js" type="text/javascript" defer="defer"></script>
<script src="https://unpkg.com/simple-jekyll-search/dest/simple-jekyll-search.min.js"></script>
<!-- Custom CSS -->
<link rel="stylesheet" href="/800-63-4/static/font-awesome/css/font-awesome.min.css">
<link rel="stylesheet" href="/800-63-4/static/css/NISTStyle.css">
<link rel="stylesheet" href="/800-63-4/static/css/NISTPages.css">
<!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
<script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
<![endif]-->
<title>NIST Special Publication 800-63C</title>
<meta property="og:title" content="NIST Special Publication 800-63C"/>
<meta name="description" content="NIST Special Publication 800-63C">
<meta property="og:description" content="NIST Special Publication 800-63C"/>
</head>
<body>
<nav class="navbar navbar-default navbar-fixed-left" role="navigation">
<ul class="nav navbar-nav">
<li id="search-box">
<input type="text" id="search-input" placeholder="Search..." onFocus="loadSearch()">
<ul id="results-container"></ul>
</li>
<li class="">
<a href="/800-63-4/">Home</a>
</li>
<li class="">
<a href="/800-63-4/sp800-63.html">SP 800-63</a>
</li>
<li class="">
<a href="/800-63-4/sp800-63a.html">SP 800-63A</a>
</li>
<li class="">
<a href="/800-63-4/sp800-63b.html">SP 800-63B</a>
</li>
<li class="active">
<a href="/800-63-4/sp800-63c.html">SP 800-63C</a>
<ul class="subnav">
<li class=""><a href="/800-63-4/sp800-63c.html#abstract">Abstract</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#reviewers">Reviewers</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#preface">Preface</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#introduction"><span class="section">1</span>Introduction</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#fal"><span class="section">2</span>FAL</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#common"><span class="section">3</span>Federation</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#GenIdP"><span class="section">4</span>General-Purpose IdP</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#wallet"><span class="section">5</span>Wallets</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#security"><span class="section">6</span>Security</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#privacy"><span class="section">7</span>Privacy</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#usability"><span class="section">8</span>Usability</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#equity"><span class="section">9</span>Equity</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#examples"><span class="section">10</span>Examples</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#references">References</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#abbr"><span class="section">A</span>Abbreviations</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#def-and-acr"><span class="section">B</span>Glossary</a></li>
<li class=""><a href="/800-63-4/sp800-63c.html#changelog"><span class="section">C</span>Changelog</a></li>
</ul>
</li>
</ul>
</nav>
<div class="page-switch">
View this document as: <b>a single page</b> | <a href="/800-63-4/sp800-63c/introduction/">multiple pages</a>.
</div>
<div class="container">
<div class="row">
<p>Wed, 28 Aug 2024 20:39:12 -0500</p>
<h1 id="abstract">
ABSTRACT <a href="#abstract" class="header-link"><i class="fa fa-link"></i></a>
</h1>
<p>This guideline focuses on the use of federated identity and the use of assertions to implement identity federations. Federation allows a given credential service provider to provide authentication attributes and (optionally) subscriber attributes to a number of separately-administered relying parties. Similarly, relying parties may use more than one credential service provider. The guidelines are not intended to constrain the development or use of standards outside of this purpose. This publication supersedes NIST Special Publication (SP) 800-63C.</p>
<h1 id="keywords">
Keywords <a href="#keywords" class="header-link"><i class="fa fa-link"></i></a>
</h1>
<p>assertions; authentication; credential service provider; digital authentication; electronic authentication; electronic credentials; federations.</p>
<h1 id="reviewers" class="no_toc">
Note to Reviewers <a href="#reviewers" class="header-link"><i class="fa fa-link"></i></a>
</h1>
<p>In December 2022, NIST released the Initial Public Draft (IPD) of SP 800-63, Revision 4. Over the course of a 119-day public comment period, the authors received exceptional feedback from a broad community of interested entities and individuals. The input from nearly 4,000 specific comments has helped advance the improvement of these Digital Identity Guidelines in a manner that supports NIST’s critical goals of providing foundational risk management processes and requirements that enable the implementation of secure, private, equitable, and accessible identity systems. Based on this initial wave of feedback, several substantive changes have been made across all of the volumes. These changes include but are not limited to the following:</p>
<ol>
<li>Updated text and context setting for risk management. Specifically, the authors have modified the process defined in the IPD to include a context-setting step of defining and understanding the online service that the organization is offering and intending to potentially protect with identity systems.</li>
<li>Added recommended continuous evaluation metrics. The continuous improvement section introduced by the IPD has been expanded to include a set of recommended metrics for holistically evaluating identity solution performance. These are recommended due to the complexities of data streams and variances in solution deployments.</li>
<li>Expanded fraud requirements and recommendations. Programmatic fraud management requirements for credential service providers and relying parties now address issues and challenges that may result from the implementation of fraud checks.</li>
<li>Restructured the identity proofing controls. There is a new taxonomy and structure for the requirements at each assurance level based on the means of providing the proofing: Remote Unattended, Remote Attended (e.g., video session), Onsite Unattended (e.g., kiosk), and Onsite Attended (e.g., in-person).</li>
<li>Integrated syncable authenticators. In April 2024, NIST published interim guidance for syncable authenticators. This guidance has been integrated into SP 800-63B as normative text and is provided for public feedback as part of the Revision 4 volume set.</li>
<li>Added user-controlled wallets to the federation model. Digital wallets and credentials (called “attribute bundles” in SP 800-63C) are seeing increased attention and adoption. At their core, they function like a federated IdP, generating signed assertions about a subject. Specific requirements for this presentation and the emerging context are presented in SP 800-63C-4.</li>
</ol>
<p>The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions.
Revision 4 of NIST Special Publication SP 800-63, <em>Digital Identity Guidelines</em>, intends to respond to the changing digital landscape that has emerged since the last major revision of this suite was published in 2017, including the real-world implications of online risks. The guidelines present the process and technical requirements for meeting digital identity management assurance levels for identity proofing, authentication, and federation, including requirements for security and privacy as well as considerations for fostering equity and the usability of digital identity solutions and technology.</p>
<p>Based on the feedback provided in response to the June 2020 Pre-Draft Call for Comments, research into real-world implementations of the guidelines, market innovation, and the current threat environment, this draft seeks to:</p>
<ul>
<li>Address comments received in response to the IPD of Revision 4 of SP 800-63</li>
<li>Clarify the text to address the questions and issues raised in the public comments</li>
<li>Update all four volumes of SP 800-63 based on current technology and market developments, the changing digital identity threat landscape, and organizational needs for digital identity solutions to address online security, privacy, usability, and equity</li>
</ul>
<p>NIST is specifically interested in comments and recommendations on the following topics:</p>
<ol>
<li>
<p>Federation and Assertions</p>
<ul>
<li>Is the concept of user-controlled wallets and attribute bundles sufficiently and clearly described to support real-world implementations? Are there additional requirements or considerations that should be added to improve the security, usability, and privacy of these technologies?</li>
</ul>
</li>
<li>
<p>General</p>
<ul>
<li>What specific implementation guidance, reference architectures, metrics, or other supporting resources could enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?</li>
<li>What applied research and measurement efforts would provide the greatest impacts on the identity market and advancement of these guidelines?</li>
</ul>
</li>
</ol>
<p>Reviewers are encouraged to comment and suggest changes to the text of all four draft volumes of the SP 800-63-4 suite. NIST requests that all comments be submitted by 11:59pm Eastern Time on October 7th, 2024. Please submit your comments to <a href="mailto:dig-comments@nist.gov">dig-comments@nist.gov</a>. NIST will review all comments and make them available on the <a href="https://www.nist.gov/identity-access-management">NIST Identity and Access Management website</a>. Commenters are encouraged to use the comment template provided on the NIST Computer Security Resource Center website for responses to these notes to reviewers and for specific comments on the text of the four-volume suite.</p>
<h1 id="preface">
Preface <a href="#preface" class="header-link"><i class="fa fa-link"></i></a>
</h1>
<p>This publication and its companion volumes, <a href="/800-63-4/sp800-63/introduction/#introduction" latex-href="#ref-SP800-63">[SP800-63]</a>, <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a>, and <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a>, provide technical guidelines to organizations for the implementation of digital identity services.</p>
<p>This document, SP 800-63C, provides requirements to identity providers (IdPs) and relying parties (RPs) of federated identity systems. Federation allows a given IdP to provide authentication attributes and (optionally) subscriber attributes to a number of separately-administered RPs through the use of federation protocols and assertions. Similarly, RPs can use more than one IdP as sources of identities.</p>
<h1 id="introduction" data-section="1">
Introduction <a href="#introduction" class="header-link"><i class="fa fa-link"></i></a>
</h1>
<p><em>This section is informative.</em></p>
<p>Federation is a process that enables the subscriber account defined in <a href="/800-63-4/sp800-63a/introduction/#introduction" latex-href="#ref-SP800-63A">[SP800-63A]</a> to be used with an RP that does not verify one of the authenticators bound to the subscriber account. Instead, a service known as an identity provider, or IdP, makes the subscriber account available through a federation protocol to the relying party, or RP. The IdP sends a verifiable statement, called an assertion, about the subscriber account to the RP, triggered by an authentication event of the subscriber. The RP verifies the assertion provided by the IdP and creates an authenticated session with the subscriber, granting the subscriber access to the RP’s functions.</p>
<p>The IdP works in one of two modes:</p>
<ul>
<li>As a verifier for authenticators bound to the subscriber account as described in <a href="/800-63-4/sp800-63b/introduction/#introduction" latex-href="#ref-SP800-63B">[SP800-63B]</a> (see details in <a href="/800-63-4/sp800-63c/GenIdP/#GenIdP">Sec. 4</a>), or</li>
<li>As a subscriber-controlled device onboarded by the CSP, often known as a digital wallet (see details in <a href="/800-63-4/sp800-63c/Wallets/#wallet">Sec. 5</a>).</li>
</ul>
<p>The federation process allows the subscriber to obtain services from multiple RPs without the need to hold or maintain separate authenticators at each RP, a process sometimes known as <em>single sign-on</em>. The federation process also is generally the preferred approach to authentication when the RP and the subscriber account are not administered together under a common security domain, since the RP does not need to verify an authenticator in the subscriber account. Even so, federation can be still applied within a single security domain for a variety of benefits including centralized account management and technical integration.</p>
<p>The federation process can be facilitated by additional parties acting in other roles, such as a federation authority to facilitate the trust agreements in place and federation proxies to facilitate the protocol connections.</p>
<h2 id="notations" data-section="1">
Notations <a href="#notations" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<p>This guideline uses the following typographical conventions in text:</p>
<ul>
<li>Specific terms in <strong>CAPITALS</strong> represent normative requirements. When these same terms are not in <strong>CAPITALS</strong>, the term does not represent a normative requirement.
<ul>
<li>The terms “<strong>SHALL</strong>” and “<strong>SHALL NOT</strong>” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.</li>
<li>The terms “<strong>SHOULD</strong>” and “<strong>SHOULD NOT</strong>” indicate that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.</li>
<li>The terms “<strong>MAY</strong>” and “<strong>NEED NOT</strong>” indicate a course of action permissible within the limits of the publication.</li>
<li>The terms “<strong>CAN</strong>” and “<strong>CANNOT</strong>” indicate a possibility and capability—whether material, physical, or causal—or, in the negative, the absence of that possibility or capability.</li>
</ul>
</li>
</ul>
<h2 id="document-structure" data-section="1">
Document Structure <a href="#document-structure" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<p>This document is organized as follows. Each section is labeled as either normative (i.e., mandatory for compliance) or informative (i.e., not mandatory).</p>
<ul>
<li>Section 1 provides an introduction to the document. This section is <em>informative</em>.</li>
<li>Section 2 describes requirements for Federation Assurance Levels. This section is <em>normative</em>.</li>
<li>Section 3 describes general requirements for federation systems. This section is <em>normative</em>.</li>
<li>Section 4 describes requirements for general-purpose IdPs. This section is <em>normative</em>.</li>
<li>Section 5 describes requirements for subscriber-controlled wallets. This section is <em>normative</em>.</li>
<li>Section 6 provides security considerations. This section is <em>informative</em>.</li>
<li>Section 7 provides privacy considerations. This section is <em>informative</em>.</li>
<li>Section 8 provides usability considerations. This section is <em>informative</em>.</li>
<li>Section 9 provides equity considerations. This section is <em>informative</em>.</li>
<li>Section 10 provides additional example scenarios. This section is <em>informative</em>.</li>
<li>References contains a list of publications referred to from this document. This section is <em>informative</em>.</li>
<li>Appendix A contains a selected list of abbreviations used in this document. This appendix is <em>informative</em>.</li>
<li>Appendix B contains a glossary of selected terms used in this document. This appendix is <em>informative</em>.</li>
<li>Appendix C contains a summarized list of changes in this document’s history. This appendix is <em>informative</em>.</li>
</ul>
<h1 id="fal" data-section="2">
Federation Assurance Level (FAL) <a href="#fal" class="header-link"><i class="fa fa-link"></i></a>
</h1>
<p><em>This section is normative.</em></p>
<p>This section defines <em>federation assurance levels</em> (FALs) and the requirements for securing federation transactions at each FAL. In order to fulfill the requirements for a a given FAL, the federation transaction <strong>SHALL</strong> meet or exceed all requirements listed for that FAL.</p>
<p>Each FAL is characterized by a set of requirements that increase the security and complexity as the FAL increases. These requirements are listed here and expanded in other sections of this document:</p>
<dl>
<dt>Audience Restriction</dt>
<dd>The assertion presented in the federation protocol is targeted to a specific RP and the RP can confirm that it is the intended audience of the assertion.</dd>
<dt>Injection Protection</dt>
<dd>The RP is strongly protected from an attacker presenting an assertion in circumstances outside a current federation transaction request. (See <a href="/800-63-4/sp800-63c/Federation/#injection-protection">Sec. 3.10.1</a> for details on injection protection.)</dd>
<dt>Trust Agreement Establishment</dt>
<dd>The agreement to participate in a federation transaction for the purposes of creating an authenticated session for the subscriber at the RP. (See <a href="/800-63-4/sp800-63c/Federation/#trust-agreement">Sec. 3.4</a> for details of the trust agreement.)</dd>
<dt>Identifier and Key Establishment</dt>
<dd>The IdP and RP have exchanged identifiers and key material to allow for the verification of assertions and other artifacts during future federation transactions. (See <a href="/800-63-4/sp800-63c/Federation/#identifiers-keys">Sec. 3.5</a> for details of key establishment.)</dd>
<dt>Presentation</dt>
<dd>The assertion can be presented to the RP either on its own (as a bearer assertion) or in concert with an authenticator presented by the subscriber.</dd>
</dl>
<p><a href="/800-63-4/sp800-63c/fal/#table-1">Table 1</a> provides a non-normative summary of aspects for each FAL. Each successive level subsumes and fulfills all requirements of lower levels (e.g., a federation process at FAL3 can be accepted at FAL2 or FAL1 since FAL3 satisfies all the requirements of these lower levels). Combinations not found in <a href="/800-63-4/sp800-63c/fal/#table-1">Table 1</a> are possible, and agencies can choose to implement stronger protections in one or more areas of requirements at a given FAL.</p>
<p latex-ignore="true"><a href="/800-63-4/sp800-63c/fal/#table-1" name="table-1">Table 1. Federation Assertion Levels</a></p>
<table latex-table="1" latex-caption="Federation Assurance Levels">
<thead>
<tr>
<th style="text-align: center">Requirement</th>
<th>FAL1</th>
<th>FAL2</th>
<th>FAL3</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center">Audience Restriction</td>
<td>Multiple RPs allowed per assertion, Single RP per assertion recommended</td>
<td>Single RP per assertion</td>
<td>Single RP per assertion</td>
</tr>
<tr>
<td style="text-align: center">Injection Protection</td>
<td>Recommended for all transactions</td>
<td>Required; transaction begins at the RP</td>
<td>Required; transaction begins at the RP</td>
</tr>
<tr>
<td style="text-align: center">Trust Agreement Establishment</td>
<td>Subscriber-driven or A priori</td>
<td>A priori</td>
<td>A priori</td>
</tr>
<tr>
<td style="text-align: center">Identifier and Key Establishment</td>
<td>Dynamic or Static</td>
<td>Dynamic or Static</td>
<td>Static</td>
</tr>
<tr>
<td style="text-align: center">Presentation</td>
<td>Bearer Assertion</td>
<td>Bearer Assertion</td>
<td>Holder-of-Key Assertion or Bound Authenticator</td>
</tr>
</tbody>
</table>
<p>While many different federation implementation options are possible, the FAL is intended to provide clear guidance representing increasingly secure deployment options. See <a href="/800-63-4/sp800-63/introduction/#introduction" latex-href="#ref-SP800-63">[SP800-63]</a> for details on how to choose the most appropriate FAL.</p>
<blockquote>
<p>Note: In these guidelines, assertions, attribute bundles, and other elements of the federation protocol are protected by asymmetric digital signatures or symmetric MACs. When either asymmetric or symmetric cryptography is specifically required, the terms “sign” and “signature” will be qualified as appropriate to indicate the requirement. When either option is possible, the terms “sign” and “signature” are used without a qualifier.</p>
</blockquote>
<h2 id="falcommon" data-section="2">
Common FAL Requirements <a href="#falcommon" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<p>At all FALs, all federation transactions <strong>SHALL</strong> comply with the requirements in <a href="/800-63-4/sp800-63c/Federation/#common">Sec. 3</a> to deliver an assertion to the RP and create an authenticated session at the RP. Examples of assertions used in federation protocols include the ID Token in OpenID Connect <a href="/800-63-4/sp800-63c/references/#ref-OIDC">[OIDC]</a> and the Security Assertion Markup Language <a href="/800-63-4/sp800-63c/references/#ref-SAML">[SAML]</a> Assertion format.</p>
<p>At all FALs, the RP needs to trust the IdP to provide valid assertions representing the subscriber’s authentication event and <strong>SHALL</strong> validate the assertion.</p>
<p>IdPs and RPs <strong>SHALL</strong> employ appropriately tailored security controls from the moderate baseline security controls defined in <a href="/800-63-4/sp800-63c/references/#ref-SP800-53">[SP800-53]</a> or an equivalent federal (e.g., <a href="/800-63-4/sp800-63c/references/#ref-FEDRAMP">[FEDRAMP]</a>) or industry standard that the organization has determined for the information systems, applications, and online services that these guidelines are used to protect. IdPs and RPs <strong>SHALL</strong> ensure that the minimum assurance-related controls for the appropriate systems, or equivalent, are satisfied. Additional security controls are discussed in <a href="/800-63-4/sp800-63c/Federation/#security-controls">Sec. 3.10</a>.</p>
<p>If no FAL is specified by the trust agreement or federation transaction, the requirements of this section still apply.</p>
<p>An IdP or RP can be capable of operating at multiple FALs simultaneously, depending on use case and needs. For example, an IdP could provide FAL3 federation transactions to a high-risk RP while providing FAL2 to an RP with a lower risk profile. Similarly, an RP could require FAL2 for normal actions but require the subscriber to re-authenticate with FAL3 for higher impact or more sensitive actions. This capability extends to other dimensions, as an IdP could simultaneously have access to subscriber accounts that have been proofed at any IAL and allow authentication at any AAL. However, an RP talking to that IdP could have restrictions on the lowest IAL and AAL it is willing to accept for access. As a consequence, it is imperative that the trust agreement establish the xALs allowed and required for different use cases.</p>
<h2 id="fal1" data-section="2">
Federation Assurance Level 1 (FAL1) <a href="#fal1" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<p>FAL1 provides a basic level of protection for federation transactions, allowing for a wide range of use cases and deployment decisions.</p>
<p>At FAL1, the IdP <strong>SHALL</strong> sign the assertion using approved cryptography. The RP <strong>SHALL</strong> validate the signature using the key associated with the expected IdP. The signature protects the integrity of the assertion contents and allows for the IdP to be verified as the source of the assertion.</p>
<p>All assertions at FAL1 <strong>SHALL</strong> be audience-restricted to a specific RP or set of RPs, and the RP <strong>SHALL</strong> validate that it is one of the targeted RPs for the given assertion.</p>
<p>At FAL1, the trust agreement <strong>MAY</strong> be established by the subscriber during the federation transaction. Note that at FAL1, it is still possible for the trust agreement to be established a priori by the RP and IdP.</p>
<p>At FAL1, the federation protocol <strong>SHOULD</strong> apply injection protection as discussed in <a href="/800-63-4/sp800-63c/Federation/#injection-protection">Sec. 3.10.1</a>. The federation transaction <strong>SHOULD</strong> be initiated by the RP.</p>
<h2 id="fal2" data-section="2">
Federation Assurance Level 2 (FAL2) <a href="#fal2" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<p>FAL2 provides a high level of protection for federation transactions, providing protections against a variety of attacks against federated systems. All the requirements for FAL1 apply at FAL2 except where overridden by more specific or stringent requirements here.</p>
<p>At FAL2, the assertion <strong>SHALL</strong> be strongly protected from injection attacks, as discussed in <a href="/800-63-4/sp800-63c/Federation/#injection-protection">Sec. 3.10.1</a>. The federation transaction <strong>SHALL</strong> be initiated by the RP.</p>
<p>At FAL2, the assertion <strong>SHALL</strong> audience restricted to a single RP.</p>
<p>At FAL2, an a priori trust agreement <strong>SHALL</strong> be established prior to the federation transaction taking place.</p>
<p>IdPs operated by or on behalf of federal agencies that present assertions at FAL2 or higher <strong>SHALL</strong> protect keys used for signing or encrypting those assertions with mechanisms validated at <a href="/800-63-4/sp800-63c/references/#ref-FIPS140">[FIPS140]</a> Level 1 or higher.</p>
<h2 id="fal3" data-section="2">
Federation Assurance Level 3 (FAL3) <a href="#fal3" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<p>FAL3 provides a very high level of protection for federation transactions, establishing very high confidence that the subscriber asserted by the IdP is the subscriber present in the authenticated session. All the requirements at FAL1 and FAL2 apply at FAL3 except where overridden by more specific or stringent requirements here.</p>
<p>At FAL3, the RP <strong>SHALL</strong> verify that the subscriber is in control of an authenticator in addition to the assertion. This authenticator is either identified in a holder-of-key assertion as described in <a href="/800-63-4/sp800-63c/Federation/#idp-managed-bound-authn">Sec 3.14</a> or is a bound authenticator as described in <a href="/800-63-4/sp800-63c/Federation/#bound-authn">Sec. 3.15</a>.</p>
<p>At FAL3, the trust agreement <strong>SHALL</strong> be established such that the IdP can identify and trust the RP to abide by all aspects of the trust agreement prior to any federation transaction taking place. To facilitate this, the key material used to authenticate the RP and IdP to each other is associated with the identifiers for the RP and IdP in a static fashion using a trusted mechanism. For example, a public key file representing the RP is uploaded to the IdP during a static registration process, and the RP downloads the IdP’s public key from a URL indicated in the trust agreement. Alternatively, the trust agreement can dictate that the RP and IdP can upload their respective public keys to a federation authority and then download each other’s keys from that same trusted authority.</p>
<p>IdPs operated by or on behalf of federal agencies that present assertions at FAL3 <strong>SHALL</strong> protect keys used for signing or encrypting those assertions with mechanisms validated at <a href="/800-63-4/sp800-63c/references/#ref-FIPS140">[FIPS140]</a> Level 1 or higher.</p>
<h2 id="request-xals" data-section="2">
Requesting and Processing xALs <a href="#request-xals" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<p>Since an IdP is capable of asserting the identities of many different subscribers with a variety of authenticators using a variety of federation parameters, the IAL, AAL, and FAL could vary across different federation transactions, even to the same RP.</p>
<p>IdPs <strong>SHALL</strong> support a mechanism for RPs to specify a set of minimum acceptable xALs as part of the trust agreement and <strong>SHOULD</strong> support the RP specifying a more strict minimum set at runtime as part of the federation transaction. When an RP requests a particular xAL, the IdP <strong>SHOULD</strong> fulfill that request, if possible, and <strong>SHALL</strong> indicate the resulting xAL in the assertion. For example, if the subscriber has an active session that was authenticated at AAL1, but the RP has requested AAL2, the IdP needs to prompt the subscriber for AAL2 authentication to step up the security of the session at the IdP during the subscriber’s interaction at the IdP, if possible. The IdP sends the resulting AAL as part of the returned assertion, whether it is AAL1 (the step-up authentication was not met) or AAL2 (the step-up authentication was met successfully).</p>
<p>The IdP <strong>SHALL</strong> inform the RP of the following information for each federation transaction:</p>
<ul>
<li>The IAL of the subscriber account being presented to the RP, or an indication that no IAL claim is being made</li>
<li>The AAL of the currently active session of the subscriber at the IdP, or an indication that no AAL claim is being made</li>
<li>The FAL of the federation transaction</li>
</ul>
<p>The RP gets this xAL information from a combination of the terms of the trust agreement as described in <a href="/800-63-4/sp800-63c/Federation/#trust-agreement">Sec. 3.4</a> and information included in the assertion as described in <a href="/800-63-4/sp800-63c/GenIdP/#assertions">Sec. 4.9</a> and <a href="/800-63-4/sp800-63c/Wallets/#assertion-contents">Sec. 5.8</a>. If the xAL is unchanging for all messages between the IdP and RP, the xAL information <strong>SHALL</strong> be included in the terms of the trust agreement between the IdP and RP. If the xAL could be within a range of possible values specified by the trust agreement, the xAL information <strong>SHALL</strong> be included as part of the assertion contents.</p>
<p>The IdP <strong>MAY</strong> indicate that no claim is made to the IAL or AAL for a given federation transaction. In such cases, no default value is assigned to the resulting xAL by the RP. That is to say, a federation transaction without an IAL declaration in either the trust agreement or the assertion is functionally considered to have “no IAL” and the RP cannot assume the account meets “IAL1”, the lowest numbered IAL described in this suite.</p>
<p>The RP <strong>SHALL</strong> determine the minimum IAL, AAL, and FAL it is willing to accept for access to any offered functionality. An RP <strong>MAY</strong> vary its functionality based on the IAL, AAL, and FAL of a specific federated authentication. For example, an RP can allow federation transactions at AAL2 for common functionality (e.g., viewing the status of a dam system) but require AAL3 be used for higher risk functionality (e.g., changing the flow rates of a dam system). Similarly, an RP could restrict management functionality to only certain subscriber accounts which have been identity proofed at IAL2, while allowing federation transactions from all subscriber accounts regardless of IAL.</p>
<p>In a federation process, only the IdP has direct access to the details of the subscriber account, which determines the applicable IAL, and the authentication event at the IdP, which determines the applicable AAL. Consequently, the IdP declares the IAL, AAL, and intended FAL for each federation transaction.</p>
<p>The RP <strong>SHALL</strong> ensure that it meets its obligations in the federation transaction for the FAL declared in the assertion. For example, the RP needs to ensure the presentation method meets the injection protection requirements at FAL2 and above, and that the appropriate bound authenticator is presented at FAL3.</p>
<h1 id="common" data-section="3">
Common Federation Requirements <a href="#common" class="header-link"><i class="fa fa-link"></i></a>
</h1>
<p><em>This section is normative.</em></p>
<p>A federation transaction serves to allow the subscriber to establish an authenticated session with the RP based on a subscriber account known to the IdP. The federation transaction can also provide the RP with a set of identity attributes within the authenticated session. The authenticated session can then be used by the RP for:</p>
<ul>
<li>logging in the subscriber to access functionality at the RP,</li>
<li>identifying the subscriber based on presented attributes, and</li>
<li>processing the subscriber attributes presented in the federation transaction.</li>
</ul>
<p>A federation transaction requires relatively complex multiparty protocols that have subtle security and privacy requirements. When evaluating a particular federation protocol, profile, or deployment structure, it is often instructive to break it down into its component relationships and evaluate the needs for each of these:</p>
<ul>
<li>the subscriber to the CSP,</li>
<li>the CSP to the IdP,</li>
<li>the subscriber to the IdP,</li>
<li>the IdP to the RP, and</li>
<li>the subscriber to the RP.</li>
</ul>
<p>In addition, the subscriber often interacts with the CSP, IdP, and RP through a user agent like a web browser. The user agent is therefore often involved in the federation process, but it is not necessary for all types of applications and interactions. As such, the actions of the subscriber described throughout these guidelines can optionally be performed through a user agent. Where necessary, requirements on the user agent are called out directly.</p>
<p>Each party in a federation protocol bears specific responsibilities and expectations that must be fulfilled in order for the federated system to function as intended.</p>
<p>The subscriber account is augmented by the IdP with federation-specific items, including but not limited to the following:</p>
<ul>
<li>One or more external subject identifiers, for use with a federation protocol</li>
<li>A set of access rights, detailing which RPs can access which attributes of the subscriber account (such as allowlists and saved runtime decisions by the subscriber)</li>
<li>Federated account usage information</li>
<li>Additional attributes collected by or assigned by the IdP to the account</li>
</ul>
<p>A subset of these attributes is made available to the RP through the federation process, either in the assertion or through an identity API (see <a href="/800-63-4/sp800-63c/Federation/#s-identity-api">Sec 3.11.3</a>). These attributes are often used in determining access privileges for attribute-based access control (ABAC) or facilitating a transaction (e.g., providing a shipping address). The details of authorization and access control are outside the scope of these guidelines.</p>
<p>To keep and manage these attributes, the RP often maintains an <em>RP subscriber account</em> for the subscriber. The RP subscriber account also contains information local to the RP itself, as described in <a href="/800-63-4/sp800-63c/Federation/#rp-account">Sec. 3.7</a>.</p>
<p>Federation transactions take place across three dimensions:</p>
<dl>
<dt>Trust Agreements:</dt>
<dd>The establishment of a policy decision that allows the CSP, IdP, and RP to connect for the purposes of federation. This policy is governed by a trust agreement, which establishes the permission to connect.</dd>
<dt>Associating Keys and Identifiers:</dt>
<dd>The association of keys and identifiers for the CSP, IdP, and RP that take part in the federation transaction. This process enables the parties to identify each other securely for future exchanges.</dd>
<dt>Federation Protocol:</dt>
<dd>The verification of the subscriber’s identity by the IdP and subsequent issuance of an assertion to the RP. This results in the passing of subscriber attributes to the RP and establishing an authenticated session for the subscriber at the RP.</dd>
</dl>
<p>These dimensions all need to be fulfilled for a federation process to be complete. The exact order in which that happens, and which parties are involved in which steps, can vary depending on deployment models and other factors.</p>
<p>The requirements for IdPs in this section apply to both general-purpose IdPs as discussed in <a href="/800-63-4/sp800-63c/GenIdP/#GenIdP">Sec. 4</a> and subscriber-controlled wallets as discussed in <a href="/800-63-4/sp800-63c/Wallets/#wallet">Sec. 5</a>.</p>
<h2 id="roles" data-section="3">
Roles <a href="#roles" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<h3 id="credential-service-provider-csp" data-section="3">
Credential Service Provider (CSP) <a href="#credential-service-provider-csp" class="header-link"><i class="fa fa-link"></i></a>
</h3>
<p>The CSP collects and verifies attributes from the subscriber and stores them in a subscriber account. The CSP also binds one or more authenticators to the subscriber account, allowing the subscriber to authenticate directly to systems capable of verifying an authenticator.</p>
<h3 id="identity-provider-idp" data-section="3">
Identity Provider (IdP) <a href="#identity-provider-idp" class="header-link"><i class="fa fa-link"></i></a>
</h3>
<p>The IdP provides a bridge between the subscriber account (as established by the CSP) and the RP that the subscriber is accessing. An IdP can be deployed as a service for multiple subscriber accounts or as a component controlled by a single subscriber.</p>
<p>The IdP establishes an authentication event with the subscriber, either through the verification of an authenticator (for general-purpose IdPs) or presentation of an activation factor (for subscriber-controlled wallets). The IdP creates assertions to represent the authentication event.</p>
<p>The IdP makes identity attributes of the subscriber available within the assertion or through an identity API (see <a href="/800-63-4/sp800-63c/Federation/#s-identity-api">Sec. 3.11.3</a>).</p>
<p><em>In some systems, this is also known as the offering party (OP).</em></p>
<h3 id="relying-party-rp" data-section="3">
Relying Party (RP) <a href="#relying-party-rp" class="header-link"><i class="fa fa-link"></i></a>
</h3>
<p>The RP processes assertions from the IdP and provides the service that the subscriber is trying to access. Unlike in a direct authentication model, the RP does not provide the verifier function to authenticators tied to the subscriber account.</p>
<p><em>In some systems, this is also known as the service provider (SP).</em></p>
<h2 id="functions" data-section="3">
Functions <a href="#functions" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<h3 id="trust-agreement-management" data-section="3">
Trust Agreement Management <a href="#trust-agreement-management" class="header-link"><i class="fa fa-link"></i></a>
</h3>
<p>The trust agreement (see <a href="/800-63-4/sp800-63c/Federation/#trust-agreement">Sec. 3.4</a>) can be managed through a dedicated party, known as a <em>federation authority</em>. The federation authority facilitates the onboarding and management of parties fulfilling different roles and functions within a trust agreement. This management provides a transitive trust to other parties in the agreement.</p>
<p>For example, an RP can enter a trust agreement with a federation authority and decide that any IdP approved by that federation authority is suitable for its purposes. This trust can hold true whether or not the IdP was covered by the trust agreement at the time the RP joined. Federation authorities are used in multilateral trust agreements as discussed in <a href="/800-63-4/sp800-63c/Federation/#authorities">Sec. 3.4.2</a>.</p>
<h3 id="authorized-party" data-section="3">
Authorized Party <a href="#authorized-party" class="header-link"><i class="fa fa-link"></i></a>
</h3>
<p>The <em>authorized party</em> in a trust agreement is the organization, person, or entity that is responsible for the specific release decisions covered by the trust agreement, including the release of subscriber attributes. The trust agreement stipulates who the expected authorized party is, as well as the parameters under which a request could be automatically granted, automatically denied, or require a runtime decision from an individual. For public-facing scenarios, the authorized party is expected to be the subscriber. For enterprise scenarios, the authorized party is expected to be the agency.</p>
<p>If the authorized party is the operator of the IdP, consent to release attributes is decided for all subscribers and established by an allowlist as described in <a href="/800-63-4/sp800-63c/GenIdP/#idp-allowlist">Sec. 4.6.1.1</a>, allowing for the disclosure of identity attribute without direct decisions and involvement by the subscriber. A trust agreement can alternatively stipulate that an individual, such as the subscriber, is to be prompted at runtime for consent to disclose certain attributes to the RP as discussed in <a href="/800-63-4/sp800-63c/GenIdP/#idp-runtime-decision">Sec. 4.6.1.3</a>. If specified by the trust agreement, it is also possible for an individual other than a subscriber to act as the authorized party. For example, an administrator of a system being prompted to release attribute information on behalf of a subscriber as part of a provisioning API.</p>
<p>Examples of different authorized parties are found in <a href="/800-63-4/sp800-63c/examples/#authorized-party-example">Sec 10.10</a>.</p>
<h3 id="proxied" data-section="3">
Proxied Federation <a href="#proxied" class="header-link"><i class="fa fa-link"></i></a>
</h3>
<p>A federation <em>proxy</em> acts as an intermediary between the IdP and RP for all communication in the federation protocol. The proxy functions as an RP on the upstream side and an IdP on the downstream side, as shown in <a href="/800-63-4/sp800-63c/Federation/#fig-1">Fig. 1</a>. When communicating through a proxy, the upstream IdP and downstream RP communicate with the proxy using a standard federation protocol, and the subscriber takes part in two separate federation transactions. As a consequence, all normative requirements that apply to IdPs and RPs <strong>SHALL</strong> apply to proxies in their respective roles on each side. Additionally, it is possible for a proxy to act as an upstream IdP to another proxy downstream, and so on in a chain.</p>
<p latex-ignore="true"><a href="/800-63-4/sp800-63c/Federation/#fig-3" name="fig-1">Fig. 1. Federation Proxy</a></p>
<p><img src="/800-63-4/sp800-63c/images/proxy.png" alt="Diagram of a federation proxy accepting assertions from an upstream IdP and providing assertions to a downstream RP." title="Federation Proxy" latex-src="proxy.pdf" latex-fig="1" latex-place="h" /></p>
<p>The role of the proxy is limited to the federation protocol; it is not involved in establishment or facilitation of a trust agreement between the upstream IdP and downstream RP. The same party can operate a federation authority as well as a proxy to facilitate federation transactions, but this function is separate from their role in managing the trust agreement. Just like other members of a federation system, the proxy can be involved in separate trust agreements with each of the upstream and downstream components, or a single trust agreement can apply to all parties such as in a multilateral agreement.</p>
<p>The federated identifier (see <a href="/800-63-4/sp800-63c/Federation/#federated-identifier">Sec. 3.3</a>) of an assertion from a proxy <strong>SHALL</strong> indicate the proxy as the issuer of the assertion. The downstream RP receives and validates the assertion generated by the proxy, as it would an assertion from any other IdP. This assertion is based on the assertion the proxy receives from the upstream IdP. The contents of the assertion from the upstream IdP can be handled in several ways, depending on the method of proxying in use:</p>
<ul>
<li>The proxy can create an all-new assertion with no information from the assertion from the upstream IdP carried in it. This pattern is useful for blinding the downstream RP, so that the RP does not know which upstream IdP the subscriber originally came from.</li>
<li>The proxy can copy attributes from the assertion from the upstream IdP into the assertion from the proxy. This pattern is useful for carrying identity attributes in the assertion to the downstream RP.</li>
<li>The proxy can include the entire assertion from the upstream IdP in the assertion from the proxy. This pattern allows the RP to independently validate the assertion from the upstream IdP as well as the assertion from the proxy.</li>
</ul>
<p>A proxied federation model can provide several benefits. Federation proxies can simplify technical integration between the RP and IdP by providing a common interface for integration. Additionally, to the extent a proxy effectively blinds the RP and IdP from each other, it can provide some business confidentiality for organizations that want to guard their subscriber lists from each other. Proxies can also mitigate some of the privacy risks described in <a href="/800-63-4/sp800-63c/Federation/#privacy-reqs">Sec. 3.9</a>, though other risks arise from their use since an additional party is now involved in handling subscriber information. For example, if an attacker is able to compromise the proxy, the attacker need not target the IdP or RP directly in order to gain access to subscriber attributes or activity since all of that information flows through the proxy. Additionally, the proxy can perform additional profiling of the subscriber beyond what the IdP and RP can do, since the proxy brokers the federation transactions between the parties and binds the subscriber account to either side of the connection.</p>
<p>See <a href="/800-63-4/sp800-63c/privacy/#blinding">Sec. 7.5</a> for further information on blinding techniques, their uses, and limitations.</p>
<p>The FAL of the connection between the proxy and the downstream RP is considered as the lowest FAL along the entire path, and the proxy <strong>SHALL</strong> accurately represent this to the downstream RP. For example, if the connection between the upstream IdP and the proxy is FAL1 and the connection between the proxy and the downstream RP otherwise meets the requirements of FAL2, the connection between the proxy and the downstream RP is still considered FAL1. Likewise, if the connection between the upstream IdP and the proxy is FAL2 and the connection between the proxy and the downstream RP is only FAL1, the overall connection through the proxy is considered FAL1.</p>
<h3 id="fulfilling-roles-and-functions-of-a-federation-model" data-section="3">
Fulfilling Roles and Functions of a Federation Model <a href="#fulfilling-roles-and-functions-of-a-federation-model" class="header-link"><i class="fa fa-link"></i></a>
</h3>
<p>The roles in a federation transaction can be connected in a variety of ways, but several common patterns are anticipated by these guidelines. The expected trust agreement structure and connection between components will vary based on which pattern is in use.</p>
<p>Different roles and functions can be fulfilled by separate parties who integrate with each other. For example, a CSP can provide attributes of the subscriber account to an IdP that is not operated by the same party or agency as the CSP.</p>
<p>It is also possible for a single party to fulfil multiple roles within a given federation agreement. For example, if the CSP provides the IdP as part of its identity services, the CSP can provision the subscriber accounts at the IdP as part of the subscriber account establishment process. Similarly, the RP can also be in the same security and administrative domain as the IdP, but still use federation technology to connect for technical, deployment, and account management benefits.</p>
<p>The same is true for other functions in the overall federation system, such as a federation authority and proxy. While the roles may seem similar, they are fundamentally distinct and do not need to be connected: a federation authority facilitates establishment of a trust agreement between parties, and a proxy facilitates connection of the federation protocol by acting as an RP to the upstream IdP and as an IdP to the downstream RP. The same entity can fulfill both the federation authority and proxy functions in the system, providing both a means of establishing trust agreements and a means of establishing technical connections between IdPs and RPs.</p>
<h2 id="federated-identifier" data-section="3">
Federated Identifiers <a href="#federated-identifier" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<p>The subscriber <strong>SHALL</strong> be identified in the federation transaction using a federated identifier unique to that subscriber. A federated identifier is the logical combination of a subject identifier, representing a subscriber account, and an issuer identifier, representing the IdP. The subject identifier is assigned by the IdP, and the issuer identifier is assigned to the IdP usually through configuration.</p>
<p>The multi-part federated identifier pattern is required because different IdPs manage their subject identifiers independently, and could therefore potentially collide in their choices of subject identifiers for different subjects. Therefore, it is imperative that an RP never process the subject identifier without taking into account which IdP issued that subject identifier. For most use cases, the federated identifier is stable for the subscriber across multiple sessions and is independent of the authenticator used, allowing the RP to reliably identify the subscriber across multiple authenticated sessions and account changes. However, it is also possible for the federated identifier and its associated use at the RP to be ephemeral, providing some privacy enhancement. Federated identifiers, and their constituent parts, are intended to be machine-readable and not managed by or exposed to the subscriber, unlike a username or other human-facing identifier.</p>
<p>Federated identifiers <strong>SHALL</strong> contain no plaintext personally-identifiable information (PII), such as usernames, email addresses, or employee numbers, etc.</p>
<h3 id="ppi" data-section="3">
Pairwise Pseudonymous Identifiers (PPI) <a href="#ppi" class="header-link"><i class="fa fa-link"></i></a>
</h3>
<p>In some circumstances, it is desirable to prevent the subscriber account from being easily linked at multiple RPs through use of a common subject identifier. The use of a pairwise pseudonymous identifier (PPI) allows an IdP to provide multiple distinct federated identifiers to different RPs for a single subscriber account. Use of a PPI prevents different RPs from colluding together to track the subscriber using the federated identifier.</p>
<h4 id="general-requirements" data-section="3">
General Requirements <a href="#general-requirements" class="header-link"><i class="fa fa-link"></i></a>
</h4>
<p>When using pairwise pseudonymous identifiers within the assertions generated by the IdP for the RP, the IdP <strong>SHALL</strong> generate a different federated identifier for each RP as described in <a href="/800-63-4/sp800-63c/Federation/#ppi-gen">Sec. 3.3.1.2</a> or set of RPs as described in <a href="/800-63-4/sp800-63c/Federation/#ppi-shared">Sec. 3.3.1.3</a>.</p>
<p>Some identity attributes such as names, physical address, phone numbers, email addresses, and others can be used to identify a subscriber outside of a federation transaction. When PPIs are used alongside these kinds of identifying attributes, it may still be possible for multiple colluding RPs to re-identify a subscriber by correlation across systems. For example, if two independent RPs each see the same subscriber identified with a different PPI, the RPs could still determine that the subscriber is the same person by comparing the name, email address, physical address, or other identifying attributes carried alongside the PPI in the respective assertions. Where PPIs are used alongside identifying attributes, privacy policies <strong>SHALL</strong> be established to prevent correlation of subscriber data consistent with applicable legal and regulatory requirements.</p>
<p>Note that in a proxied federation model (see <a href="/800-63-4/sp800-63c/Federation/#proxied">Sec. 3.2.3</a>), the upstream IdP may be unable to generate a PPI for the downstream RP, since the proxy could blind the IdP from knowing which RP is being accessed by the subscriber. In such situations, the PPI is generally established between the IdP and the federation proxy. The proxy, acting as an IdP, can provide a PPI to the downstream RP. Depending on the protocol, the federation proxy may need to map the PPI back to the associated identifiers from upstream IdPs in order to allow the identity protocol to function. In such cases, the proxy will be able to track and determine which PPIs represent the same subscriber at different RPs. The proxy <strong>SHALL NOT</strong> disclose the mapping between the PPI and any other identifiers to a third party or use the information for any purpose other than those allowed for transmission of subscriber information defined in <a href="/800-63-4/sp800-63c/Federation/#transmit-subscriber-info">Sec. 3.9.1</a>.</p>
<h4 id="ppi-gen" data-section="3">
Pairwise Pseudonymous Identifier Generation <a href="#ppi-gen" class="header-link"><i class="fa fa-link"></i></a>
</h4>
<p>The PPI <strong>SHALL</strong> contain no identifying information about the subscriber (e.g., username, email address, employee number, etc.). The PPI <strong>SHALL</strong> be difficult to guess by a party having access to information about the subscriber, having at least 112 bits of entropy as stated in <a href="/800-63-4/sp800-63c/references/#ref-SP800-131A">[SP800-131A]</a>. PPIs can be generated randomly and assigned to subscribers by the IdP or could be derived from other subscriber information if the derivation is done in an irreversible, unguessable manner (e.g., using a keyed hash function with a secret key as discussed in <a href="/800-63-4/sp800-63c/references/#ref-SP800-131A">[SP800-131A]</a>).</p>
<p>Unless the PPI is designated as shared by the trust agreement, the PPI <strong>SHALL</strong> be disclosed to only a single RP.</p>
<h4 id="ppi-shared" data-section="3">
Shared Pairwise Pseudonymous Identifiers <a href="#ppi-shared" class="header-link"><i class="fa fa-link"></i></a>
</h4>
<p>The same shared PPI <strong>SHALL</strong> be used for a specific set of RPs if all the following criteria are met:</p>
<ul>
<li>The trust agreement stipulates a shared PPI for a specific set of RPs;</li>
<li>The authorized party consents to and is notified of the use of a shared PPI;</li>
<li>Those RPs have a demonstrable relationship that justifies an operational need for the correlation, such as a shared security domain or shared legal ownership; and</li>
<li>All RPs in the set of a shared PPI consent to being correlated in such a manner (i.e., one RP cannot request to have another RP’s PPI without that other RP’s knowledge and consent).</li>
</ul>
<p>The RPs <strong>SHALL</strong> conduct a privacy risk assessment to consider the privacy risks associated with requesting a shared PPI. See <a href="/800-63-4/sp800-63c/privacy/#notice">Sec. 7.2</a> for further privacy considerations.</p>
<p>The IdP <strong>SHALL</strong> ensure that only intended RPs are included in the set; otherwise, a rogue RP could learn of the shared PPI for a set of RPs by fraudulently posing as part of that set.</p>
<p>The sector identifier feature of <a href="/800-63-4/sp800-63c/references/#ref-OIDC">[OIDC]</a> provides a mechanism to calculate a shared PPI for a group of RPs. In this protocol, the identifiers of the RPs are all listed at a URL that can be fetched by the IdP over an authorized protected channel. The shared PPI is calculated by taking into account the sector identifier URL along with other inputs to the algorithm, such that all RPs listed in the sector identifier URL’s contents receive the same shared PPI.</p>
<h2 id="trust-agreement" data-section="3">
Trust Agreements <a href="#trust-agreement" class="header-link"><i class="fa fa-link"></i></a>
</h2>
<p>All federation transactions <strong>SHALL</strong> be defined by one or more trust agreements between the applicable parties.</p>
<p>The trust agreement <strong>SHALL</strong> establish a trust relationship between the RP and:</p>
<ul>
<li>The CSP responsible for provisioning and managing the subscriber account,</li>
<li>The IdP responsible for providing assertions and attributes, or</li>
<li>Both the CSP and IdP.</li>
</ul>
<p>Trust agreements establish the terms for federation transactions between the parties they affect, including things like the allowed xALs and the intended purposes of identity attributes exchanged in the federation transaction. The trust agreement <strong>SHALL</strong> establish usability and equity requirements for the federation transaction. The trust agreement <strong>SHALL</strong> disclose details of the proofing process used at the CSP, including any compensating controls and exception handling processes.</p>
<p>All trust agreements <strong>SHALL</strong> define a specific population of subscriber accounts that the agreement is applicable to. The exact means of defining this population are out of scope of this document. In many cases, the population is defined as the full set of subscriber accounts that the CSP manages and makes available through an IdP. In other cases, the population is a demarcated subset of accounts available through an IdP. It is also possible for an RP to have a distinct trust agreement established with an IdP for a single subscriber account, such as in a subscriber-driven trust agreement.</p>
<p>During the course of a single federation transaction, it is important for the policies and expectations of all parties be unambiguous for all parties involved. Therefore, there <strong>SHOULD</strong> be only one set of trust agreements in effect for a given transaction. This will usually be determined by the unique combination of CSP, IdP, and RP participating in the transaction. However, these agreements could vary in other ways, such as different populations of subscribers being governed by different trust agreements.</p>
<p>The existence of a trust agreement between parties does not preclude the existence of other agreements for each party in the agreement to have with other parties. For example, an IdP can have independent agreements with multiple RPs simultaneously, and an RP can likewise have independent agreements with multiple IdPs simultaneously. The IdP and RP need not disclose the existence or terms of trust agreements to parties outside of or not covered by the agreement in question.</p>
<p>Trust agreements <strong>SHALL</strong> establish terms regarding expected and acceptable IALs and AALs in connection with the federated relationship.</p>
<p>Trust agreements <strong>SHALL</strong> define necessary mechanisms and materials to coordinate redress and issues between the different participants in the federation, as discussed in <a href="/800-63-4/sp800-63c/Federation/#redress">Sec. 3.4.3</a>.</p>
<p>Establishment of a trust agreement is required for all federation transactions, even those in which the roles and applications exist within a single security domain or shared legal ownership. In such cases, the establishment of the trust agreement can be an internal process and does not need to involve a formal agreement. Even in such cases, it is still required for the IdP to document and disclose the trust agreement to the subscriber upon request.</p>
<p>Even though subscribers are not generally a party directly involved in the trust agreement’s terms, subscribers are affected by the terms of the trust agreement and the resulting federation transactions. As such, the terms of the trust agreement need to be made available to subscribers in clear and understandable language. The means by which the subscriber can access these terms, and the party responsible for informing the subscriber, varies based on the means of establishment of the trust agreement and the terms of the trust agreement itself. Additionally, the subscriber’s user agent is not usually party to the trust agreement, unless it is acting in one of the roles of the federation transaction.</p>
<h3 id="bilateral" data-section="3">
Bilateral Trust Agreements <a href="#bilateral" class="header-link"><i class="fa fa-link"></i></a>
</h3>