线上核验身份信息的方法及装置与流程

本说明书一个或多个实施例涉及身份安全认证领域，尤其涉及线上进行身份信息核验的方法和装置。

背景技术：

在线下的各种应用场景中，传统对用户的身份核验通常是基于证件实现的，即遵循“由证件实现证实人的身份真实性”逻辑。具体实现中，自然人提供证件(如身份证、护照等)，由代表场景商户的自然人(如酒店的前台人员，行政办理大厅的窗口办事人员)通过视检的方式确认用户与证件的对应关系，并且通过视检或是读卡设备的协助确认证件的真实性，在此基础上从证件上获取所需要的验证信息，即可认为该验证信息是可信身份信息，之后根据场景商户的业务逻辑提供服务。

对于线上业务，也存在着与线下应用场景类似的身份核验要求。例如远程开户，需要验证用户使用的身份信息是正确的，且用户使用的是自己的身份信息，甚至于更严格的要求，需要用户证明拥有有效的合法身份证。然而，线上的身份核验面临诸多问题，例如，线上无法通过视检的方式确认实体证件，无法通过视检方式确认用户与证件信息的对应关系，实际中各业务系统的核验要求不统一，核验数据不够可靠，等等。

因此，希望能有改进的方案，可以更加安全有效地实现线上身份信息的核验。

技术实现要素：

本说明书一个或多个实施例描述了一种在线进行身份信息核验的方法和装置，可以结合在线业务的需求，灵活而安全地实现身份信息的核验。

根据第一方面，提供了一种线上核验身份信息的方法，通过可信应用的服务端执行，包括：

响应于来自业务应用的针对在线业务的身份核验请求，确定所述在线业务所需的第一身份核验信息，其中，所述身份核验请求通过用户申请所述业务应用中的所述在线业务而触发生成；

获取第三方可信核验源支持的第二身份核验信息，以及确定所述用户以及对应的用户终端支持的第三身份核验信息；

根据所述第一身份核验信息，所述第二身份核验信息和所述第三身份核验信息，确定身份信息采集指令；

获取所述用户终端按照所述身份信息采集指令所采集的所述用户的身份信息项；

将所述身份信息项发送至所述第三方可信核验源，以得到核验结果；

将所述核验结果通知所述业务应用。

根据一种实施方式，上述方法还包括鉴权过程，具体包括：

响应于所述身份核验请求，向所述用户发出所述可信应用的应用鉴权请求；

接收用户输入的鉴权信息；

基于所述鉴权信息进行应用鉴权。

在一种可能设计中，通过以下方式确定身份信息采集指令：

确定所述第一身份核验信息对应的第一信息项集合；

确定所述第二身份核验信息对应的第二信息项集合，以及所述第三身份核验信息对应的第三信息项集合；

在所述第二信息项集合和所述第三信息项集合均包含所述第一信息项集合中的全部信息项的情况下，确定身份信息采集指令包括所述第一身份核验信息中的信息项；

在所述第一信息项集合中存在任一信息项没有包含在所述第二信息项集合或所述第三信息项集合中的情况下，确定身份信息采集指令为放弃采集的指令。

在另一种可能设计中，通过以下方式确定身份信息采集指令：

确定所述第一身份核验信息对应的第一强度级别；

确定所述第二身份核验信息对应的第二强度级别，以及所述第三身份核验信息对应的第三强度级别；

在所述第二强度级别和所述第三强度级别均不低于所述第一强度级别的情况下，确定身份信息采集指令包括所述第一身份核验信息中的信息项；

在所述第二强度级别和所述第三强度级别中的任一个低于所述第一强度级别的情况下，确定身份信息采集指令为放弃采集的指令。

在一个实施例中，身份信息采集指令包括，采集实名实人实证信息的指令；在这样的情况下，通过以下方式获取用户的身份信息项：

获取所述终端通过硬件和相应控件，读取的所述用户的实体证件的物理标识信息；和/或，获取预先存储的可信电子凭证，将所述物理标识信息和/或所述可信电子凭证作为实证信息；

获取通过所述终端采集的所述用户的生物特征信息作为实人信息；以及

获取所述用户的实名信息。

进一步地，根据一种实现方式，上述可信电子凭证通过以下方式生成：

获取所述用户的核验身份信息；

将所述核验身份信息发送至所述第三方可信核验源；

接收所述第三方可信核验源基于所述核验身份信息生成的电子凭证。

在另一实施例中，身份信息采集指令包括，采集实名实人信息的指令；在这样的情况下，通过以下方式获取用户的身份信息项：

获取通过所述终端采集的所述用户的生物特征信息作为实人信息；以及

获取所述用户的实名信息。

根据一种实施方式，第三方可信核验源包括第一核验源和第二核验源，在这样的情况下，通过以下方式得到核验结果：

将所述身份信息项中的第一部分发送到第一核验源，以及将所述身份信息项中的第二部分发送到第二核验源；

从所述第一核验源接收第一结果，从所述第二核验源接收第二结果；

将所述第一结果和第二结果合并，从而得到所述核验结果。

根据第二方面，提供一种线上核验身份信息的装置，部署于可信应用的服务端，包括：

第一确定单元，配置为响应于来自业务应用的针对在线业务的身份核验请求，确定所述在线业务所需的第一身份核验信息，其中，所述身份核验请求通过用户申请所述业务应用中的所述在线业务而触发生成；

第二确定单元，配置为获取第三方可信核验源支持的第二身份核验信息，以及确定所述用户以及对应的用户终端支持的第三身份核验信息；

指令确定单元，配置为根据所述第一身份核验信息，所述第二身份核验信息和所述第三身份核验信息，确定身份信息采集指令；

信息获取单元，配置为获取所述用户终端按照所述身份信息采集指令所采集的所述用户的身份信息项；

信息发送单元，配置为将所述身份信息项发送至所述第三方可信核验源，以得到核验结果；

结果通知单元，配置为将所述核验结果通知所述业务应用。

根据第三方面，提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面的方法。

根据第四方面，提供了一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面的方法。

通过本说明书实施例提供的方法和装置，当线上业务需要进行身份核验的情况下，可以利用可信应用来实现用户身份信息的线上核验。在核验过程中，根据在线业务的核验要求，结合核验源支持的核验信息和用户终端支持的核验信息，来采集用户的身份信息，发往第三方可信核验源进行核验，从而保证核验结果的权威性和安全性。并且，以上方式支持可信电子凭证，支持多种不同级别的核验方式，使得在线核验过程更加安全而灵活。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1示出本说明书披露的一个实施例的实施场景示意图；

图2示出根据一个实施例的申请和生成可信电子凭证的过程示意图；

图3示出根据一个实施例的线上核验身份信息的方法流程图；

图4示出根据一个实施例的确定身份信息采集指令的流程图；

图5示出根据一个实施例的核验装置的示意性框图。

具体实施方式

下面结合附图，对本说明书提供的方案进行描述。

图1为本说明书披露的一个实施例的实施场景示意图。在图1中，业务应用是需要线上调用真实身份核验服务的应用，可信应用是执行真实身份核验服务的入口应用。业务应用可以是可信应用本身，或者可信应用中的子应用，或者可信应用所支撑的应用，也可以是可信应用之外、但是被允许调用可信应用的核验服务的第三方应用。例如，可信应用可以是支付宝；相应的，业务应用可以是，支付宝支撑的在线应用，如余额宝、花呗、网商银行等，也可以是允许调用支付宝相应服务的第三方应用，如滴滴、饿了吗等等。

为了实现在线身份核验，根据本说明书的一个实施例，在可信应用的服务端中设置身份核验栈点。身份核验栈点与真实身份核验系统中的核验平台对接，通过核验平台(或称为第三方可信核验源)为用户提供身份核验服务。可以理解，该身份核验栈点可以支持与可信应用对接的多个在线业务应用，例如，支付宝本身，支付宝支撑的在线应用，以及支付宝上集成的第三方应用。

真实身份核验系统包括核验平台与信息平台。信息平台用于存储用户的真实身份数据，保证绝对安全。例如，信息平台可以采用物理隔离的专用网；只允许写入文件，不允许协议交互；只允许写入，不允许协议读出等。核验平台服务于身份核验栈点，从信息平台提取信息，以此为依据对身份核验栈点提供的信息进行验证。通常，身份核验栈点与真实身份核验系统属于不同域，因此，身份核验栈点与核验平台彼此通过签名和验签保证对对方身份的确认。

基于以上系统架构，当线上业务需要进行身份核验的情况下，可以利用可信应用来实现用户身份信息的线上核验。具体地，在线业务应用可以调用可信应用的核验服务；可信应用后台根据业务应用对应的在线业务的核验要求，结合核验源支持的核验信息和用户终端支持的核验信息，采集用户的身份信息，发往第三方可信核验源进行核验，从而保证核验结果的权威性和安全性。并且，以上架构可以支持可信电子凭证，支持多种不同级别的核验方式，使得在线核验过程更加安全而灵活。

下面首先描述通过上述第三方可信核验源为用户生成可信电子凭证的过程。该过程为可选过程。在生成了可信电子凭证的情况下，可以为后续的身份核验提供更多的核验方式选择。

图2示出根据一个实施例的申请和生成可信电子凭证的过程示意图。

如图2所示，首先在步骤s201，用户通过可信应用申请获取可信电子凭证。

然后，在步骤s202，可信应用采集用户的核验身份信息。核验身份信息根据可信核验源的核验要求而设置。一般来说，颁发可信电子凭证时的身份验证是高安全级别的验证，因此需要全面的身份信息。可以利用多种方式来采集用户的核验身份信息。

在一个实施例中，在该步骤s202，通过用户终端的硬件通信功能(例如nfc功能)以及相应的控件，读取用户实体证件的物理标识信息以及身份内容信息，其中实体证件例如是实体身份证，护照等，实体证件的物理标识信息是证件物理实体本身的标识信息，用于标识和区分实体证件，例如身份证的卡信息，护照的实体信息，更具体的，比如二代身份证芯片中的dn号，新一代护照中的芯片序列号等。而身份内容信息是证件上可读可视的信息，例如身份证上显示的用户姓名，身份证号，有效期等等。另外，还采集用户的生物特征信息用于实人认证，例如利用摄像头采集人脸信息，或采集指纹信息。将这些信息共同作为上述的核验身份信息。

在另一实施例中，接收用户手工输入的驾驶证相关信息，作为上述核验身份信息。

在又一实施例中，通过专用机具，读取用户实体证件的物理标识信息，例如芯片dn号；通过用户手工输入方式采集身份证号、姓名、民族信息等身份内容信息；利用摄像头采集人脸信息。将这些信息共同作为上述的核验身份信息。

然后，在步骤s203，可信应用将核验身份信息发送给核验源。

接着，在步骤s204，核验源基于核验身份信息生成可信电子凭证。

在一个实施例中，核验源利用信息平台中的数据对用户的核验身份信息进行校验。校验通过之后，核验源可以对上述核验身份信息进行哈希，由此生成可信凭证。在另一实施例中，每个向核验源申请可信凭证的申请请求具有一个序列号，核验源将该序列号与核验身份信息进行组合，对组合的结果进行哈希，由此生成可信电子凭证。

然后，在步骤s205，核验源将生成的可信电子凭证返回给可信应用。

尽管在以上的图示中仅示出一个核验源，但是核验源也可以是多个。下面以2个核验源为例，说明多个核验源的情况。

在核验源包括第一核验源和第二核验源的情况下，可以将核验身份信息划分为第一核验源需要的第一核验信息，和第二核验源需要的第二核验信息。在步骤s203，将第一核验信息发送至第一核验源，将第二核验信息发送至第二核验源。

例如，在一个例子中，第一核验源为公安一所ctid平台，第二核验源为人口库。相应地，第一核验信息可以包括身份证卡信息，身份证号、姓名、人脸信息等，第二核验信息可以包括民族信息。于是，可以将身份证卡信息，身份证号、姓名、人脸信息等发送到公安一所ctid平台，将民族信息发送到人口库进行校验。

各个核验源校验之后会生成各自的凭证，返回给应用。于是，在步骤s204，可信应用从第一核验源接收第一凭证，从第二核验源接收第二凭证。进一步地，可信应用将所述第一凭证和第二凭证合并，从而生成用户所需的可信电子凭证。

生成的可信电子凭证可以保存在用户终端的安全存储区中，或存储在可信应用客户端/服务端。通常，可信电子凭证可以通过可视化的方式在可信应用中展示，例如公安一所的ctid网证，官方机构提供的电子驾驶证，电子居住证等等。

需要理解，一般来说，可信电子凭证的申请和生成，是在用户在线请求身份核验之前预先进行的，并且是可选的。在生成有上述可信电子凭证的情况下，则后续可以使用该可信电子凭证辅助进行身份核验。

图3示出根据一个实施例的线上核验身份信息的方法流程图，该方法通过可信应用的服务端执行，服务端可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来实现。

如图3所示，在该线上执行的方法中，首先，在步骤30，从业务应用接收到针对某项在线业务的身份核验请求。在线上的场景下，一般地，由用户申请业务应用中的某项在线业务，从而触发业务应用发出身份核验请求，以调用可信应用的身份核验服务。例如，用户在申请网商银行(业务应用)中的在线开户业务(在线业务)时，可以触发网商银行调用支付宝(可信应用)的身份核验服务。相应地，支付宝服务端将会收到来自网商银行的针对上述用户申请开户服务的身份核验请求。

以上的身份核验请求相当于对可信应用的一个服务调用请求，因此，在一个实施例中，可以先通过可信应用本身对此调用服务进行鉴权和访问控制，以增加安全性。

可选的，在步骤31，对用户进行鉴权，从应用的层面判断用户是否有权限进行该身份核验。

具体地，步骤31可以包括，响应于上述身份核验请求，向用户发出可信应用的应用鉴权请求。例如向用户呈现要求用户输入鉴权信息的界面。鉴权信息例如可以是，账户密码，人脸，指纹等等。

接着，接收用户输入的鉴权信息，例如用户手工输入账户密码，或者用摄像头拍摄人脸，或者录入指纹，等等。

然后，可信应用基于用户录入的鉴权信息，对用户的本次操作进行应用鉴权。例如，对比用户本次录入的信息与之前在可信应用中记录的信息是否相同。如果应用鉴权没有通过，则拒绝用户接入。在一个实施例中，还向用户返回提示信息，例如“不具备访问权限”或者“登录失败”。

在鉴权通过的情况下，继续执行后续步骤。

在步骤32，响应于上述身份核验请求，确定用户请求的在线业务所需的身份核验信息，以下称为第一身份核验信息。

需要理解，本文中的“第一”，“第二”仅仅是为了表述的清楚而对类似概念进行的标记和区分，并不具有其他限定作用。

根据不同等级业务的不同安全性要求，第一身份核验信息可以包括多种类别的各种身份信息项，例如实名信息，实人信息，实证信息的各种组合。

实名信息是用户一系列有关联的身份信息的数字呈现，通常为文本形式。实名信息例如包括，姓名，性别，身份证号，民族，等等。实名信息是较为基础的身份信息。

实人信息是用以证明用户本人的信息的数字呈现，通常包含生物特征信息，例如人脸信息，指纹信息，等等。

实证信息是用户拥有的实体证件信息的数字呈现，通常包含用户实体证件的物理标识信息，例如，身份证的卡信息(芯片dn号)，护照中的芯片序列号等。

通常，实人信息和实证信息需要与实名信息结合使用。

在此基础上，实人实名信息是实名信息和实人信息的关联组合，通常表现为文本形式+生物特征信息。例如，姓名为张三，性别为男，身份证号为xxx,民族为汉，人脸图像为xxx。

实人实名实证信息则是以上三种信息的关联组合，通常表现为文本形式+生物特征信息+证件信息。例如，姓名为张三，性别为男，身份证号为xxx，民族为汉，人脸图像为xxx，身份证dn号为xxx。

在一个实施例中，各种在线业务预先向可信应用登记本业务需要验证的身份信息，于是，在步骤32，可信应用可以通过预先登记的信息确定出发出请求的在线业务所需的第一身份核验信息。在另一实施例中，在线业务可以在身份核验请求中指示出需要验证的身份信息，于是，在步骤32，可信应用可以通过上述身份核验请求，确定出在线业务所需的第一身份核验信息。

此外，在步骤33，可信应用获取第三方可信核验源支持的第二身份核验信息，以及确定用户以及用户终端支持的第三身份核验信息。

关于第二身份核验信息，可以理解，可信应用在预先与第三方核验源对接时，双方会明确约定，可以核验哪些信息，以及所支持的核验模式。在可信应用对接多个核验源的情况下，会与各个核验源分别约定可以核验的信息。根据上述约定信息，可信应用可以获取第三方可信核验源支持的第二身份核验信息。

第三身份核验信息包括用户支持的身份核验信息，和用户终端支持的身份核验信息。用户支持的身份核验信息包括，用户是否如前所述申领了电子可信凭证。如果用户已经申请获得了可信电子凭证，那么可以认为，用户支持可信电子凭证作为一种实证信息。

用户终端支持的身份核验信息依赖于用户终端的物理配置和控件设置。例如，在终端具有摄像头且允许可信应用调用该摄像头的情况下，认为终端支持采集人脸图像作为实人信息；在终端具有指纹采集装置的情况下，认为终端支持采集指纹作为实人信息；在终端具有nfc功能且安装了相应控件的情况下，认为终端支持读取身份证的卡信息作为实证信息。以上终端的物理配置和控件设置信息，可以在可信应用客户端与服务端交互的过程中，通过客户端收集并传递给服务端，由此，服务端可以知晓终端的物理配置和控件设置所支持的身份核验信息。此外，对于可以通过用户输入而获得的身份信息，例如用户姓名，年龄等，默认作为终端支持的身份核验信息。

以上用户支持的身份核验信息和用户终端支持的身份核验信息共同构成了第三身份核验信息。

接着，在步骤34，根据前述的在线业务需要的第一身份核验信息，核验源支持的第二身份核验信息，和所述第三身份核验信息，确定身份信息采集指令。

可以理解，原则上，希望按照在线业务的需要来采集用户的身份信息进行核验。但是，也需要考虑核验源的核验能力，和终端支持的采集能力。如果核验源的核验能力和终端的采集能力能够满足在线业务的需要，那么就可以按照在线业务的需要进行采集，也就是，将身份信息采集指令确定为，采集第一身份核验信息中的信息项。然而，如果核验源的核验能力不足，或者终端的采集能力不足，此时，就无法按照在线业务的要求进行采集或进行核验，相应地，可以将身份采集指令确定为放弃采集的指令。

具体地，在一个实施例中，可以将第一/第二/第三身份核验信息整理为信息项集合，通过判断第一身份核验信息的集合是否落入第二/第三身份核验信息对应的集合，判断核验源的核验能力和终端的采集能力能够满足在线业务的需要。

具体地，可以确定在线业务所需的第一身份核验信息对应的第一信息项集合。例如，第一信息项集合包括{姓名，身份证号，性别，人脸，身份证卡信息}。

此外，确定第二身份核验信息对应的第二信息项集合，以及第三身份核验信息对应的第三信息项集合。例如，第二信息项集合可以为：{姓名，身份证号，性别，民族，年龄，人脸，身份证卡信息}，第三信息项集合可以为{姓名，身份证号，性别，人脸，指纹信息，身份证卡信息}。

如果第二信息项集合和第三信息项集合均包含第一信息项集合中的全部信息项，也就是，第一信息项集合同时作为第二信息项集合和第三信息项集合的子集，那么可以确定，核验源的核验能力和终端的采集能力能够满足在线业务的需要，此时，将身份信息采集指令确定为，包括第一身份核验信息中的信息项。

如果第一信息项集合中存在任一信息项没有包含在第二信息项集合或第三信息项集合中，那么，确定身份信息采集指令为放弃采集的指令。

在另一实施例中，可以确定第一/第二/第三身份核验信息各自对应的强度级别，通过判断第一身份核验信息的级别是否高于第二/第三身份核验信息对应的级别，判断核验源的核验能力和终端的采集能力能够满足在线业务的需要。

强度级别的设置规则可以预先设定，遵循的原则为，实证信息的认证强度高于实人信息，并进一步高于实名信息。

例如，在一个例子中，可以设置4种强度级别，从高到低依次为：

级别1，对应于实名实人实证核验，且采用强实证认证，在该级别下，需要采集实体证件的物理标识信息，同时读取用户的可信电子凭证，将这两者作为实证信息。此外，还需采集生物特征信息作为实人信息，以及采集其他实名信息；

级别2，对应于实名实人实证核验，但采用弱实证认证，在该级别下，可以采集实体证件的物理标识信息，或者读取用户的可信电子凭证，将这两者中的任一项作为实证信息。此外，还需采集生物特征信息作为实人信息，以及采集其他实名信息；

级别3，对应于实名实人核验，在该级别下，需要采集生物特征信息(例如人脸图像)作为实人信息，以及采集其他实名信息；

级别4，对应于实名核验，在该级别下，仅需采集用户的实名信息。

在其他实施例中，还可以对身份核验的强度级别进行其他的设定。例如，在一种方式中，进一步考虑同一类别下不同信息项的重要程度，将身份核验信息划分为更多级别。例如，考虑同为实人信息(同一类别)，指纹信息的安全度高于人脸，为包含指纹信息的身份核验信息赋予更高的级别；同为实名信息，身份证号的重要性高于性别，为包含身份证号的身份核验信息赋予更高的级别，等等。在一个具体例子中，可以将身份核验信息划分为例如10个级别。

下面结合图4以及以上4个级别的例子进行描述。

图4示出根据一个实施例的确定身份信息采集指令的流程图，即以上步骤34的子步骤。如图4所示，在步骤341，根据以上的级别设定规则，确定在线业务所需的第一身份核验信息对应的强度级别，称为第一强度级别。在步骤342，分别确定第二/第三身份核验信息各自对应的强度级别，称为第二强度级别/第三强度级别。

在一个具体例子中，假定在线业务需要采用弱实证认证的方式认证实名实人实证信息，那么在步骤341，确定第一身份核验信息对应于上述例子中的级别2。假定核验源支持强实证认证的实名实人实证信息，那么在步骤342可以确定第二强度级别为级别1。另外假定，用户终端没有安装读卡控件，无法读取实体卡，但是用户预先获取了可信电子凭证，那么在步骤342可以确定第三强度级别为级别2。

可以理解，以上步骤341和342也可以并行执行，或者交换顺序执行。

接着，在步骤343和步骤344，分别判断第二强度级别和第三强度级别是否低于第一强度级别。如果步骤343和344的判断均为否，即，第二强度级别和第三强度级别均不低于第一强度级别，则可以确定，核验源的核验能力和终端的采集能力能够满足在线业务的需要，此时，在步骤345，将身份信息采集指令确定为，包括第一身份核验信息中的信息项。

沿用以上例子，假定第一强度级别为级别2，第二强度级别为级别1，第三强度级别为级别2，则第二强度级别和第三强度级别均不低于第一强度级别。此时，将身份信息采集指令确定为第一身份核验信息中的信息项。

如果步骤343的判断为是，即，第二强度级别低于第一强度级别，则认为核验源的核验能力无法满足在线业务的需要；如果步骤344的判断为是，即，第三强度级别低于第一强度级别，则认为用户和用户终端的采集能力无法满足在线业务的需要。在以上任一种情况下，在线业务的身份核验需要无法得到满足，则在步骤346，放弃采集身份信息。在一个实施例中，还向用户发出提示信息，例如“无法进行核验”，“请安装身份证读卡控件，以完成核验”等等。

在一个具体例子中，假定第一强度级别为级别1，第二强度级别为级别1，第三强度级别为级别2，则第三强度级别低于第一强度级别。此时，放弃身份信息采集，并向用户发出提示信息。

可以理解，以上步骤343和344也可以并行执行，或者交换顺序执行。

通过以上方式，确定了身份信息采集指令。接着，将该身份信息采集指令传递至用户终端，使得终端按照该指令采集用户的身份信息项。相应地，在步骤35，服务端获取终端按照上述身份信息采集指令所采集的用户的身份信息项。

在一个实施例中，上述身份信息采集指令包括，采集实名实人实证信息的指令。在这样的情况下，终端通过硬件和相应控件，读取用户的实体证件的物理标识信息；和/或，获取预先存储的可信电子凭证，将物理标识信息和/或可信电子凭证作为实证信息。

更具体地，在身份信息采集指令指示强实证采集方式的情况下(例如，对应于第一身份核验信息的级别为级别1)，终端读取用户的实体证件的物理标识信息，并且获取预先存储的可信电子凭证。在身份信息采集指令指示弱实证采集方式的情况下(例如，对应于第一身份核验信息的级别为级别2)，终端读取用户的实体证件的物理标识信息，或者，获取预先存储的可信电子凭证，将两者中的任一个作为实证信息。

在一个实施例中，可信电子凭证存储在用户终端中特定的安全存储区。此时，通过访问该安全存储区读取可信电子凭证。在另一实施例中，可信电子凭证由当前的可信应用存储，例如存储在客户端或者服务端。此时，可信应用可以对应地直接从客户端/服务端读取可信电子凭证的数据。在又一实施例中，可信电子凭证通过另一可信应用申请并存储，也就是，图2所示的可信应用，与执行图3的身份核验过程的可信应用为不同的应用。在可信凭证存储在其他应用中的情况下，可以通过调用该其他应用读取该可信电子凭证。

进一步的，终端还采集用户的生物特征信息作为实人信息，例如根据第一身份核验信息中的具体信息项，采集人脸信息，或指纹信息。

此外，还获取用户的实名信息。在一个例子中，实名信息可以通过在客户端向用户渲染输入界面，并接收用户输入信息的方式获取。在另一例子中，在读取实体证件时可以同时获取证件上记载的信息，例如姓名、身份证号、证件有效期等，作为实名信息。

通过以上方式，可以采集用户的实名实人实证信息。

在另一个实施例中，身份信息采集指令包括，采集实名实人信息的指令(例如，对应于第一身份核验信息的级别为级别3)。在这样的情况下，终端采集用户的生物特征信息作为实人信息，例如采集人脸信息，或指纹信息。此外，还获取用户的实名信息。

在又一实施例中，身份信息采集指令仅指示采集实名信息(例如，对应于第一身份核验信息的级别为级别4)。在这样的情况下，终端获取用户的实名信息，例如姓名，身份证号，性别，民族，等。

如此，可信应用根据在线业务的需要，并考虑了核验源的核验能力和终端采集能力，采集了用户的身份信息项，用于核验。

接着，在步骤36，可信应用将所采集的身份信息项发送至第三方可信核验源，以得到核验结果。这个过程中，可信应用和核验源可以通过签名和验签建立信任关系，确保数据的安全有效。

核验源接收到上述身份信息项后，可以基于信息平台中存储的用户信息进行核验。更具体地，核验源可以通过将各个身份信息项与保存的用户信息直接比对，来进行用户身份核验。或者，核验源也可以比对身份信息项的哈希值，与保存的用户信息项的哈希值，以此进行核验。

在核验之后，核验源可以向可信应用返回核验结果。核验结果可能对应有两种模式。在鉴别模式下，核验源反馈的是核验通过/核验失败的核验结果，在信息模式下，核验源可以返回附加的用户信息，例如用户的民族信息。

在一些实施例中，核验源可以有多个。在这样的情况下，可以根据各个核验源的核验要求，将身份信息项分为对应的多个组，将各组信息发送给对应的核验源，从各个核验源接收各自的核验结果。

具体地，在一个例子中，第三方可信核验源包括第一核验源和第二核验源。在这样的情况下，在步骤36，将身份信息项中的第一部分发送到第一核验源，以及将身份信息项中的第二部分发送到第二核验源。

在一个实施例中，上述第一部分和第二部分可以存在交集。

例如，在一个例子中，采集的身份信息项包括，姓名，身份证号，民族，人脸信息，以及身份证卡信息。在这样的情况下，可以用户姓名、身份证号、人脸信息以及身份证卡信息发送到公安一所ctid平台(第一核验源)，请求核验各个信息项；将用户姓名、身份证号和民族发送人口库(第二核验源)，请求对民族信息进行核验。

相应地，第一核验源可以返回第一结果，第二核验源可以返回第二结果。可信应用将所述第一结果和第二结果合并，从而得到最终核验结果。

核验结果可以包括核验成功/失败的通知，也可以包括经过核验的用户的真实身份信息。

例如，在一个具体例子中，核验结果可以表示为：用户姓名为**，用户身份证号为**，用户民族为***，用户人脸与身份证上的人脸一致。

或者，在又一例子中，核验结果可以包括，用户姓名正确，用户身份证号正确，用户民族正确，用户人脸与身份证上的人脸一致。

之后，在步骤37，可信应用将核验结果通知业务应用。在获得所需的身份信息的核验结果之后，业务应用就可以根据其业务逻辑执行在线业务，例如在用户核验通过的情况下，根据用户身份信息进行用户在线开户操作。

通过以上过程，可信应用后台根据在线业务的核验要求，结合核验源支持的核验信息和用户终端支持的核验信息，采集用户的身份信息，发往第三方可信核验源进行核验，从而保证核验结果的权威性和安全性。并且，核验过程支持可信电子凭证，支持多种不同级别的核验方式，使得在线核验过程更加安全而灵活。

根据另一方面的实施例，还提供一种线上核验身份信息的装置。图5示出根据一个实施例的核验装置的示意性框图，该装置部署于可信应用的服务端，并可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来实现。如图5所示，该装置500包括：

第一确定单元52，配置为响应于来自业务应用的针对在线业务的身份核验请求，确定所述在线业务所需的第一身份核验信息，其中，所述身份核验请求通过用户申请所述业务应用中的所述在线业务而触发生成；

第二确定单元53，配置为获取第三方可信核验源支持的第二身份核验信息，以及确定所述用户以及对应的用户终端支持的第三身份核验信息；

指令确定单元54，配置为根据所述第一身份核验信息，所述第二身份核验信息和所述第三身份核验信息，确定身份信息采集指令；

信息获取单元55，配置为获取所述用户终端按照所述身份信息采集指令所采集的所述用户的身份信息项；

信息发送单元56，配置为将所述身份信息项发送至所述第三方可信核验源，以得到核验结果；

结果通知单元57，配置为将所述核验结果通知所述业务应用。

根据一种可能的设计，上述装置500还包括鉴权单元51，配置为：

响应于所述身份核验请求，向所述用户发出所述可信应用的应用鉴权请求；

接收用户输入的鉴权信息；

基于所述鉴权信息进行应用鉴权。

在一种实施方式中，所述指令确定单元54配置为通过以下方式确定身份信息采集指令：

确定所述第一身份核验信息对应的第一信息项集合；

确定所述第二身份核验信息对应的第二信息项集合，以及所述第三身份核验信息对应的第三信息项集合；

在所述第二信息项集合和所述第三信息项集合均包含所述第一信息项集合中的全部信息项的情况下，确定身份信息采集指令包括所述第一身份核验信息中的信息项；

在所述第一信息项集合中存在任一信息项没有包含在所述第二信息项集合或所述第三信息项集合中的情况下，确定身份信息采集指令为放弃采集的指令。

在另一种实施方式中，所述指令确定单元54配置为通过以下方式确定身份信息采集指令：

确定所述第一身份核验信息对应的第一强度级别；

确定所述第二身份核验信息对应的第二强度级别，以及所述第三身份核验信息对应的第三强度级别；

在所述第二强度级别和所述第三强度级别均不低于所述第一强度级别的情况下，确定身份信息采集指令包括所述第一身份核验信息中的信息项；

在所述第二强度级别和所述第三强度级别中的任一个低于所述第一强度级别的情况下，确定身份信息采集指令为放弃采集的指令。

在一个实施例中，身份信息采集指令包括，采集实名实人实证信息的指令；在这样的情况下，信息获取单元55配置为：

获取所述终端通过硬件和相应控件，读取的所述用户的实体证件的物理标识信息；和/或，获取预先存储的可信电子凭证，将所述物理标识信息和/或所述可信电子凭证作为实证信息；

获取通过所述终端采集的所述用户的生物特征信息作为实人信息；以及

获取所述用户的实名信息。

进一步地，在一个实施例中，装置500还包括凭证生成单元(未示出)，配置为：

获取所述用户的核验身份信息；

将所述核验身份信息发送至所述第三方可信核验源；

接收所述第三方可信核验源基于所述核验身份信息生成的电子凭证。

在另一实施例中，身份信息采集指令包括，采集实名实人信息的指令；在这样的情况下，信息获取单元55配置为：

获取通过所述终端采集的所述用户的生物特征信息作为实人信息；以及

获取所述用户的实名信息。

根据一种实施方式，所述第三方可信核验源包括第一核验源和第二核验源，相应地，信息发送单元56配置为：

将所述身份信息项中的第一部分发送到第一核验源，以及将所述身份信息项中的第二部分发送到第二核验源；

从所述第一核验源接收第一结果，从所述第二核验源接收第二结果；

将所述第一结果和第二结果合并，从而得到所述核验结果。

通过以上装置，可以安全而灵活地对用户的身份信息进行核验，确保核验结果的权威性和安全性。

根据另一方面的实施例，还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行结合图2到图4所描述的方法。

根据再一方面的实施例，还提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现结合图2到图4所述的方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。