+
+Figure - Identity Proofing in the Digital Identity Life Cycle
+
+Identity proofing is thought to be done once, at the time of
+enrollment/registration. But that may not be the only case and may be
+required at various stages of the digital identity lifecycle where life
+events warrant it. As illustrated in Figure 1, the following are the
+digital identity lifecycle processes:
+
+1. Sponsorship: The onboarding process to obtain a digital identity.
+ This process may require the applicant to either have or create an
+ account with the CSP prior to sponsorship. This is the first step in
+ the digital identity lifecycle.
+
+2. Enrollment and Registration: The process through which an applicant
+ applies to become a subscriber of the CSP and the CSP validates the
+ applicant’s identity. This is generally done via an in-person or
+ remote identity-proofing process.
+
+3. Creation: After a successful Identity Proofing event, the CSP
+ provisions a credential by binding the credential to the
+ subscriber’s digital identity.
+
+4. Updates: The act or process by which a requirement to be identity
+ proofed after the initial digital identity is established. Examples
+ of identity-proofing updates include:
+
+ 1. Per policy, an organization may require identity proofing of
+ their users every three years, such as a government employee who
+ needs to renew the certificates on their smart card.
+
+ 2. Change in name or gender may require the subscriber to be
+ identity proofed again.
+
+ 3. The subscriber may initially have been identity proofed at a
+ lower assurance level but, based on required access to
+ higher-risk transactions, the subscriber may be asked to be
+ identity proofed at a higher level of assurance.
+
+ 4. There are several scenarios, including times of emergency or
+ transactions between strangers, when one may need to be identity
+ proofed to ensure that that digital identity still belongs to
+ that real-life person who was identity proofed at enrollment.
+
+5. Suspension/Revocation: Revocation is the process of permanently
+ changing the status of a credential to invalid (e.g., the credential
+ has been compromised or the status of the sponsor has changed).
+ There may also be an expiration of the credential bound to the
+ subscriber, which may either trigger another identity-proofing event
+ to renew the credential or surrender the credential housed on a
+ smart card to the CSP. Reasons for suspending or revoking a
+ credential include:
+
+ 1. Lost/stolen device.
+
+ 2. Death of the subscriber.
+
+What is the difference Between In-Person Proofing and Remote Proofing?
+======================================================================
+
+In-person identity proofing is when individuals are required to present
+themselves and their documentation directly to a person. Remote identity
+proofing is used when individuals are not expected to present themselves
+or their documents in person and, instead, provide it online. In either
+case, this traditionally involves validating and verifying presented
+data against one or more corroborating authoritative sources of data.
+
+Why is remote identity proofing hard and what are the challenges?
+=================================================================
+
+Historically, IdPs/CSPs who offered remote identity proofing services
+typically relied on *knowledge-based authentication (KBA),* where
+applicants were asked static questions about themselves and expected to
+be the only ones to know the answers to such questions, such as job
+history, credit report data or credit history, their mother’s maiden
+name, their date of birth, etc. IDPs/CSPs used data collection
+companies, such as the credit bureaus, Lexis/Nexis, SEON Technologies,
+Silent Eight, and others, as authoritative sources of identity
+information to verify the applicant’s responses. If applicants responded
+correctly to these questions, the credit bureaus would provide a scoring
+to indicate the assurance of that identity based upon the answers
+provided. The CSPs, in turn, used those scores in determining the
+acceptable level of assurance that the identity was verified. However,
+due to recent data breaches, massive amounts of personally identifiable
+information (PII) have been stolen and made available from multiple
+sources, including those on the dark web. Reports of fraud activity
+clearly show that significant amounts of PII have fallen into the hands
+of criminals and are being used for identity-related crimes, such as
+stealing services, assets, or benefits. The recent Twitter, LastPass,
+and AT&T data breaches, as reported by the Identity Theft Resource
+Center, are good examples of these types of compromised identity data.
+3 As a
+result, solely relying on the use of KBA is insufficient for
+corroborating an individual’s claimed identity.
+
+Successful remote identity proofing is contingent on the user having
+technical knowledge of the process and what is needed to accomplish it
+successfully (e.g., the user has a smartphone and the ability to use it
+to capture images/pictures and has valid identification that can be
+verified with the issuing authority). Online remote identity proofing is
+difficult because the validation and verification process can be
+cumbersome and challenging. Identity documentation may not be available,
+or the documentation provided by the applicant may be insufficient.
+Further difficulties arise when not all applicants have a smartphone or
+government-issued identification card that can be remotely validated.
+Some may find the identity validation and verification process can be
+too time-consuming or difficult. This increased user friction causes
+applicants to get frustrated and abandon the service.
+
+The U.S. Government Accountability Office (GAO) released a remote
+identity proofing report that identified four out of six federal
+agencies that are still relying on PII-related KBA.
+4 The GAO
+report cites high costs and implementation challenges for certain
+segments of the public as reasons why some agencies have not adopted
+alternative identity-proofing methods to KBA. For example, the lack of a
+mobile phone for some applicant populations was given as a key
+implementation challenge. Organizations still using KBA should evaluate
+the value of their KBA solutions and, where possible, replace them with
+a more dynamic KBA. Additionally, the European Union Agency for
+Cybersecurity, ENISA, which is dedicated to achieving a common
+level-high of cybersecurity across Europe, also published a remote I.D.
+proofing report in March 2021.
+5 In their
+report, they’ve identified similar gaps with a lack of awareness and
+understanding of the remote proofing process, the variation in quality
+and completeness of identity evidence across the many European
+countries, and the desire to use physical presence as the benchmark,
+which, while tempting, cannot be reasonable when considering the
+variables introduced in remote proofing.
+
+Over the last few years, there have been multiple government efforts to
+offer the public secure and private online access to participating
+government programs both here in the U.S. and abroad. The goal was to
+make managing government-provided benefits, services, and applications
+easier and more secure for the populations they were designed to serve.
+Whether agency applications and services would need to integrate with a
+single government authentication service is still in question. A single
+authentication entity for government services would require users to
+first be redirected to this central authentication service via secure
+protocols to register, be identity proofed, and assigned an
+authenticator (either remotely or in-person). Once the user has been
+identity proofed and acquired an authenticator, the authenticator could
+be presented to any Government online application or service that
+accepts them, provided they meet the required identity assurance level
+of that application or service. Gaining consensus across multiple
+agencies of the one government to use a common authentication service
+has proven to be much more difficult than anticipated.
+
+Another remote proofing challenge is that there are too many
+misperceptions about why personal information, especially biometrics, is
+being requested and used. Many citizens do not trust the government to
+protect their personal information and question how it is being used. As
+a result, many people are reluctant to share their personal information
+for fear that the information will be used for more than the specified
+purposes. By not carefully explaining why data is being collected, how
+it is being used, and whether or not the data is stored or destroyed
+after remote identity proofing is complete, individuals may not provide
+the required information and will therefore fail remote identity
+proofing.
+
+According to concerns expressed by the GAO report, additional work is
+needed to ensure that a fraudulent image, such as a photo of a mask, is
+not being provided in lieu of a live image — a threat known as a
+“presentation attack.” Keeping up with ever-evolving threats to remote
+identity proofing and implementing the proper security controls to
+mitigate those threats is an ongoing challenge.
+
+Challenges with remote identity proofing extend to other countries as
+well. The United Kingdom (U.K.) was among the first to try remote
+identity proofing, but it has been plagued with performance issues. One
+of their key problems was centered around the datasets used by the
+identity providers when trying to confirm a user’s identity. Applicant
+data used for verification did not match what was on the government’s
+systems, resulting in the U.K. government not being able to create and
+manage the system. Due to these problems, private industry is taking
+over the effort with the first task addressing the issue of the
+mismatched datasets used by the identity providers.
+
+Summary
+=======
+
+Today, many organizations and government agencies rely heavily on being
+able to accurately identify, credential, monitor, and manage user access
+to information and information systems across their enterprise to ensure
+they know who is accessing their data. There are numerous situations
+where it is important to reliably establish an association of a digital
+identity with a real-life subject. Identity proofing establishes that a
+person is who they say they are based on the validity of one or more
+pieces of identity evidence. The more due diligence incorporated into
+the identity-proofing process, the higher the confidence that the
+applicant is who they claim to be.
+
+Historically, those who offered remote identity proofing services
+typically relied on knowledge-based authentication (KBA), where
+applicants were asked static questions about themselves (such as their
+mother’s maiden name, the street they grew up on, or their father’s date
+of birth) and expected to be the only one to know the answers to such
+questions. However, vast amounts of data about an individual have been
+stolen in data breaches and are readily available to purchase online.
+This stolen data can be used by fraudsters to then obtain access to your
+bank account, receive your stimulus check, or your tax returns. It is
+due to this high increase in stolen identities that organizations are
+finding that they no longer trust that digital identity and must improve
+their remote identity-proofing efforts to more effectively thwart
+fraudsters.
+
+The use of online remote identity proofing services is difficult because
+the validation and verification process can be cumbersome and
+challenging. Identity documentation may not be available, or the
+documentation provided by the applicant may be insufficient. Further
+difficulties arise when not all applicants have a smartphone or
+government-issued identity card that can be remotely validated. Some may
+find the identity validation and verification process can be too
+time-consuming or difficult. This increased user friction causes
+applicants to get frustrated and abandon the service.
+
+
+
+Authors
+=======
+
+**Lorrayne Auld**
+
+**Principal Cybersecurity Engineer, MITRE Corporation**
+
+Lorrayne has over 25 years of experience in the area of identity and
+access management, secure web, portal, and Public Key Infrastructure
+(PKI) technologies supporting the Federal Government. She has worked
+both as a hands-on integrator and as a cybersecurity engineer providing
+guidance to the government. She has helped multiple agencies with their
+Identity, Credential, and Access Management (ICAM) strategies,
+implementation guidance, and best practices.
+
+Lorrayne serves as the focal point for researching, understanding, and
+applying ICAM emerging technologies while ensuring ongoing growth within
+this area. She also serves as the senior advisor to the ICAM capability
+area as well as a mentor to junior staff. She has spoken at conferences
+on higher assurance identity proofing and next-generation authentication
+technologies. Lorrayne is a member of Kantara, IDPro, Women in Identity,
+and the FIDO Alliance.
+
+**Sandy Christopher**
+
+**Senior Communications Advisor, MITRE Corporation**
+
+Building on 20+ years of leading communication and change, Sandy
+delivers holistic communication programs that measurably engage
+stakeholders and achieve business goals. Throughout her career, Sandy
+has worked with executive leadership to create strategic communication
+plans that align employees with the priorities of the organization. She
+is an innovative problem solver with extensive domestic and
+international communication experience on a wide range of issues,
+including organizational change, crisis communications, healthcare,
+information technology, ethics, operational risk, quality, deregulation
+of the utility industry, human resources, environmental, and financial
+services.
+
+**Russ Reopell**
+
+**Principal Cybersecurity Engineer, MITRE Corporation**
+
+With over 25 years of experience in identity and access management,
+Public Key Infrastructure (PKI) technologies, and web services focused
+on identity, authentication, and authorization, Mr. Reopell has
+supported the Federal Government, Department of Defense, and
+Telecommunication companies. He began his career as a programmer and
+quickly became involved in the design, development, integration, and
+testing of various Air Force and Naval support systems. In the early
+80s, he began working on information security systems and helped deploy
+security solutions in federal and commercial spaces until finally
+focusing on Identity, Credential, and Access Management (ICAM)
+strategies, implementation guidance, and best practices.
+
+Russ worked closely with other MITRE staff and served as MITRE’s ICAM
+Capability Area Lead for many years. Russ was the go-to person across
+MITRE to assist with or guide staff in the design and integration of
+ICAM capabilities to the many sponsors MITRE supports. He is responsible
+for researching, understanding, and applying ICAM emerging technologies
+and helped to grow work in this ever-evolving area. Russ is a member of
+IDPro and enjoys mentoring junior staff to increase their knowledge as
+well as pique their curiosity about the many exciting innovations in the
+ICAM space.
+
+| + | Person Identity | Non-human Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Usage | Multi-faceted, must accommodate multiple access requirements to many applications or protected resources | -Purpose-specific, -single requirement for each deployment |
+Purpose-specific, with a single requirement for each deployment | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Lifecycle | -Created during the ‘joiner’ process, modified when ‘moves’ occur, continually monitored for compliance, disabled, and then deleted according to the ‘leaver’ process.1 | +Created during the ‘joiner’ process, modified when ‘moves’ occur, continually monitored for compliance, disabled, and then deleted according to the ‘leaver’ process. 1 | Created on deployment of the device/service, deleted on termination. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Access -end-points |
+endpoints
Users typically access computer services from smartphones, PCs, and laptops on an interactive basis. | Endpoints are typically devices or device controllers. They can also be computer applications, service routines, or Internet bots. | Strategic Alignment and Access Governance | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Applicant | +A subject undergoing the processes of enrollment and identity proofing. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Architecture | Framework for the design, deployment, and operation of an information technology infrastructure. It provides a structure whereby an organization can standardize the technology it uses and align its IT infrastructure with digital transformation policy, IT development plans, and business goals. | Introduction to IAM Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Architecture Overview | Describes the architecture components required for supporting IAM across the enterprise. | Introduction to IAM Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Architecture Patterns | Identifies the essential patterns that categorize the IT infrastructure architecture in an organization and will guide the deployment choices for IAM solutions. | Introduction to IAM Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assertion | A formal message or token that conveys information about a principal, typically including a level of assurance about an authentication event and sometimes additional attribute information. Sometimes this is called a Security Token. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assurance Level | A category describing the strength of the identity proofing process and/or the authentication process. See NIST SP.800-63-3 for further information. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Asymmetric Cryptography | Any cryptographic algorithm which depends on pairs of keys for encryption and decryption. The entity that generates the keys shares one (see Public Key) and holds and protects the other (see Private Key). They are referred to as asymmetric because one key encrypts, and the other decrypts. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Attribute Provider | Sometimes the authority for attributes is distinguished from the authority for identities. In this case, the term Attribute Provider is sometimes used. It is a subset or type of an Identity Information Authority. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Attribute-Based Access Control (“ABAC”) / Claims-Based Access Control (“CBAC”) | a pattern of access control system involving dynamic definitions of permissions based on information (“attributes”, or “claims”), such as job code, department, or group membership. | Introduction to Policy-Based Access Controls (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Attributes | Key/value pairs relevant for the digital identity (username, first name, last name, etc.). | An Overview of the Digital Identity Lifecycle (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Audit Repository | A component that stores records about all sorts of events that may be useful later to determine if operations are according to policy, support forensic investigations, and allow for pattern analysis. Typically, this is highly controlled to prevent tampering. Audit Repository is the ISO name for this concept and is localized to the IDM. In this model, the term is generalized to indicate a service that supports event records from any part of the ecosystem. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Authentication | Authentication is the process of proving that the user with a digital identity who is requesting access is the rightful owner of that identity. Depending on the use-case, an ‘identity’ may represent a human or a non-human entity; may be either individual or organizational; and may be verified in the real world to a varying degree, including not at all. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Authentication (AuthN) | The act of determining that to a level of assurance, the principal/subject is authentic. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Authenticator | The means used to confirm the identity of a user, processor, or device, such as a username and password, a one-time pin, or a smart card. | Identity and Access Management Workforce Planning | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| AuthN Assertion | A security token whereby the IDP provides identity and authentication information securely to the RP. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Authoritative Source | The system of record (SOR) for identity data; an organization may have more than one authoritative source of data in their environment. | User Provisioning in the Enterprise | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Authorization | Determining a user’s rights to access functionality with a computer application and the level at which that access should be granted. In most cases, an ‘authority’ defines and grants access, but in some cases, access is granted because of inherent rights (like patient access to their own medical data) | Introduction to Access Control, Authentication and Authorization | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Authorization (AuthZ) | Authorization is how a decision is made at run-time to allow access to a resource. We break this down into two types: shared and local. The FICAM framework includes this as a subcomponent of the Access Management System. AuthZ is not included in the ISO or Internet2 models. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Automatic Certificate Management Environment (ACME) | A communication protocol for automating lifecycle management of PKI certificates. Significant providers like Let's Encrypt leverage ACME to support issuing TLS certificates for web servers. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Bilateral Federation | A bilateral federation is one that consists of only two entities: one Identity Provider (IdP) and one Service Provider (SP). This is the most common model for an enterprise identity federation. | Federation Simplified (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Binding | Associating an authenticator with an identity. | -Identity and Access Management Workforce Planning | ++ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Bot | Sometimes called an Internet bot, short for ‘robot’ but referring to a software routine that performs automated tasks over the Internet or a web robot referring to an autonomous network application, or simply a ‘bot’ referring to an automated, typically repetitive, task used for a specific purpose. | Non-Human Account Management (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Ceremonies | Predictable interactions that users can infrequently navigate in a well-watched place | Introduction to Identity – Part 2: Access Management | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Certificate Authority Trust List (CTL) | A client maintains a list of trusted Certificate Authorities created and managed by the software provider or local administrators. The client will only trust certificates issued under one of the CAs in the CTL, so the CTL serves as a "safe list." | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Certificate Management System (CMS) | A system that provides management and reporting layers for certificate issuance and revocation. A CMS integrates CA products with Identity Governance and Administration (IGA) systems as well as Service Desk systems. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Certificate Policy (CP) | A document that defines the high-level policy requirement for a PKI. RFC 3647 identifies a PKI's policy framework and describes a CP's contents and outline. An enterprise operating a CA will often publish its certificate policy to external parties so they can determine whether to trust certificates issued by the CA. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Certificate Practices Statement (CPS) | A CP identifies the requirements for managing a CA and issuing PKI certificates. A CPS describes how a CA implements those requirements. The CPS uses the same outline as the CP, defined in RFC 3647. Unlike the CP, enterprises rarely publish their CPS in unredacted form. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Certificate Revocation List (CRL) | A certificate authority will publish a list of revoked certificates, called a CRL so that clients can verify that a certificate is still good. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Certificate Signing Request (CSR) | When requesting a certificate, the requesting entity provides a copy of the public key, their identifiers, and other information in a specially formatted binary object called a CSR. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Channel | The communication avenue between you and your end-user, or your agent and their customer. This could be phone, chat, social media, or others. | Managing Identity in Customer Service Operations | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CIA Triad | The fundamental Information security concepts of risk classification of resources from the perspectives of Confidentiality, Integrity, and Availability. | Non-Human Account Management (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Claimant | +A subject whose identity is to be verified by using one or more authentication protocols. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Claimed Identity | +An applicant’s declaration of unvalidated and unverified personal attributes. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Claims-Based Access Control (CBAC) | See Attribute-Based Access Control (ABAC) | Introduction to Policy-Based Access Controls (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Classical Computer | A computer that uses binary encoding and Boolean logic to make calculations in a deterministic way. We use the term Classical Computers in contrast with Quantum Computers. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Cloud Infrastructure Entitlement Management (CIEM) | a categorization of technologies focused on managing the granting, verification, and refinement of permissions for cloud and hybrid technologies. CIEM is often seen as a component of Identity Governance and Administration (IGA) | Techniques To Approach Least Privilege | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Competency Model | A collection of tasks, knowledge, and skills (TKS) needed for effective job performance. A competency model is part of a workforce framework. | Identity and Access Management Workforce Planning | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Consent | Permission for something to happen or agreement to do something. | Introduction to Privacy and Compliance for Consumers | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Consumer Protection Law | Laws and regulations that are designed to protect the rights of individual consumers and to stop unfair, deceptive, and fraudulent business practices. | Laws Governing Identity Systems | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Context | conditions under which an action on a resource is authorized for a subject, such as time of access, location of access, or a compliance state. | Introduction to Policy-Based Access Controls (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Continuous Authentication | Continuous authentication is a mechanism that uses a variety of signals and measurements to determine during a user session if there is any change in the confidence that it is still the same user that authenticated at the beginning of the session, and trigger an authentication action if there is a drop in confidence. | Designing MFA for Humans | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Contract Law | Laws that relate to making and enforcing agreements between or among separate parties. | Laws Governing Identity Systems | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Credential | A credential allows for authentication of an entity by binding an identity to an authenticator. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Credential | +An object or data structure that authoritatively binds an identity—via an identifier or identifiers—and (optionally) additional attributes to at least one authenticator possessed and controlled by a subscriber. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Credential Management | How to issue, manage, and revoke authenticators bound to identities. Credential Management roughly corresponds to the IDPro term for Credential Services; we use the term Credential Management here to correlate to the Federal Identity, Credential, and Access Management (FICAM) initiative’s terms. | @@ -350,225 +371,236 @@ via the IDPro GitHub repository:IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Credential Service Provider | +A trusted entity that issues or registers subscriber authenticators and issues electronic credentials to subscribers. A CSP may be an independent third party or may issue credentials for its own use. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Credential Services | Credential Services issue or register the subscriber authenticators, deliver the credential for use, and subsequently manage the credentials. We include PKI information for IAM architectures that must include system components that need certificates and private keys. This roughly corresponds to the FICAM component called Credential Management Systems. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Credentials | Any attribute or shared secret that can be used to authenticate a user. | Account Recovery (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Cryptographic Module | A hardware or software component that securely performs cryptographic operations within a logical boundary. Cryptographic Modules store private keys within this boundary and use them for cryptographic functions at the request of an authorized user or process. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Cryptographic Module Validation Program (CMVP) | A program allowing cryptographic module developers to test their modules against the requirements defined in FIPS-140. The computer security resource center under the United States National Institute of Standards and Technology (NIST) maintains a publicly available list of validated modules. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Data Controller | Defined in Article 4(7) of the GDPR: “‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data;”. This article uses the term “organisation” as a synonym for “data controller”, since organisations involved in IAM will normally be data controllers. | An Introduction to the GDPR | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Data Mapping | “a system of cataloguing what data you collect, how it’s used, where it’s stored, and how it travels throughout your organization and beyond.” | Impact of GDPR on Identity and Access Management | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Data Processor | Defined in Article 4(8) of the GDPR for situations where an organisation processes personal data solely on the instructions of others. A Data Processor must not determine the purposes of processing, for example by processing in its own interests, or, beyond limited technical choices, the means of doing so. Data Processors are regulated by Article 28: in particular they must have a contract with the Data Controller that covers all the subjects listed in Article 28(3). Data Processors are excluded from some, but not all, of the liabilities and duties of Data Controllers. | An Introduction to the GDPR | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Data Protection by Design | Data protection through technology design. See GDPR Article 25 for more detail | Impact of GDPR on Identity and Access Management | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Data Protection Officer | An individual who must be appointed in any organization that processes any data defined by the GDPR as sensitive. The DPO is responsible for “Working towards the compliance with all relevant data protection laws, monitoring specific processes, such as data protection impact assessments, increasing employee awareness for data protection and training them accordingly, as well as collaborating with the supervisory authorities.”(See GDPR Articles 35, 37, 38, and 39 for more detail) | Impact of GDPR on Identity and Access Management | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Data Subject | Defined in Article 4(1) of the GDPR (see “Personal Data” above) as the formal term for the human to whom personal data relates. This article uses the term “individual” as a synonym for “data subject”. | An Introduction to the GDPR | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Decentralized Identifier (DID) | An identifier that is created and anchored in a decentralized system such as a blockchain or ledger and can represent any entity in the ecosystem – an issuer, a holder, a verifier, and even an identity hub. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Delegated Authorization Framework | An access control framework that decouples authentication from authorization, allowing the password to stay local and protected | Introduction to Identity – Part 2: Access Management | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Digital Cards | Represent verifiable credentials that users collect over time and are stored as part of the user agent or the identity hub of the user. It’s somewhat simpler to refer to them as digital cards rather than verifiable credentials when speaking about them. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Digital Identity | the combination of a unique identifier together with relevant attributes that uniquely identifies an entity.. | An Overview of the Digital Identity Lifecycle (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Digital Wallet | represents a digital metaphor for a physical wallet and is generally represented by the combination of the user agent and the underlying capabilities of the computing device, such as secure storage and secure enclaves on a mobile phone. The digital wallet contains digital cards. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Directory | A directory is a central repository for user identities and the attributes that make up those identities. A user identity might be John Smith with firstName attribute as John, lastName attribute as Smith, title attribute as Director, and Department attribute as Marketing. The attributes in the directory can be used to make authorization decisions about what this user should have access to in applications. | Authentication and Authorization | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Discretionary Access Control | a pattern of access control system involving static, manual definitions of permissions assigned directly to users. | Introduction to Policy-Based Access Controls (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| dPKI | A decentralized public key infrastructure and is usually implemented via an immutable blockchain or ledger – a place where DIDs can be registered and looked up alongside the associated public keys of the DID and its metadata. dPKI can be described more generally as the verifiable data registry, as the dPKI is just one of many possible implementations for a verifiable data registry. While this paper refers to dPKI, the reader should be aware that a verifiable data registry need not necessarily be “decentralized”. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Electronic Identification, Authentication, and Trust Services (eIDAS) | European legislation gives legal standing to electronic signatures under eIDAS. This legislation also documents providing legally binding digital signatures with X.509 certificates to comply with Qualified Signature requirements. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Electronic Identification, Authentication and Trust Services (eIDAS) | European legislation that gives legal standing to electronic signatures. This legislation also documents how to provide legally binding digital signatures with X.509 certificates to comply with Qualified Signature. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Elliptic Curve Cryptography (ECC) | An asymmetric cryptosystem based on calculating points along elliptic curves. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Encryption | Processing data using a cryptographic algorithm to provide confidentiality assurance. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Enforcement | The mechanism that ensures an individual cannot perform an action or access a system when prohibited by policy. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Enrollment | Also known as Registration. Enrollment is concerned with the proofing and lifecycle aspects of the principal (or subject). The entity that performs enrollment has sometimes been known as a Registration Authority, but we (following NIST SP.800-63-3) will use the term Credential Service Provider. | -IAM Reference Architecture | ++ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Enterprise Architecture | An architecture covering all components of the information technology (IT) environment | Introduction to IAM Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Entitlement | The artifact that allows access to a resource by a principal. This artifact is also known as a privilege, access right, permission, or an authorization. An entitlement can be implemented in a variety of ways. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Entitlement Catalog | A database of entitlements and their related metadata. The catalog includes an index of entitlement data pulled from business systems, applications, and platforms, as well as technical and business descriptions of the entitlements or their use | User Provisioning in the Enterprise | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Entitlement Management | Cataloging and managing all the accesses an account may have. This is the business process to provision access. | Introduction to Identity - Part 1: Admin-time (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| External identifier | The means by which a person in control of a digital identity refers to that identity when interacting with a system | Identifiers and Usernames | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Federal Agency Smart Credential Number (FASC-N) | A unique identifier associated with a smart card. FASC-N is used in the US Federal Government PIV standard to support Physical Access. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Federal Information Processing Standard (“FIPS”) 140 | A NIST standard defining “Security Requirements for Cryptographic Modules. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Federated Access Controls | an access control architecture that accommodates separation of user/subject authority and resource/object authority. | Introduction to Policy-Based Access Controls (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Federated Identity | The means of linking a person’s electronic identity and attributes, stored across multiple distinct identity management systems | Introduction to Identity – Part 2: Access Management | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Fractured Identity | A case where a single end-user has multiple disparate digital identities. | Managing Identity in Customer Service Operations | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Fraud Law | Laws that protect against the intentional misrepresentation of information made by one person to another, with knowledge of its falsity and for the purpose of inducing the other person to act, and upon which the other person relies with resulting injury or damage. | Laws Governing Identity Systems | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Gantt Chart | A popular schedule format that displays both activity and timeframes in a single chart | Introduction to Project Management for IAM Projects | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| General Data Protection Act (GDPR) | Formally, Regulation 2016/679 of the European Union, in force May 25, 2018. Available at https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679 | An Introduction to the GDPR | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Governance | Making sure that accountable owners are demonstrably in control. | Strategic Alignment and Access Governance | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Groups | A set of identities with defined permissions. In this specific context, a group contains many individuals, but the group identity is opaque, and no information is available regarding which group member took an individual action. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Hardware Security Module (HSM) | A hardware device that generates and protects cryptographic keys. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Holder | The entity that holds verifiable credentials. Holders are typically users but can also be organizations or devices. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identification | Uniquely establish a user of a system or application. | Introduction to Access Control | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identifier | The way a system refers to a digital identity. PKI Certificates support both internal and external identifiers. See Ian Glazer’s article, “Identifiers and Usernames,” for a generic overview of identifiers. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity | Defining attributes for a human user that may vary across domains, e.g., a user’s digital identity will have a different definition in a work environment as opposed to the user’s bank. A device identifier is sometimes referred to as its identity. | Non-Human Account Management (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity | +An attribute or set of attributes that uniquely describes a subject within a given context. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Analytics and Intelligence (IdA) | Identity analytics and intelligence mean looking at entitlement data, looking at the assignment of that, and trying to figure out and define what risk looks like. IdA provides a risk-based approach for managing system identities and access, with the intention of centralizing governance, visibility, and reporting for access-based risk. | @@ -595,51 +627,61 @@ via the IDPro GitHub repository:Identity and Access Management Workforce Planning | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Evidence | +Information or documentation the applicant provides to support the claimed identity. Identity evidence may be physical (e.g., a driver’s license) or digital (e.g., an assertion generated and issued by a CSP based on the applicant successfully authenticating to the CSP). | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Federation | An identity federation is a group of computing or network providers that agree to operate using standard protocols and trust agreements. In a Single Sign-On (SSO) scenario, identity federation occurs when an Identity Provider (IdP) and Service Provider (SP) agree to communicate via a specific, standard protocol. The enterprise user will log into the application using their credentials from the enterprise rather than creating new, specific credentials within the application. By using one set of credentials, users need to manage only one credential, credential issues (such as password resets) can be managed in one location, and applications can rely on the appropriate enterprise systems (such as the HR system) to be the source of truth for a user’s status and affiliation. Identity federations can take several forms. In academia, multilateral federations, where a trusted third party manages the metadata of multiple IdPs and SPs, are fairly common. 1 This article focuses, however, on the enterprise use case where bilateral federation arrangements, where the agreements are one-to-one between an IdP and an SP, are the most common form of identity federation in use today. |
Federation Simplified (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Governance and Administration (IGA) | a discipline that focuses on identity life cycle management and access control from an administrative perspective. | Introduction to Identity - Part 1: Admin-time (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Governance and Administration (IGA) | Includes the collection and use of identity information as well as the governance processes that ensure the right person has the right access to the right systems at the right time. | Introduction to IAM Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Governance and Administration (IGA) | a solution for automating user management and authorizations in target systems, building on the organization’s customer and human resource processes. | Strategic Alignment and Access Governance | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Hub or Repository | The place where users can store their encrypted identity-related information. An identity hub can be anywhere – on the edge, on the cloud, or on your own server. Its purpose is to store personal data. Some implementations may allow other entities to access the identity hub of the user if the user specifically grants such access. You can think of an identity hub as the individual’s personal data store. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Information Authority (IIA) | This represents one or more data sources used by the IDM as the basis for the master set of principal/subject identity records. Each IIA may supply a subset of records and a subset of attributes. Sometimes the IIA is distinguished from the Identity Information Provider or IIP. We use IIA to include the service that actually provides the information as well as the root authority. This corresponds to Identity Information Source in ISO/IEC 24760-2 and Identity Sources in Internet2. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Lifecycle Management | A process that detects changes in authoritative systems of record and updates identity records based on policies. | User Provisioning in the Enterprise | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Management (IDM) | A set of policies, procedures, technology, and other resources for maintaining identity information. The IDM contains information about principals/subjects, including credentials. It also includes other data such as metadata to enable interoperability with other components. The IDM is shown with a dotted line to indicate that it is a conceptual grouping of components, not a full-fledged system in itself. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Proofing | accruing evidence to support “who this is.” Identity proofing is the last, but not the least, important part of this admin-time section. This is the process of collecting and verifying information about a person for the purpose of providing an account or a corresponding credential. This is typically performed before an account is created or the credential is issued, or a special privilege is granted. | Introduction to Identity - Part 1: Admin-time (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Proofing | +The process by which a CSP collects, validates, and verifies information about a person. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Provider (IdP) | An Identity Provider (IdP) performs a service that sends information about a user to an application. This information is typically held in a user store, so an identity provider will often take that information and transform it to be able to be passed to the service providers, AKA apps. The OASIS organization, which is responsible for the SAML specifications, defines an IdP as “A kind of SP that creates, maintains, and manages identity information for principals and provides principal authentication to other SPs within a federation, such as with web browser profiles.” | @@ -651,85 +693,95 @@ via the IDPro GitHub repository:IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Provider (IdP) | +The party that manages the subscriber’s primary authentication credentials and issues assertions derived from those credentials. This is commonly the CSP as discussed within this article. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Register | This is the datastore that contains the enrolled entities and their attributes, including credentials. See the IDM section for elaboration. The terms Directory, Identity Repository, and Attribute Store are sometimes used as synonyms. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Repository | The identity repository is a directory or a database that can be referenced by external systems and services (such as authentication or authorization services). | User Provisioning in the Enterprise | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Identity Theft Law | Laws governing crimes in which the perpetrator gains access to sensitive personal information belonging to the victim (such as birth dates, passwords, email addresses, driver's license numbers, social security numbers, financial records, etc.), and then uses this information to impersonate the victim for personal gain, such as to commit fraud, establish credit in the victim’s name, or access the victim’s accounts. | Laws Governing Identity Systems | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Impersonation | A scenario where a user is able to perform actions as though they are a known user other than themself. | Managing Identity in Customer Service Operations | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Infrastructure-as-code | the process of managing and provisioning computer data centers through machine-readable definition files rather than physical hardware configuration or interactive configuration tools. | Techniques To Approach Least Privilege | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Internet Key Exchange (IKE) | A subordinate standard under IPsec specifying how to use X.509 certificates to establish symmetric keys for an IPsec tunnel.certificates to establish symmetric keys for an IPsec tunnel. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Internet Protocol Security (IPsec) | A standard for communication between two machines providing confidentiality and integrity over the Internet Protocol. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Intra-organizational (Single Sign-On): | A central digital identity, such as an account in a directory, is linked by downstream systems as authoritative for authentication. | An Overview of the Digital Identity Lifecycle (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Inter-organizational (Federation) | An organization relies on another organization’s digital identity and lifecycle management processes. | An Overview of the Digital Identity Lifecycle (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Internal identifier | The way an identity management system refers to a digital identity | Identifiers and Usernames | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issuer | The entity that issues verifiable credentials about subjects to holders. Issuers are typically a government entity or corporation, but an issuer can also be a person or device. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Joiner/Mover/Leaver | The joiner/mover/leaver lifecycle of an employee identity considers three stages in the life cycle: joining the organization, moving within the organization, and leaving the organization. | Introduction to Identity - Part 1: Admin-time (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Journey-based Creation | The process that guides a customer through a series of interactions prior to establishing a digital identity. For example, capturing the minimum basic information needed from a customer to enable creation of an identity. | An Overview of the Digital Identity Lifecycle (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Just-in-time (JIT) Access | a technique where a credential or a permission is granted to a principal for a temporary timeframe when they need the permission to perform an activity. Access is revoked once the activity is complete, limiting its usage. | Techniques To Approach Least Privilege | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Key | In a cryptosystem, a Key is a piece of information used to encrypt or decrypt data in a cryptographic algorithm. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Knowledge-Based Authentication (KBA) | A method of authentication that uses information known by both the end-user and the authentication service but is not necessarily a secret. | Account Recovery (v2), Managing Identity in Customer Service Operations | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Knowledge-Based Authentication (KBA) | +Identity-verification method based on knowledge of private information associated with the claimed identity. This is often referred to as knowledge-based verification (KBV) or knowledge-based proofing (KBP). | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Least Privilege | Also known as the Principle of Least Privilege; a resource, such as a user, must only be able to access the resources (e.g., applications, data) that are necessary for it to function. | @@ -753,7 +805,7 @@ via the IDPro GitHub repository:|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| MFA Prompt Bombing | Also known as MFA fatigue, MFA prompt bombing is a cyber-attack technique that describes when an attacker bombards a user with mobile-based push notifications, which sometimes leads to the user to approve the request out of annoyance which might lead to an account takeover. | -Multi-factor Authentication | +Multi-factor Authentication | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Multi-Factor Authentication (MFA) | @@ -931,15 +983,25 @@ via the IDPro GitHub repository:User Provisioning in the Enterprise | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Registration | +See Enrollment | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Registration Authority (RA) | An individual, system, or business function which provides registration and identity proofing for entities receiving certificates and manages the certificate issuance and renewal process. The most important responsibilities of an RA include identity proofing and binding the private key to the identity. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Relying Party (RP) | A component, system, or application that uses the IDP to identify its users. The RP has its own resources and logic. Note that the term ‘relying service’ is used in the ISO/IEC standards to encompass all types of components that use identity services, including systems, sub-systems, and applications, independent of the domain or operator. We will use the more common Relying Party (or RP). An RP roughly corresponds to the Agency Endpoint in the FICAM model or to Identity Consumers in the Internet2 model. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Remote | +In the context of remote authentication or remote transaction, an information exchange between network-connected devices where the information cannot be reliably protected end to end by a single organization’s security controls. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Resource or Object | an asset protected by access controls, such as an application, system, or door. | @@ -1091,126 +1153,131 @@ via the IDPro GitHub repository:Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Subscriber | +A party enrolled in the CSP identity service. | +Defining the Problem – Identity Proofing Challenges | +||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| System Account | A generic term for a privileged account that has extensive permissions that enable system configuration changes. | Non-Human Account Management (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Task | Lowest level of defined activity; multiple tasks will typically be grouped into stages of project phases | Introduction to Project Management for IAM Projects | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Threat Modeling | Threat modeling is an analysis technique used to help identify threats, attacks, vulnerabilities, and countermeasures that could impact an application or process. | Account Recovery (v2), Designing MFA for Humans | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Tort Law | The body of law that covers situations where one person’s behavior causes injury, suffering, unfair loss, or harm to another person, giving the injured person (or the person suffering damages) a right to bring a civil lawsuit for compensation from the person who caused the injury. Examples include battery, fraud, defamation, negligence, and strict liability. | Laws Governing Identity Systems | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Transport Layer Security (“TLS” ) | A cryptographic protocol designed to provide confidentiality and integrity of communications between two endpoints. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Trust Federation | a trust framework between multiple entities with the purpose of leveraging identity and access management information in a controlled fashion | Introduction to Identity – Part 2: Access Management | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Trust Framework | This component represents the legal, organizational, and technical apparatus that enables trust between the IDM and the RPs. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Trust Root | A technical structure that provides the IDP and RP the ability to recognize each other with a high degree of certainty. This is similar to the concept of Trust Anchor (NIST SP.800-63-3), but we allow for a structure that relies on a mutually agreed-upon third party. A trust root derives from the operation of a Trust Framework. | IAM Reference Architecture | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Two-Factor Authentication (2FA) | A specific case of Multi-Factor Authentication (see: IDPro’s Consolidated Terminology) where two factors must be checked to validate a user’s identity. | Designing MFA for Humans | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Universal Resolver | An identifier resolver that works with any decentralized identifier system through DID drivers. The purpose of a universal resolver is to return a DID document containing DID metadata when given a specific DID value. This capability is very useful because DIDs can be anchored on any number of disparate dPKI implementations. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| User or Subject | a person or entity who may receive access within an access control system. | Introduction to Policy-Based Access Controls (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| User Agent | A user agent is any software that retrieves, renders, and facilitates end-user interaction with Web content. | Cloud Service Authenticates Via Delegation – SAML | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| User Provisioning | The means by which user accounts are created, maintained, and deactivated/deleted in a system according to defined policies. | User Provisioning in the Enterprise | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| User Provisioning and Lifecycle Management | how user records get where they need to be but only as long as they are needed | Introduction to Identity - Part 1: Admin-time (v2) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Username | a common term used for an external identifier | Identifiers and Usernames | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Username | An identifier unique to the authentication service used in conjunction with a shared secret to authenticate a user. | Account Recovery (v2), Managing Identity in Customer Service Operations | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Validator | An entity that verifies a certificate and confirms that the other party controls the private key in the transaction. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Verifiable Credentials | Attestations that an issuer makes about a subject. Verifiable credentials are digitally signed by the issuer. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Verifiable Presentations | The packaging of verifiable credentials, self-issued attestations, or other such artifacts that are then presented to verifiers for verification. Verifiable presentations are digitally signed by the holder and can encapsulate all the information that a verifier is requesting in a single package. This is also the place where holders can describe the specific terms of use under which the presentation is performed. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Verifier | The entity that verifies verifiable credentials so that it can provide services to a holder. | A Peek into the Future of Decentralized Identity | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Workforce Framework | An outline of the job categories, work roles, and competency models needed to execute workforce planning. | Identity and Access Management Workforce Planning | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Workforce Planning | Activities that ensure an organization has the right talent to execute business and technical objectives. | Identity and Access Management Workforce Planning | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| X.509 | An ISO standard from the X.500 series that defines the basic rules for encoding public key certificates. | Practical Implications of Public Key Infrastructure for Identity Professionals | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Zero Standing Privilege (ZSP) | a state where JIT access is used for all permissions and no long-standing permissions are assigned to principals. | Techniques To Approach Least Privilege | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Zero Trust | From NIST Draft Special Publication 800-207, “Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet)” | Introduction to Identity – Part 2: Access Management |