Skip to content

Latest commit

 

History

History
80 lines (49 loc) · 3.91 KB

handles.md

File metadata and controls

80 lines (49 loc) · 3.91 KB
Raw

Handles

Overview

Countries with an established user base can now enroll users into a secure portal using their unique identifiers, known as handles. This feature facilitates convenient access to digital services and timely benefits from both the government and private sector. This method eliminates the necessity for users to memorize new or system-generated IDs.

What is a handle?

UIN/ VID are system-generated unique identifiers provided to Residents. Residents have the option to verify their identity or authenticate themselves using either UIN/ VID.

What if we provide residents with the option to personalize their handle (username) and utilize it for authentication purposes?

Handles can range from their phone number, email ID, or any linked functional ID/sectoral ID. Additionally, residents can also create a custom username through the resident portal.

How does it work?

The implementation of custom handles involves the below steps:

  1. Mark the fields that can be used as user handles. A new attribute is introduced in identity schema called as handle which accepts a boolean value. More than one field in the identity schema can be marked as handle.
E.g.: -> “phone” : {
"fieldCategory": "phone number",
"format": "none",
"type": "string",
"fieldType": "default",
"requiredOn" : "",
"handle" : true
},

  1. When a user registers, the collected user data should include the "selectedHandles" field. Since multiple fields can be designated as handles, the user is given the freedom to choose which handle fields to utilize. Alternatively, the client UI collecting user data during registration can provide this option to the user or set the selected handles to default values predetermined by the country.

    • Please note that selectedHandles is also one of the field in identity schema.
    "selectedHandles" : {
"fieldCategory": "none",
"format": "none",
"type": "array",
"items" : { "type" : "string" },
"fieldType": "default"  }

  2. When the collected identity object is sent to the ID repository, it validates the data and accepts the handle provided it is unique among the registered handles. If duplicated, a request to register the user is rejected.

  3. Once identity is successfully processed and stored in an ID-repository, identity credentials are issued to the IDA to store user credentials for each ID (UIN & VID) as well for each selected handle.

  4. ID-repository can be configured to disable issuance of user credential to IDA for both UIN or VID using the properties below:

    mosip.idrepo.identity.disable-uin-based-credential-request=true

What is a handle collision? How can handle collisions be avoided?

If the system is configured to use multiple functional IDs as handles and if two different functional IDs follow the same format/pattern to generate an ID, there is a possibility of a handle collision occurring. A handle collision between two different functional IDs will result in the denial of creating or updating a handle for a resident.

Solution: Each handle stored is suffixed with a handle_type, which is determined by the handle field ID in the identity schema. For every authentication request, IDA will require the handle with the appropriate handle_type as input.

The aforementioned property has been added to the ID repository to append a handle type to each identity creation.

mosip.identity.fieldid.handle-postfix.mapping={'phone':'@phone'}

The Below property is introduced in Id-authentication-default.properties file to validate the handle value based on the postfix provided in the inidivdualId input.

mosip.ida.handle-types.regex={ '@phone' : '^\\+91[1-9][0-9]{7,9}@phone$' }

To conclude, by incorporating custom handles, we can offer users an intuitive method for authentication that doesn't require them to memorize extra or complicated identification codes generated by the system.