mosip / inji Goto Github PK

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Error pops up (Flight mode must be disabled for the scanning functionality) even if the device is not in flight mode. Camera does not activate

To Reproduce
Steps to reproduce the behavior:

1. Go to SCAN (second icon from left)
2. See error

Expected behavior
Camera should activate and can scan QR code

iOS release build
Version 0.4.0 (1.0.0)

Screenshots

Describe the bug
The error message when revoked VID used should be revised

To Reproduce

1. Request credential with VID that is revoked.

Current behaviour
Displayed error message "Invalid id::VID is REVOKED".

Expected behaviour
the error message should be "VID is revoked".

Screenshots

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Additional context
Error message should not contain special characters and uppercase.

Describe the bug
Removed fullname attribute in policy and try to generate VC, for the name field in the app the value is blank but when we checked in All vid list--it displays undefined

To Reproduce

1. Click “Add VID”
2. Enter correct UIN code and click “Generate VID” – should display screen to enter verification code
3. Enter correct verification code – should display “Downloading your VID”
4. Click “Back home” – should be taken back to page with generated VC or loading screen
5. Once available, click generated VC – should be taken to detailed view
6. clicked on Generated VC and check fullname lable-it should be in blank.
7. Go back to All Vid List and see fullname is displayed with undefined .

Current behavior
when we are in the home page the VC is named as undefined

Expected behavior
the name feild should be left empty in the home page

Screenshots

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Additional context
Add any other context about the problem here.

Details:
When only one VC is downloaded on Inji and is being shared the app should not prompt the user to select a VC. It should be selected by default when user is trying to share it.

Scope of work:

• Have a combined review of the code changes made for the ID4Africa demo along with the NL team
• Incorporate feedback
• Merge the code back into the repo

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Ability to map UI card to VC using templates.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
"network request failed" message is still showing after the network is connected when we try to add id and when otp is provided

To Reproduce

1. turn off the internet connection in your mobile
2. open the app and authenticate it
3. click on add id
4. enter an valid uin and click on generate
5. it will show a message as “network request failed”
6. turn on the internet connection in your mobile
7. click on add id and enter otp

Current behavior
the “network request failed” is still showing in mobile app

Expected behavior
the “network request failed” should not be showing in the previous screen and vc should be generated

Video
https://user-images.githubusercontent.com/86289097/185603034-edeec75f-6d5f-4a17-abd3-8ee68910bc83.mp4

Smartphone (please complete the following information):

• Device: Android
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Additional context
apk details 0.2.2 for 1.1.5 Release 0.2.2 · idpass/inji
ENV : qa3.mosip.net

Describe the bug
When a resident uses Inji to download a VC they are currently receiving 4 email notifications. Out of that ->
3 emails are sent for credential issuance status
1 email is sent for confirming credential issuance
Totally the resident receives 4 emails

To Reproduce
Steps to reproduce the behavior:

1. Enroll a resident with an emailID to which you have access and generate UIN
2. Install and setup the Inji app on your smartphone
3. Use the above UIN to download a VC on the app
4. You will receive 4 emails to the configured emailID. Out of that ->
   3 emails are sent for credential issuance status
   1 email is sent for confirming credential issuance
   The resident receives 4 emails in total.

Expected behavior
The resident should receive 2 emails only - 1 email for credential issuance status and 1 email for confirming credential issuance.

Proposed solution

• During the first installation and setup, the user should be able to select between passcode and bio unlock options for the app.

• If the user selects bio to unlock, an option to record biometrics is presented based on the device setting and model.

• After the biometric is recorded the app prompts the user to set a passcode to unlock. This is a fallback mechanism in case bio unlock is disabled.

• A user can enable/disable bio unlock at any point. They can use the 'Biometric unlock' option in the Profile section of the app.

Implementation Notes:

• While setting up biometric unlock the app only stores a flag that says this feature is enabled (no actual biometric data is stored in the app).

• For bio unlock the app uses Expo's Local Authentication module (https://docs.expo.dev/versions/latest/sdk/local-authentication/). It uses the same biometric configuration that the user setup for unlocking their phone.

Linked Issues:
https://github.com/idpass/idpass-mosip-resident-app/issues/16
idpass#27

Linked Bugs
idpass#167
idpass#196

Describe the bugs

1. "REQUEST" header in request tab is off-centered (Android)
2. Exit button "x" is unclickable on iPhone devices with notch (iOS)
3. Back button and Edit button is unclickable on iPhone devices with notch (iOS)

To Reproduce
Steps to reproduce the behavior:

BUG 1

1. Go to REQUEST (third button from the left)
2. See error

BUG 2

1. Click on Add Card
2. See error

BUG 3

1. Click a card in My Cards
2. See error

Release Build
iOS build: Version 0.4.0 (1.0.0)
Android build: 0.4.0-beta.1

Screenshots
BUG 1

BUG 2

BUG 3

Describe the bug
Accept request and share VC button has some traces of white lines

To Reproduce

1. scan the qrcode on banker's phone

Current behavior
The accept request and share VC button has white line traces

Expected behavior
the accept request and share VC buttons shouldnt have any white line traces overlayed

Screenshots

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Mobile app session should get expired, if the app is opened for a longer time and user tries to login again with the PIN to generate VC by using UIN/VID.

Current behaviour
Session not getting expired

Expected behaviour
It should end up the active session and try to ask kindly re login.
Actual: Session wont get expire.

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

<NOTE: Review pending based on design>

Proposed solution:

• For a specific VC (depending on the case) the app will extract the face image and then send it to the SDK as input.

• The SDK will accept image1 as an input, open the camera capture image2 and then match image1 and image2. If both match it returns true else it returns false.

• The app will then handle the response from the SDK

The following cases state how the SDK will be used:

• Case 1: The resident is themself doing an auth before sharing VC. The app will then identify the selected VC to share, extract the face image from it, and then send it to the SDK as input.

  • Input to SDK→ image from VC

  • Response → True or False

• Case 2: The requesting/relying party will receive a VC and then do an auth. The app will then identify the received VC for auth, extract the face image from it, and then send it to the SDK as input.

  • Input to SDK→ image from VC

  • Response → True or False

• Case 3: The requesting/relying party will receive a VC and then do an auth of both the sender and the receiver of the VC.

  • The app can first identify the received VC for auth, extract the face image from it, and then send it to the SDK as input.

  • If the response from the previous step is true, then the app can extract the face image from the receiver’s VC, and then send it to the SDK as input for a match.

  • If the response from the above step is true then the app can add both this metadata to VC and bundle it as a Verifiable Presentation and store it.

TODO:

• We will also need to add documentation about the SDK

Open question:

• Will we use a different SDK for the iOS app?

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
When Residents request VC with VID the UIN label should be changed to VID

To Reproduce

1. Get VC by entering VID
2. View the generated VC

Current behavior
Even though the Resident request the VC with VID still we see UIN label while viewing VC in My VID's Section

Expected behavior
UIN label should be changed to VID

Screenshots

Smartphone (please complete the following information):

• Device: Andriod
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Additional context
https://github.com/mosip/inji/actions/runs/2926569813 apk
Environment : qa5.mosip.net

As a user of Inji
I want to understand whether my VC is locked or not
So that I can decide on which action to take

API:s needed in MOSIP

• getAuthFactorLockStatus(verifiableCredential)

There is an expectation on the returned data is to understand if the VC is locked or unlocked, and for how the current status will persist.

"status": "unlocked",
"remainingTime": 600

Where remainingTime is in seconds and -1 is used to indicate that the state is persistent.

Note that a separate draft issue has been raised regarding business process question around lock/unlock of individual auth factors.

Dependencies
Required to enable the work done in idpass#133

Problem statement:
A resident should be able to use Inji and download a VC with a newly generated VID

Details:

• The app should provide an option for the resident to download a VC with a newly generated VID.

• After selecting this option the resident will be required to enter UIN/VID and do an OTP auth.

• On successful auth in the step above, a request to download a VC with a new VID will be submitted.

• The app can prompt the user to choose between the type of VID that needs to be used

• The VID types presented will be based on policy configured

• The newly generated VID should be part of the VC that is returned to the app

• Additional info regd one-time use or expiry can be displayed in the VC

============================
SUBTASKS

• New component for creating VID
• Call the VID creating API Mimoto
• Error Handling: Handle all the errors and show the error messages or notifications
• Pass newly created VID to the VC creation component

Describe the bug
The error message "connection interrupted" should be revised to more user friendly message

To Reproduce

1. Establish a connection between resident and relying party
2. Resident chooses the VC to share and clicks on "Share button".
3. The requesting relying party thens clicks on "Reject button".

Current behavior
Displays "The Connection was interrupted, Please try again" in relying party mobile

Expected behavior
App should display a user friendly message.

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Resident phone remains in sharing state when Banker's phone gets disconnected to some reason like network issue .

Prerequisite
device A (requesting): Bluetooth enabled and device B ( Resident phone sharing): Bluetooth, location and camera access: enabled

To Reproduce

1. On device A, go to REQUEST (third icon from left) - verify qr code is displayed and message is correct

2. On device B, go to SCAN (second icon from left) - verify camera is activated

3. On device B, scan QR code displayed on device A – verify device B displays “Connecting…”

4. Device A should display “Connected to device. Waiting for VID…”. Device B should display “Sharing VID” card

5. Enter text on “Reason for sharing (optional)” and click “Accept request and choose VID”

6. Device B should display card with list of possible VC to share. No VC should be preselected. “Share” button should only be activated when a VC has been selected. Name of receiving device should be displayed.

7. Bankers phone disconnected with error “The connection was interrupted.please try again“

Current behavior
phone stuck with sharing screen unable to switch back to previous screen untill we close the app and re login to Mobile App.

Expected behavior
App should switch back to previous screen.

Screenshots

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Additional context
apk details: 0.3.0-rc5-dirty-newlogic
Qa env details: QA4(1.2.1)

Problem statement:
Residents with iOS devices should be able to use Inji to download their digital credentials and view and share them with others.

Proposed solution:
In order to support iOS devices, we will be using Google Nerby Messages API which requires internet connectivity.

2 modes will be introduced in the app when it is requesting for VC -> Offline and Online

Offline mode - uses Google Nearby Communications which does not require internet connectivity
Online mode - uses Google Nerby Messages API which requires internet connectivity

These modes will be available in both android and iOS apps.

Implementation details:
idpass#94 (comment)

A demo video of cross-platform sharing is available here
It shows sharing and receiving of credentials between android and iOS devices.

Acceptance criteria:

• A resident should be able to download, install, and set up Inji on their iOS device.
• A resident should be able to use their UIN/VID to download digital credentials on their phone and view the details.
• A resident should be able to share and receive credentials from an iOS device to another iOS device.
• A resident should be able to share and receive credentials from an iOS device to an android device.
• A resident should be able to share and receive credentials from an android device to an iOS device.
• When both the sharer and receiver are using android apps, they should be able to share and receive credentials without any internet connectivity.
• Between a sharer and receiver even if one of the devices is iOS, sharing and receiving will not be possible without internet connectivity.
• Except for the offline/online modes, all other features of the iOS app should be similar to the android app.

Supported versions:
iOS 12 and above

Differences between the iOS and Android Inji apps:
https://drive.google.com/file/d/1Uyx0M2e5_70UCcHJoHC3MouWIuz2oMG7/view?usp=sharing

Linked tasks:
idpass#130
idpass#94
idpass#129
idpass#151

Problem statement: Residents who have not received their VID/UIN will not be able to use the mobileID app. to download their credentials. Need to build a mechanism for them to use the app.

Proposed solution: We will provide a means by which such residents can use their application ID, get UIN/VID, and then proceed to download their credentials.

Proposed design:

A new resident API will be created on MOSIP platform https://mosip.atlassian.net/browse/MOSIP-21674

Proposed UI for app is given below

Process flow:

Describe the bug
Toast is not displayed informing users to enable Bluetooth
“MOSIP Resident App is asking to turn on Bluetooth” with options “Deny” and “Allow”

To Reproduce
Prerequisite (requesting device: iOS): Bluetooth disabled

1. Go to third icon from left
2. See error

iOS release build
Version 0.4.0 (1.0.0)

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Scope of work:

• To change the CSS styling of the resident app from one place (styleUtils.ts)
• Add a secondary purple theme to demonstrate the theme switching feature.
• Apply new card layout and design as close to the UI prototype.

The prototypes are given below

Problem statement:

A resident should be able to prove presence using the verifier’s phone.

Prerequisite:

• The verifier should have a smartphone with secure hardware

• The verifier installs and sets up the mobileID app on their smartphone which has the selfie auth feature

• The resident should be able to share their credential (VC) with the verifier’s phone

Proposed solution:

• The resident scans the QR code of the verifier’s app to initiate sharing of VC

• The resident is prompted with a consent asking for permission to click their picture for selfie authentication

  • When the resident clicks on the consent checkbox, the 'Verify presence and share' button will be disabled as the face-auth will be performed on the verifier's app (requesting device)
  • When the resident unchecks this consent checkbox the 'Verify presence and share' button will be enabled and the face-auth can be performed on the resident's phone using the same button. Requirement details here

• After giving consent the resident can click on the Share button and initiate sharing

• On receiving VC on the verifier’s phone the app brings up the camera to capture the resident’s picture and then initiates a match with the picture in the received credential using the SDK.

  • On a successful match, the app creates a verifiable presentation and also signs it.

  • A successful match message also will be shown

  • A failed match will be conveyed by a corresponding message

• This info should also be displayed in the history tab

  • On the resident's phone consent should be logged as shown below
    • '9721931281 shared. Consent is given for presence verification'
  • On the verifier's phone
    • '9721931281 received. Presence verified' -> when the app receives ID and face-auth is successful.
    • '9721931281 received. Presence verification failed' -> when the app receives ID and face-auth fails.

• If the resident does not give consent to capture a face image and chooses the 'Accept request and choose ID' option, then a normal share without face auth will happen

NOTE: Creating a Verifiable Presentation when a successful auth happens has been removed from the scope of this feature.

Process flow:

Mock UI
When resident scans QR code on relying party's device, they see the following screen

Open questions

• Where will the auth status be stored? In VC? ANSWER As a verifiable presentation

• How will additional metadata be stored and VC signed? ANSWER As a verifiable presentation

• What happens to the shared VC if face auth fails? Should relying party’s app discard the VC? Or store it?

Tech Notes:

Re-use already available SDKs for selfie auth

============================
SUBTASKS

• Adding consent information in the QR code
• Reading the consent information in the QR code and displaying it to the resident.
• Wireframe for displaying consent text
• After VC is received, perform authentication by integrating with SDK

Requirement:
Provide the ability for a resident to secure their ID by locking and unlocking associated authentication modes

Proposed solution

Pre-requisite:

• OIDC flow should be integrated. Till IDP is ready we will integrate with keycloak in qa4 for token
• use the token from above to invoke platform APIs i.e the status API in this case

Details:

• A resident using Inji will be able to view the lock/unlock status of the allowed authentication types
• The allowed authentication types will be controlled based on the auth.types.allowed configuration
• To view the lock/unlock status the resident will need to sign in using the OIDC token auth
• The resident will be able to submit a request to lock/unlock allowed authentication types
• The lock/unlock activity should be logged as part of the transaction history.

This feature will NOT be supported in 1.1.5 version of platform.

Linked tickets:
idpass#133
idpass#157

Problem statement:

A resident should be able to use their phone and prove their presence using the mobile app (selfie-based auth)

Prerequisite:

• The resident should have a smartphone with secure hardware

• The resident installs and sets up the mobileID app on their smartphone

Proposed solution:

• The resident installs the mobile app on their smartphone and downloads credentials (VC)

• After initiating share by scanning the QR code on relying party’s phone and accepting the request to share, the resident chooses the 'Verify presence and share' option

• The app brings up the camera and captures the resident’s picture automatically and then initiates a match with the picture in the selected credential using the SDK.

  • On a successful match, the app creates a verifiable presentation and also signs it.

  • A successful match and sharing initiated message also will be shown

  • A failed match will be conveyed by a corresponding message

  • The resident should be able to try again in case of a failed match

• This info should also be displayed in the history tab

  • The audit log for verification and sharing should be different from a normal sharing flow.
  • The audit can be
    • '9721931281 verified and shared' -> when face-auth successful and sharing complete
    • '9721931281 verification failed' -> when face-auth fails and no sharing happens

NOTE: Creating a Verifiable Presentation when a successful auth happens has been removed from the scope of this feature.

Process flow:

Proposed UI of resident’s phone:

This is similar to the workflow when the resident shares VC with an added step of selfie auth.

Open questions

• Where will the auth status be stored? In VC?

• How will additional metadata be stored and VC signed?

Tech Notes:

• Re-use already available SDKs for selfie auth

Describe the bug
Should get user-friendly message instead of a JSON parse error in the Mobile app ,when try to generate VC using UIN/VID but ended up with error.

To Reproduce

1. Enter valid UIN
2. click on Generate ID

Current behavior
we are receiving JSON pares error and unable to download VC

Expected behavior
Error message should be revised.

Screenshots

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Additional context
UIN: 3271450621
Qa4 env (1.2.1 release)
apk details : https://github.com/idpass/inji/actions/runs/2336108380

UI mock screen for displaying consent content from QR code

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Prerequisite device A (requesting): Bluetooth enabled
Prerequisite device B (sharing): Bluetooth, location and camera access: enabled

1. Share VC from device B to device A with reason for sharing verify that it is displayed under ""Received VIDs""
2. Share same VC from device B to device A a second time with reason for sharing verify that only one VC is displayed under ""Received VIDs""
3. Under Received VID view VC

Current behavior
Displayed only one "reason for sharing" instead for 2.

Expected behavior
single VC should have 2 Reason for sharing.

Screenshots

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: 1.2.0.1
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Additional context
Env: qa5.mosip.net

Describe the bugs

1. The QR code on the requesting device (iOS) is not displayed during the process of sharing ID. (Android >> iOS)
2. The QR code on the requesting device (android) is not displayed during the process of sharing ID. (Android >> Android)
3. After rejecting, receiving device (iOS) did not direct me back to QR code after dismissing toast. Also gets stuck in Incoming ID page after dismissing toast (Android >> iOS)

To Reproduce bugs
Steps to reproduce the behavior:

BUG 1

1. On device A (iOS), go to REQUEST
2. On device B (android), go to SCAN
3. Scan QR code using device B
4. Device A should display “Connected to device. Waiting for VC…”. Device B should display “Sharing VC” card
5. See error in device A: QR code not displayed

BUG 2

1. On device A, go to REQUEST
2. On device B, go to SCAN
3. Scan QR code using device B
4. Device A should display “Connected to device. Waiting for VC…”. Device B should display “Sharing VC” card
5. See error in device A: QR code not displayed

BUG 3
Steps:

1. On device A (iOS), go to REQUEST
2. On device B (android), go to SCAN
3. Scan QR code using device B
4. Device A should display “Connected to device. Waiting for VC…”. Device B should display “Sharing VC” card
5. Click “Accept request and choose VC”
6. Device B should display card with list of possible VC to share. No VC should be preselected. “Share” button should only be activated when a VC has been selected. Name of receiving device should be displayed.
7. On device B, select VC to share and click “Share”
8. On device B, text “Sharing…” should be displayed. On device A, “Incoming VC” card should be displayed
9. On device A, click “Reject”
10. See Error

Release Build
iOS build: Version 0.4.0 (1.0.0)
Android build: 0.4.0-beta.1

We are trying to build a feature in the INJI app that identifies the user's face in React native.

We are trying to implement this feature by using the tflite/mobileNet model to achieve this task.

For that, I have taken below were the references

Face recognition app with ReactJS

Tflite React native app

Image classification with ReactJs and Tensorflow

@urviljoshi please update the description based on your work

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Mobile id - While sharing VC the reason optional text box has issues [text box within a text box].

To Reproduce

1. Open the app in the two mobiles
2. Turn on bluetooth in both the mobiles
3. Now have one mobile in request state and from another mobile scan QR code
4. From the phone you have scanned the QR code, will be now in sharing VC screen
5. Click on the reason for sharing textbox

Current behavior
When we enter the first letter the textbox getting replaced by a new textbox and the single letter that we are typing is disapearing in seconds as shown in the attached video

Expected behavior
The textbox should get the inputs normally and any letters should not dissaper

Screenshots

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Additional context
qa4.mosip.net

As an Inji user
I would like to be able to revoke a VC VID
So that I can prevent it from being used and shared
So that I can prevent it from being used to generate VCs

API:s needed on the MOSIP side

• revokeCredential(VID)
• getRevocationStatus(verifiable_credential)
• revokeCredential(verifiable_credential)

Business process questions
The questions were answered during a call on 2022-07-27 and the outcome is that:

• VID revocation only affects future VC requests from this VID
• Existing VC:s will not be affected, thus there is no need to check for revocation status on the VC level

How should the revocation status be propagated to parties with which a VC has been shared?
I.e I share my VC with a bank, then I revoke it 2 days later. When/how will the bank understand that my VC has been revoked?

Is there any hierarchy/dependency between UIN/VID/VC? I.e could revocation of one VC affect other VC:s?

Dependencies
idpass#210

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Able to get VC when dropdown selected as UIN and input data is VID number and vice-versa

To Reproduce

1. Open the app and authenticate it
2. From the home screen clikck on generate VC
3. Select the dropdown as UIN and enter the value of VID
4. Click on genrate VC

Current behavior
It is allowing us to the OTP page and aloowing to genrate VC, this is issue is happening in vice-versa senario also, while selecting VID dropdown and entering UIN value it is allowing us to genrate VC.

Expected behavior
It should not allow us to genrate vc and need to show a error message as invalid UIN

Screenshots

Smartphone (please complete the following information):

• Device: Android
• OS: [e.g. iOS8.1]
• Inji app version: [e.g 0.3.0]
• Mimoto version: [e.g 1.2.x]
• MOSIP Version: [e.g. 1.2.1]
• Mimoto server: [e.g. https://.....com]
• MOSIP server: [e.g. https://...mosip.com]

Additional context
Env: qa4.mosip.net

It is an analysis and estimation task. What it will take to upgrade to Java 17.

The outcome of the analysis per repo is to be updated on MOSIP's confluence page

Describe the bug
Even if the location in the device is disabled, the camera is active. It can scan QR codes but fails to connect to the requesting device, remaining in the "Connecting..." state.

To Reproduce
Steps to reproduce the behavior:

1. Disable location
2. Click on SCAN (second icon from left)
3. Scan QR code from requesting device
4. See error

Expected behavior
Popup is displayed asking to activate location. Toast bellow should appear if location was not activated
“Location services must be enabled for the scanning functionality"

Android Release Build
0.4.0-beta.1

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug

1. Screen froze on "Requesting credential..." loading screen (iOS)

To Reproduce
Steps to reproduce the behavior:

1. Click "Add VC" and enter valid UIN/VID
2. Click “Generate VC” – should display screen to enter verification code
3. Deactivate internet access
4. Enter correct verification code
5. See Error

Release Build
iOS build: Version 0.4.0 (1.0.0)
Android build: 0.4.0-beta.1

Problem statement:
The system should be able to generate a VC with VID in it.

Current design:

• In the current implementation data share policy only supports UIN in shareable attributes and not VID.

• Even when a VID is passed to generate a VC, the ID repo finds the corresponding UIN and adds it to the VC

Points to consider
The countries that use Inji will fall under one of the below categories:

1. Countries where both UIN and VID are used and available to residents
2. Countries where only VID is available to residents (Ex: Philippines)

• residents will only use VIDs to download VC
• a resident will definitely have at least one perpetual VID at any point in time

Open question:

• A user may use UIN or any type of VID (temporary, one-time use, etc.) to generate the VC. How will the system know which VID to include in VC?

  • Should the system by default put the perpetual VID into the VC if it exists for a resident? Preferred Approach

  • If perpetual VID doesn't exist for a resident, then generate one and use it in VC?

Scenarios:

• A resident uses a perpetual VID to generate a VC - chooses the option to have VID in VC → VC contains perpetual VID

• A resident who has a perpetual VID uses UIN to generate a VC - chooses the option to have VID in VC → VC contains perpetual VID

• A resident who has a temporary VID and no perpetual VID uses UIN to generate a VC - chooses the option to have VID in VC → system generates perpetual VID and uses that in the VC

• After the IDP feature is complete, the resident will be able to use a userId to generate VC. The resident has a perpetual VID - chooses the option to have VID in VC -> VC contains perpetual VID

• After the IDP feature is complete, the resident will be able to use a userId to generate VC. The resident has no perpetual VID - chooses the option to have VID in VC -> system generates perpetual VID and uses that in the VC

============================
SUBTASKS

• Check VID availability feature in 1.2.1
• Send VID in the credentials.
• UI task(Wireframes): Ability to choose between UIN or VID