IDBB Status Meeting 9th January 2024

Owned by smita.selot
Jan 10, 2024
3 min read

Attendees

@Jane Rose Anthony

@Jaume DUBOIS

@smita.selot

Rounak Nayak

Agenda

  • Some of the use cases related to re-issuance and revoke are not clear

  • Some APIs are internal in MOSIP; For example: the issuance

  • MOSIP does not support some APIs

  • Some requirements are not easy to implement/enforce. For example, revoke is vaguely defined by W3C

  • Data sharing: Policy-driven vs Consent Driven

Minutes of the meeting

  • Identity credential sharing should be driven by the citizen consent in the front end and the data share policy in the backend. The policy controls which data should be shared and thus protects the data of citizens who might otherwise consent to share all data including biometrics.

  • Credential issuance is an asynchronous process, so trigger credential issuance will not issue credentials immediately. The credentials will get issued after some time only. When the credential issuance API is called, it will return the transaction ID. The transaction ID is used to retrieve the status of the credential issuance afterwards. If the credential is issued, then there's an option for downloading the credential using the transaction ID. The credential issuance is an internal API.

  • The credential issuance API has been made asynchronous to handle the credential requests at scale. Once the credential is issued, it can be pushed to the partner system requesting it thus avoiding the callback to retrieve the credentials.

  • Currently, MOSIP issues a PSUT. The response can be sent as a simple JSON response or a VC to the OpenCRVS system.

  • The Physical Identity Credential such as an ID Card must have an embedded QR code which can link to IDBB and prove the authenticity/validity of the ID card. The embedded information is usually a facial image.

  • According to the W3C standard, when the credential is revoked, the credential is added to a revocation list. The mechanism for verifying a revoked physical credential is a two-step process. In the first step, the VC embedded in the QR code is verified to check if the credential exists. In the second step, which may happen online or offline, the VC is searched in the revocation list. Revocation verification can happen offline or online to allow different options. Right now, MOSIP does not support revocation.

  • The Philippines has a greyscale, low-resolution facial image embedded in the QR code of their national ID card. However, this QR code is not machine-readable. The QR code can be made machine-readable by solutions such as Tech5. But these solutions are licensed and hence costly to implement. Other solutions are using compression algorithms and using Base45 encoding (better than Base64 encoding).

  • The iris or fingerprints should not be embedded in the QR code, as it poses a security risk.

  • For biometrics updates, all the other demographic data should also be taken afresh to prevent fraud.

  • Block/Unblock APIs cannot be used for suspend/resume, as each ID (UIN + Virtual IDs) is blocked/unblocked individually. For Block/Unblock, deactivate/activate should be used.

  • Since Deactivate/Activate are internal APIs, their functionality can be provided via wrapper APIs to Justice/Police authorities to suspend an ID in case of fraud.

Action Items

  • Smita and Rounak to discuss the revocation use case in detail.

  • Check with Sasi about the QR code solutions.

  • Smita to add the voting card workflow showing the Credential Update (address update), consent from the citizen for notifying the voting system, and subsequent notification to the Voting card system. The citizen can give consent to share the updated credential at the time of credential update.

  • Jaume is looking for a solution so that data can be verified for a 1:1 match without sharing the data.

 [SS1]Digital Agreement for Policy