SECURE-1. SECURITY PRACTICES

Entities MUST apply appropriate and industry-accepted information security STANDARDS, guidelines, and practices to the systems that support their identity functions and services.

SUPPLEMENTAL GUIDANCE

Entities may satisfy this Requirement by confirming that they (a) have considered existing information security standards, guidelines and practices relevant to their environment; (b) have identified the specific sources of guidance that are appropriate for their operations, in light of the information security risks they face; and (c) have implemented the portions of that guidance they deemed appropriate.

This Requirement does not mandate which information security policies, procedures or technologies an entity should or must use. However, some specific policies and technologies are the subject of other, more specific items elsewhere in this Requirements set.

Entities must have risk-based countermeasures and safeguards in place to resist common threats to identity solutions and identity data, including, for example, Session hijacking; Eavesdropping; Theft; Man-in-the-middle; Online Guessing; Replay; Unauthorized copying or duplication; and Insider Threats.

The security standards, guidelines, and practices employed in digital identity management services, to govern the security of their networks, devices, solutions, and systems, MUST be both operational and well documented. Please note the applicability of Requirement INTEROP-5 (DOCUMENTED PROCESSES) regarding documentation and best practice INTEROP-BP-G (RECOMMENDED LEGAL COMPLIANCE) regarding limitations imposed by laws. Please note the applicability of best practice INTEROP-BP-F (RECOMMENDED FEDERATION COMPLIANCE) and Requirement INTEROP-6 (THIRD-PARTY COMPLIANCE) regarding limitations arising from the involvement of THIRD-PARTIES such as intermediaries, similar service providers, or FEDERATIONS.

REFERENCES

Potential candidates for adoption include: ISO/IEC 27000 series, PCI-DSS, NIST SP 800-53-4, CSA CCM, COBIT v5, FFIEC (multiple documents), PCI-DSS, NISTIR 7621 R1 (draft)

APPLIES TO ACTIVITIES

REGISTRATION, CREDENTIALING, AUTHENTICATION, AUTHORIZATION, TRANSACTION, INTERMEDIATION

KEYWORDS

POLICIES, RISK, SECURITY, OPEN-STANDARDS

SECURE-2. DATA INTEGRITY

Entities 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).

SUPPLEMENTAL GUIDANCE

The execution of all identity transactions and functions must make use of transport that offers confidentiality and integrity protection (e.g., properly configured TLS)..

Where operations and functions are executed by separate organizations, secure transport mechanisms and business processes must be used to preserve the confidentiality and integrity of identity data being transmitted to and stored by service providers.

Authentication data (e.g., passwords and passphrases) must be properly protected through industry accepted cryptographic techniques (e.g., salted and hashed).

Sensitive data collected during identity transactions must be protected at all times using industry accepted practices for encryption and data protection.

Appropriate access control measures must be in place to ensure access to identity data is restricted to only authorized users with a need to know. Appropriate access control measures including multifactor authentication must be in place to ensure that access to identity data by data custodians is restricted to users responsible for administering and maintaining the data. See SECURE-8 (MULTIFACTOR AUTHENTICATION). All access to identity data must be securely logged and separation of duties SHOULD be a considered as a means to further limit access. See SECURE-14 (SECURITY LOGS).

Please note, the IDESG Privacy Requirements (PRIVACY-1 through PRIVACY-15) also impose separate requirements on the handling and storage of identifiers attributes and credentials.

REFERENCES

FICAM TFPAP Trust Criteria, LOA 1-3, Multiple Sections, PCI-DSS (actually Requirement 7 & 8 – pages 61-72), ISO 27002 (2005) Sec. 11, FFIEC, Wholesale Payment System Booklet (http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_WholesalePaymentSystems.pdf)

APPLIES TO ACTIVITIES

REGISTRATION, CREDENTIALING, AUTHENTICATION, AUTHORIZATION, TRANSACTION INTERMEDIATION

KEYWORDS

ATTRIBUTE, DATA-INTEGRITY, SECURITY

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.

SUPPLEMENTAL GUIDANCE

Potential controls that can be put in place to prevent unauthorized disclosure and reproduction include: The use of secure transport for credential and token data (see SECURE-2 (DATA INTEGRITY)); Implementation of industry accepted cryptographic techniques for the storage of credential and token data(see SECURE-2 (DATA INTEGRITY)); Implementation of industry accepted key management and protection techniques (see SECURE-11 (KEY MANAGEMENT); Out-of-band distribution of credentials or tokens; In-person issuance of credentials or tokens; and Anti-tampering and/or counterfeiting mechanism for tokens with a physical instantiation.

REFERENCES

FICAM TFPAP Trust Criteria, Registration and Issuance, LOA 2-3, #3 (p.21, 37)

APPLIES TO ACTIVITIES

CREDENTIALING

KEYWORDS

CREDENTIAL, DUPLICATION, DATA-INTEGRITY, PROCESS, SECURITY, TOKEN

SECURE-4. CREDENTIAL PROTECTION

Entities 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.

SUPPLEMENTAL GUIDANCE

When providing token and credential information to users, steps must be taken to allow users to authenticate the source of the information. This can include digital signing of credential information, providing secure transport mechanisms for the information (e.g., properly configured TLS), or delivering the information out of band (e.g., traditional mail or SMS).

REFERENCES

FICAM TFPAP Trust Criteria, Registration and Issuance, LOA 2-3, #4 (p.21, 37)

APPLIES TO ACTIVITIES

CREDENTIALING

KEYWORDS

CREDENTIAL, DATA-INTEGRITY, SECURITY, TOKEN

SECURE-5. CREDENTIAL ISSUANCE

Entities 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.

SUPPLEMENTAL GUIDANCE

Procedures exist to ensure the user(s) who receives the credential and associated tokens is the same user(s) who participated in registration. These can include: The use of secure transport for credential and token data (see SECURE-2 (DATA INTEGRITY)); Out-of-band distribution of credentials or tokens; In-person issuance of credentials or tokens.

Attribute verification (i.e., identity proofing) done during registration must be robust enough to provide sufficient confidence in the identity to support the intended use(s) of the credential. Subsequent attribute verification (i.e., proofing) must be executed in a manner consistent with intended use of the attributes.

REFERENCES

FICAM TFPAP Trust Criteria, Registration and Issuance, LOA 2-3, #4 (p.21, 37)

APPLIES TO ACTIVITIES

CREDENTIALING

KEYWORDS

CREDENTIAL, DATA-INTEGRITY, PROCESS, PROVISIONING, SECURITY, TOKEN

SECURE-6. CREDENTIAL UNIQUENESS

Entities that issue or manage credentials MUST ensure that each account to credential pairing is uniquely identifiable within its namespace for authentication purposes.

SUPPLEMENTAL GUIDANCE

A unique identifier must be assigned to each pairing of associated account and credential. This is to be used for the purposes of binding registration information with credentials in order to facilitate authentication and to avoid collisions of identifiers in the namespace.

REFERENCES

FICAM TFPAP Trust Criteria, Security, LOA 1-3, #1 (p.19), ISO 27002 (2005) Section 11 (Access Control), FFIEC, PCI-DSS 8.1, http://pcidsscompliance.net/pci-dss-requirements/how-to-comply-to-requirement-8-of-pci-dss/

APPLIES TO ACTIVITIES

CREDENTIALING, AUTHENTICATION

KEYWORDS

CREDENTIAL, IDENTIFIER, PROVISIONING, SECURITY

SECURE-7. TOKEN CONTROL

Entities that authenticate a USER MUST employ industry-accepted secure authentication protocols to demonstrate the USER's control of a valid token.

SUPPLEMENTAL GUIDANCE

Successful authentication requires that the user prove, through a secure authentication protocol, that he or she controls the appropriate token(s). Control is best demonstrated by a user providing token value through the authentication protocol (e.g., password, PIN, or biometric).

REFERENCES

FICAM TFPAP Trust Criteria, Authentication Process, LOA 2, #6 (p.21)

APPLIES TO ACTIVITIES

AUTHENTICATION

KEYWORDS

CONTROLS, IDENTIFIER, PROVISIONING, SECURITY, TOKEN

SECURE-8. MULTIFACTOR AUTHENTICATION

Entities that authenticate a USER MUST offer authentication mechanisms which augment or are alternatives to a password.

SUPPLEMENTAL GUIDANCE

Entities must offer users an authentication mechanism other than single-factor authentication based on a password as a shared secret. Examples include (but are not limited to): “something-you-have” (e.g., computing device, USB token, mobile phone, key fob, etc.) or “something-you-are” (e.g., biometric), or a combination of these. The additional or alternative mechanism(s) must ensure the binding and integration necessary for use as an authentication mechanism. See SECURE-9 (AUTHENTICATION RISK ASSESSMENT) and its Supplemental Guidance for more information about choosing risk appropriate authentication mechanisms.

REFERENCES

NIST SP 800-63-2

APPLIES TO ACTIVITIES

AUTHENTICATION

KEYWORDS

AUTHENTICATION, MULTIFACTOR, SECURITY, TOKEN

SECURE-9. AUTHENTICATION RISK ASSESSMENT

Entities MUST have a risk assessment process in place for the selection of authentication mechanisms and supporting processes.

SUPPLEMENTAL GUIDANCE

Entities relying on authentication mechanisms must have a process in place for assessing the risks associated with providing access to their systems, applications, and/or network(s) and must leverage this to inform decisions on the selection of authentication mechanisms and supporting identity services.

Additional controls (e.g., geolocation or device identification) may be used. The party granting access may also request additional verified attributes to support authorization decisions where required by risk or business needs.

REFERENCES

NIST SP 800-63

APPLIES TO ACTIVITIES

AUTHORIZATION

KEYWORDS

ASSESSMENT, AUTHENTICATION, RISK, SECURITY

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.

SUPPLEMENTAL GUIDANCE

At a minimum, ~~service providers~~entities should have documented policies and processes to address disaster recovery, continuity of business, and denial of service prevention/recovery. See INTEROP-5 (DOCUMENTED PROCESSES).

REFERENCES

FFIEC-Business Continuity Planning, Retail Payment System Handbook, and Wholesale Payment System Handbook, E-Banking Handbook, https://www.ffiec.gov/; “IT Handbooks”, at http://ithandbook.ffiec.gov/it-booklets.aspx; ISO 20000-1 (2011) (Part 1: Service management system requirements) and -2 (2012) (Part 2: Guidance on the application of service management systems) 1.6.3.1 & 1.6.3.2, ISO 27002 (2005)- Section 14.1; CSA CCM, https://cloudsecurityalliance.org/download/cloud-controls-matrix-v3-0-1/ , NIST 800-53-4, Continuity Planning, Incident Response; COBIT V5 DSS04 “Manage Continuity”

APPLIES TO ACTIVITIES

REGISTRATION, CREDENTIALING, AUTHENTICATION, AUTHORIZATION, INTERMEDIATION

KEYWORDS

PROCESS, SECURITY, UPTIME

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.

SUPPLEMENTAL GUIDANCE

To support the security and interoperability of cryptographic solutions, ~~organizations~~ entities must follow best practices and standards for cryptographic algorithms and key management including the generation, protection, distribution, and recovery of keys.

REFERENCES

NIST 800-57 (3-parts – Key Management- http://dx.doi.org/10.6028/NIST.SP.800-57pt3r1, http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf, http://dx.doi.org/10.6028/NIST.SP.800-57pt3r1; , ISO/IEC 27002 - 12.3.1; PCI-DSS- 3.6.1-3.6.8 ; (see table of requirements at page 18+); FFIEC - Information Security http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf, see 5.1.2.3(a), 5.3, 5.3.2, 2.1.2, 2.11; Wholesale Payment Systems Booklet, http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_WholesalePaymentSystems.pdf

APPLIES TO ACTIVITIES

REGISTRATION, CREDENTIALING, AUTHENTICATION, AUTHORIZATION, INTERMEDIATION

KEYWORDS

PKI, POLICIES, SECURITY

SECURE-12. RECOVERY AND REISSUANCE

Entities 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.

SUPPLEMENTAL GUIDANCE

Procedures must be in place to reasonably prevent hijacking of an account through recovery and reset options: a common vector for identity thieves and other attackers. At a minimum, ~~service providers~~entities must provide reset, recovery, and reissuance procedures that afford a commensurate level of security to the processes used during the initial registration and credentialing operations. These procedures may include out-of-band verification, device identification, or any combination of similar techniques used to increase the security of reset, reissuance, and recovery options while also meeting IDESG Usability Requirements (USABLE-1 through USABLE-7).

REFERENCES

FICAM TFPAP Trust Criteria “Token & Credential Management”), LOA 2-3, #1, #2, #4, TFPAP Trust Criteria, Management and Trust Criteria, LOA 2-3, #3,#4, #6 (p.35); PCI-DSS v 2.0- 8.5.2 (p. 48) (corresponds to 8.2.2 in PCI-DSS v3. – p.67); NIST SP 800-63, Token and Credential Management Activities 7.1.2 (p. 58)

APPLIES TO ACTIVITIES

REGISTRATION, CREDENTIALING

KEYWORDS

ACCOUNT, CREDENTIAL, EXPIRY, LOSS, PROCESS, PROVISIONING, RECOVERY, SECURITY, TOKEN

SECURE-13. REVOCATION

Entities that issue credentials or tokens MUST have processes and procedures in place to invalidate credentials and tokens.

SUPPLEMENTAL GUIDANCE

~~Service Providers~~Entities must be capable of revoking, deactivating, or otherwise invalidating credentials or tokens. Invalidated credentials include those that have expired, have been determined to be compromised, or have been canceled by either the issuing entity or user.

Timeliness of revocation and deactivation may be dictated by regulation, environment, or trust frameworks.

REFERENCES

FICAM TFPAP Trust Criteria, Token & Credential Management, LOA 2-3, #4 (p.32)

APPLIES TO ACTIVITIES

REGISTRATION, CREDENTIALING

KEYWORDS

CREDENTIAL, EXPIRY, LOSS, PROCESS, REVOCATION, SECURITY, TOKEN

SECURE-14. SECURITY LOGS

Entities 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.

SUPPLEMENTAL GUIDANCE

Transactions and events associated with systems that support identity management functions must be time-stamped and logged. Where necessary additional information related to the events also must be logged (such as the source of an authentication assertion) with the data needed to support audits.

Selection of logging and timestamping standards, processes, and procedures should be consistent with the processes outlined in SECURE-1 (SECURITY PRACTICES).

Audit records and logs must be protected consistent with SECURE-2 (DATA INTEGRITY).

REFERENCES

As an example: HIPAA Security Regulations regarding development and maintenance of logging procedures and records: 45 CFR Part 164, § 164.308(a)(1)(ii)(D), § 164.408(c): http://www.ecfr.gov/cgi-bin/text-idx?node=pt45.1.164&rgn=div5

APPLIES TO ACTIVITIES

REGISTRATION, CREDENTIALING, AUTHENTICATION, AUTHORIZATION, INTERMEDIATION

KEYWORDS

AUDIT, LOGS, PROCESS, SECURITY

SECURE-15. SECURITY AUDITS

Entities 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.

SUPPLEMENTAL GUIDANCE

Both internal and third-party audits are considered acceptable for conformance to this Requirement. This Requirement does not dictate frequency of audits. However, the processes, policies, procedures for conducting audits, and audit findings, as well as those for defining the frequency of audits, must be documented. Additionally, a process for remediating and correcting deficiencies identified during audits must also be documented.

REFERENCES

As an example: HIPAA Security Regulations regarding auditable controls and periodic review of logs: 45 CFR Part 164, § 164.308(a)(1)(ii)(D), § 164.312(b): http://www.ecfr.gov/cgi-bin/text-idx?node=pt45.1.164&rgn=div5

APPLIES TO ACTIVITIES

REGISTRATION, CREDENTIALING, AUTHENTICATION, AUTHORIZATION, INTERMEDIATION

KEYWORDS

AUDIT, LOGS, POLICIES, PROCESS, SECURITY

IDESG Glossary

(as approved by Plenary May 13, 2016)

Glossary term	Definition and source or reference
ACCESSIBLE	A product, service, environment or facility which is usable by USERs with the widest range of capabilities. [ISO 9241-210]
ACCOUNTABILITY	The property of a system or system resource that ensures that the actions of a USER or AGENT may be traced uniquely to that USER or AGENT, which can then be held responsible for its actions. [RFC4949]
AGENT	A non-human application or service acting in the digital environment on behalf of a human USER. Synonymous with "non-person entity" (NPE). See USER.
ANONYMOUS	An INTERACTION designed such that the data collected is not sufficient to infer the identity of the USER involved nor is such data sufficient to permit an ENTITY to associate multiple INTERACTIONs with a USER or to determine patterns of behavior of a USER. [IDESG IDEF] [UXC-Dict] See PSEUDONYMOUS
ASSERTION	A statement from an ATTRIBUTE provider to a RELYING PARTY. [NIST SP 800-63-2] NOTE: ASSERTIONs may be used to communicate CLAIMs, ATTRIBUTEs, IDENTIFIERs, or DIGITAL IDENTITIES. See CLAIM
ATTRIBUTE	A named quality or characteristic that is claimed to be inherent in or ascribed to someone or something. [IDESG Taxonomy]
AUTHENTICATION [FM]	"AUTHENTICATION" is defined in the IDEF Functional Model in part as a "Process of determining the validity of one or more CREDENTIALs used to claim a DIGITAL IDENTITY." [FM] CREDENTIAL AUTHENTICATION: Process of determining the validity of one or more CREDENTIALs used to claim a DIGITAL IDENTITY. [IDESG Taxonomy] DIGITAL IDENTITY AUTHENTICATION: Process used to achieve sufficient confidence in the binding between the USER or AGENT and the presented DIGITAL IDENTITY. [OpenID Connect]
AUTHORIZATION [FM]	"AUTHORIZATION" is defined in the IDEF Functional Model in part as a "Process of granting or denying requests for specific access to resources." [FM]
CLAIM	A statement about the USER or AGENT asserting a property of the USER or AGENT without necessarily containing identity information. NOTE: CLAIMs refer to the content of an ASSERTION rather than the specific source and destination. See ASSERTION
CONTROL	SECURITY CONTROL: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. [SP 800-37] PRIVACY CONTROL: The administrative, technical, and physical safeguards employed within an entity to ensure compliance with applicable privacy requirements and manage privacy risks.
CREDENTIAL	A set of data presented as evidence of a claimed DIGITAL IDENTITY. [IDESG Taxonomy]
CREDENTIALING [FM]	"CREDENTIALING" is defined in the IDEF Functional Model in part as a "Process to bind an established DIGITAL IDENTITY with a CREDENTIAL." [FM]
DATA INTEGRITY	The property that data has not been inappropriately altered.
DIGITAL IDENTITY	An ATTRIBUTE set that can be uniquely distinguished in a given context and can be used for a digital interaction. [IDESG Taxonomy]
DIGITAL IDENTITY MANAGEMENT FUNCTIONS [FM]	The functions described in the IDESG Functional Model (REGISTRATION, CREDENTIALING, AUTHENTICATION, AUTHORIZATION, and INTERMEDIATION), which also encompass enrollment, identity proofing, identity vetting, access control, attribute management, transaction processing, and identity data maintenance.
ENTITY	Any organization providing or using identity services. [IDESG IDEF][UXC-Dict] NOTE: The correct usage of ENTITY is “Organization providing or using identity services”; synonymous with Service Provider in the ID Ecosystem. USER should be used for persons. AGENT should be used for non-persons. NOTE: The word “actor” has been employed in this Glossary to replace the term “entity” previously used in some definitions, where ENTITY (as an organization) is not exclusively intended.
FEDERATION	An association comprising any number of service providers and IDENTITY PROVIDERS. [SAML v2.0] NOTE: This definition concerns IDENTITY and CREDENTIAL FEDERATIONs.
IDENTIFIER	ATTRIBUTE or value that can be used to distinguish a DIGITAL IDENTITY. [IDESG Taxonomy]
IDENTITY	see DIGITAL IDENTITY
IDENTITY PROVIDER	An ENTITY that creates, maintains, and manages trusted IDENTITY information. [NSTAC]
INTERACTION	An event involving two or more actors. See TRANSACTION
INTERACTION DESIGN	A term given to a set of design areas that focuses on the INTERACTION value of content, as opposed to its presentation or information value. The INTERACTION topics include USER interface controls, error handling, and feedback systems. The term “INTERACTION DESIGN” is intended to differentiate these topics from other topics for purposes of evaluation and development. [Human Factors]
INTERMEDIATION [FM]	"INTERMEDIATION" (or "Transaction Intermediation") is defined in the IDEF Functional Model in part as "Processes and procedures that limit linkages between TRANSACTIONs and facilitate CREDENTIAL portability." [FM]
INTEROPERABILITY	The ability of independent systems to exchange meaningful information and initiate actions from each other, in order to operate together to mutual benefit. In particular, it envisages the ability for loosely-coupled independent systems to be able to collaborate and communicate. [NSTAC]
MINIMIZATION	See the IDESG Baseline Requirement “PRIVACY-1. DATA MINIMIZATION” [Reqts]
MULTIFACTOR	MULTIFACTOR AUTHENTICATION: AUTHENTICATION using two or more different factors to achieve AUTHENTICATION. Factors include something one knows (e.g., password/PIN), something one has (e.g., cryptographic identification device, token), or something one is (e.g., biometric). [SP 800-53]
NONPROPRIETARY PUBLISHED FORMAT/ SPECIFICATION	A known and consistent format that is published and transparent to all RELYING-PARTIES and IDENTITY PROVIDERS in the relevant network, and is not controlled by a commercial interest. [IDESG IDEF]
PATHWAY	A route or routes of events, actions or INTERACTIONs leading to a defined result. [UXC-Dict]
PERSONAL INFORMATION	Any information about or linked to a USER that is collected, used, transmitted, or stored in or by DIGITAL IDENTITY MANAGEMENT FUNCTIONS. [IDESG IDEF]
PROVISIONING	Creating USER access accounts and assigning privileges or entitlements within the scope of a defined process or INTERACTION; providing USERs with access rights to applications and other resources that may be available in an environment; may include the creation, modification, deletion, suspension or restoration of a defined set of privileges. [ABAC]
PSEUDONYMOUS	An INTERACTION designed such that the data collected is not sufficient to allow the ENTITY to infer the USER involved but which does permit an ENTITY to associate multiple INTERACTIONs with the USER’s claimed identity. [IDESG IDEF] [UXC-Dict]
REGISTRATION [FM]	"REGISTRATION" is defined in the IDEF Functional Model in part as a "process that establishes a DIGITAL IDENTITY for the purpose of issuing or associating a CREDENTIAL." [FM]
RELYING PARTY	Actor that relies on an identity ASSERTION or CLAIM. [ISO/IEC 29115]
STANDARD	OPEN STANDARDS are standards made available to the general public and are developed (or approved) and maintained via a collaborative and consensus driven process. OPEN STANDARDS facilitate INTEROPERABILITY and data exchange among different products or services and are intended for widespread adoption. (ITU-T) See also: IDESG Standards Adoption Policy v2.0 [SAPv2]
TOKEN	Something that the claimant possesses and controls that is used to authenticate the claimant’s DIGITAL IDENTITY. [IDESG Taxonomy]
TRANSACTION	A specialized form of INTERACTION that involves an exchange of some kind. See INTERACTION
USABILITY	Extent to which a system, product or service can be used by USERs to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. [ISO/IEC 9241-210]
USER	An individual human being. See AGENT
USER-CENTRIC	Systems, design and/or program processes that put the individual human being at the center of the activity. Equivalents and related terms may include: USER, user-centered, human-centered, end user, individual user, user-friendly. [IDESG IDEF] [UXC-Dict]
USER EXPERIENCE	A USER’s perceptions and responses resulting from the use of an ENTITY’s services as rendered by expected USER AGENTs.

INDEX OF KEYWORDS by page number

(This is auto-generated from the “KEYWORDS” as listed, and may differ from the Glossary)