Guidelines

1

VNPass login and SP local login flows should be independent

The use case flow of users logging in through VNPass on your channel should be totally segregated from your current Local Login flow.

In other words, "Sign in with VN Pass" or "Sign Up with VNPass" flows should never be merged with your existing SP local login or local registration flow.

2

Linking identifier (attribute/s) should be unique & verified

As part of the of account linking (one time) step the unique identifier that will be used for linking your internal users' profile with VNPass should be based on atributes that are unique per user record (no possible duplicates) and to be verified.

3

SOP level to be highlighted in the Use Case diagram

VNPass user account Strength of Profile (SOP) level need to be mentioned in the use case flow as per business requirement. For more details on VNPass account types please refer to User Account Types.

4

UUID needs to be stored

The UUID which is shared by VNPass needs to be stored mandatorily post account linking/user account registration process flows with VNPass.

5

Linking of Verified VNPass with Non-Verified Local Accounts and vice versa is LESS Recommended

SP should keep in mind that during use case designing , SP should not perform linking of the below cases:

• SP local Unverified accounts with VNPass Verified accounts (SOP2/SOP3)

• SP local Verified accounts with VNPass Unverified accounts (SOP1)

6

Email only as a unique verfied attribute is NOT Recommended

Automatic account linking scenarios do include a scenario where Verfied Email only can be used as the unique identifier to link existing verified user at SP with verified user in VNPass. Although it is acceptable in some specific cases but we do not recommend it unless none of the earlier acceptable scenarios are possible

7

Local User ID/password setting for customers during VNPass registration flow is NOT allowed

During the New User Registration Flow via VNPass (Whether New customer to SP or existing customer with no Online account) SP should not do the following:

• User should not be promoted to create username and password

• Uername and password created by SP in backened for user should not be shared via email or SMS

8

Local User Account Password change during VNPass Sign in flow is NOT Allowed

SP should not provide user an ability to change his/her local account password when logging in through VNPass

9

Sharing of New Local account details is NOT allowed through VNPass

• During the new registration flow through VNAE Pass, SP is allowed to create a new user ID or online account ID for the customer and set a temp password in the backend at SP side.

• User should not be aware of such backend process since account has been reated using a Digital ID (password-less) platform.

• Local user ID/password MUST NOT be shared with customer during or post registration flow.

• SP can share the local account details with user via email ir SMS onl once user attempts to login through SP local login mechanism by clicking on Forget Password in SP login channel.

10

Use Case Release

In order to provide the best experience covering all users (Existing users with/without online access & New to SP Users), SP needs to plan implementation of Automatic, Manual & New User Registration and cover all scenarios in the same release for go-live

11

UUID shoud be used for Sign-in (during authentication)

One the SP user profile has been updated with the UUID and linked with VNPass account, subsequent Sign-in attempts by user should be based on matching UUID

12

Error Message Guidelines

Error message needs to be aligned with VNPass button guideline which includes the error message, it is available under the design guidelines in the VNPass Toolkit.

13

User to initiate authentication not SP

SP is recommended not to initiate VNPass authentication on behalf of user. Applying for a service needs to be initiated by user.

14

Consistent allowed user type & experience (local vs VNPass) should be maintained

• They allowed user types and services through local login needs to be similarly allowed to login via VNPass too. For example, if an SP allows basic non-verified users to avail baisc services through local login then same users should be allowed to login through VNPass.

15

Onboarding redirect URL

• In order to initiate onboarding on Stage environment, redirect URL provided should be either Dev or Stage enviroment.

• In order to Go Live, the production refirect URL will be required by SP after assessment sign-off by VNPass Onboarding team.

16

VNPass usage for limited scope must be avoided

• VNPass is intended for Authentication purpose and hence the full journey needs to be implemented by SP for users to avail all services on SP channel similar to Lgin through SP Local mechanism.

• For example: Using VNPass for updating user details (email/mobile number) alone should be avoided

17

Selected Use Case Flow

Please make sure to highlight use case no (UC X.X.X) in your submitted use case scenarios diagram

18

Client Credentials from VNPass should only be used for approved use case channel

• VNPass client credentials are channel (Web or Mobile) specific.

• The Client Credentials are shared by VNPass onboarding team after use case has been approved.

• These credentials should not be reused for a diffent channel/use case without being discussed and approved by VNPass team.