NIST PIV and digital identity SP 800-217 (Draft)
All1 Introduction 2112 Architecture 4053 Trust Agreements 5744 Federation Assurance Level (FAL) 7885 Requirements of IdPs and RPs 8766 Protocol Requirements 996Appendix A Examples 1221Appendix B Glossary of Terms 1373Appendix C Abbreviations 1401
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Introduction 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 This section is informative. PIV Cards and derived PIV credentials allow for a very hi | |
| 1.1 in 1 |
Background | This document is a companion document to [FIPS201] , providing specific details for implementing PIV federation for PIV identity accounts. [FIPS201] defines standards for the use of PIV credentials, including the establishment of the PIV id | |
| 1.2 in 1 |
Purpose and Scope | This document focuses on the use of federation technologies with PIV identity accounts for federal employees and contractors. This document does not discuss citizen-facing use cases covered in [SP800-63C] . This document does not address cr | |
| 1.2.1 in 1.2 |
Creating Technical Interoperability Profiles of This Guideline 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 The guidelines in this document alone are not intended to provide full technical interoper | |
| 1.3 in 1 |
Federation Use Cases 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 In a direct authentication , the claimant presents their authenticator to a verifie | |
| 1.3.1 in 1.3 |
Federation Considerations | The use of a federation protocol allows RPs to be shielded from the complexities and requirements of managing individual authenticators. When a new authentication technology is adopted, only the IdP needs to be updated in order for the enti | |
| 1.4 in 1 |
Audience 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 This document is intended for stakeholders who are responsible for procuring, designing, impleme | |
| 1.5 in 1 |
Notations | This guideline uses the following typographical conventions in text: • Specific terms in CAPITALS represent normative requirements. When these same terms are not in CAPITALS , the term does not represent a normative requirement. – The ter | |
| 1.6 in 1 |
Document Structure | This document is organized as follows. Each section is labeled as either normative (i.e., mandatory for compliance) or informative (i.e., not mandatory). • Section 2 describes a general architecture for PIV federation. This section is info | |
| 2 | Architecture 405 | 406 407 408 409 410 411 412 413 414 415 416 417 418 419 This section is informative. PIV federation is the process by which a subscriber uses their PIV identity account to access an RP using an IdP for that account. As shown in Figure | |
| 2.1 in 2 |
PIV Identity Account | A PIV identity account, as established in [FIPS201] , is the digital account of a PIV cardholder, a party also known as the subject or subscriber in [SP800-63] . This account contains a set of identity attributes for the subscriber, binding | |
| 2.1.1 in 2.1 |
PIV Credentials 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 Authentication to a PIV identity account is accomplished using one or more PIV credenti | |
| 2.1.2 in 2.1 |
Home Agency Identity Management System | The canonical record for a PIV identity account is stored in the identity management system (IdMS) of the home agency of the PIV identity account, known in this document as the home agency IdMS. This system stores and manages the attributes | |
| 2.2 in 2 |
Identity Providers | As described in [SP800-63C] , the IdP provides a bridge between the PIV identity account (established in the home agency IdMS) and the RP using a federation protocol. In a federation transaction, the IdP acts as the verifier for the authent | |
| 2.2.1 in 2.2 |
PIV IdP | The PIV IdP is the PIV IdP identified in a trust agreement to provide federated assertions for a population of PIV identity accounts for an RP. Establishment of the PIV IdP in the trust agreement is discussed in greater detail in Sec. 3 . | |
| 2.2.2 in 2.2 |
Home Agency IdP | When a home agency officially endorses a specific PIV IdP for the PIV identity accounts that the agency issues, that IdP is known as the home agency IdP for that population of PIV identity accounts. The home agency IdP is often run by the h | |
| 2.2.3 in 2.2 |
Subscriber-Controlled wallets 552 | 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 The PIV IdP can be a subscriber-controlled wallet, as defined in [SP800-63C] . In this architecture, the IdP is issued a signed attribute bundle that rep | |
| 2.3 in 2 |
Relying Parties | In the context of a PIV federation, a subscriber logs into the RP using the federation protocol to use the RP’s services and functionality. The nature of the services provided by the RP and the nature of the RP’s deployment are outside the | |
| 3 | Trust Agreements 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 This section is normative. The federation process defined in [SP800-63C] requires the establishment of a tru | |
| 3.1 in 3 |
Bilateral Agreements | An RP MAY enter a trust agreement directly with the PIV IdP in a bilateral fashion, as discussed in [SP800-63C] . When the PIV IdP is the home agency IdP for an agency, the home agency IdMS SHALL make its home agency IdP record available t | |
| 3.2 in 3 |
Multilateral Agreements | Establishment of the trust agreement MAY be facilitated through the use of a trusted third party known as a federation authority, as discussed in [SP800-63C] . This creates a multilateral trust agreement between different PIV IdPs and RPs u | |
| 3.3 in 3 |
Identity Proxies and Brokers | An identity proxy (also known as an identity broker) takes federated authentications from one domain and asserts them outbound to another domain, as discussed in [SP800-63C] . All requirements for proxies enumerated therein apply to identit | |
| 3.4 in 3 |
Shared Signaling | In addition to sharing account information for the purposes of federated login, additional signals can be shared between the IdP and RP for the specific uses described in [SP800-63C] . The IdP SHOULD inform the RP of significant status cha | |
| 3.5 in 3 |
Home Agency IdPs 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 Only the home agency responsible for issuing PIV identity accounts SHALL declare the home agency IdP for tho | |
| 3.5.1 in 3.5 |
Home Agencies and Subscriber-Controlled Wallet 769 | 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 Subscriber-controlled wallets can be a trusted mechanism for PIV federation, even if they are not controlled by the home agency. The home agency can declare tha | |
| 4 | Federation Assurance Level (FAL) 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 This section is normative. The federation assurance level, or FAL, is defined in [SP800-63C] as | |
| 4.1 in 4 |
Reaching Different FALs in PIV Federation | The FAL classification of a PIV federation transaction primarily depends on several aspects of the federation process, including the establishment of the trust agreement, as discussed in Sec. 3 . [SP800-63C] defines general requirements for | |
| 4.1.1 in 4.1 |
FAL1 | FAL1 allows federation in a wide variety of situations, particularly when the results of a risk assessment show that the risk is low, and the value of making the federated connection outweighs the complexities of implementing higher FALs. T | |
| 4.1.2 in 4.1 |
FAL2 | All of the requirements for FAL1 apply at FAL2 except when more specific or stringent requirements in this section override them. As defined in [SP800-63C] , FAL2 requires the assertion presentation to be protected against injection by an | |
| 4.1.3 in 4.1 |
FAL3 | All of the requirements for FAL1 and FAL2 apply at FAL3 except when more specific or stringent requirements in this section override them. The PIV IdP at FAL3 SHALL establish identifiers and key material for RP such that the IdP can identi | |
| 4.2 in 4 |
Selecting FAL | Agencies SHALL select the FAL appropriate for a given RP using the digital identity risk management process specified in [SP800-63] . Notwithstanding the results of that process specifying a higher assurance level, agencies SHOULD use feder | |
| 5 | Requirements of IdPs and RPs 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 This section is normative. This section details the requirements for IdPs and RPs in a PIV fede | |
| 5.1 in 5 |
General-Purpose IdP Requirements | PIV IdPs SHALL follow all requirements for general-purpose IdPs enumerated in [SP800-63C] in addition to the applicable requirements in this section. All assertions generated by a PIV IdP SHALL follow the requirements enumerated in [SP800- | |
| 5.1.1 in 5.1 |
Authentication Requirements | The PIV IdP SHALL authenticate the subscriber using a valid and current PIV credential, which can be a PIV Card or derived PIV credential bound to the PIV identity account. Note that [FIPS201] specifies that derived PIV credentials must be | |
| 5.1.2 in 5.1 |
PIV Identity Account Identification | The IdP SHALL issue a unique federated identifier for each PIV identity account according to the requirements in Sec. 6.2.1 , consisting of the logical combination of: • A subject identifier for the PIV identity account that is locally uni | |
| 5.1.3 in 5.1 |
Session Management | The IdP SHALL create a secure session with the subscriber after a successful authentication event with a PIV credential using session management, as described in [SP800-63B] . The IdP SHALL record the time of the last successful authenticat | |
| 5.2 in 5 |
Subscriber-Controlled wallets 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 When using a subscriber-controlled wallet, the PIV IdP SHALL follow all requirements for subscriber-co | |
| 5.3 in 5 |
RP Requirements | PIV RPs SHALL follow all of the requirements for RPs enumerated in [SP800-63C] . | |
| 5.3.1 in 5.3 |
Assertion Processing | The RP SHALL verify that all assertions contain all required elements as enumerated in Sec. 6.2 . The RP SHALL reject any assertion that does not meet these requirements. | |
| 5.3.2 in 5.3 |
RP Subscriber Accounts | It is common practice for the RP to associate a federated login with a local account record. This record is defined as the RP subscriber account in [SP800-63C] . The RP subscriber account can contain things like access rights at the RP as w | |
| 5.3.3 in 5.3 |
Session Management | The RP SHALL create a secure session with the subscriber upon successfully processing the assertion from the IdP. The RP SHALL NOT tie the session lifetime to the lifetime of the assertion. In common practice, the session lifetime at the RP | |
| 5.3.4 in 5.3 |
Changing the Federated Identifier | To facilitate recovery of an account when a federated PIV identity account can no longer be used, an RP MAY change the federated identifier bound to an RP subscriber account in limited circumstances to be recorded in the trust agreement: • | |
| 6 | Protocol Requirements 996 | 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 This section is normative. A federation protocol connects the IdP and | |
| 6.1 in 6 |
Required Attributes | As stated in Sec. 3 , the trust agreement establishes the set of attributes that the IdP provides to the RP and the purposes the RP has for those attributes. Some attributes are required to be available at the IdP. Some of the available att | |
| 6.1.1 in 6.1 |
Last Updated Time | The last updated attribute is provided as a hint to the RP about the current freshness of the attributes available from the IdP to allow the RP to decide when to refresh any attributes kept in the RP subscriber account. The timestamp is ca | |
| 6.2 in 6 |
Assertion Contents | As specified in [SP800-63C] , the successful validation of a federated assertion is required to begin an authenticated session at the RP. The assertion contains a combination of attributes about the subscriber as well as attributes about th | |
| 6.2.1 in 6.2 |
Federated Identifier | The assertion created by a PIV IdP includes a federated identifier for the PIV identity account, as defined in [SP800-63C] . The federated identifier consists of the logical combination of both a subject identifier for the PIV identity acco | |
| 6.2.2 in 6.2 |
Authorization and Access Rights 1129 | 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 The assertion MAY contain indicators for the authorizations and | |
| 6.2.3 in 6.2 |
Certificate Identifiers | The PIV authentication certificate is issued to PIV identity cardholders as part of the PIV Card and can uniquely identify a PIV identity account, as described in [FIPS201] . Within PIV federation, the PIV authentication certificate is not | |
| 6.3 in 6 |
Discovery and Registration | The IdP SHALL publish its configuration information in a standard machine-readable format and location that are appropriate to the federation protocol in use. The information in the configuration document SHALL be sufficient to allow for th | |
| 6.4 in 6 |
Assertion Presentation 1163 | 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 The IdP SHALL support back-channel assertion presentation, if possible within | |
| 6.5 in 6 |
Attribute APIs | The IdP SHALL make identity attributes for the subscriber available through a standard identity API, if possible within the federation protocol in use. The identity API SHALL require protected access from the RP. The IdP SHALL allow limite | |
| 6.6 in 6 |
Identity Proxies and Brokers | An identity proxy acting in a PIV federation context SHALL disclose the IdPs used as sources of attributes to the downstream RP. For example, if an assertion contains attributes for a PIV identity account from IdP A and IdP B, the proxy wil | |
| Appendix A | Examples 1221 | 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 This appendix is informative. This appendix contains seve | |
| A.1 in A |
Direct Connection to the Home Agency IdP | Agency A, which issues and manages PIV identity accounts, sets up an OpenID Connect IdP in order to make its PIV identity accounts available online through a federation process. The agency publishes its home agency IdP record from its publi | |
| A.2 in A |
Multilateral Federation Network | Agencies A, B, and C each have a home agency IdP running OpenID Connect for their PIV identity accounts. All three agencies join a multilateral federation in which the federation authority independently verifies that each home agency IdP re | |
| A.3 in A |
Enterprise Application | The home agency IdP establishes a pairwise agreement with an RP to provide an enterprise-class service to the subjects of the agency’s PIV identity accounts. As part of this trust agreement, the home agency IdP allows access to a provisioni | |
| A.4 in A |
PKI-Based Federation Gateway 1295 | 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 A service provider that does not issue any PIV identit | |
| A.5 in A |
PIV Federation Proxy as a Federation Authority | A federation proxy is set up within a multilateral federation. The proxy is run by the federation authority. All IdPs under the multilateral agreement register the proxy as an RP. The RPs within the federation authority connect to the proxy | |
| A.6 in A |
FAL3 With a PIV Card and PKI-Based Derived PIV Credentials | The PIV Card and certain PKI-based derived PIV credentials can be used as IdP-managed bound authenticators for use at FAL3. The home agency IdP authenticates the PIV identity account using an authenticator bound to the account and then crea | |
| A.7 in A |
FAL3 With an RP-Bound Authenticator | The home agency IdP authenticates the PIV identity account using an authenticator bound to the account, and then creates an assertion that is flagged as FAL3 and using an RP-bound authenticator. When the RP receives the assertion, it proce | |
| A.8 in A |
Issuance to a Digital Wallet | The home agency provides a service to issue PIV-account-backed credentials to digital wallets. This home agency has decided to accept any wallet as capable of issuing credentials at FAL1. During issuance, the subscriber logs in to the home | |
| Appendix B | Glossary of Terms 1373 | 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 This section is informative. home agency The agency responsible for the issuance and management | |
| Appendix C | Abbreviations 1401 | 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 This section is informative. AAL Authentication Assurance Level API Application Programming Interface CSP Crede |
64 of 64.