Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEP-9: add proof_of_liveness field #1322

Closed
theclabs opened this issue Nov 30, 2022 · 1 comment · Fixed by #1323
Closed

SEP-9: add proof_of_liveness field #1322

theclabs opened this issue Nov 30, 2022 · 1 comment · Fixed by #1323

Comments

@theclabs
Copy link
Contributor

What problem does your feature solve?

As an extension of #1301 Anchors often have different KYC "tiers" that allow their users to transact in small to large amounts.
To increase these levels, Anchors usually ask for proof of liveness, either as a selfie or videos with challenges, as well as requesting photo_proof_residence or proof_of_income.

However, the SEP-9 list of standard KYC fields does not include a field used to do a user proof of liveness.

What would you like to see?

Adding a proof_of_liveness field of type binary standardizes anchors' request for the user to provide dynamic images or videos proving their liveness. Anchors may need this information to upgrade their users' to a higher "tier" or revalidate a expired KYC.

{
    "status": "NEEDS_INFO",
    "fields": {
        "proof_of_liveness": {
            "description": "A clear photo of the user face with no glasses",
            "type": "binary"
            }
    }
}

or

{
    "status": "NEEDS_INFO",
    "fields": {
        "proof_of_liveness": {
            "description": "A clear video of the user face smiling",
            "type": "binary"
            }
    }
}

This field could be passed in a SEP-12 PUT /customer OR POST /customer/files request. If passed to POST /customer/files, the file ID returned would then need to be referenced in the subsequent PUT /customer request.

@github-actions
Copy link

This issue is stale because it has been open for 30 days with no activity. It will be closed in 30 days unless the stale label is removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants
@theclabs @JakeUrban and others