|Functional Area||Criteria||Description||Needed for Bronze||Needed for Silver||Institution Meets||Notes||Supporting Doc Link||Link 2|
|4.2.1 Business, Policy and Operational Criteria||.1 InCommon Participant.||The IdPO must be an InCommon Participant in good standing in order to be considered for certification under this IAP. In this context, “good standing” means not in arrears with respect to financial obligations to InCommon nor out of compliance with other contractual obligations to InCommon.||✓||✓|
|.2 Notification to InCommon||The IdP Operator must notify InCommon of any circumstance that may affect the status of its compliance with this IAP. 1. The IdP Operator must notify InCommon of any significant changes to |
its operation that may affect the status of its compliance and hence its qualification under this IAP. Notification should occur no less than 30 days before the changes are to be made effective, or as soon as practicable after an unanticipated change is noted. 2. The IdPO must report to InCommon any breach of security or integrity of its IdMS Operations that may affect the status of its compliance and hence its qualification under this IAP. A report must be made as soon as practicable after any such incident is noted.
|.3 Continuing Compliance||After initial certification by InCommon, IdP Operators must declare to InCommon continued compliance with profiles under this IAP at least every 3 years.||✓||✓|
|.4 IdPO Risk Management||The IdPO's Information Technology operations must align with the organization’s risk management objectives as demonstrated by a periodic review process or other equivalent control.||✓||✓|
|4.2.2 Registration and Identity Proofing||.1 RA Authentication||Each RA must authenticate to the IdMS using a credential that meets or exceeds Silver requirements. Communications between an RA and the IdMS shall be encrypted using an |
Approved Algorithm that also authenticates the IdMS platform.
|.2 Identity Verification Process|| 1. The identity proofing and registration process shall be performed according to|
written policy or practice statements that specify the particular steps taken by IdPO
staff or systems to verify identities.
2. The above statement(s) shall address the primary objectives of registration and
identity proofing, including:
Ensuring a person with the claimed identity information does exist, and that the
identity information is sufficient to uniquely identify a single person within the
IdPO’s range of foreseeable potential Subjects;
Ensuring that the physical person requesting registration is entitled to the claimed
|.3 Registration Records||1. A record of the facts of registration shall be maintained by the IdPO. 2. The record of the facts of registration shall include:|
Identity proofing document types and issuers;
Full name as shown on the documents;
Date of birth;
Current Address of Record.
3. Records also must include revocation or termination of registration.
4. Registration records must be retained for 7.5 years beyond the expiration of any
credential issued to the Subject by the IdPO.
|.4 Identity Proofing||Prior to this process, the Subject supplies his or her full name, date of birth, and an|
Address of Record to be used for communication with the Subject, and may, subject to
the policy of the IdPO, also supply other identifying information. For each Subject, the
full name, date of birth and Address of Record must be verified using one or more of
the following methods:
|.4.1 Existing Relationship|| If the IdPO is a function of an enterprise, the identity proofing process may be able|
to leverage a pre-existing relationship, e.g., the Subject is an employee or student.
Where some or all of the identity proofing done at the time the existing relationship
was established is comparable to that required in §22.214.171.124.2 or §126.96.36.199.3 below,
those results may be relied upon for this purpose. The IdPO’s Registration
Authority (RA) shall confirm that the Subject is a person with a current relationship
to the organization, record the nature of that relationship and verify that the
relationship is in good standing with the organization.
|.4.2 In-person Proofing||1. The RA shall establish the Subject’s IdMS registration identity based on|
possession of a valid current government photo ID that contains the Subject’s
picture (e.g., driver’s license or passport), and either an address or nationality.
2. The RA inspects the photo ID and compares the image to the physical Subject.
The RA records the document type and issuer, the address given on the ID if
there is one, and the date of birth shown on the ID if there is one. If the ID
appears valid, the photo matches the physical Subject, and the ID confirms the
Subject’s date of birth, the RA authorizes issuance of Credentials.
3. If the address given on the ID does not confirm the Address of Record, the
Address of Record must be confirmed as described in §188.8.131.52 below.
|.4.3 Remote Proofing|
1. The RA shall establish the Subject’s IdMS registration identity based on
possession of at least one valid government ID number (e.g., a driver’s license or
passport) and either a second government ID number or financial account
number (e.g., checking account, savings account, loan or credit card) with
confirmation via records of either number.
2. The RA verifies other information provided by the Subject using both of the ID
numbers above through record checks either with the applicable agency or
institution or through credit bureaus or similar databases, and confirms that:
name, date of birth, and other personal information in records are on balance
consistent with the application and sufficient to identify a unique individual. If
this appears to be the case, the RA authorizes issuance of Credentials.
3. If the record checks do not confirm the Address of Record, it must be confirmed
as described in §184.108.40.206 below.
|.5 Address of Record Confirmation|
The Address of Record must be confirmed before the Subject’s record can be
considered to meet the requirements of this IAP. If the Address of Record was not
confirmed as part of Identity proofing, then it must be accomplished by one of the
1. The RA contacts the Subject at the Address of Record and receives a reply from the
2. The RA issues Credentials in a manner that confirms the Address of Record supplied
by the Subject.
For a physical Address of Record, the RA requires the Subject to enter online
a temporary Secret from a notice mailed to the Subject’s Address of Record.
For an electronic Address of Record, the RA confirms the ability of the Subject
to receive telephone communications at a telephone number or e-mail at an
Any Secret not sent over a Protected Channel shall be invalidated upon first use.
|.6 Protection of Personally Identifiable Information||Any personally identifiable information collected during registration or identity proofing must be protected from unauthorized disclosure or modification.||✓||✓|
|4.2.3 Credential Technology||.1 Credential Unique Identifier|
1. Each Credential issued by the IdPO shall include a unique identifier (e.g., userID,
Distinguished Name, serial number) that distinguishes it from all other Credentials in
use by the IdPO.
2. A Subject can have more than one Credential unique identifier, but a given
Credential unique identifier must map to at most one Subject.
3. The IdPO shall clearly associate the Credential unique identifier to the Subject’s
registration record in the IdMS, for use by the Verifier or other parties.
|.2 Basic Resistance to Guessing Authentication Secret|| The Authentication Secret and the controls used to limit online guessing attacks shall|
ensure that an attack targeted against a given Subject’s Authentication Secret shall have
a probability of success of less than 2-10 (1 chance in 1,024) over the life of the
Authentication Secret. This requires that an Authentication Secret be of sufficient
complexity and, in most cases, that the number of invalid attempts to enter an
Authentication Secret for a Subject be limited.
Refer to NIST Special Publication 800-63-1 [SP 800-63], Appendix A, for a discussion
of Authentication Secret complexity and resistance to online guessing.
|.3 Strong resistance to Guessing Authentication Secret|
1. The Authentication Secret and the controls used to limit online guessing attacks shall
ensure that an attack targeted against a given Subject’s Authentication Secret shall
have a probability of success of less than 2-14 (1 chance in 16,384) over the life of
the Authentication Secret. This requires that an Authentication Secret be of
sufficient complexity and that the number of invalid attempts to enter an
Authentication Secret for a Subject be limited.
2. The Authentication Secret shall have at least 10 bits of min-entropy to protect against
an untargeted attack.
Refer to NIST Special Publication 800-63-1 [SP 800-63], Appendix A, for a discussion
of Authentication Secret complexity and resistance to online guessing and how to
|.4 Stored Authentication Secrets|| |
Authentication Secrets shall not be stored as plaintext. Access to encrypted stored
Secrets and to decrypted copies shall be protected by discretionary access controls that
limit access to administrators and applications that require access.
Three alternative methods may be used to protect the stored Secret:
Authentication Secrets may be concatenated to a variable salt (variable across a
group of Authentication Secrets that are stored together) and then hashed with an
Approved Algorithm so that the computations used to conduct a dictionary or
exhaustion attack on a stolen Authentication Secret file are not useful to attack other
similar Authentication Secret files. The hashed Authentication Secrets are then
stored in the Authentication Secret file. The variable salt may be composed using a
global salt (common to a group of Authentication Secrets) and the userID (unique
per Authentication Secret) or some other technique to ensure uniqueness of the salt
within the group of Authentication Secrets; or
Store Secrets in encrypted form using Approved Algorithms and decrypt the needed
Secret only when immediately required for authentication; or
Any method protecting stored Secrets at NIST [SP 800-63] Level 3 or 4 may be
|.5 Basic Protection of Authentication Secrets|
Authentication Secrets shall not be stored as plaintext. Access to stored Secrets and
to plaintext copies shall be protected by discretionary access controls that limit
access to administrators and applications that require access.
Plaintext passwords or Secrets shall not be transmitted across a network.
|.6 Strong Protection of Authentication Secrets|| Any Credential Store containing Authentication Secrets used by the IdP (or the IdP’s|
Verifier) is subject to the operational constraints in §220.127.116.11 and §4.2.8 (that is, the
same constraints as IdMS Operations). When Authentication Secrets are sent from
one Credential Store to another Credential Store (for example in an account
provisioning operation) Protected Channels must be used.
Whenever Authentication Secrets used by the IdP (or the IdP’s Verifier) are sent
between services for verification purposes (for example, an IdP to a Verifier, or
some non-IdP application to a Verifier), Protected Channels should be used, but
Protected Channels without client authentication may be used.
If Authentication Secrets used by the IdP (or the IdP’s Verifier) are exposed in a
transient fashion to non-IdP applications (for example, when users sign on to those
applications using these Credentials), the IdPO must have appropriate policies and
procedures in place to minimize risk from this exposure.
|4.2.4 Credential Issuance and Management||.1 Credential Issuance|| To ensure that the same Subject acts throughout the registration and Credential issuance|
process, the Subject shall identify himself or herself in any new transaction (beyond the
first transaction or encounter) with information known only to the Subject, for example
a temporary Secret which was established during a prior transaction or encounter, or
sent to the Subject’s Address of Record. When identifying himself or herself in person,
the Subject shall do so either by using a Secret as described above, or through the use
of an equivalent process that was established during a prior encounter.
|.2 Credential Revocation or Expiration|
1. The IdPO shall revoke Credentials within 72 hours after being notified that a
Credential is no longer valid or is compromised.
2. If the IdPO issues Credentials that expire automatically within 72 hours or less then
the IdPO is not required to provide an explicit mechanism to revoke the Credentials.
|.3 Credential Renewal or Re-issuance|
A Subject must be authenticated for purpose of Credential renewal or re-issuance by
any of the following methods:
1. By use of a non-expired and valid Credential.
2. By use of a single-use secret delivered to the Subject from the IdPO by means of a
pre-registered out of band delivery mechanism.
3. The Subject may supply correct answers to pre-registered personalized questions
designed to be difficult for any other person to know.
After expiration of the current Credential, if none of these methods is successful then
the Subject must re-establish her or his identity with the IdPO per Section 4.2.2 before
the Credential may be renewed or re-issued.
Authentication Secrets shall not be recovered; new Authentication Secrets shall be
|.4 Credential Issuance Records Retention|| The IdPO shall maintain a record of the unique identifier and time of issuance or|
revocation of each Credential issued or revoked for a minimum of 7.5 years beyond the
expiration of the Credential.
|.5 Resist Token Issuance Tampering Threat|| The process or processes used by the IdPO in 18.104.22.168, 22.214.171.124, and 126.96.36.199 must enable|
the Subject to verify that the IdPO is the source of any token or Credential data they
|4.2.5 Authentication Process||.1 Resist Replay Attack|| The authentication process must ensure that it is impractical to achieve successful authentication by recording and replaying a previous authentication message.||✓||✓|
|.2 Resist Eavesdropper Attack|| The authentication protocol must resist an eavesdropper attack. Any eavesdropper who|
records all the messages passing between a Subject and a Verifier or relying party must
find that it is impractical to learn the Authentication Secret or to otherwise obtain
information that would allow the eavesdropper to impersonate the Subject.
|.3 Secure Communication||Communication between Subject and IdP must use a Protected Channel.||✓||✓|
|.4 Proof of Possession||The authentication process shall prove the Subject has possession of the Authentication Secret or Token.||✓||✓|
|.5 Resist Session Hijacking Threat|| Session maintenance methods implemented by the IdP shall resist session hijacking. ||✓||✓|
|.6 Mitigate Risk of Credential Compromise||The IdPO must have policies, practices, or guidelines in place that prohibit Subjects|
from sharing their Credentials and mitigate risks of a Subject's Credential being
acquired by someone else through other means. Subjects must be informed of these
policies, practices or guidelines and educated about the importance of keeping their
|4.2.6 Identity Information Management||.1 Identity Record Qualification|| If Subject records in an IdMS do not all meet the same set(s) of IAP criteria, then the|
IdP must have a reliable mechanism for determining which IAQ(s), if any, are
associated with each record.
|4.2.7 Assertion Content||.1 Identity Attributes|
The actual meaning of any attribute values identified as attributes recommended for use
by InCommon Participants should be consistent with definitions in the InCommon
Attribute Summary [InC-AtSum].
|.2 Identity Assertion Qualifier|| An IdPO may be certified by InCommon to be eligible to include one or more|
InCommon IAQs as part of Assertions. The IdP must not include an InCommon IAQ
that it has not been certified by InCommon to assert and must not include an IAQ if
that Assertion does not meet the criteria for that IAP. The IdP must be capable of
including an InCommon IAQ when the necessary criteria are met for the Subject.
|.3 Cryptographic Security|| Cryptographic operations are required between an IdP and any SP. Cryptographic operations shall use Approved Algorithms.|
The Assertion must be either:
Digitally signed by the IdP; or
Obtained by the SP directly from the trusted entity (e.g., the IdP or Attribute
Service) using a Protected Channel.
|4.2.8 Technical Environment||.1 Software Maintenance||IdMS Operations shall use up-to-date supported software.||✓|
|.2 Network Security|| Appropriate measures shall be used to protect the confidentiality and integrity of|
network communications supporting IdMS operations. Protected Channels should
be used for communications between systems.
All personnel with login access to IdMS Operations infrastructure elements must use
access Credentials at least as strong as the strongest Credential issued by the IdPO.
|.3 Physical Security|| IdMS Operations shall employ physical access control mechanisms to restrict access to|
sensitive areas, including areas such as leased space in remote data centers, to
|.4 Reliable Operations||IdMS Operations shall employ techniques to minimize system failures and ensure that any failures are not likely to result in inaccurate Assertions being sent to SPs.||✓|