Skip to content

Commit 396a319

Browse files
committed
minor edits
1 parent 076365c commit 396a319

File tree

1 file changed

+22
-33
lines changed

1 file changed

+22
-33
lines changed

articles/active-directory/verifiable-credentials/remote-onboarding-new-employees-id-verification.md

Lines changed: 22 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -14,52 +14,41 @@ ms.author: barclayn
1414

1515
# Onboard new remote employees using ID verification
1616

17-
Onboarding to IT systems is a challenging step because the user being onboarded is not in the trust boundary yet. Verified IDs can help to establish trust based on identity verification by using attestations based from government-issued documents.
17+
Enterprises onboarding new remote users face a significant challenge because onboarding users aren't yet inside the trust boundary. Microsoft Entra Verified ID can help establish trust based on identity verification using attestations based from government-issued documents.
1818

1919
## When to use this pattern
2020

21-
1. Customer has modern HR system with API support that allows programmatic integration to query the HR system to do a reliable matching of user profiles.
21+
1. You have a modern Human resources (HR) system with API support that allows programmatic integration to query the HR system to do a reliable matching of user profiles.
2222

23-
2. Customer already has started their passwordless journey.
23+
2. Your organization has already started their passwordless journey.
2424

2525
## Solution
2626

27-
1. Custom portal for employee onboarding
27+
1. A custom portal for new employee onboarding.
2828

29-
2. A backend job sends the new hire is provided a uniquely identifiable link to that portal from (A) that represents the new hire’s specific process. For this use case, the account for the new hire should already be provisioned in Azure AD. Consider using [Lifecycle Workflows](../governance/what-are-lifecycle-workflows.md) as the triggering point of this flow.
29+
2. A backend job provides new hires with a uniquely identifiable link to the employee onboarding portal from (A) that represents the new hire’s specific process. For this use case, the account for the new hire should already be provisioned in Azure AD. Consider using [Lifecycle Workflows](../governance/what-are-lifecycle-workflows.md) as the triggering point of this flow.
3030

31-
3. New hire clicks the link to the portal in (A) above and it is guided through a wizard-like experience:
31+
3. New hires select the link to the portal in (A) above and are guided through a wizard-like experience:
32+
- **Step 1**: New Hires are redirected to acquire a verified ID from the Identity verification partner (also referred to IDV. To learn more about the identity verification partners: <https://aka.ms/verifiedidisv>)
33+
- **Step 2**: New Hires present the Verified ID acquired in Step 1
34+
- **Step 3**: System receives the claims from identity verification partner, looks up the user account for the new hire and performs the validation. For considerations on how to perform the user lookup, [k]()
35+
- **Step 4**: System executes the onboarding logic to locate the Azure AD account of the user, and [generate a temporary access pass using MS Graph](https://learn.microsoft.com/graph/api/resources/temporaryaccesspassauthenticationmethod?view=graph-rest-1.0)
3236

33-
- Step 1: **New Hire** is redirected to acquire a verified ID from the Identity verification partner (also referred to IDV. To learn more about the identity verification partners: <https://aka.ms/verifiedidisv>)
34-
35-
- Step 2: **New Hire** presents the Verified ID acquired in Step 1
36-
37-
- Step 3: System receives the claims from identity verification partner, looks up the user account for the new hire and performs the validation. For considerations on how to perform the user lookup, [k]()
38-
39-
- Step 4: System executes the onboarding logic to locate the Azure AD account of the user, and [generate a temporary access pass using MS Graph](https://learn.microsoft.com/graph/api/resources/temporaryaccesspassauthenticationmethod?view=graph-rest-1.0)
40-
41-
![High level flow diagram](media/remote-onboarding-new-employees-id-verification/high-level-flow-diagram.png
37+
![High level flow diagram](media/remote-onboarding-new-employees-id-verification/high-level-flow-diagram.png)
4238

4339
## Issues and considerations
4440

45-
1. The link that is used to initiate the process needs to:
46-
47-
- Be specific to the remote employee.
48-
- Be valid for a short period of time.
49-
- Become invalid after the user completes the flow..
50-
- Be designed with a mechanism to correlate the link to the unique identifier of the HR Record, and the Azure AD account should be defined and used to validate when the new hire comes to the site.
51-
52-
2. It is not uncommon to have discrepancies between the claims in the VC and the attributes in IT systems (HR/Directory) for legitimate users. For example, an employee might have a first name “James” but his profile says “Jim”. For those scenarios:
53-
54-
1. At the beginning of the HR process, ask candidates to provide the name exactly as it appears in government issued documents when they first are created in the HR system, and ask separately the name the user might prefer. This will simplify the validation logic
55-
56-
2. Design validation logic to include attributes that are more likely to have an exact match against the HR system. Common attributes include street address, date of birth, nationality, national identification number (if applicable), in addition to first and last name.
57-
58-
3. As a fallback, plan for human review to disambiguate lookups who result in ambiguous/non-conclusive results. This might include temporarily storing the attributes presented in the VC, phone call with the user, etc.
59-
60-
3. For multinational organizations, customers might need to work with different identity proofing partners based on the region of the user.
61-
62-
4. Assume that the initial interaction between the user and the onboarding partner is untrusted. The onboarding portal should generate detailed auditing on each specific request / notification generated for auditing purposes.
41+
1. The link used to initiate the process needs to:
42+
- Be specific to the remote employee.
43+
- Be valid for a short period of time.
44+
- Become invalid after the user completes the flow.
45+
- Be designed with a mechanism to correlate the link to the unique identifier of the HR Record, and the Azure AD account should be defined and used to validate when the new hire comes to the site.
46+
2. It isn't uncommon to have discrepancies between the claims in the VC and the attributes in IT systems (HR/Directory) for legitimate users. For example, an employee might have a first name “James” but his profile says “Jim”. For those scenarios:
47+
1. At the beginning of the HR process, ask candidates to provide the name exactly as it appears in government issued documents when they first are created in the HR system, and ask separately the name the user might prefer. This simplifies validation logic.
48+
2. Design validation logic to include attributes that are more likely to have an exact match against the HR system. Common attributes include street address, date of birth, nationality, national identification number (if applicable), in addition to first and last name.
49+
3. As a fallback, plan for human review to disambiguate lookups who result in ambiguous/non-conclusive results. This might include temporarily storing the attributes presented in the VC, phone call with the user, etc.
50+
3. For multinational organizations, customers might need to work with different identity proofing partners based on the region of the user.
51+
4. Assume that the initial interaction between the user and the onboarding partner is untrusted. The onboarding portal should generate detailed auditing on each specific request / notification generated for auditing purposes.
6352

6453
## Additional resources
6554

0 commit comments

Comments
 (0)