Identity Federation Common Operating Rules v.1.4 Lead ...1.3 S teve Sk ordins ki S im p li fed A ppend x B, cr os rence f requi rem ents for C redential Provider and Identity Provider

Identity Federation

Common Operating Rules v.1.4 By: IdF v.2 Project Team Lead Author: Stephen Skordinski Version: 1.4 Published: November 8, 2013

TSCP Identity Federation v.2 Common Operating Rules v.1.4

Document change history for Identity Federation Common Operating Rules.

Date Version Author Changes Made

12/3/2009

.8

Stephen Skordinski Approved as having met the maturity requirements to move from stage 2 to stage 3.

BAES: APPROVED (Richard Skedd)

Boeing: APPROVED (Tim Bird approved post meeting via email)

LMCO: APPROVED (Tony Bass)

7/12/2010

.81

Stephen Skordinski

Replaced references to Federation Operator with Federation Management Author i ty to reflect TSCP terminology.

Removed Exhibits 1 and 2 from document as they lacked relevance to the current content.

Removed technical information relating to the claim requirements, which is duplicated from the DSIF v1 technical profile.

Updated Key Size table to maintain alignment for TSCP CP requirements.

11/16/2010

.91

Stephen Skordinski

Major update to support the Architecture Board Guidance on the DSIF v1 COR.

09/28/2011

.92

Stephen Skordinski / Patrick Patterson / Mark Burns / Richard Skedd

Document revision by DSIF v1 project team. Includes support for 800-63-1 draft 3.

11/16/2011

1.0

Stephen Skordinski

Minor updates made by AB.

Approved by AB for external publication as a draft document.

5/1/2012

1.1

Aiko Woods

Prepared for publication as “final” document vs. “draft.”

6/20/12

1.2

Aiko Woods

Revised appendix A per S. Skordinski.

11/9/12

1.3

Steve Skordinski

Simplified Appendix B, cross reference of requirements for Credential Provider and Identity Provider.

5/13/2013 1.3 Justin Gercken Full review. Edited, reformatted, and published. 10/22/2013 1.4 Steve Skordinski Updated proofing and vetting requirement for

LoA 3.

11/8/2013 1.4 Justin Gercken Review, format, and publish.

TSCP, Inc. Copyright © 2013 i


Copyright © 2013 Transglobal Secure Collaboration Participation, Inc.

All rights reserved.

Terms and Conditions

Transglobal Secure Collaboration Participation, Inc. (TSCP) is a consortium comprising a number of commercial and government members (as further specified at http://www.tscp.org) (each a “TSCP Member”). This specification was developed and is being released under this open source license by TSCP. Use of this specification is subject to the disclaimers and limitations described below. By using this specification you (the user) agree to and accept the following terms and conditions:

1. This specification may not be modified in any way. In particular, no rights are granted to alter, transform, create derivative works from, or otherwise modify this specification. Redistribution and use of this specification, without modification, is permitted provided that the following conditions are met:

Redistributions of this specification must retain the above copyright notice, this list of conditions, and all terms and conditions contained herein.

Redistributions in conjunction with any product or service must reproduce the above copyright notice, this list of conditions, and all terms and conditions contained herein in the documentation and/or other materials provided with the distribution of the product or service.

TSCP’s name may not be used to endorse or promote products or services derived from this specification without specific prior written permission.

2. The use of technology described in or implemented in accordance with this specification may be subject to regulatory controls

under the laws and regulations of various jurisdictions. The user bears sole responsibility for the compliance of its products and/or services with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for its products and/or services as a result of such laws or regulations.

3. THIS SPECIFICATION IS PROVIDED “AS IS” AND WITHOUT WARRANTY OF ANY KIND. TSCP AND EACH TSCP MEMBER DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT, MERCHANTABILITY, QUIET ENJOYMENT, ACCURACY, AND FITNESS FOR A PARTICULAR PURPOSE. NEITHER TSCP NOR ANY TSCP MEMBER WARRANTS (A) THAT THIS SPECIFICATION IS COMPLETE OR WITHOUT ERRORS, (B) THE SUITABILITY FOR USE IN ANY JURISDICTION OF ANY PRODUCT OR SERVICE WHOSE DESIGN IS BASED IN WHOLE OR IN PART ON THIS SPECIFICATION, OR (C) THE SUITABILITY OF ANY PRODUCT OR A SERVICE FOR CERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF TSCP OR ANY THIRD PARTY.

4. IN NO EVENT SHALL TSCP OR ANY TSCP MEMBER BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO THE USE OF THIS SPECIFICATION, INCLUDING, WITHOUT LIMITATION, A CLAIM THAT SUCH USE INFRINGES A THIRD PARTY’S INTELLECTUAL PROPERTY RIGHTS OR THAT IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS SPECIFICATION, THE USER WAIVES ANY SUCH CLAIM AGAINST TSCP OR ANY TSCP MEMBER RELATING TO THE USE OF THIS SPECIFICATION. IN NO EVENT SHALL TSCP OR ANY TSCP MEMBER BE LIABLE FOR ANY DIRECT OR INDIRECT DAMAGES OF ANY KIND, INCLUDING CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHATSOEVER ARISING OUT OF OR RELATED TO ANY USER OF THIS SPECIFICATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

5. TSCP reserves the right to modify or amend this specification at any time, with or without notice to the user, and in its sole discretion. The user is solely responsible for determining whether this specification has been superseded by a later version or a different specification.

6. These terms and conditions will be interpreted and governed by the laws of the State of Delaware without regard to its conflict of laws rules. Any party asserting any claims related to this specification irrevocably consents to the personal jurisdiction of the U.S. District Court for the District of Delaware and to any state court located in such district of the State of Delaware and waives any objections to the venue of such court.

TSCP, Inc. Copyright © 2013 ii


TSCP Member Contributors

The following individuals and their companies have contributed to the construction and authoring of this document.

Name Company

Richard Skedd

BAE Systems

Tim Bird

Boeing

Patrick Patterson

EADS

Tony Bass

Lockheed Martin

Mark Burns

Northrop Grumman

Soma Bojja

Raytheon

Rob Sherwood

TSCP

Stephen Skordinski

TSCP

Vijay Takanti

TSCP

.

TSCP, Inc. Copyright © 2013 iii


Contents 1 Introduction .............................................................................................................................. 1

1.1 Background ............................................................................................................................. 1

1.2 IdP and Credential Provider Relationship ................................................................................. 2

1.3 Document Terminology ............................................................................................................ 2

1.4 Maintenance and Issuance of the Common Operating Rules ................................................... 3

2 Document Notation .................................................................................................................. 4

3 Common Operating Rules ....................................................................................................... 5

3.1 Registration and Issuance Controls .......................................................................................... 5

3.1.1 Security Principal Identifier ............................................................................................... 5

3.1.2 Identity Provisioning Process ........................................................................................... 5

3.1.3 Identity Provisioning Application Processing .................................................................... 6

3.1.4 Initial Identity Proofing and Vetting Requirements ........................................................... 6

3.1.5 Multiple Registration, Identity Proofing, and Token and Credential Encounters .............. 7

3.1.6 Identity Association .......................................................................................................... 7

3.1.7 Credential Acknowledgment ............................................................................................ 8

3.2 Credential Requirement Control ............................................................................................... 8

3.2.1 Enumeration of Acceptable Credential Types .................................................................. 8

3.2.2 Credential Security Characteristics .................................................................................. 9

3.3 Credential Management Controls ........................................................................................... 11

3.3.1 Credential Storage ......................................................................................................... 11

3.3.2 Credential Verification Services ...................................................................................... 12

3.3.3 Credential Renewal / Re-issuance ................................................................................. 13

3.3.4 Credential Revocation and Destruction .......................................................................... 13

3.4 Authentication Process Controls ............................................................................................ 14

3.5 Assertions Controls ................................................................................................................ 15

3.6 Facility Management & Operational Controls .......................................................................... 16

3.6.1 Site Location & Construction .......................................................................................... 17

3.6.2 Physical Access ............................................................................................................. 17

3.6.3 Power and Air Conditioning ............................................................................................ 17

3.6.4 Water Exposures ............................................................................................................ 17

TSCP, Inc. Copyright © 2013 iv


3.6.5 Fire Prevention & Protection .......................................................................................... 17

3.6.6 Media Storage ................................................................................................................ 17

3.6.7 Assertion Signing Key Storage ...................................................................................... 17

3.6.8 Waste Disposal .............................................................................................................. 17

3.6.9 Off-Site backup .............................................................................................................. 17

3.7 Procedural Controls ............................................................................................................... 17

3.7.1 Trusted Roles ................................................................................................................. 18

3.7.2 Number of Persons Required per Task.......................................................................... 18

3.7.3 Identification and Authentication for Each Role .............................................................. 18

3.7.4 Roles Requiring Separation of Duties ............................................................................ 18

3.8 Personnel Controls................................................................................................................. 18

3.8.1 Qualifications, Experience, and Clearance Requirements ............................................. 18

3.8.2 Background Check Procedures ..................................................................................... 19

3.8.3 Training Requirements ................................................................................................... 19

3.8.4 Retraining Frequency and Requirements ...................................................................... 19

3.8.5 Job Rotation Frequency and Sequence ......................................................................... 19

3.8.6 Sanctions for Unauthorized Actions ............................................................................... 19

3.8.7 Independent Contractor Requirements .......................................................................... 19

3.8.8 Documentation Supplied To Personnel .......................................................................... 19

3.9 Audit Logging Procedures ...................................................................................................... 19

3.9.1 Event Logging ................................................................................................................ 19

3.9.2 Types of Events Recorded ............................................................................................. 20

3.9.3 Frequency of Processing Audit Logs ............................................................................. 20

3.9.4 Protection of Audit Logs ................................................................................................. 20

3.9.5 Audit Log Backup Procedures ....................................................................................... 21

3.9.6 Audit Collection System (internal vs. external) ............................................................... 21

3.9.7 Notification to Event-Causing Subject ............................................................................ 21

3.9.8 Vulnerability Assessments ............................................................................................. 21

3.10 Compromise and Disaster Recovery ..................................................................................... 21

3.10.1 Incident and Compromise Handling Procedures ............................................................ 21

3.10.2 Computing Resources, Software, and / or Data are Corrupted ..................................... 21

3.10.3 Assertion Signing Key Compromise Procedures............................................................ 21

3.10.4 Business Continuity Capabilities after a Disaster ........................................................... 22

TSCP, Inc. Copyright © 2013 v


3.11 Termination............................................................................................................................ 22

3.11.1 Credential Provider Termination ..................................................................................... 22

3.11.2 IdP Termination .............................................................................................................. 22

3.12 Records, Transfer, and Archival Controls ............................................................................... 22

3.12.1 Protection of Security Principal Data .............................................................................. 22

3.12.2 Transmission of Registration Data ................................................................................. 22

3.12.3 Record Retention ........................................................................................................... 22

3.12.4 Types of Records Archived ............................................................................................ 23

3.12.5 Protection of Archive ...................................................................................................... 23

3.12.6 Archive Backup Procedures ........................................................................................... 23

3.12.7 Requirements for Time-Stamping of Records ................................................................ 23

3.12.8 Archive Collection System (internal or external) ............................................................ 23

3.12.9 Procedures to Obtain & Verify Archive Information ........................................................ 23

4 References ............................................................................................................................. 24

TSCP Documentation: ................................................................................................................ 24

OMB Publications: ...................................................................................................................... 24

NIST 800 Series Special Publications: ...................................................................................... 24

Federal Information Processing Standards: ............................................................................ 24

Appendix A: Requirements for Assertion of Claims in the TSCP Profile v.1.3 ............................ 25

IPV Level ...................................................................................................................................... 25

Credential Type ........................................................................................................................... 26

Credential Strength .................................................................................................................... 27

Appendix B: Requirements by Entity ............................................................................................ 28

Figures

Figure 1. Federation entities interaction and functional roles. ............................................................... 1 Figure 2. Attribute, assertion, and claim relationship. ............................................................................ 3

Tables Table 1. Federation assurance levels. ................................................................................................... 5 Table 2. Auditable events. ................................................................................................................... 20

TSCP, Inc. Copyright © 2013 vi

TSCP Identity Federation v.2 Common Operation Rules v.1.3

1 Introduction 1.1 Background Identity federation technologies have emerged to enable authentication and authorization of users whose identities are managed by one organization, but who require access to information resources or services provided by another organization. Acceptance of identity data that contains identity information and other attributes (claims) by a Relying Party (RP) depends on the RP’s confidence in the policies and procedures used by the Credential Provider who performed the initial identity proofing and who issued the Credential, and the Identity Provider (IdP), who validates and binds that Credential to additional attributes; the RP must have confidence in the IdP’s ability to authenticate the Security Principal (terms are defined below), as well as the IdP’s ability to generate and transfer an assertion of the Security Principal’s identity to the RP. This document describes the Common Operating Rules (COR) that pertain to organizations that desire to use Identity Federation technologies to collaborate across participating organizations in a secure and interoperable manner. The Common Operating Rules establish mandatory operational policy for Credential Providers and IdPs that, when implemented, enable RPs to have increased confidence in the assertion data passed by the IdP. The COR can serve as a basis for:

• Establishment of a compliance infrastructure for identity federation.

• Inclusion by reference in business agreements and contracts between federation participants.

Though this document is not written to support any particular cross-domain identity federation architecture, it addresses the requirements of known technologies, such as SAML and WS-Federation. Figure 1 depicts federation entities and their roles.

Figure 1. Federation entities interaction and functional roles

TSCP, Inc. Copyright © 2013 Page 1 of 30


An identity federation infrastructure involves the following entities:

• Attribute Provider – An entity that stores authoritative data related to the Security Principal. The attribute provider may provide attributes to the IdP that are included in the assertion issued by the IdP.

• Auditor – An entity that audits the implementation of the COR by the IdP and Credential Provider(s). Audits 1) compare the mapping of the COR to the IdP’s practice statement and 2) examine the IdP’s systems and operations for compliance with the practice statement.

• Credential Provider – An entity that issues digital identities to Security Principals and performs any identity proofing or vetting that may be required to ensure a valid binding of a Credential to the Security Principal.

• Relying Party (RP) – An entity that accepts an assertion as a method of authentication of a Security Principal. Examples of relying parties include systems that will use the attributes associated with the identity to make access control decisions.

• Security Principal – An entity, usually a person, who requests access to resources maintained by the Relying Party. The Security Principal can be positively identified and verified via an authentication process by the IdP, using the Credential provided by the Credential Provider.

• Identity Provider (IdP) – An entity that validates that the Security Principal has possession and control of a Credential that is issued by the Credential Provider. The IdP may or may not be the same entity as the Credential Provider. The IdP consumes one or more Credentials presented by the Security Principal, supplements that Credential with attributes obtained from one or more Attribute Authorities, and creates a new assertion incorporating the obtained attributes for transmission to Relying Parties.

• Trust Framework Provider (TFP) – An entity that defines or adopts an on-line identity trust model, and then certifies identity providers that are in compliance with that mode. The TFP is responsible for establishing and maintaining the COR.

1.2 Identity Provider and Credential Provider Relationship

The IdP and the Credential Provider may or may not be part of the same organization. There can be a one-to-many relationship between the IdP and Credential Provider, and there can also be a one-to-many relationship between the Credential Provider and the Credential types issued by the Credential Provider.

If the IdP is NOT the same entity as the Credential Provider, the IdP is responsible for ensuring that the Credential Provider meets all of the requirements outlined herein for the Credential Provider role prior to accepting any Credential from that Credential Provider. Examples of such proof are a management assertion letter from a qualified auditor (for Level 3 and Level 4 Federation Assurance levels), or an appendix to a commercial contract (for Level 1 and Level 2 assurance levels). In either case, the IdP SHALL make such an assertion letter or appendix available to the appropriate Relying Parties and/or the Trust Framework Provider (TFP).

The IdP and Credential Providers must author practice statements against the applicable policies contained in the COR.

1.3 Document Terminology

The following concepts are also essential for understanding and applying the rules contained within the document.

Attributes: Properties that provide information about a Security Principal.



Claims: Public statements of attributes associated with a Security Principal made by an IdP, and used by Relying Parties to grant access to resources. These claims may include, but are not limited to, the following: the Security Principal’s authentication token, the Security Principal’s identity, the Security Principal’s network and access device, and the Security Principal’s roles in an organization.

Assertion: Signed collections of claims. While claims are conceptual abstractions, assertions are structured messages that conform to a technical standard and are passed between instances of running software.

Sessions: Connections between the security principal and the IdP after the successful authentication of one or both parties.

Figure 2 below depicts the relationship between these terms.

Figure 2. Attribute, assertion, and claim relationship.

1.4 Maintenance and Issuance of the Common Operating Rules

These Common Operating Rules are maintained by TSCP. Change requests may be submitted to [email protected]. These Change Requests will be vetted by the TSCP Architecture Committee (AC), and if agreed upon, an updated version of the COR will be issued.

Figure 2. Attribute, assertion, and claim relationship


mailto:[email protected]


2 Document Notation

The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].


http://tools.ietf.org/html/rfc2119


3 Common Operating Rules The following sections and subsections describe Common Operating Rules for identity federation. Requirements statements are indicated by level four headings (e.g., 1.1.1.1).

The Common Operating Rules are a complementary policy to the TSCP Certificate Policy (CP). If a Credential Provider operates a certified public key infrastructure (PKI), the results of the certification can be deemed an acceptable equivalent to auditing the systems governed by the CP. Additional Credential Provider requirements specified in the COR must be implemented in accordance with the requirements of the COR. The results of any audit of a Credential Provider must be made available to any IdP that accepts Credentials from that Credential Provider.

The IdP Common Operating Rules support four levels of Federation Assurance. Requirements that are unique to each of the four levels are described within each relevant section of the document.

An RP will impose on an IdP a level of Federation Assurance for acceptance of identity assertions, based on the security requirements of the RP. The COR allows RPs to establish varying levels of confidence in an IdP (see Table 1 below).

Table 1. Federation assurance levels

Federation Assurance Level

Description

Level 1 Little or no confidence in the identity assertion validity.

Level 2 Some confidence in the identity assertion validity.

Level 3 High confidence in the identity assertion validity. Level 4 Very high confidence in the identity assertion validity.

3.1 Registration and Issuance Controls

3.1.1 Security Principal Identifier This section describes the requirements related to the naming of a Security Principal.

3.1.1.1 Level 1: No requirements.

3.1.1.2 Level 2, Level 3, and Level 4: Each Security Principal MUST have a unique, permanent and never-reassigned identifier within the scope of its Credential Provider that can be uniquely associated with tokens, Credentials and/or attributes issued to that identity.

3.1.2 Identity Provisioning Process This section describes the requirements related to the provisioning for an identity.

3.1.2.1 The Credential Provider MUST identify and manage the Sponsors who can perform or approve a request for the provisioning of an identity. Examples of Sponsors MAY include, but are not limited to, human resources personnel or company managers.

3.1.2.2 Each Credential Provider SHALL detail and document the provisioning and enrollment process for its Security Principals.

For all identity provisioning requests, the following requirements apply:

3.1.2.3 Level 1: The applicants for the Credential Provider identities SHALL be responsible for providing accurate information in their applications for provisioning.

3.1.2.4 Level 2, Level 3, and Level 4: The Sponsors for the Credential Provider identities SHALL be responsible for providing accurate information in their applications for provisioning.



3.1.3 Identity Provisioning Application Processing This section describes the requirements for processing applications for an identity.

3.1.3.1 It is the responsibility of the Credential Provider to verify that the information in identity provisioning applications is accurate. The Credential Provider SHALL specify procedures to verify information in identity applications.

3.1.4 Initial Identity Proofing and Vetting Requirements This section describes the requirements to ensure that a Security Principal’s identity is verified and checked by the Credential Provider prior to issuing an identity to a Security Principal. Remote registration is limited to Levels 1 through 3.

For all Security Principals, the following identity proofing and vetting requirements apply:

3.1.4.1 Level 1: The name associated with the Security Principal is provided by the applicant and accepted without verification.

3.1.4.2 Level 2: The Credential Provider MAY support in-person and/or remote registration. The identity of the person performing the identity verification MUST be recorded.

The person performing the identity verification MUST sign a declaration that he or she verified the identity of the Security Principal as required by the COR.

The Credential Provider MUST collect the applicant’s full name, including surname and given name(s), from an unexpired government-issued document(s).

The Credential Provider MUST record the full name, including surname and given name(s), of the Security Principal, and maiden name, if applicable.

The Credential Provider MUST record the full name and legal status of the Security Principal's employer.

The Credential Provider MUST record an email address for the Security Principal.

The Credential Provider MUST obtain a declaration signed by the Security Principal indicating his acceptance of the Credential Provider's privacy policy.

The Credential Provider MUST record the date and time of the verification.

3.1.4.3 Level 3: For all Credential types, the Credential Provider MUST support identity-proofing procedures that are compliant with the proofing and vetting requirements of the TSCP CP for a medium (or higher) level of assurance; except that the Credential Provider MAY replace the in-person identity-proofing procedure with a remote identity-proofing procedure which meets the following remote proofing requirements:

Option 1: The Credential Provider MUST ensure the applicant has possession of a valid Government ID (e.g., a driver’s license or passport) number and a financial or utility account number (e.g., checking account, savings account, utility account, loan or credit card) confirmed via records of both numbers. Note that confirmation of the financial or utility account may require supplemental information from the applicant.

The Credential Provider MUST verify information provided by the applicant including Government ID number AND account number through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address and other personal information in records are consistent with the application and sufficient to identify a unique individual. At a minimum, the records check for both the ID number AND the account number SHALL be used to confirm the name and address of the applicant. For utility account numbers, confirmation SHALL be performed by verifying knowledge of recent account activity. (This technique may also be applied to some financial accounts.)

The Credential Provider SHALL confirm the applicant’s address by either:



• Credential Provider issues Credentials in a manner that confirms the ability of the applicant to receive mail at a physical address associated with the applicant in records; or;

• If personal information in records includes both an electronic address and a physical address that are linked together with the applicant’s name, and are consistent with the information provided by the applicant, then the Credential Provider MAY issue credentials in a manner that confirms the ability of the applicant to receive messages (SMS, voice or e-mail) sent to the electronic address. Any secret sent over an unprotected session SHALL be reset upon first use.

The Credential Provider MAY permit the applicant to provide alternative identification attributes so long as the Credential Provider can verify the values provided by the applicant match an authoritative source, and that the attributes provide verification that is commensurate with the baseline requirement to verify a Government ID number and a financial or account number.

Option 2: The Credential Provider MAY use a remote video conference session to execute the proofing and vetting requirements of the TSCP CP for a medium (or higher) level of assurance. As the identification documents of the applicant cannot be physically examined during a video conference, the Credential Provider MUST identify, document, and implement a procedure to validate the identification documents provided by the applicant.

3.1.4.4 Level 4: For all Credential types, the Credential Provider MUST support identity-proofing procedures that are compliant with the proofing and vetting requirements of the TSCP CP for a medium (or higher) level of assurance.

3.1.5 Multiple Registration, Identity Proofing, and Token and Credential Encounters Registration, identity proofing, and Credential issuance are discrete steps of the credentialing process. This process may be broken up into a number of separate physical encounters and electronic transactions. (Two electronic transactions are considered to be separate if they are not part of the same protected session.) In these cases, the following methods SHALL be used to ensure that the same Security Principal acts as an applicant throughout the process. For all Security Principals, the following requirements apply:

3.1.5.1 Level 1: There is no specific requirement; however, some effort SHOULD be made to uniquely identify and track the applicant.

3.1.5.2 Level 2 and 3: The Security Principal SHALL identify himself/herself in any new electronic transaction (beyond the first transaction or encounter) by presenting a temporary secret that was established during a prior transaction or encounter, or sent to the Security Principal’s phone number, email address, or physical address on record.

3.1.5.3 Level 4: The Credential Provider MUST support registration, identity proofing, and Credential issuance procedures that are compliant with the proofing and vetting requirements of the TSCP CP for a medium (or higher) level of assurance.

3.1.6 Identity Association This section describes the requirements and procedures for Credential Providers to associate identities with the Security Principals.

The following requirements apply when associating a Security Principal to a name:

3.1.6.1 Level 1: The name associated with the Security Principal is provided by the Applicant and accepted without verification.

The name associated with the Security Principal MAY be pseudonymous.



3.1.6.2 Level 2: The name associated with the Security Principal MAY be pseudonymous, but the Credential Provider SHALL know the actual identity of the Security Principal. In addition, pseudonymous Level 2 Credentials must be distinguishable from Level 2 Credentials that contain verified names.

The Credential Provider MUST unambiguously associate issued Credentials with a single managed identity (as identified in Section 3.1.1).

3.1.6.3 Level 3 and Level 4: The name associated with the Security Principal at the Credential Provider MUST be verified.

AND

The Credential Provider MUST unambiguously associate issued Credentials with a single managed identity (as identified in Section 3.1.1).

Practice Note: There is a policy conflict between existing pseudonym guidance in the Federal Bridge Certificate Policy (CP) and the NIST Special Publication 800-63-1 (Draft 3).

The Federal Bridge CP states pseudonyms for “DNs in certificates issued by Entity Certificate Authorities (CA) may contain a pseudonym (such as a large number) as long as name space uniqueness requirements are met.”

NIST 800-63-1 (Draft 3) states “only verified names may be specified in credentials and assertions at Levels 3 and 4.”

As a result of this conflicting guidance, the COR permits pseudonyms in level 3 and 4 credentials, pending consideration of future guidance from FICAM.

3.1.7 Credential Acknowledgment This section describes the Credential acknowledgment requirements a Credential Provider MUST support when issuing Credentials to Security Principals.

3.1.7.1 The Credential Provider SHALL specify procedures to verify the legal acceptance of an identity by a Security Principal.

The following requirements apply when issuing a Credential to a Security Principal:

3.1.7.2 Level 1 and Level 2: The failure of a Security Principal to provide a negative consent when provided a Credential MAY be considered Credential acknowledgement by the Credential Provider.

3.1.7.3 Level 3 and Level 4: The Credential Provider MUST record a positive acknowledgement of the Credential by the Security Principal. Examples of positive acknowledgement MAY include, but are not limited to, a review of the usage terms and conditions of the Credential, and a physical signature by the Security Principal, or the action of checking a consent check box on a web form.

3.2 Credential Requirement Control 3.2.1 Enumeration of Acceptable Credential Types This section identifies the Credentials that may be issued by Credential Providers and accepted by IdPs, under the policy guidance of the COR.

3.2.1.1 Only the following Credentials are acceptable to be issued by a Credential Provider or accepted by an IdP operating under this policy. When an IdP accepts an authentication from a Security Principal, it SHALL differentiate between the types of Credentials used, and SHALL pass this information along to the RP.

Memorized Secret Token

A secret shared between the Security Principal and the Credential Provider that the Security Principal memorizes and uses to authenticate his or her identity to the



Credential Provider. Memorized Secret Tokens are typically character strings (e.g., passwords and passphrases) or numerical strings (e.g., PINs).

Out of Band Token

A physical token that is uniquely addressable and can receive a Credential Provider selected secret for one-time use. The device is possessed and controlled by the Security Principal and supports private communication over a channel that is separate from the primary channel for authentication. The token authenticator is the received secret and is presented to the IdP using the primary channel for e-authentication. For example, a Security Principal attempts to log into a website and receives a text message on his or her cellular phone or a voice message on a land line (pre-registered with the Credential Provider during the registration phase) with a random authenticator to be presented as a part of the authentication process.

Single Factor One-Time Password (OTP) Device

A hardware device that supports the spontaneous generation of one-time passwords. This device has an embedded secret that is used as the seed for generation of one-time passwords, and does not require activation through a second factor. Authentication is accomplished by providing an acceptable one-time password and thereby proving possession of the device.

Multi-Factor One-Time Password

A hardware device that generates one-time passwords for use in authentication and that requires activation through a second factor of authentication. The second factor of authentication may be achieved through some kind of integral entry pad, an integral biometric (e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). The one-time password is typically displayed on the device and manually input to the authenticator as a password, although direct electronic input from the device to a computer is also allowed. The OTP device is something the Security Principal has, and it may be activated by either something the Security Principal knows or something the Security Principal is (biometric).

PKI Credentials

A device that uses embedded symmetric or asymmetric cryptographic keys. Authentication is accomplished by proving possession of the private keys. When used, the following SHALL be differentiated:

• PKI Certificates issued under the Credential Provider’s own basic assurance policy.

• PKI Certificates issued under a policy mapped to TSCP medium-software.

• PKI Certificates issued under a policy mapped to TSCP medium-hardware.

• PKI Certificates issued under a policy mapped to TSCP iceCAP. 3.2.2 Credential Security Characteristics This section identifies mandatory security characteristic policies for each of the Credential types addressed in the COR.

3.2.2.1 The Credential MUST possess the following security characteristics based on type:

Memorized Secret Token

The Memorized Secret Token issued by the Credential Provider MUST comply with the following security requirements, and the IdP must indicate in a claim to the RP which level of complexity is satisfied:



Difficulty A:

• A value of at least 6 characters MUST be used.

Difficulty B:

• A Password of at least 8 characters MUST be used.

• The Password MUST contain at least one uppercase character, one lowercase character, and one number.

• The Password MUST lock out authentication attempts after a maximum of five consecutive unsuccessful tries.

• The Password MUST be changed at a minimum interval of every 180 days. Out of Band Token

Out of Band Credentials issued by Credential Providers MUST comply with the following security requirements:

• The token MUST be uniquely addressable and support communication over a channel that is separate from the primary channel for authentication.

• The Out of Band Token value MUST be changed at a minimum interval of every five minutes.

• A token of at least six numeric characters MUST be used.

Single Factor One-Time Password

Single Factor One-Time Password Credentials issued by Credential Providers MUST comply with the following security requirements:

• The Credential Provider MUST use a NIST1 (or equivalent) approved block cipher or hash function to combine a symmetric key stored on device with a nonce to generate a one-time password.

• The cryptographic module performing this operation SHALL be validated at FIPS 140-2 Level 1 (or equivalent) or higher.

• The nonce MAY be a date and time, or a counter generated on the device.

• The one-time password MUST have a limited lifetime, on the order of minutes. Practice Note: As part of good security practice, Single Factor One-Time Password devices are typically used in combination with a Memorized Secret Token during the verification process.

PKI Credentials

PKI Credentials issued by Credential Providers MUST comply with the following security requirements:

1 U.S. Dept. of Commerce, National Institute of Standards and Technology.

Practice Note: As part of good security practice, Out of Band Tokens are typically used in combination with a Memorized Secret Token during the verification process.



• Basic Assurance Certificates MUST comply with the Credential Providers CP.

• All higher allowed assurance level Certificates MUST comply with the Credential Provider’s CP, MUST be mapped to the TSCP CP, and the Credential Provider MUST hold a valid cross-certificate issued by TSCP (or PKI bridged equivalent) indicating such a mapping.

*For details on how credentials map to Levels of Assurance, see Appendix A.

3.3 Credential Management Controls

This section identifies mandatory requirements for the management of Credentials.

3.3.1 Credential Storage The following Credential Storage requirements MUST be met by the Credential Provider:

3.3.1.1 Level 1: Files of shared secrets used by Credential Providers at Level 1 authentication SHALL be protected by discretionary access controls that limit access to administrators and only to those applications that require access. Such shared secret files SHALL NOT contain the plain-text passwords; typically they contain a one-way hash or “inversion” of the password. Passwords MUST not be stored in the clear.

In addition, any method allowed for the protection of long-term shared secrets at Levels 2, 3, or 4 may be used at Level 1.

3.3.1.2 Level 2: Files of shared secrets used by Credential Providers at Level 2 SHALL be protected by discretionary access controls that limit access to administrators and only to those applications that require access. Such shared secret files SHALL NOT contain the plain-text passwords or secrets; two alternative methods MAY be used to protect the shared secret:

• Passwords may be concatenated to a variable salt (variable across a group of passwords that are stored together) and then hashed with a NIST (or equivalent) approved algorithm so that the computations used to conduct a dictionary or exhaustion attack on a stolen password file are not useful to attack other similar password files. The hashed passwords are then stored in the password file. The variable salt may be composed using a global salt (common to a group of passwords) and the username (unique per password) or some other technique to ensure uniqueness of the salt within the group of passwords.

• Shared secrets may be stored in encrypted form using NIST (or equivalent) approved encryption algorithms and modes, and the needed secret decrypted only when immediately required for authentication.

In addition, any method allowed to protect shared secrets at Level 3 or 4 MAY be used at Level 2.

3.3.1.3 Level 3 and Level 4: Files of long-term shared secrets used by Credential Providers or IdPs at Level 3 SHALL be protected by discretionary access controls that limit access to administrators and only to those applications that require access. Such shared secret files SHALL be encrypted so that:

• The encryption key for the shared secret file is encrypted under a key held in a FIPS 140-2 Level 2 (or equivalent) or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 (or equivalent) cryptographic module and decrypted only as immediately required for an authentication operation.

• Shared secrets are protected as a key within the boundary of a FIPS 140-2 Level 2 (or equivalent) or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 (or equivalent) cryptographic module and is not exported in plain-text from the module.



3.3.2 Credential Verification Services This section identifies requirements for the verification of Credentials by the IdP and Credential Provider.

The following Credential Verification Services requirements MUST be met by the Credential Provider and/or IdP:

3.3.2.1 Level 1: Long term secrets SHOULD NOT be shared with other parties unless absolutely necessary.

3.3.2.2 Level 2: Long term shared authentication secrets, if used, SHALL NOT be revealed to any party except the Security Principal and Credential Provider (including IdPs operated as a part of the Credential Provider); however, session (temporary) shared secrets MAY be provided by the Credential Provider to independent IdPs.

Cryptographic protections are required for all messages between the Credential Provider and IdP that contain private Credentials or assert the validity of weakly-bound or potentially revoked Credentials. Private Credentials SHALL only be sent through a protected channel to an authenticated party to ensure confidentiality and tamper protection.

The Credential Provider MAY send the IdP a message that either asserts that a weakly-bound Credential is valid, or that a strongly bound Credential has not been subsequently revoked. In this case, the message SHALL be logically bound to the Credential, and the message, the logical binding, and the Credential SHALL all be transmitted within a single integrity-protected session between the IdP and the authenticated Credential Provider. If revocation is an issue, the integrity-protected messages SHALL either be time-stamped, or the session keys SHALL expire with a time period no longer than that of the revocation list. Alternatively, the time-stamped message, binding, and Credential MAY all be signed by the Credential Provider, although, in this case, the three in combination would comprise a strongly bound Credential with no need for revocation.

Practice Note: Credentials that describe the binding between a user and token in a tamper-evident fashion are considered Strongly Bound Credentials. For example, modification of a digitally signed credential (such as a public key certificate) can be easily detected through signature verification. The binding between a user and token can be modified in Weakly Bound Credentials without invalidating the credentials. Weakly bound credentials require supplemental integrity protection and/or access controls to ensure that the binding represented by the credential remains accurate. For example, replacing the value of a hashed password in a password file associates the user with a new password, so access to this file is restricted to system users and processes.

Strongly bound credential mechanisms require little or no additional integrity protection, whereas weakly bound credentials require additional integrity protection or access controls to ensure that unauthorized parties cannot spoof or tamper with the binding of the identity to the token representation within the credential. Unencrypted password files are private credentials that are weakly bound, and hence, need to be afforded confidentiality, as well as integrity protection. Signed password files are private credentials that are strongly bound. An unsigned pairing of a public key and the name of its owner is an example of a public credential that is weakly bound. Finally, a signed public key certificate represents a public credential that is strongly bound.

3.3.2.3 Level 3 and Level 4: Credential Providers SHALL provide a secure mechanism to allow IdPs to ensure that the Credentials are valid. Such mechanisms may include on-line validation servers or the involvement of Credential Provider servers that have access to status records in authentication transactions.

Temporary session authentication keys MAY be generated from long-term shared secret keys by Credential Providers and distributed to third party IdPs as a part of the verification services offered by the Credential Provider, but long-term shared secrets SHALL NOT be shared with any third parties, including third party IdPs.

When supporting mutual authentication protocols, the assurance level of the Credential used by the Identity Provider and/or Credential Provider for mutual authentication SHALL be commensurate with, or higher than, the level of the Credential being verified.



3.3.3 Credential Renewal / Re-issuance This section identifies requirements for the renewal or re-issuance of Credentials by the Credential Provider.

The following Credential Renewal / Re-issuance requirements MUST be met by the Credential Provider:


3.3.3.2 Level 2: The Credential Provider SHALL establish suitable policies for the renewal and re- issuance of Credentials. Proof-of-possession of the unexpired current token SHALL be demonstrated by the Security Principal prior to the Credential Provider allowing renewal and re-issuance. Passwords SHALL NOT be renewed; they SHALL be re-issued. After expiration of the current token, renewal and re-issuance SHALL NOT be allowed. All interactions SHALL occur over a protected channel, such as SSL/TLS. Secondary Credentials MUST NOT be renewed or re-issued.

3.3.3.3 Level 3 and Level 4: Renewal and re-issuance SHALL only occur prior to the expiration of the current Credential. Security Principals SHALL authenticate to the Credential Provider using the existing Credential in order to renew or re-issue the Credential. All interactions SHALL occur over a protected channel such as SSL/TLS.

If PKI Credentials are being reissued, the Credential Provider MUST support certificate re-key procedures for a medium (or higher) assurance level in the TSCP CP.

3.3.3.4 When supporting mutual authentication protocols during the Credential renewal/re- issuance process, the assurance level of the Credential used by the Credential Provider for mutual authentication SHALL be commensurate with, or higher than, the level of the Credential being verified.

Practice Note: In the case of hardware PKI, a certificate should not be re-issued for a period beyond the life of the token. For example, a smart card has a remaining validity period of two years printed on the card. PKI credentials that are valid for over two years should not be installed on the card.

3.3.4 Credential Revocation and Destruction This section identifies requirements for the revocation and destruction of Credentials by the Credential Provider.

The following Credential Revocation and Destruction requirements MUST be met by the Credential Provider:


3.3.4.2 Level 2: The Credential Provider SHALL revoke or destroy Credentials within 72 hours after being notified that a Credential is no longer valid or is compromised to ensure that a Security Principal using the Credential cannot successfully be authenticated. If the Credential Provider issues Credentials that expire automatically within 72 hours (e.g., issues fresh certificates with a 24 hour validity period each day) then the Credential Provider is not required to provide an explicit mechanism to revoke the Credentials.

Credential Providers that register passwords SHALL ensure that the revocation or de- registration of the password can be accomplished in no more than 72 hours.

If Basic Assurance PKI Credentials are being revoked and or destroyed, the Credential Provider MUST support Credential revocation and destruction requirements in Credential Provider’s CP.

3.3.4.3 Level 3: Credential Providers SHALL have a procedure to revoke Credentials within 24 hours.



The Verifier SHALL ensure that the tokens they rely upon are either freshly issued (within 24 hours) or still valid.

Shared secret based authentication systems MAY simply remove revoked Security Principals from the verification database.

Secondary Credentials MUST have a lifetime less than 2 hours.

If PKI Credentials are being revoked and/or destroyed, the Credential Provider MUST support Credential revocation and destruction requirements in the TSCP CP.

3.3.4.4 Level 4: Credential Providers SHALL have a procedure to revoke Credentials within 24 hours.

The Verifier SHALL ensure that the Credentials they rely upon are either freshly issued (within 24 hours) or still valid.

If PKI Credentials are being revoked and or destroyed, the Credential Provider MUST support Credential revocation and destruction requirements in the TSCP CP.

Secondary Credentials must have a lifetime of less than 15 minutes.

If PKI Credentials are being revoked and/or destroyed, the Credential Provider MUST support Credential revocation and destruction requirements in the TSCP CP.

The Credential MUST be revoked and/or destroyed when the Credential Provider ends their relationship with the Security Principal. The Credential Provider MUST notify the Security Principal of the revocation and/or destruction of a Credential.

The Credential Provider SHOULD establish policies for cryptographic token collection to avoid the possibility of unauthorized use of the token after it is considered out of use.

3.4 Authentication Process Controls 3.4.1.1 The Security Principal SHALL prove to the Verifier, through a secure authentication

protocol, that he or she controls the Credential.

The following Authentication requirements MUST be met by the IdP:

3.4.1.2 Level 1: The Security Principal SHALL prove, through a secure authentication protocol, that he or she controls the Credential.

Plain-text passwords or secrets SHALL NOT be transmitted across a network.

Practice Note: This level does not require cryptographic methods. For example, password challenge-response protocols that combine a password with a challenge to generate an authentication reply satisfy this requirement. Common protocols that meet this requirement include APOP [RFC 1939], S/KEY [SKEY], and Kerberos [KERB].

Long-term shared authentication secrets MAY be revealed to Verifiers.

3.4.1.3 Level 2: Protocols used at Level 2 and above SHALL be at least weakly man-in-the-middle resistant.

NIST (or equivalent) approved cryptography SHALL be used at a level commensurate with the level being protected.

Session data transmitted between the Security Principal and the IdP following a successful Level 2 verification MUST be protected as described in the NIST FISMA (or equivalent) guidelines.


http://www.ietf.org/rfc/rfc1939.txt

http://en.wikipedia.org/wiki/S/KEY

http://en.wikipedia.org/wiki/Kerberos_(protocol)


3.4.1.4 Level 3: Strong cryptographic mechanisms SHALL be used to protect Credentials. Long- term shared authentication secrets, if used, SHALL never be revealed to any party except the Security Principal and Credential Provider; however, session (temporary) shared secrets MAY be provided to Verifiers by the Credential Provider, possibly via the Security Principal. NIST (or equivalent) approved cryptographic techniques SHALL be used for all operations including the transfer of session data.

3.4.1.5 Level 4: Either public key or symmetric key technology MAY be used. Long-term shared authentication secrets, if used, SHALL never be revealed to any party except the Security Principal and Credential Provider; however, session (temporary) shared secrets may be provided to Verifiers by the Credential Provider. Strong NIST (or equivalent) approved cryptographic techniques SHALL be used for all operations including the transfer of session data. All sensitive data transfers shall be cryptographically authenticated using keys that are derived from the authentication process in such a way that man-in-the-middle attacks are strongly resisted.

3.5 Assertions Controls

This section describes the requirements for the use of assertions.

3.5.1.1 The security token used for the exchange of claims MUST be a SAML token.

3.5.1.2 The protocol used to exchange SAML tokens MUST be either SAML 2.0 (or later) or WS- Federation 1.1 (or later).

3.5.1.3 The IdP MUST document a binding process to demonstrate any attribute included in the assertion sent to the RP is bound to the associated Security Principal.

3.5.1.4 The assertion generated by the IdP MUST have a time-to-live of 5 minutes.

The following Assertion requirements MUST be met by the IdP:

3.5.1.5 Level 1: Bearer assertions and assertion references SHALL be specific to a single transaction, i.e., one-time use.

The assertion reference that is used MUST have a minimum of 64 bits of entropy.

If assertion references are used, they SHALL be freshly generated whenever a new assertion is created by the IdP. In other words, bearer assertions and assertion references are generated for one-time use.

The IdP MUST either digitally sign all assertions sent to RPs or transmit assertions to RPs via a mutually authenticated TLS channel.

The PKI Credentials used SHALL be commensurate with, or higher than, the level of the assertion being issued.

The IdP MAY issue session cookies to Security Principals that are valid for up to 12 hours.

3.5.1.6 Level 2: All requirements from Level 1 apply.

At Level 2, assertions MUST specify whether the name of the Security Principal is a verified name or a pseudonym.

The IdP MUST digitally sign all assertions it issues.

The IdP MUST encrypt the assertion for the RP using a public key provided by the RP.

The IdP MUST use encrypted channels when passing assertions to either the Security Principal or the RP.

All assertion protocols used at Level 2 and above require the use of NIST (or equivalent) approved cryptographic techniques.

3.5.1.7 Level 3: All requirements from Level 1 and Level 2 apply.



The signing certificate used by the IdP MUST abide by TSCP medium Commercial Best Practices (CBP) or higher.

The Security Principal MUST demonstrate that he or she was the party that authenticated to the IdP.

Practice Note: This could be demonstrated, for example, by the presence of a cookie set by the IdP in the Security Principal’s browser.

The IdP MUST reliably determine the “liveness” of the Security Principal with a Relying Party since the last assertion was delivered by the IdP. This means that the IdP MUST have evidence that the Security Principal is actively using the services of the Relying Party and has not been idle for more than 30 minutes.

The IdP MAY issue session cookies to Security Principals that are valid for up to 30 minutes.

3.5.1.8 Level 4: All requirements from Level 1, Level 2, and Level 3 apply.

The signing certificate used by the IdP MUST abide by TSCP CP medium hardware policy or higher.

Bearer assertions MAY be used provided the following requirements are met:

• The IdP MUST establish a mutually authenticated TLS session with the Security Principal.

• The IdP MUST ensure the Security Principal presents a valid Level 4 PKI Credential.

• The IdP MUST include the Security Principal’s certificate that was validated during the TLS handshake as a claim in the assertion.

Practice Note: The RP establishes a mutually authenticated TLS session with the Security Principal, and compares the certificate from the Security Principal / RP TLS session to the certificate passed as a claim in the assertion.

Holder of Key assertions MAY be used provided the following requirements are met:

• The IdP MUST ensure the Security Principal presents a valid Level 4 PKI Credential.

• The IdP MUST generate a holder-of-key assertion that references a key that is part of the Level 4 PKI Credential (used to authenticate to the IdP) or linked to it through a chain of trust.

Practice Note: The RP verifies that the Security Principal possesses the key that is referenced in the holder-of-key assertion using a Level 4 protocol (where the RP plays the role attributed to the IdP).

3.6 Facility Management & Operational Controls For Level 3 and Level 4 Federation Assurance levels, the controls that apply to a CA from Section 5 of the TSCP CP SHALL apply to the IdP functions. Controls for the Credential Provider at these assurance levels are already implied as part of conformance to the other conditions elsewhere in this document.

Thus, Level 1 and Level 2 Federation Assurance level requirements SHALL be enumerated in this section. Level 3 and Level 4 policies are additive to those from Section 5 of the TSCP CP and only required where explicitly listed (i.e., listed as a level 3 or level 4 requirement in the following sections). However, unless otherwise stipulated, this section does not impose any requirements or policy controls on a Credential Provider.

For Level 1 assurance level: No requirements.



For Level 2 assurance level, the following stipulations apply:

3.6.1 Site Location & Construction 3.6.1.1 The site where the IdP infrastructure is situated SHALL CONFORM to best commercial

practices for the protection of computing equipment of moderate value. The site location and construction, when combined with other physical security protection mechanisms, shall provide robust protection against unauthorized access to the IdP equipment and records.

3.6.2 Physical Access 3.6.2.1 Access SHALL be controlled and limited to those that can demonstrate a need to access

the equipment used by the IdP.

3.6.2.2 The IdP MUST ensure no unauthorized access to the hardware is permitted.

3.6.2.3 The IdP MUST ensure all removable media and paper containing sensitive plain-text information is stored in secure containers.

3.6.3 Power and Air Conditioning 3.6.3.1 Adequate Power and Air Conditioning SHALL be maintained.

3.6.4 Water Exposures No stipulations.

3.6.5 Fire Prevention & Protection 3.6.5.1 Adequate prevention methods consistent with local bylaws and codes relating to fire

protection SHALL be adopted.

3.6.6 Media Storage 3.6.6.1 When media containing information pertaining to the IdP service is stored, it

SHALL be stored in conformity with the stipulations for protection of sensitive or personal information found elsewhere in this document, and in conformance with local or national regulation.

3.6.7 Assertion Signing Key Storage The private key for the token signing certificate of the federation STS meets the following requirements:


3.6.7.2 Level 2: The private key for the token signing certificate of the federation SAML STS MUST be stored on a security module approved at FIPS 140-2 Level 1 or higher.

3.6.7.3 Level 3 and Level 4: The private key for the token signing certificate of the federation SAML STS must be stored on a hardware security module approved at FIPS 140-2 Level 2 or higher.

3.6.8 Waste Disposal 3.6.8.1 Sensitive waste material SHALL be disposed of in a secure fashion.

3.6.9 Off-Site backup No stipulations.

3.7 Procedural Controls For Level 1 assurance level: No requirements.




3.7.1 Trusted Roles The IdP MUST support the following Trusted Roles:


3.7.1.2 Level 2, Level 3, and Level 4:

IdP Operator – The Operator SHALL be responsible for the routine operation of the IdP equipment and operations, such as system backups and recovery or changing recording media.

IdP Administrator – The Administrator SHALL be responsible for:

• Installation, configuration, and maintenance of the IdP.

• Establishing and maintaining IdP system accounts.

• Configuring RP profiles in the IdP system.

• Activating and backing up of IdP assertion signing certificate keys.

IdP Audit Administrator – The Audit Administrator SHALL be responsible for:

• Reviewing, maintaining, and archiving audit logs.

• Performing or overseeing internal compliance audits to ensure that the IdP and the Credential Provider(s) used by the IdP are operating in accordance with its Common Operating Rules Practice Statement.

3.7.2 Number of Persons Required per Task The following persons required per task requirements MUST be met by the IdP:

3.7.2.1 Level 1 and Level 2: No requirements.

3.7.2.2 Level 3 and Level 4: Access to the IdP STS components requires two person physical access controls.

Two or more persons shall be required to perform the token signing key generation.

3.7.3 Identification and Authentication for Each Role The following identification and authentication for each role requirements MUST be met by the IdP:


Level 2, Level 3, and Level 4: An individual SHALL identify and authenticate with a Credential commensurate with, or higher than, the level of the IdP being managed before being permitted to perform any actions set forth above for that role or identity.

3.7.4 Roles Requiring Separation of Duties 3.7.4.1 Under no circumstance SHALL a person assigned the IdP audit administrator role be

assigned or perform any other IdP role at the same time.

3.8 Personnel Controls

For Level 1 assurance level: No stipulations.


3.8.1 Qualifications, Experience, and Clearance Requirements 3.8.1.1 All personnel involved in the operation of the IdP SHALL possess appropriate

qualifications consistent with the professional operation of this type of service.



3.8.2 Background Check Procedures 3.8.2.1 All personnel involved in any Trusted Role as enumerated in Section 3.7.1 MUST meet

the employment criteria of the company operating the IdP and the approval of the service owner.

3.8.3 Training Requirements 3.8.3.1 All personnel performing duties with respect to the operation of the IdP SHALL receive

comprehensive training in the following subjects:

• Identity federation and information security principles and mechanisms.

• All IdP duties they are expected to perform.

• All IdP software versions in use that the personnel will be required to use as part of their duties.

• Disaster recovery and business continuity procedures.

Documentation SHALL be maintained identifying all personnel who received training.

3.8.4 Retraining Frequency and Requirements 3.8.4.1 Individuals responsible for trusted roles SHALL be aware of changes in the IdP systems

and operations, as applicable. Any significant change to the operations SHALL have a corresponding training (awareness) plan.

3.8.5 Job Rotation Frequency and Sequence No stipulations.

3.8.6 Sanctions for Unauthorized Actions 3.8.6.1 Anyone who does not adequately perform in his or her position as a Trusted Role MUST

be removed from that Trusted Role. This includes any actions that are not consistent with maintaining the trustworthiness of the IdP by any RP.

3.8.7 Independent Contractor Requirements No stipulations.

3.8.8 Documentation Supplied To Personnel 3.8.8.1 All Trusted Roles MUST be provided with adequate documentation to perform their role.

3.9 Audit Logging Procedures



3.9.1 Event Logging 3.9.1.1 Events MAY be logged in various systems, as well as different formats.

3.9.1.2 The events identified in the table MUST be logged and SHOULD be automatically recorded. Logs may be stored on systems that are logically or physically separate from where the event occurred. The logs MAY be stored in different formats, including hand written logs where applicable (such as physical access records). At a minimum, each audit record SHALL include the following (either recorded automatically or manually for each auditable event):

• The type of event.

• The date and time the event occurred.

• Success or failure, where appropriate.



• The identity of the entity and/or operator that caused the event.

3.9.2 Types of Events Recorded

Table 2. Auditable events

Auditable Events Security Audit

Any attempt to delete or modify the Audit logs. Any changes to the Audit parameters, e.g., audit frequency and type of event audited. Failed Logons. Obtaining a third-party time-stamp. Any attempt to delete or modify the Audit logs.

Local Data Entry

All security-relevant data that is entered in the system.

Remote Data Entry All security-relevant messages that are received by the system. Physical Access / Site Security Known or suspected violations of physical security.

Anomalies

Software error conditions. Network attacks (suspected or confirmed). Equipment failure. Resetting Operating System Clock. Software error conditions.

Miscellaneous Appointment of a Trusted Role. Installation of a Federation Service.

Assertion Generator

Errors: Information about a significant problem of which the administrator should be aware, usually involving a loss of functionality or data. Warnings: Indicates a problem that is not immediately significant, but that may signify conditions that could cause future issues. Success Audit: Indicates an audited security event when an audited access attempt is successful with detailed information about each token involved in the transaction, including claims information; for example, a successful logon attempt. Failure Audit: Indicates a security event that occurs when an audited access attempt fails with detailed information about each token involved in the transaction, including claims information; for example, an inbound token was not valid. Errors: Information about a significant problem of which the administrator should be aware, usually involving a loss of functionality or data.

3.9.3 Frequency of Processing Audit Logs 3.9.3.1 Audit logs SHALL be reviewed to resolve issues and as required, to ensure proper

operation of the system.

3.9.4 Protection of Audit Logs 3.9.4.1 System configuration and procedures SHALL be implemented together to ensure that:

• Only authorized people have read access to the logs.

• Only authorized people may archive audit log.

• Audit logs are not modified.



3.9.4.2 The system MAY overwrite audit logs after they have been backed up and archived.

3.9.5 Audit Log Backup Procedures 3.9.5.1 Logs required by these operating rules must be backed up and restoration procedures

must be tested and verified.

3.9.6 Audit Collection System (internal vs. external) 3.9.6.1 The audit log collection system MAY be external to the IdP.

3.9.7 Notification to Event-Causing Subject This COR imposes no requirement to provide notice that an event was audited to the individual, organization, device, or application that caused the event.

3.9.8 Vulnerability Assessments No stipulations.

3.10 Compromise and Disaster Recovery For Level 1 assurance level: No stipulations.

For Level 2, Level 3, and Level 4 assurance levels, the following stipulations apply:

3.10.1 Incident and Compromise Handling Procedures 3.10.1.1 If an IdP detects a potential hacking attempt or other form of compromise, it SHALL

perform an investigation in order to determine the nature and the degree of damage. If the assertion signing key or the CA that issued the assertion signing key is suspected of compromise, the procedures outlined in Section 3.10.3 SHALL be followed. Otherwise, the scope of potential damage SHALL be assessed in order to determine if the IdP needs to be rebuilt.

3.10.1.2 The IdP MUST notify all RPs of suspected compromise of the IdP’s system.

3.10.1.3 The IdP MAY notify all Security Principals of the suspected compromise, if deemed relevant, and in accordance with national, state, and local laws and regulations.

3.10.2 Computing Resources, Software, and/or Data are Corrupted 3.10.2.1 If IdP equipment is damaged or rendered inoperative, but the assertion signing key(s) is

not destroyed; the operation SHALL be reestablished as quickly as possible.

3.10.2.2 If IdP equipment is damaged or rendered inoperative and the assertion signing key(s) is destroyed; the operation SHALL NOT resume operation until a new assertion signing key has been issued, and distributed to the RPs.

3.10.3 Assertion Signing Key Compromise Procedures 3.10.3.1 RPs SHALL be securely notified at the earliest feasible time of the compromise.

3.10.3.2 A new assertion signing key pair SHALL be generated by the IdP in accordance with procedures set forth in the applicable COR Practice Statement.

3.10.3.3 The IdP SHALL also investigate what caused the compromise or loss, and what measures MUST be taken to preclude recurrence.

3.10.3.4 The IdP SHALL notify all Security Principals for whom the IdP issues assertions of the compromise and relevant information around when assertion issuance may be restored.

3.10.3.5 The IdP SHALL NOT resume operation until a new assertion signing key has been issued, and distributed to the RPs.



3.10.4 Business Continuity Capabilities after a Disaster 3.10.4.1 In the case of a disaster, whereby an IdP installation is physically damaged and all

copies of the assertion signing key are destroyed as a result, the IdP SHALL follow Section 3.10.3.

3.11 Termination


For Level 2, Level 3, and Level 4 assurance levels, the following stipulations apply:

3.11.1 Credential Provider Termination 3.11.1.1 The IdP MUST notify all Security Principals that the IdP will no longer accept

Credentials issued by the Credential Provider for authentication to the IdP.

3.11.1.2 The IdP SHALL notify the RPs of the change in accepted Credential Providers.

3.11.2 IdP Termination 3.11.2.1 In the event of termination of an IdP, the IdP SHALL request all assertion signing

certificates issued to it by a CA be revoked.

3.11.2.2 The IdP SHALL notify the RPs of the change in the IdP status.

3.12 Records, Transfer, and Archival Controls

This section outlines the controls required of both IdPs and Credential Providers, as specified by the requirements.

For Level 1 assurance: No stipulations.

For Level 2, Level 3, and Level 4, the following Controls apply:

3.12.1 Protection of Security Principal Data 3.12.1.1 Sensitive data, including all Personally Identifiable Information (PII) collected during the

registration stage, MUST be protected at all times by the Credential Provider (e.g., transmission and storage) in accordance with national, state, and local laws and regulations.

3.12.2 Transmission of Registration Data If the Credential Provider and the Registration Authority(s) are remotely located and communicate over a network, the following requirements apply:

3.12.2.1 Level 1: No requirements. 3.12.2.2 Level 2, Level 3, and Level 4: The entire registration transaction between the

Registration Authority and Credential Provider SHALL occur over a mutually authenticated protected channel. Credentials used to establish mutual authentication SHALL be of an assurance level that is equal to or greater than that of the Credential being managed. Equivalently, the transaction MAY consist of time stamped or sequenced messages signed by their source and encrypted for their recipient. In either case, NIST (or equivalent) approved cryptography that provides a level of assurance equal to or greater than that of the Credential being managed is required.

3.12.3 Record Retention The following Records Retention requirements MUST be met by the Credential Provider:

3.12.3.1 Level 1: No requirements. 3.12.3.2 Level 2 and Level 3: A record of the registration, history, and status of each Credential

(including revocation) SHALL be maintained by the Credential Provider or its representative.



The Credential Provider SHALL maintain a record of each individual whose identity has been verified and the steps taken to verify his or her identity, including any information collected from the applicant.

The record retention period for data is seven years and six months beyond the expiration or revocation (whichever is later) of the Credential.

The Credential Provider SHALL have the ability to provide records of identity proofing to Relying Parties if required, providing such a request is consistent with the legal regulation under which the Credential Provider operates.

3.12.3.3 Level 4: All requirements from Level 2 and 3 apply.

The minimum record retention period for Level 4 Credential data is ten years and six months beyond the expiration or revocation of the Credential.

3.12.3.4 For all assurance levels, retention policies for information SHALL be in accordance with national, state, and local laws and regulations, which MAY supersede the preceding requirements.

3.12.4 Types of Records Archived 3.12.4.1 Archive records SHALL be sufficiently detailed to establish the proper operation of the

component or the validity of any assertion issued by the IdP. At a minimum, the following MUST be archived:

• Common Operating Rules Practice Statement.

• Contractual obligations.

• All Audit Logs.

• Other data or applications to verify archive contents.

• Documentation required by compliance auditors.

3.12.5 Protection of Archive 3.12.5.1 No unauthorized user SHALL be permitted to write, modify, or delete the archive at the

IdP. Authorized users are limited to those acting in the trusted roles identified in Section 3.7.1, Trusted Roles.

3.12.6 Archive Backup Procedures 3.12.6.1 Audit logs and audit summaries SHALL be backed up at least once every 30 days by the

IdP.

3.12.7 Requirements for Time-Stamping of Records 3.12.7.1 The IdP SHALL time-stamp archive records as they are created. 3.12.7.2 All participating IdP systems MUST run time synchronization software. 3.12.7.3 All IdP systems SHALL regularly synchronize with a time service, such as the National

Institute of Standards and Technology (NIST) Atomic Clock, or NIST Network Time Protocol (NTP) Service.

3.12.8 Archive Collection System (internal or external) No stipulations.

3.12.9 Procedures to Obtain & Verify Archive Information 3.12.9.1 Procedures detailing how to create, verify, package, and transmit archive information

SHALL be published by the IdP in the applicable Common Operating Rules Practice Statement.



4 References TSCP Documentation:

TSCP Identity Federation Assertion Profile v.1.1, available at http://www.tscp.org/library/documents.

TSCP Electronic Identity Guidance v.1.0, available at http://www.tscp.org/library/documents.

UK Government References: Office of the e-Envoy, Registration and Authentication: E-Government Strategy Framework Policy and Guidelines, September 2002, Available at: http://interim.cabinetoffice.gov.uk/media/252544/assurance_v2.pdf.

OMB Publications: [OMB 04-04] OMB Memorandum M-04-04, E-Authentication Guidance for Federal agencies, December 16, 2003, available at: http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf.

NIST 800 Series Special Publications: Nist special publications available at: http://csrc.nist.gov/publications/nistpubs/index.html.

[SP 800-63] NIST Special Publication 800-63, Electronic Authentication Guideline, February 20, 2008.

[Draft SP 800-63-1] NIST Special Publication 800-63-1 (Draft 3), Electronic Authentication Guideline, June 2011.

Federal Information Processing Standards: FIPS can be found at: http://csrc.nist.gov/publications/fips/.

FIPS 46-3: Federal Information Processing Standard Publication 46-3, Data Encryption Standard (DES), NIST, October 25, 1999.

FIPS 140-2: Federal Information Processing Standard Publication 140-2, Security Requirements for Cryptographic Modules, NIST, May 25, 2001.

FIPS 180-2: Federal Information Processing Standard Publication 180-2, Secure Hash Standard (SHS), NIST, August 2002.

FIPS186-2: Federal Information Processing Standard Publication 186-2, Digital Signature Standard (DSS), NIST, June 2000.

FIPS 197: Federal Information Processing Standard Publication 197, Advanced Encryption Standard (AES), NIST, November 2001.


http://www.tscp.org/library/documents






http://interim.cabinetoffice.gov.uk/media/252544/assurance_v2.pdf

http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf

http://csrc.nist.gov/publications/nistpubs/index.html

http://csrc.nist.gov/publications/fips/


Appendix A: Requirements for Assertion of Claims in the TSCP Profile v.1.3

Two claim types in the TSCP Technical Profile are specifically bound to definitions in the TSCP Common Operating Rules: IPVLevel and the Credential (Credential Type and Credential Strength components). This section provides the formal definition, and the COR requirements they are bound to.

IPV Level

The Identity Proofing and Vetting Level attribute designates the strength of the process that has been followed to vet and proof the identity of the Security Principal. The asserting party must comply with the following sections of the COR in order to assert the urn:tscp:IPVLevel attribute:

• 3.1.1 Security Principal Identifier

• 3.1.2 Identity Provisioning Process

• 3.1.3 Identity Provisioning Application Process

• 3.1.4 Initial Identity Proofing and Vetting Requirements

• 3.1.5 Multiple Registration, Identity Proofing, and Token and Credential Encounters

• 3.1.6 Identity Association

• 3.1.7 Credential Acknowledgement

Assertion of the IPV Level requires the asserting party to be in compliance with each identified section of the COR, at the equivalent level. In cases where the asserting party is in compliance with different requirements at different levels, the lowest level has precedence.

urn:tscp:IPVLevel:1 (compliant with all policies at least to level 1)




The Identity Provider MUST always assert the highest IPV Level under which the Credential Provider can bind the Credential to the Security Principal. If the IdP is not the same organization as the Credential Provider, the IdP MUST have a mechanism to retrieve the IPV level from the Credential Provider.

Examples of proper use of proofing and vetting attribute when multiple Credentials exist:

Use Case 1:

• Credential Provider A has issued Security Principal Z two Credentials.

• When issuing Security Principal Z Credential 1, the proofing and vetting is completed at COR level 2.


In this use case, the IdP will assert a proofing and vetting level of urn:tscp:IPVLevel:2, if the Security Principal presents Credential 1, and a proofing and vetting level of urn:tscp:IPVLevel:3, if the Security Principal presents Credential 2. If both Credentials are presented, the IdP SHOULD assert the highest proofing and vetting level for the for the Security Principal, in this use case, urn:tscp:IPVLevel:3.

Use Case 2:

• Credential Provider A has issued Security Principal Z two Credentials.





• When Security Principal Z undergoes the issuance process for Credential 2, the Credential Provider verifies the Security Principal also possesses Credential 1.

In this use case, the IdP will assert a proofing and vetting level of urn:tscp:IPVLevel:3 for both Credential 1 and Credential 2, as both have been bound to COR Level 3 proofing and vetting procedures.

Credential Type

The Credential Type attribute identifies the type of Credential the security principal used to authenticate during the authentication process. When asserting these values, the IdP MUST ensure the Credential used by the security principal maps to the corresponding definitions found below:

• urn:tscp:simple_password

o A password which complies with COR Section 3.2.2.1, Password/PIN Difficulty A.

• urn:tscp:complex_password

o A password which complies with COR Section 3.2.2.1, Password/PIN Difficulty B.

• urn:tscp:oob

o An out of band token which complies with COR Section 3.2.2.1, Out of Band Token.

• urn:tscp:sf_otp

o A onetime password token which complies with COR Section 3.2.2.1, Single Factor One-Time Password.

• urn:tscp:PKI

o A PKI Credential with unknown policy OIDs, or policies OIDs which do not map to TSCP policies, or a PKI credential that does not meet the requirements for basic software or basic hardware stated below.

• urn:tscp:PKI:basicSoftware

o PKI Certificates issued under the Credential Provider’s own basic assurance policy and stored on a FIPS 140-2 Level 1 cryptographic module.

• urn:tscp:PKI:basicHardware

o PKI Certificates issued under the Credential Provider’s own basic assurance policy and stored on a FIPS 140-2 Level 2 hardware cryptographic module.

• urn:tscp:PKI:mediumSoftware

o TSCP Medium Software Certificate or PKI bridged Equivalent, as defined by the TSCP CP.

• urn:tscp:PKI:mediumHardware

o TSCP Medium Hardware Certificate or PKI bridged Equivalent, as defined by the TSCP CP.

• urn:tscp:PKI:highHardware

o TSCP High Hardware Certificate or PKI bridged Equivalent, as defined by the TSCP CP.



• urn:tscp:PKI:mediumCBPSoftware

o TSCP Medium Commercial Best Practices Software Certificate or PKI bridged Equivalent, as defined by the TSCP CP.

• urn:tscp:PKI:mediumCBPHardware

o TSCP Medium Commercial Best Practices Hardware Certificate or PKI bridged Equivalent, as defined by the TSCP CP.

• urn:tscp:PKI:highCBPHardware

o TSCP High Commercial Best Practice Hardware Certificate or PKI bridged Equivalent, as defined by the TSCP CP.

• urn:tscp:PKI:IceCAP-hardware

o TSCP IceCAP Hardware Certificate or PKI bridged Equivalent, as defined by the TSCP CP.

• urn:tscp:PKI:IceCAP-cardAuth

o TSCP IceCAP cardAuth Certificate or PKI bridged Equivalent, as defined by the TSCP CP.

Credential Strength

The Credential strength indicates the approximate level of assurance a relying party can place in the security of the token used by the Security Principal to authenticate.

Credential Strength Token Types urn:tscp:CredentialStrength:1 urn:tscp:simple_password

urn:tscp:CredentialStrength:2 urn:tscp:complex_password urn:tscp:oob urn:tscp:sf_otp PKI certificates stored on a FIPS 140-2 Level 1 validated cryptographic module. This explicitly includes:

• urn:tscp:PKI:mediumSoftware • urn:tscp:PKI:mediumCBPSoftware • urn:tscp:PKI:basicSoftware

urn:tscp:CredentialStrength:3

urn:tscp:oob combined with urn:tscp:simple_password or urn:tscp:complex_password urn:tscp:sf_otp combined with urn:tscp:simple_password or urn:tscp:complex_password

urn:tscp:CredentialStrength:4

PKI certificates stored on a FIPS 140-2 Level 2 (or above) validated hardware cryptographic module. This explicitly includes:

• urn:tscp:PKI:mediumHardware • urn:tscp:PKI:highHardware • urn:tscp:PKI:mediumCBPHardware • urn:tscp:PKI:IceCAP-hardware • urn:tscp:PKI:IceCAP-cardAuth • urn:tscp:PKI:basicHardware



Appendix B: Requirements by Entity

The following table enumerates which policies are applicable to the Credential Provider, which policies apply to the Identity Provider (IdP), and which policies apply to both.

Requirements Index 1: Credential and Identity Provider Requirements References

Requirement Entity Applied to 3.1.1.2 Credential Provider 3.1.2.1 Credential Provider 3.1.2.2 Credential Provider 3.1.2.3 Credential Provider 3.1.2.4 Credential Provider 3.1.3.1 Credential Provider 3.1.4.1 Credential Provider 3.1.4.2 Credential Provider 3.1.4.3 Credential Provider 3.1.4.4 Credential Provider 3.1.5.1 Credential Provider 3.1.5.2 Credential Provider 3.1.5.3 Credential Provider 3.1.6.1 Credential Provider 3.1.6.2 Credential Provider 3.1.6.3 Credential Provider 3.1.7.1 Credential Provider 3.1.7.2 Credential Provider 3.1.7.3 Credential Provider 3.2.1.1 Credential Provider 3.2.2.1 Credential Provider 3.3.1.1 Credential Provider 3.3.1.2 Credential Provider 3.3.1.3 Credential Provider and Identity Provider 3.3.2.1 Credential Provider and Identity Provider 3.3.2.2 Credential Provider and Identity Provider 3.3.2.3 Credential Provider and Identity Provider 3.3.3.1 Credential Provider 3.3.3.2 Credential Provider 3.3.3.3 Credential Provider 3.3.3.4 Credential Provider 3.4.1.1 Credential Provider 3.4.1.2 Credential Provider 3.4.1.3 Credential Provider 3.4.1.4 Credential Provider 3.5.1.1 Identity Provider 3.5.1.2 Identity Provider



Requirement Entity Applied to

3.5.1.3 Identity Provider 3.5.1.4 Identity Provider 3.5.1.5 Identity Provider 3.5.1.6 Identity Provider 3.5.1.7 Identity Provider 3.5.1.8 Identity Provider 3.6.1.1 Identity Provider 3.6.2.1 Identity Provider 3.6.2.2 Identity Provider 3.6.2.3 Identity Provider 3.6.3.1 Identity Provider 3.6.5.1 Identity Provider 3.6.6.1 Identity Provider 3.6.7.1 Identity Provider 3.6.7.2 Identity Provider 3.6.7.3 Identity Provider 3.6.8.1 Identity Provider 3.7.1.1 Identity Provider 3.7.1.2 Identity Provider 3.7.2.1 Identity Provider 3.7.2.2 Identity Provider 3.7.3.1 Identity Provider 3.7.4.1 Identity Provider 3.8.1.1 Identity Provider 3.8.2.1 Identity Provider 3.8.3.1 Identity Provider 3.8.3.2 Identity Provider 3.8.4.1 Identity Provider 3.8.6.1 Identity Provider 3.8.8.1 Identity Provider 3.9.1.1 Identity Provider 3.9.1.2 Identity Provider 3.9.3.1 Identity Provider 3.9.4.1 Identity Provider 3.9.4.2 Identity Provider 3.9.5.1 Identity Provider 3.9.6.1 Identity Provider 3.10.1.1 Identity Provider 3.10.1.2 Identity Provider 3.10.1.3 Identity Provider 3.10.2.1 Identity Provider



3.10.2.2 Identity Provider

Requirement Entity Applied to 3.10.3.1 Identity Provider 3.10.3.2 Identity Provider 3.10.3.3 Identity Provider 3.10.3.4 Identity Provider 3.10.3.5 Identity Provider 3.10.4.1 Identity Provider 3.11.1.1 Identity Provider 3.11.1.2 Identity Provider 3.11.2.1 Identity Provider 3.11.3.2 Identity Provider 3.12.1.1 Credential Provider 3.12.2.1 Credential Provider 3.12.2.2 Credential Provider 3.12.3.1 Credential Provider 3.12.3.2 Credential Provider 3.12.3.3 Credential Provider 3.12.3.4 Credential Provider 3.12.4.1 Identity Provider 3.12.5.1 Identity Provider 3.12.6.1 Identity Provider 3.12.7.1 Identity Provider 3.12.7.2 Identity Provider 3.12.7.3 Identity Provider 3.12.9.1 Identity Provider


Documents

Identity Federation Common Operating Rules v.1.4 Lead ...1.3 S teve Sk ordins ki S im p li fed A ppend x B, cr os rence f requi rem ents for C redential Provider and Identity Provider