This use case provides the high-level process steps for establishing a digital identity for an internal user and modifying the digital identity record over time as the user's attributes change. Internal users are those who are primarily affiliated with the ministry performing the process defined in the use case. They are typically employees or contractors, for whom the ministry is responsible for vetting and/or maintaining authoritative identity data. The creation of a digital identity for internal users is typically tied to an employee or contractor on-boarding process, initiated when an individual becomes affiliated with a ministry. A digital identity is an electronic representation of an individual that is composed of identity attributes, commonly biographic and biometric data elements. A digital identity record should be distinguishable from other stored electronic identities.
This use case is distinct from credentialing in that identity records can be created without the issuance of a credential. In reality this is not often done, however we address the concept of a discreet identity record which persists and may be maintained as such. Likewise, identity data can be linked and shared with other systems separate from the creation of a particular user account or the assignment of privileges typically performed as part of provisioning processes. In the current state, however, creation of an identity record, credentialing, and provisioning are often tightly bound processes.
5.1.1 Target State Vision:
The target state vision is for a digital identity to be created or modified once in the authoritative system(s) and for authoritative identity attributes to be linked and shared in an automated fashion with other systems across the enterprise. In this vision, a core identity record is established in a single authoritative repository. Application-specific credentials and role
information or privileges are decoupled from the core identity record and are applied as needed via provisioning workflows for individual applications (as described in Use Case 4). This
distinction allows for streamlined management of digital identity information.
5.1.2 Target State Analysis
This use case describes the processes of capturing data to identify an individual within a system of digital identity records. Personal data is used to create a digital identity record, which can be used as a proxy for a person‘s true identity within IT systems. Once a record is established within a system, one benefit inherent to the management of identities is its segregation of people and things into classes or groups, to which policies may be applied or conclusions drawn. There are many ways to classify attributes, and some common elements associated with a digital identity include:
Core Identity attributes: Data that help uniquely describe an identity such as legal name,
date of birth, address.
Contact information attributes: information such as address, phone number, or e-mail
address that is associated with an individual.
Context-specific attributes: Data that are only used in a specific context such as, salary
IDIM Corporate Provisioning Architecture- version 1.0 Page 40 Affiliations: Associations with specific ministry locations, roles, internal or external groups,
or professional/academic organizations.
Biometrics: Biological and behavioural attributes, such as facial image, fingerprints, voice
recognition, or other forms of biometrics.
Credentials: An object that may be presented by an individual or system to prove the
authenticity of an identity claim. This includes a password, digital certificate, or ID card for humans and digital certificates or other technologies for systems.
Role information: Categories often used to trigger rules (i.e. for access and provisioning).
5.1.2.1 Key Issues of Digital Identity in current State:
In the current state, digital identity record creation is generally accomplished through
independent means in numerous diverse systems with no reliable synchronization of identity data, which can lead to inefficiencies and even security problems. There is typically no minimum set of data required within an organization to provide for uniqueness or enable disambiguating users across the enterprise. Key issues in maintaining a digital identity in the current state use case include:
Administrative burden associated with digital identity creation and maintenance: The
current processes and systems often require manual attribute updates within multiple systems, creating a large administrative burden for identity record maintenance.
Identity data accuracy: Identity information is often duplicated across multiple systems.
Records can easily get out of sync when updates are performed in one system but not the others, resulting in conflicting records for an individual across the enterprise.
Data security: Maintaining the same identity information in multiple systems increases the
possibility of exposure of the information.
Lack of integration: A given user‘s attributes, credentials, and privileges are often
distributed across multiple identity systems that are not linked, preventing a complete view of an individual‘s authoritative identity attributes and the ability to share identity data within or outside the enterprise. The lack of coordination across systems also increases the risk associated with failing to terminate all associated accounts upon user separation from the organization.
5.1.2.2 Key assumptions for Creation/Maintenance of Digital Identity:
• Identity Proofing and Background Checks, which include vetting of individuals against claimed identity, validation of an Applicant‘s eligibility for access to government resources, and completion of the security clearance process (as applicable), is
completed outside of this use case. Identity Proofing enables a level of trust that identity records are properly assigned to the right individuals, and is closely tied to identity record creation. Background Checks, on the other hand, provide information such that an eligibility determination may be made.
IDIM Corporate Provisioning Architecture- version 1.0 Page 41
• Identity records deletion processes are governed by business and other ministry policies, and cannot be uniformly described in this use case. Record retention policies and practices must comply with all legislation and policies, including privacy.
• The identity record creation process steps generally align across ministries based on worker type (e.g. employee, contractor). Differences based on worker type have been noted within the process flow.
5.1.2.3 Architectural Changes to Support the Target Vision:
The process flows in this section reflect the following architectural changes:
• Developing a common, government-wide specification for the minimum set of core attributes that comprise a digital identity record for an internal user.
• Establishing unique user profiles will require ministries to employ a methodology to deterministically establish unique records, including establishing data quality and transformation services to clean up low quality data.
• Establishing a way for the core identity store to be configured so that representatives from each of these systems can create, update, or delete the appropriate attributes as needed.
• Establishing a mechanism by which the authoritative identity data to be shared from core data repositories is utilized across the enterprise.
• In the case of core digital identity attributes, all systems should be automatically provisioned from the core identity repository. A fully compliant system will provide an authoritative view of an individual‘s identity for all core attributes.
• In the case of peripheral attributes, such as required training certifications or
qualifications, an automated service such as a direct connection between systems or a Master Data Exchange (MDX) should allow for the linking of these attributes to any systems or services that may require them.
• Enabling interoperability between systems by establishing or leveraging existing data standards.
• Minimizing manual and/or paper-based processes for collecting and sharing data that is used to create a digital identity record.
The following assumptions are added in the target state for this use case:
• Data is exchanged electronically, and authoritative data sources have been identified for each of the core identity attributes identified in the planned digital identity specification. • Data that was formerly managed in paper-based systems will have appropriate auditing
IDIM Corporate Provisioning Architecture- version 1.0 Page 42
• Managed processes for the appropriate sharing of identity data within the digital identity record creation and maintenance processes have been established in advance of the start of the process flows described.
• There will be a single, automated, government-wide, managed business process for on- boarding new workers.
5.1.2.4 Target State Process Flow
The target steps for this use case are broken into two different paths: 1) Create a new identity record and
2) Change an existing identity record.
Part 1: Create a new identity record
1. An individual becomes affiliated with a ministry via the on-boarding process. An on-boarding package is created based upon information provided by the individual on standardized,
electronic forms.
2. The on-boarding package is provided electronically to a Data Administrator or Authorized User for the authoritative identity data repository. The Data Administrator or Authorized User authenticates to the system, and then creates an identity record from core identity attributes for the individual.
3. Upon completion of the identity record creation process, any other attribute classes (non- core) may be made available via the MDX to one or more additional systems. This step is often tied closely to provisioning (see Use Case 4).
Part 2: Change an existing identity record
1. A request is initiated to change an individual‘s non-core attributes of their digital identity record or the changes are made directly using one of the following methods (updates to Core Identity attributes are outside the scope of this use case):
a. The Data Administrator/Authorized User receives an electronic notification or request to update an individual‘s identity record. The Data Administrator/Authorized User logs into the system and verifies the attribute change per policy and updates the affected identity attributes in the identity repository.
b. The individual logs into the system and updates his own identity data in the affected system where this is allowed and available via a self-service interface.
c. The record change is triggered and completed automatically based upon workflows established within the ministry.
2. The updated identity attribute(s) are made available to affected systems via direct connection or an MDX.
3. The identity record is maintained for the required time period and deactivated or otherwise flagged.
IDIM Corporate Provisioning Architecture- version 1.0 Page 43
The figure(s) below shows the data interchanges and information flow as described in the processes outlined above. The hexagonal figures represent the various services that are employed throughout the process. Repositories and systems are also depicted. This graphical depiction of the process should illustrate the architecture needed to support this target state use case.
IDIM Corporate Provisioning Architecture- version 1.0 Page 44
Figure 9: Use Case 1 (Part 2) – Target State - Modify Digital Identity
5.1.3 Gaps
This section provides a summary of the high-level gaps between the as-is and target states for this use case. Gaps may focus on Data, Technology, Business and/or Service Layer activities. Explanations about the drivers and impact of each gap are also provided.
1. No common definition or data specification identifying the minimum data
elements for creating and sharing non-Core digital identity data: The digital identity
data specification in the Identity Information Reference Model and Standards will
minimize duplicate entries based on mismatched information for a single individual. The standard will also help streamline the manner in which users can be provisioned into systems.
IDIM Corporate Provisioning Architecture- version 1.0 Page 45
2. Need for common definitions of additional identity attributes required for line of
business specific functions: In addition to core data elements, other common identity
attributes should be standardized, and methods should be adopted to translate local data to the standardized set in order to enable data sharing across ministries. This set of data may be considered line of business specific and may be identified by the
communities of interest that will share it. In particular, standardizing attributes used to make authorization decisions has the potential to greatly reduce costs.
3. Inability to correlate and synchronize digital identity records and automatically
push and pull identity data between systems: A service such as the MDX and/or a
set of common interconnections must be developed to index and link authoritative sources of core identity data and peripheral data such that it may be collected once and shared many times across applications.
4. Lack of authoritative sources for contractor/affiliate identity data: Identity
information is not collected centrally for contractors and other tightly affiliated personnel that are not employees. The lack of authoritative sources for this data can cause security risks such as improper overlapping responsibilities, lack of de-provisioning, and also cause inefficiencies when contractors work on multiple contracts within a ministry or across multiple ministries.
5. Prevalence of redundant collection and management of digital identity data for a single user: Attributes are currently collected and stored in multiple locations,
sometimes within a single application. Data should be collected as infrequently as possible, and the information should be linked to the authoritative source to manage updates and reduce the need to request the information.
IDIM Corporate Provisioning Architecture- version 1.0 Page 46