年龄
而不是： “把你的护照寄给我们。”
你是否年满18岁？
✓ 18岁以上
一种不同的验证方法
传统的身份验证通常始于要求客户证明自己的身份。而Checkify则从另一个问题入手：企业真正需要了解什么？只需请求年龄证明、人脸识别证明、身份证明或访问权限证明，即可获得交互所需的结果——无需收集所有不必要的背景信息。
先从问题开始
首先明确企业的需求——然后只要求提供建立这种需求所必需的保证。
而不是： “把你的护照寄给我们。”
你是否年满18岁？
✓ 18岁以上
而不是： “完成另一个CAPTCHA。”
这是真人吗？
✓ 人工验证
关键时刻： 确实需要更强有力的身份验证措施。
此人是否已达到所需的身份验证级别？
✓ 已满足所需保证
而不是： 在门口手动检查不必要的信息。
此人是否获得授权？
✓ 访问权限已批准
索取证据。接收结果。仅当需要采取进一步行动时才升级。
建筑学
传统验证方式要求提供文件。Checkify 要求提供证明。
传统供应商的情况各不相同。以下几点描述的是以文档为中心的常见模式——并非所有供应商都会在所有情况下都如此。
证据与证明
如果企业只需要年龄阈值结果，那么流程设计应该围绕确定这一事实展开，而不是向企业暴露无关的身份信息。
18岁以上？
✓ 是的
处理证据是为了确立证明。这与不必要地将原始证据暴露给请求方是不同的。
可重复使用的证明
在有支持的情况下，现有的验证证据可以帮助满足以后的 Checkify 请求，而无需不必要地重复原始收集过程。
这并非一次验证即可万能。证明材料可能需要满足有效性要求，更严格的要求可能需要额外证据，并且可能需要进行时效性验证或重新验证。
渐进式保障
订阅新闻简报、购买受年龄限制的商品和进行高价值交易不一定需要相同的验证流程。
Checkify 允许请求业务请求与该操作相适应的保证。
客户体验
参与服务之间采用一种熟悉的验证层——但不声称普遍接受。
然后，另一个网站往往会重复类似的流程。
摩擦程度取决于所需的证明——并非每个请求都相同。
数据最小化
架构对企业至关重要，因为不必要的身份数据会带来运营风险。
减少不必要的身份信息进入业务工作流程的数量。
避免收集与决策无关的信息。
要求提供与该操作相符的证明文件，而不是自动进行完整的身份验证。
设计验证以客户审核和批准其提供的样稿为核心。
可信度
GLO6 的理念并非“永远不核实身份”。有些互动确实需要更有力的证据。
区别不在于“永远不要核实身份”，而在于：不要索要超出实际操作所需的证明——当需要更强的保证时，再升级流程。
单层
通过一个验证层提供年龄、人名、身份、企业和访问证明——每一种都得到支持。
互联网的验证层。
通过方法
传统验证: 执行身份或年龄验证流程。
Checkify: 请提供所需的年龄证明。
传统验证: CAPTCHA 或浏览器挑战。
Checkify: 请求人工验证。
传统验证: 工作人员会在适用情况下手动检查证件或身份证件。
Checkify: 请索取或扫描所需的Checkify证明。
传统验证: 默认情况下运行完整的身份验证流程。
Checkify: 升级至必要的身份验证级别。
Checkify 的两面
企业提出需求，用户予以认可，Checkify 证明这一点。
要求提供互动所需的证明——在线或在 Checkify 设置点亲自提供。
从 Checkify 应用程序构建和控制可重用的证明，并在批准请求之前对其进行审查。
对于开发者
通过支持的插件、JavaScript 嵌入或 API 请求所需的证明，然后在您的应用程序中使用结果。
年龄。人类。身份。访问权限。
首先准备好贵公司需要的证明，然后让 Checkify 来处理建立该证明所需的验证流程。