[GoodID] issue basic identity certificate

[sirpy]

Given a user faceid and whether to process their image for gender

Add certificate creation method:

1. verify faceid belong to the same wallet and the owner of the faceid
2. if requested - run gender estimation on user image in from facetec db
3. collect age range from facetec db
4. issue a certificate using veramo.io sdk
   • certificate should include unique:true, gender:X (if permission given), age: range
5. return certificate

Update enrollment process:

1. Update the enrollment process to also issue the above certificate.
2. enrollment process should recieve also optional user signed permission to process their image for gender.

Add an API endpoint to issue certificate for existing faceid

1. for an existing user that doesnt need to go through enrollment this api endpoint should receive faceid nd whether to process their image for gender, and just call the certificate creation method and return the certificate

[L03TJ3]

Aligned with ticket: https://github.com/GoodDollar/GoodWeb3-Mono/issues/117

It is possible for a user to reject the scanned data and manually (I assume through design by dropdowns) to give back the supposed actual data for their gender / age

[L03TJ3]

@decentralauren @patpedrosa

@sirpy says 'Signed permission to process image'

Thats not a step I see necessarily, we only have the screen for permissions to check for eligible offers? will this be a TOS type of copy? or do we need their explicit permission to process the image for additional scanning?

[decentralauren]

@L03TJ3 this will be a variation of the current flow. @patpedrosa is working on it now. How it will work:

If users have:

• Already Face Verified with us
• a FV that expires >3 months from date of this check Then they will simply be asked if we can use their existing FV data to read new properties. Pat's working on what this looks like now.

If users do not fit into the above bucket (new user or user with FV that will expire in the next 3months) they go through the FV flow.

[sirpy]

@L03TJ3 letting the user choose his age/gender doesnt make sense, it has to be trusted data. @decentralauren @patpedrosa Regarding signed permission - not critical, lets skip it.

[decentralauren]

@sirpy OK - to confirm, which of these do you mean:

1. we do NOT technically need to ask the user's permission to use their existing Facetec data to find age and gender (assuming this is a product decision so want to confirm)
2. We still do technically require this, however do not require them to sign to do so

We may still keep the step for consent / information purposes though I'm not sure it's necessary.

Regarding use choosing age/gender - this is only done in the case of a dispute (if user wants to change from / challenge the system-generated values). In these instances the disputed value will remain unverified. @sirpy we will eventually want to include self-reported data as part of GoodID (e.g. Household income), so should consider how we will do this and clearly indicate that this data has "lower veracity" than "trusted" sources.

[sirpy]

@decentralauren we said there's no dispute. lets only include the actual requirements please.

all permissions requests are product decisions, legal etc.. you decide.

[decentralauren]

@sirpy we are including dispute, however we are not including dispute resolution.

[sirpy]

@decentralauren @patpedrosa Ok. i'm looking at the dispute ticket and it is incomplete, please make sure issues contain the description, design and requirements. They should at least contain the basic requirements of the UX.

I'd suggest to simply send them to a typeform for the mvp

[decentralauren]

@sirpy which ticket are you referring to?

@patpedrosa @L03TJ3 - let's align on a ticket drafting and review process. Right now I don't think I've even seen the ticket Hadar refers to. Our Monday and Tuesday meetings can be used to refine together once we have a consistent template.

[johnsmith-gooddollar]

actually last item is covered by the first one (issue certificate endpoint) as it already uses existing Face ID and will fail if no one.

so just the second point left todo in addition to https://github.com/GoodDollar/GoodServer/pull/466/files, will be done in a separate PR

[decentralauren]

[ ] Age edge cases - how to handle people who are on the verge of aging into another range

@decentralauren

[decentralauren]

@johnsmith-gooddollar - if users are on the verge of "aging out" into another age bracket, we should verify them based on their initial results and then afford them the option to re-verify their age later by going through the FV flow again.

[johnsmith-gooddollar]

@decentralauren amazon s3 api does not provide an "probability" option.

in facetec we have this percentage and if it's <95% endpoint returns success: false, so we could understand user is at the endge of the next one age range. but we declined to use this API in favour to S3. Amazon returns us just 'low' and 'high' age estimates.

So, I suggest to just ask used "would you like to pass FV again to much proper estimation ? yes/no" each time he/she issues/updates basic identity certificate. If user isn't whitelisted (has no Face ID) - notify he/she will be redirected to FV

[decentralauren]

Thanks @johnsmith-gooddollar - How about this flow (may be same as you suggest, just want to be clear):

This scenario is for users who have previously FV'd, for whom we are re-analyzing a past scan that may put them in an incorrect age range.

Flow:

1. User goes straight from "Upgrade your GoodID" to "Verify Segmentation" screen as their FV credentials are still within active range (expiry in >3 months from date of upgrade)
2. User gets to "Verify Segmentation" screen.
3. Two options here: 3a. On "Verify Segmentation" screen, they are presented the option to re-do the FV process if their age (specifically) is wrong 3b. On "Verify Segmentation" screen, they dispute the age, at which point we ask them to redo the FV process
4. They redo FV flow and are treated like a new FV from a UX flow perspective from this point on

This would require us to either track who is in this special state (already FV'd) and provide them an alternate "dispute age" path OR to offer this to anyone who disputes their age (to redo their FV / try again)

Option 2:

1. User goes straight from "Upgrade your GoodID" to "Verify Segmentation" screen as their FV credentials are still within active range (expiry in >3 months from date of upgrade)
2. User gets to "Verify Segmentation" screen.
3. On "Verify Segmentation" screen, there is text saying something like "If your age is incorrect, you may retry your Face Verification at the end once you have completed this process and been issued your new GoodID"
4. They proceed with the flow.

This obviously is not a great UX as they are forced to go through the process and then do the FV again, which could result in them changing their eligibility for an offer etc.

What from Option 1 do you feel is the best approach?

[johnsmith-gooddollar]

I think option 2 I s simple and corresponds to the flow I've described in the most part

[sirpy]

@decentralauren lets focus on simple mvp. once we have data about issues we can understand what needs to be solved. lets not try to solve issues that are not here yet. all the dispute flows and issues should be created separately to be implemented in the future.

[decentralauren]

@sirpy sounds good. So we will go forward with option 2, and just make sure to update the copy on the GoodID page.

[sirpy]

@decentralauren i dont understand the "retry" thing. and I dont understand the need to handle edge cases at the moment. user either agree or dispute. lets keep it simple.

[decentralauren]

@sirpy I'm fine with all being handled via dispute, though we should make it accessible for any user to redo their FV if they choose.

I was responding to what @johnsmith-gooddollar had asked above in an earlier comment with a potential solution. Can you two please discuss and let me know what you want to do?

[sirpy]

we should in the future. lets keep features to a minimum. extra features in future iterations.

[decentralauren]

@sirpy ok! Adding it as a separate ticket in the GoodID part of the dapp - can pick it up when we have time.

[vldkhh]

verified on storybook