Comparison of Certification Requirements
Draft
IDEF v.1 Baseline Requirement ReferenceIDEF Baseline Requirement TextColumn1Mapping -- Kantara IAF 1400 SAC Reference Number and TitleColumn2Conformance Disposition F=Full, P=Partial, NE=Not Equivalent, NCR=No Comparable Requirement, N/A=not Applicable Rationale for Partial Disposition Scope DifferenceFinal DispositionCommentsKantara CommentsFullPartialNot EquivalentNo Comparable RequirementN/A
INTEROP-1: Third-Party AuthenticationEntities MUST be capable of accepting external USERS authenticated by THIRD-PARTIES. NCR/NANCR/NAThis Baseline BR Interop 1 applies to relying parties in the IE. Kantara 1400 is applicable to IDPs, CSPs, CSMs but not RPs. Requirement is N/A for Kantara 1400 SACs.This requirement is NA for CSP entities.XX
INTEROP-2: Third-Party CredentialsEntities who issue credentials or assertions MUST issue them using content and methods that are capable of being consumed for multiple purposes and multiple recipients. CM_CPP#020 - Certificate Policy/Certification Practice StatementLOA 4: P, LOA 2,3: NCRSee underlined text. Normative reference to third party IETF standard is general and is directed toward policy statement, not requirement of third-party credentials.Kantara text references policy statement generally, while IDESG requirement is specifically about interoperable credential consumption.Needs discussion with KantaraLOA 4 credentials are PKI certificates and the technology allows the credentials to be federated across any RP. Kantara does not preclude but also does not require federation/multi-use credentials and IDM accounts at LOA 2,3. While not precluded by Kantara -- it is not enabled or required which is the express purpose og Interop-2. PKI certificates (Kantara LOA 4) are capable of multiple uses and federation, this is a result of public key technology rather than compliance to any of the Kantara SACs. ICP/CPS SAC CM_CPP#020 does not actually actually provide for interoperability/federation, as noted above, it is the technology of PKI that enabables LOA 4 to meet BR Interop-2.Does Kantara agree with the IDEF Requirement? Is the IDEF requirement too vague to satisfy the need for interoperability? For example, could it instead refer to the conformant use of open credential/assertion standards and profiles that are consumable by other interoperable entities? Look to S3A - The Specified ServiceXX
INTEROP-3: Standardized CredentialsEntities that issue credentials or assertions MUST issue them in a format that conforms to public open STANDARDS listed in the IDESG Standards Registry, or if that Registry does not include feasible options, then to non-proprietary specifications listed in the IDESG Standards Inventory. CM_CPP#020 - Certificate Policy/Certification Practice Statement CM_VAS#030 -- Assertion assurance level CM_VAS#010 -- approved cryptography CM_CSM#050 -- Inactive credentialsLOA 4: F, LOA 2,3: PKantara SACs for LOA 2,3 are intentionally technologically agnostic and do not specify any standard for credentials or AuthN protocols/specifications. Kantara LOA does not specify credential standards beyond PKI and RFC 3647. See cooments for details.Needs discussion with KantaraCM_CPP#020 requires that CP/CPS must conform to IETF RFC 3647 and RFC 3647 is based on Internet X.509 v.3 Public Key Infrastructure and certificate format. The intention of this SAC is that X.509 v.3 certificates would be generated and consumed -- these are based on standard specifications and format and would clearly meet the requirements of Interop-3 at LOA 4. Also add mapping: #010 Approved (assertion) cryptography, CM_VAS#030 Assertion assurance level both at LOA 2,3,4 and CM_VAS#100 Bind reference to assertion LOA 2,3,4. Kantata IAF is intentionally technology agnostic and does not specify conformance to any specific AuthN protocols/specifications. However, these are 3 generic SACs to enable interoperability, security and acceptance of AuthN assertions. The Kantara SAC does not refer to the IDESG Standards Registry or the IDESG Standards Inventory. This is OK and is to be expected. Is LOA2/3 CSP using an IDESG- recognized standard? X
INTEROP-4:Standardized Data Exchanges Entities that conduct digital identity management functions MUST use systems and processes to communicate and exchange identity-related data that conform to public open STANDARDS. CM_CPP#020 Certificate Policy/Certification Practice StatementLOA 4: F, LOA 2,3 :NCRSee comments for detail.Kantara covers policy statement, while IDESG covers functions, systems and processesLOA 4: F, LOA 2,3 :NCRAs indicated above, CM_CPP#020 requires conformance to RFC 3647 which is based on Internet X.509. RFC 3647 explains how extension fields are standardized for use through X.509 format. The PKI interface for X.509 certificates/registries is standardized -- this meets the BR Interop-4 requirements for LOA 4. While CM_CPP#020 van be applied to LOA 2,3, Kantara specifies that these LOA are non-PKI and the justification for LOA 4 conformance is based on RFC3647, which does not apply to LOA 2,3 non-pki. Interop-4 is primarily directed to standarization of data exchange for AuthN and AuthR transactions (assertions, credentials, attributes, etc.) Kamntara SACs are technology agnostic and allow different propocols/specifications for data interface without specifying use. The focus in the SACs is security, interoperability is not addressed in the Kantara SACs.SAC could be updated to require use of public open standardsX
INTEROP-5:Documented Processes Entities MUST employ documented business policies and processes in conducting their digital identity management functions, including internally and in transactions between entities. CO_NUI#010 General Service Definition CO_NUI#020 -- Service Definition Inclusions CO_ISM#010Documented Policies and Procedures CM_CPP#010 Credential policy and Practice Statement LOA 2,3,4 ID_POL#030 Published proofing Policy LOA 2,3,4FDisposition F for LOA 2,3,4. 1. Combination of the cited SACs demonstrates SACs intention that policies and practices associated with IDM functions covered by IAF 1400 (i.e., IDP, CSM, CM) are documented and available for the functions associated with IDP, CSP, CM, registration (these functions are the basis and scope for Kantara certifications -- this meets the BR Interop-5 requirement for F disposition. However, it is recognized that IDEF Baseline Requirements are much broader in scope and address more functions/roles than IAF 1400.X
INTEROP-6: Third-Party Compliance Entities that act as THIRD-PARTY service providers for another entity, in conducting digital identity management functions, must comply with each of the applicable IDESG Baseline Requirements that apply to that other entity and those relevant functions. CO_ESC#010 Contracted policies and procedures CO_NUI#020 -- Service Definition Inclusions CO_ISM#010 Documented Policies and Procedures CM_CPP#010 Credential policy and Practice Statement LOA 2,3,4 ID_POL#030 Published proofing Policy LOA 2,3,4FSee comments for discussion. The CO_ESC#010and #020 do not refer specifically to any of the requirements of the the BRs, and the functions covered and potentially contracted to a third-party. However the cited SACs create accountability for compliance with applicable SACs for any contracted entities -- this is the same type of requirement as BR Interop-6. This is an example of IAF 1400 and IDEF BR intending to cover to the same requirements for contracted entity compliance with applicable requirements.X
INTEROP-7: User Redress Entities MUST provide effective mechanisms for redress of complaints or problems arising from identity transactions or the, failure of the entity to comply with the IDESG Baseline Requirements. These mechanisms MUST be easy for USERS to find and access. NCRNCRThe intent of Interop-7 is that users have redress for the scope of the IDM services that they use/receive from a service provider. This type of requirement is not addressed in IAF 1400 SACs.Confirmed - there is no comparable requirement. Kantara to consider inclusion in IAF schemeX
INTEROP-8. AccountabilityEntities MUST be accountable for conformance to the IDESG Baseline Requirements, by providing mechanisms for auditing, validation, and verification. CO_ESM#040 Financial Provisions CO-ISM#020 Policy Management/Responsibility LOA 2,3,4 CO-ISM#060 LOA 2,3,4 Quality Management CO_ISM#080 Internal Service Audit CO_ISM#100 Audit Records ID_VRC#010 Verification records for Personal Applicants ID_VRC#020 Verification records for Affiliated Applicants LOA 2,3,4 ID_VRC#030 Record RetentionFIDESG requires mechanisms for auditing, Kantara requirements, taken together, provide various mechanisms. Note that IDESG does not include quantitative or qualitative test of mechanismsIDESG requirement is not specific on level of audit mechanismF disposition at LOA 2,3,4. Comment: Accountability is not just about auditing and keeping auditable records. BR Interop-8 specifically requires "mechanisms" for accountability which may be audits and audit records but may also be policies, practices, management structure, quality assurance, financial accountability etc. 1. Add following SACs that apply: CO_ESM#040 Financial Provisions LOA 2,3,4; CO-ISM#020 Policy Management/Responsibility LOA 2,3,4(note by itself this only applies to security and would be P -- however this contributes to determination of F); CO-ISM#060 LOA 2,3,4 Quality Management (same comment as ISM#020; CO_OPN#040 Personnel skills -- sufficient, trained, qualified personnel certainly is a "mechanism" for accountability; ID_VRC#010 Verification records for Personal Applicants, ID_VRC#020 Verification records for Affiliated Applicants LOA 2,3,4 and ID)_VRC#030 Record retention all 3 at LOA 2,3,4 established accountability for the ID proofing functions;X
PRIVACY-1. DATA MINIMIZATION Entities MUST limit the collection, use, transmission and storage of personal information to the minimum necessary to fulfill that transaction’s purpose and related legal requirements. Entities providing claims or attributes MUST NOT provide any more personal information than what is requested. Where feasible, IDENTITY-PROVIDERS MUST provide technical mechanisms to accommodate information requests of variable granularity, to support data minimization. CO_ESM#030 Legal & Contractual compliance CO_NUI#020 Service Definition Inclusions CO_ESM#050 Data retention and ProtectionPKantara requirements do not specify data minimization, but Kantara requirement of legal conformity would include data minimization for specific jurisdictions under FIPPs-based laws.Kantara requires compliance with laws. Where data minimization is part of law, there may be partial coverage in the requirements.Full with FICAM Privacy ProfileNone of theIAF 1400 SACs address data minimization specifically. It would be depenent upon the Kantara assessor to determine which contractual/legal requirements would need to be reviewed/audited, this may or may not include any legal data minimization laws/ruels for the jurisdiction.This requirement is fully covered by the FICAM Privacy Profile CriteriaX
PRIVACY-2. PURPOSE LIMITATION Entities MUST limit the use of personal information that is collected, used, transmitted, or stored to the specified purposes of that transaction. Persistent records of contracts, assurances, consent, or legal authority MUST be established by entities collecting, generating, using, transmitting, or storing personal information, so that the information, consistently is used in the same manner originally specified and permitted. NCRFull with FICAM Privacy ProfileThis requirement is fully covered by the FICAM Privacy Profile CriteriaX
PRIVACY-3. ATTRIBUTE MINIMIZATION Entities requesting attributes MUST evaluate the need to collect specific attributes in a transaction, as opposed to claims regarding those attributes. Wherever feasible, entities MUST collect, generate, use, transmit, and store claims about USERS rather than attributes. Wherever feasible, attributes MUST be transmitted as claims, and transmitted credentials and identities MUST be bound to claims instead of actual attribute values. NCR/NANeeds discussion with KantaraIn general, PRIV-3 is intended to apply to relying parties and transaction intermediaries that may require attribute information beyond AuthN transaction for AuthR/access. This is beyond scope of IAF 1400 SAC.This requirement is NA for CSP entities.XX
PRIVACY-4. CREDENTIAL LIMITATION Entities MUST NOT request USERS’ credentials unless necessary for the transaction and then only as appropriate to the risk associated with the transaction or to the risks to the parties associated with the transaction. NCR/NANCR/NAIn general, PRIV-3 is intended to apply to relying parties and transaction intermediaries that may require attribute information beyond AuthN transaction for AuthR/access. This is beyond scope of IAF 1400 SAC.This requirement is NA for CSP entities.XX
PRIVACY-5. DATA AGGREGATION RISK Entities MUST assess the privacy risk of aggregating personal information, in systems and processes where it is collected, generated, used, transmitted, or stored, and wherever feasible, MUST design and operate their systems and processes to minimize that risk. Entities MUST assess and limit linkages of personal information across multiple transactions without the USER's explicit consent. NCRFull with FICAM Privacy ProfileThis requirement is fully covered by the FICAM Privacy Profile CriteriaX
PRIVACY-6. USAGE NOTICEEntities MUST provide concise, meaningful, and timely communication to USERS describing how they collect, generate, use, transmit, and store personal information. CO_NUI#010 General Service Definition CO_ESMI#050 Data Retention and Protection CO_ESMI#055 Termination provisions CO_NUI#030 Due Notification CO_NUI#040 User Acceptance ID_POL#030 Published Proofing Policy PKantara notice terms, taken together, do not fulfill the requirements specified in IDESG USAGE NOTICE requirement.Specific IDESG requirements not all covered in related Kantara requirementsFull with FICAM Privacy ProfileKantara notice and service description criteria are general in nature and do not represent a PII usage notice and how PII is stored, used and transmitted as specified in PRIV-6.This requirement is fully covered by the FICAM Privacy Profile CriteriaX
PRIVACY-7. USER DATA CONTROL Entities MUST provide appropriate mechanisms to enable USERS to access, correct, and delete personal information. CO_NUI#070 Change of Subscriber Information CM_IDP#010 Revision to Subscriber informationFX
PRIVACY-8. THIRD-PARTY LIMITATIONSWherever USERS make choices regarding the treatment of their personal information, those choices MUST be communicated effectively by that entity to any THIRD-PARTIES to which it transmits the personal information. CO_ESC#010 Contracted policies and proceduresPIf USERS "choices regarding the treatment of their personal information" under IDESG requirement is considered "critical policies, procedures, and practices sub-contractors are required to fulfill" under Kantara, then this PRIV-8 may be addressed by CO_ESC #010 otherwise this requirement is not addressed.PPRIV-8 may be addressed by SAC CO_ESC#010 to the extent that there are clear contracts/agreements that among federated entities that specifically address this requirement, otherwise this is NCR. Also, the requirement for PRIV-8 includes that the CSP passess on user preferences in a controlled seucre manner. SACs are silent on this. SAC could be updated to make the specifying of downstream obligations mandatoryX
PRIVACY-9. USER NOTICE OF CHANGES Entities MUST, upon any material changes to a service or process that affects the prior or ongoing collection, generation, use, transmission, or storage of USERS’ personal information, notify those USERS, and provide them with compensating controls designed to mitigate privacy risks that may arise from those changes, which may include seeking express affirmative consent of USERS in accordance with relevant law or regulation. CO_NUI#030 Due notificationPRequirements are generally equivalent, but note that Kantara requirement doesn't include compensating controls, but instead anticipates binary decision of "accept or terminate."Full with FICAM Privacy ProfileThis requirement is fully covered by the FICAM Privacy Profile CriteriaX
PRIVACY-10. USER OPTION TO DECLINE USERS MUST have the opportunity to decline registration; decline credential provisioning; decline the presentation of their credentials; and decline release of their attributes or claims. NCRFull with FICAM Privacy ProfileThis requirement is fully covered by the FICAM Privacy Profile CriteriaX
PRIVACY-11. OPTIONAL INFORMATION Entities MUST clearly indicate to USERS what personal information is mandatory and what information is optional prior to the transaction. NCRFull with FICAM Privacy ProfileThis requirement is fully covered by the FICAM Privacy Profile CriteriaX
PRIVACY-12. ANONYMITYWherever feasible, entities MUST utilize identity systems and processes that enable transactions that are anonymous, anonymous with validated attributes, pseudonymous, or where appropriate, uniquely identified. Where applicable to such transactions, entities employing service providers or intermediaries MUST mitigate the risk of those THIRD-PARTIES collecting USER personal information. Organizations MUST request individuals’ credentials only when necessary for the transaction and then only as appropriate to the risk associated with the transaction or only as appropriate to the risks to the parties associated with the transaction. CM_VAS#040 No pseudonyms ID_POL#010 Unique service identity ID_POL#020 Unique service identity CM_CRN#090 Nature of SubjectNEKantara requirement appears to be contrary to IDESG requirementPartial with FICAM Privacy ProfileKantara CM_VAS#040 does not necessarily contradict PRIVACY-12. Certain architectures can be conformant with CM_VAS#040 and also meet the requirement. At most, suggest that guidance text could be added to SAC.X
PRIVACY-13. CONTROLS PROPORTIONATE TO RISK Controls on the processing or use of USERS' personal information MUST be commensurate with the degree of risk of that processing or use. A privacy risk analysis MUST be conducted by entities who conduct digital identity management functions, to establish what risks those functions pose to USERS' privacy. CO_ISM#030 Risk ManagementPIDESG specifies privacy risk analysis, while Kantara requirement applies more generally to security risks.Partial with FICAM Privacy ProfilePRIV-13 requires risk assessment for privacy controls. SAC CO-ISM#030 addresses risk assessment for security controls. These are different purposes and while there is not assurance that risk assessment under cited SAC would address privacy risks.Confirmed - there is no comparable requirement. Kantara to consider inclusion in IAF schemeX
PRIVACY-14. DATA RETENTION AND DISPOSAL Entities MUST limit the retention of personal information to the time necessary for providing and administering the functions and services to USERS for which the information was collected, except as otherwise required by law or regulation. When no longer needed, personal information MUST be securely disposed of in a manner aligning with appropriate industry standards and/or legal requirements. CO_ESM#050 Data Retention and Protection CO_ESM#055 Termination provisionsPKantara requirement applies "legal" limit on retention as ceiling, IDESG sets legal limit on retention as floor. Kantara does not require entity to limit retention to time necessary for providing function, as does IDESG (except where that text is part of FIPPs-based law).Full with FICAM Privacy ProfileThis requirement is fully covered by the FICAM Privacy Profile CriteriaX
PRIVACY-15. ATTRIBUTE SEGREGATION Wherever feasible, identifier data MUST be segregated from attribute data. ---- NEEDS FIXING with more detail in the body of the requirementCM_CRN#090 Nature of SubjectNEKantara requirement suggests linking attributes and identifiersNeeds discussion with KantaraClarification from IDESG is required - does the IDEF requirement apply to all instances of data segregation or just within a transaction? Where is the Supplemental Information?X
SECURE-1. SECURITY PRACTICESEntities MUST apply appropriate and industry-accepted information security STANDARDS, guidelines, and practices to the systems that support their identity functions and services. CO_ISM#010 Documented policies and procedures CO_ISM#120 Best Practice Security Management CO_OPN#010 Technical securityFX
SECURE-2. DATA INTEGRITYEntities MUST implement industry-accepted practices to protect the confidentiality and integrity of identity data—including authentication data and attribute values—during the execution of all digital identity management functions, and across the entire data lifecycle (collection through destruction). CO_ESM#050 Data Retention and Protection CO_ESM#055 Termination provisions CM_ASS#010 Validation and Assertion Security CM_ASS#015 No False AuthenticationFKantara is based on "legal and regulatory requirements" while IDESG is based on "industry-accepted practices." Otherwise they requirements are roughly equivalent.X
SECURE-3. CREDENTIAL REPRODUCTION Entities that issue or manage credentials and tokens MUST implement industry-accepted processes to protect against their unauthorized disclosure and reproduction. CO_SCO#010 Secure remote communications CM_CTR#020 Protocol threat risk assessment and controls CM_CTR#040 Specified Service's Key Management CM_VAS#060 No assertion manufacture/modification CM_VAS#070 Assertion protectionsFIf listed Kantara requirements, taken together, reflect "industry-accepted processes" then provisions maybe equivalentX
SECURE-4. CREDENTIAL PROTECTIONEntities that issue or manage credentials and tokens MUST implement industry-accepted data integrity practices to enable individuals and other entities to verify the source of credential and token data. CO_SCO#010 Secure remote communications CM_CTR#020 Protocol threat risk assessment and controls CM_CTR#030 System Threat Risk Assessment & Controls CM_CTR#040 Specified Service's Key ManagementFIf listed Kantara requirements, taken together, reflect "industry-accepted data integrity practices" then provisions maybe equivalentX
SECURE-5. CREDENTIAL ISSUANCEEntities that issue or manage credentials and tokens MUST do so in a manner designed to assure that they are granted to the appropriate and intended USER(s) only. Where registration and credential issuance are executed by separate entities, procedures for ensuring accurate exchange of registration and issuance information that are commensurate with the stated assurance level MUST be included in business agreements and operating policies. CO_ESC#010 Contracted policies and procedures CO_SCO#010 Secure remote communications CM_CTR#020 Protocol threat risk assessment and controls CM_CTR#030 System Threat Risk Assessment & Controls ID_IPV#010 Required evidence ID_IPV#030 Evidence checks – primary ID ID_IPV#040 Evidence checks – secondary ID ID_IPV#050 Applicant knowledge checks ID_AFV#010 Required evidence ID_AFV#020 Evidence checks ID_IDC#010 Authenticate Original Credential ID_IDC#020 Record Original Credential ID_IDC#030 Issue Derived Credential ID_SCV#010 Secondary checks CM_CRN#010 Authenticated Request CM_CRN#020 Unique identity CM_CRN#030 Credential uniqueness CM_CRD#015 Confirm Applicant’s identity (in person)FX
SECURE-6. CREDENTIAL UNIQUENESSEntities that issue or manage credentials MUST ensure that each account to credential pairing is uniquely identifiable within its namespace for authentication purposes. CM_CTR#040 Specified Service's Key Management ID_POL#010 Unique service identity ID_POL#020 Unique Subject identity ID_IDC#010 Authenticate Original Credential ID_IDC#020 Record Original Credential ID_IDC#030 Issue Derived Credential CM_CRN#030 Credential uniquenessFKantara requirements, taken together, appear directed at ensuring that unique account-to-credential pairing is maintainedX
SECURE-7. TOKEN CONTROLEntities that authenticate a USER MUST employ industry-accepted secure authentication protocols to demonstrate the USER's control of a valid token. CO_SCO#020 Limited access to shared secrets ID_IDC#010 Authenticate Original Credential CM_CRD#010 Notify Subject of Credential Issuance CM_CRD#015 Confirm Applicant’s identity (in person) CM_CRD#020 Confirm Applicant’s identity (in person) CM_ASS#018 Ensure token validity CM_ASS#030 Proof of PossessionFThe requirements are equivalent to the extent that the Kantara requirements, taken together, constitute "industry-accepted protocolsX
SECURE-8. MULTIFACTOR AUTHENTICATION Entities that authenticate a USER MUST offer authentication mechanisms which augment or are alternatives to a password. ID_IPV#010 Required evidence ID_IPV#030 Evidence checks – primary ID ID_IPV#040 Evidence checks – secondary ID ID_IPV#050 Applicant knowledge checks ID_AFV#010 Required evidence ID_AFV#020 Evidence checks CM_AGC#010 Entropy level CM_MFA#010 Permitted multi-factor tokensFKantara IPV covers initial "proofing" rather than later "authentication" stepX
SECURE-9. AUTHENTICATION RIST ASSESSMENTEntities MUST have a risk assessment process in place for the selection of authentication mechanisms and supporting processes. CO_ISM#030 Risk ManagementFKantara risk management provision is general, while IDESG requirement is specific to authentication mechanismsX
SECURE-10. UPTIME Entities that provide and conduct digital identity management functions MUST have established policies and processes in place to maintain their stated assurances for availability of their services. CO_ISM#040 Continuity of Operations PlanFKantara requirement is specific to disaster recovery, while IDESG requirement is more generally applicable to service availability (covering other outages due to maintenance, upgrades, etc.)x
SECURE-11. KEY MANAGEMENT Entities that use cryptographic solutions as part of identity management MUST implement key management policies and processes that are consistent with industry-accepted practices. CO_SCO#010 Secure remote communications CM_CTR#040 Specified Service's Key Management CM_STS#020 Stored Secret Encryption CM_SKP#010 Key generation by Specified Service CM_SKP#020 Key generation by SubjectFEquivalence is increased to the extent that the listed Kantara requirements, taken together, are considered "industry-accepted practices"x
SECURE-12. RECOVERY AND ISSUANCEEntities that issue credentials and tokens MUST implement methods for reissuance, updating, and recovery of credentials and tokens that preserve the security and assurance of the original registration and credentialing operations. ID_IDC#010 Authenticate Original Credential CM_RNR#010 Changeable PIN/Password CM_RNR#020 Proof-of-possession on Renewal/Re-issuance CM_RNR#030 Renewal/Re-issuance limitations CM_RNR#040 Authentication key life CM_RNR#050 Record Retention CM_RKY#010 Verify Requestor as Subscriber CM_RKY#020 Re-key requests other than Subject CM_SRR#010 Submit RequestFThe listed Kantara requirements, taken together, appear directed to preserving security of original registration and credentialing.x
SECURE-13. REVOCATIONEntities that issue credentials or tokens MUST have processes and procedures in place to invalidate credentials and tokens. CM_RVP#010 Revocation procedures CM_RVP#020 Secure status notification CM_RVP#030 Revocation publication CM_RVP#040 Verify Revocation Identity CM_RVP#050 Revocation Records CM_RVP#060 Record Retention CM_RVR#010 Verify revocation identity CM_RVR#020 Revocation reason CM_RVR#030 Verify Subscriber as Revocant CM_RVR#040 Verify CSP as Revocant CM_RVR#050 Verify Legal Representative as Revocant CM_SRR#010 Submit Request CM_ASS#020 Post AuthenticationFThe listed Kantara requirements appear directed toward establishing processes and procedures to invalidate credentials and tokensx
SECURE-14. SECURITY LOGSEntities conducting digital identity management functions MUST log their transactions and security events, in a manner that supports system audits and, where necessary, security investigations and regulatory requirements. Timestamp synchronization and detail of logs MUST be appropriate to the level of risk associated with the environment and transactions. CO_NUI#050 Record of User Acceptance CO_SER#010 Security Event Logging CM_SER#010 Security event logs ID_VRC#020 Verification Records for Affiliated Applicants ID_VRC#030 Record Retention CM_CSM#010 Maintain Status RecordFThe listed Kantara requirements appear directed toward establishing logs of transactions to support security audits, etc.x
SECURE-15. SECURITY AUDITSEntities MUST conduct regular audits of their compliance with their own information security policies and procedures, and any additional requirements of law, including a review of their logs, incident reports and credential loss occurrences, and MUST periodically review the effectiveness of their policies and procedures in light of that data. CO_ISM#060 Quality Management CO_ISM#080 Internal Service AuditFx
USABLE-1. USABILITY PRACTICESEntities conducting digital identity management functions MUST apply user-centric design, and industry- accepted appropriate usability guidelines and practices, to the communications, interfaces, policies, data transactions, and end-to-end processes they offer, and remediate significant defects identified by their usability assessment. NCRNCRConfirmed - there is no comparable requirement. Kantara to consider inclusion in IAF schemex
USABLE-2. USABILITY ASSESSMENT Entities MUST assess the usability of the communications, interfaces, policies, data transactions, and end-to- end processes they conduct in digital identity management functions. NCRNCRConfirmed - there is no comparable requirement. Kantara to consider inclusion in IAF schemex
USABLE-3. PLAIN LANGUAGE Information presented to USERS in digital identity management functions MUST be in plain language that is clear and easy for a general audience or the transaction's identified target audience to understand. CO_NUI#010 General Service Definition CO_NUI#030 Due notificationNCRKantara requirements don't specify "plain language that is clear and easy . . . To understand," but reference "intended user community" and "appropriate" policy" and "reliable fashion."NCRConfirmed - there is no comparable requirement. Kantara to consider inclusion in IAF schemex
USABLE-4. NAVIGATIONAll choices, pathways, interfaces, and offerings provided to USERS in digital identity management functions MUST be clearly identifiable by the USER. NCRNCRConfirmed - there is no comparable requirement. Kantara to consider inclusion in IAF schemex
USABLE-5. ACCESSIBILITY All digital identity management functions MUST make reasonable accommodations to be accessible to as many USERS as is feasible, and MUST comply with all applicable laws and regulations on accessibility. CO_ESM#030 Legal & Contractual complianceNCRKantara requirements may be equivalent where accessibility is required by law.NCRConfirmed - there is no comparable requirement. Kantara to consider inclusion in IAF schemex
USABLE-6. USABILITY FEEDBACKAll communications, interfaces, policies, data transactions, and end-to-end processes provided in digital identity management functions MUST offer a mechanism to easily collect USERS' feedback on usability. NCRNCRConfirmed - there is no comparable requirement. Kantara to consider inclusion in IAF schemex
USABLE-7. Wherever public open STANDARDS or legal requirements exist for collecting user requests, entities conducting digital identity management functions MUST offer structured opportunities for USERS to document and express these requests, early in their interactions with those functions. Entities MUST provide a response to those user requests on a reasonably timely basis. CO_ESM#030 Legal & Contractual complianceNCRKantara requirements may be equivalent where "user requests" are regulated by law.NCRConfirmed - there is no comparable requirement. Kantara to consider inclusion in IAF schemex