发明内容
本说明书一个或多个实施例描述了提供和获取安全身份信息的方法及装置,通过这样的方法和装置,用户在线下可以利用可信应用,通过展示二维码的方式,安全便捷地向业务方提供经过核验的安全身份信息。
根据第一方面,提供了一种提供安全身份信息的方法,该方法由可信应用服务端执行,包括:
响应于来自于用户的、用于请求身份核验的第一请求,获取核验所需的第一身份信息;
将所述第一身份信息发送至第三方可信核验源进行核验;
向注册平台发送用于进行注册的注册信息,所述注册信息包括所述用户的身份索引,所述身份索引基于经过核验的所述第一身份信息的至少一部分而生成;
接收注册平台返回的二维码信息,用于展示对应的二维码以供扫描;
接收注册平台发送的第二请求,所述第二请求包含所述身份索引,扫描了所述二维码的第一业务方的标识信息,所述第一业务方所需要的第二身份信息,以及所述第一业务方的公钥;
生成安全身份信息,所述安全身份信息包括所述第一业务方的标识信息,以及加密信息,所述加密信息是利用所述第一业务方的公钥,对所述身份索引对应的所述用户的第二身份信息进行加密得到的;
将所述安全身份信息发送至所述注册平台,以使得注册平台根据所述第一业务方的标识信息将所述加密信息路由至所述第一业务方。
在一个实施例中,在获取核验所需的第一身份信息之前,上述方法还包括:
向所述用户发出所述可信应用的应用鉴权请求;
接收用户输入的鉴权信息;
基于所述鉴权信息进行应用鉴权;
在所述应用鉴权通过的情况下,获取所述第一身份信息。
在一个实施例中,可以通过所述可信应用的客户端所在的终端,采集所述第一身份信息。例如,包括通过所述终端上的摄像头采集人脸信息;和/或通过所述终端的NFC功能和其上的控件,读取身份证信息。
在一个实施例中,可以通过可信应用的客户端,接收用户的输入信息,以获得所述第一身份信息,上述输入信息例如可以包括,用户姓名,身份证号,口令。
根据一种实施方式,还可以读取预先生成的可信凭证,作为上述第一身份信息的一部分。
在一个实施例中,所述可信凭证通过以下方式生成:
获取用户的核验身份信息;
将所述核验身份信息发送至所述第三方可信核验源;
接收所述第三方可信核验源基于所述核验身份信息生成的所述可信凭证。
进一步地,在一个实施例中,第三方可信核验源包括第一核验源和第二核验源;相应地,所述可信凭证通过以下方式生成:
获取第一核验信息和第二核验信息作为所述核验身份信息;
将所述第一核验信息发送至所述第一核验源,将所述第二核验信息发送至第二核验源;
从所述第一核验源接收第一凭证,从所述第二核验源接收第二凭证;
将所述第一凭证和第二凭证合并,从而生成所述可信凭证。
根据一种实施方式,可以通过以下步骤生成所述安全身份信息:
根据所述身份索引,确定对应的用户;
获取所述用户的第二身份信息;
利用所述第一业务方的公钥,对所述用户的第二身份信息进行加密,得到所述加密信息。
根据第二方面,提供一种获取安全身份信息的方法,该方法由注册平台执行,包括:
接收来自第一应用的注册信息,所述注册信息包括第一应用中的用户的身份索引,所述身份索引基于经过第三方可信核验源核验过的所述用户的第一身份信息的至少一部分而生成;
根据所述身份索引和所述第一应用的应用信息,生成二维码信息,并将该二维码信息返回给所述第一应用;
从第一业务方接收身份请求信息,所述身份请求信息由所述第一业务方通过扫描所述二维码信息对应的二维码而生成,所述身份请求信息包括所述二维码信息,以及所述第一业务方的业务索引信息,所述业务索引信息对应于所述第一业务方预先向所述注册平台提交的业务注册信息;
根据所述身份请求信息中包含的所述二维码信息,确定所述身份索引和所述第一应用的应用信息,以及根据所述业务索引信息,确定所述第一业务方的标识信息,所述第一业务方需要的第二身份信息,以及所述第一业务方的公钥;
向所述第一应用发送第二请求,所述第二请求包含所述身份索引,所述第一业务方的标识信息,所述第二身份信息,以及所述第一业务方的公钥;
从所述第一应用接收安全身份信息,所述安全身份信息包括所述第一业务方的标识信息,以及加密信息,所述加密信息由所述第一应用利用所述第一业务方的公钥,对所述身份索引对应的用户的第二身份信息进行加密而得到;
根据所述第一业务方的标识信息,将所述加密信息发送至所述第一业务方。
在一个实施例中,注册信息还包括超时时间;在这样的情况下,每隔所述超时时间,重新生成二维码信息。
根据一种可能的设计,注册中心可以与特定应用的服务端位于同一物体实体中;在这样的情况下,注册信息可以包括第一字段,在所述第一字段具有第一值的情况下,指示出所述第一应用为所述特定应用,在所述第一字段具有第二值的情况下,指示出所述第一应用不是所述特定应用。
在一个实施例中,上述第一字段具有第一值,即,注册中心与第一应用的服务端位于同一物体实体中;此时,注册中心可以在本地将所述二维码信息提供给所述第一应用的应用逻辑;在本地将所述第二请求提供给所述第一应用的应用逻辑;然后,在本地从所述第一应用的应用逻辑获取所述安全身份信息。
根据第三方面,提供一种获取安全身份信息的方法,该方法由需要安全身份信息的业务方执行,包括:
读取用户通过第一应用展示的用户二维码,获得对应的二维码信息,所述二维码信息由注册平台根据所述用户的身份索引和所述第一应用的应用信息而生成,其中所述身份索引基于经过第三方可信核验源核验过的所述用户的第一身份信息的至少一部分而生成;
向所述注册平台发送身份请求信息,所述身份请求信息包括所述二维码信息,以及本业务方的业务索引信息,所述业务索引信息对应于本业务方预先向所述注册平台提交的业务注册信息,所述业务注册信息包括,本业务方的标识信息,本业务方需要的第二身份信息,以及本业务方的公钥;
从注册平台接收加密信息,所述加密信息由所述第一应用利用所述公钥,对所述用户的第二身份信息进行加密而得到;
对所述加密信息进行解密,获得所述用户的第二身份信息。
在一个实施例中,业务方通过以下步骤向所述注册平台发送身份请求信息:
通过解析所述用户二维码,确定所述注册平台的平台地址;
将所述二维码信息,所述本业务方的业务索引信息组合成为所述身份请求信息;
按照所述平台地址,将所述身份请求信息发送到所述注册平台。
在一个实施例中,业务方利用本业务方的私钥,对所述加密信息进行解密。
根据第四方面,提供一种提供安全身份信息的装置,该装置部署于可信应用服务端,包括:
第一信息获取单元,配置为响应于来自于用户的、用于请求身份核验的第一请求,获取核验所需的第一身份信息;
第一信息发送单元,配置为将所述第一身份信息发送至第三方可信核验源进行核验;
注册信息发送单元,配置为向注册平台发送用于进行注册的注册信息,所述注册信息包括所述用户的身份索引,所述身份索引基于经过核验的所述第一身份信息的至少一部分而生成;
二维码接收单元,配置为接收注册平台返回的二维码信息,用于展示对应的二维码以供扫描;
第二请求接收单元,配置为接收注册平台发送的第二请求,所述第二请求包含所述身份索引,扫描了所述二维码的第一业务方的标识信息,所述第一业务方所需要的第二身份信息,以及所述第一业务方的公钥;
身份信息生成单元,配置为生成安全身份信息,所述安全身份信息包括所述第一业务方的标识信息,以及加密信息,所述加密信息是利用所述第一业务方的公钥,对所述身份索引对应的所述用户的第二身份信息进行加密得到的;
身份信息发送单元,配置为将所述安全身份信息发送至所述注册平台,以使得注册平台根据所述第一业务方的标识信息将所述加密信息路由至所述第一业务方。
根据第五方面,提供一种获取安全身份信息的装置,该装置部署于注册中心,包括:
注册信息接收单元,配置为接收来自第一应用的注册信息,所述注册信息包括第一应用中的用户的身份索引,所述身份索引基于经过第三方可信核验源核验过的所述用户的第一身份信息的至少一部分而生成;
二维码生成单元,配置为根据所述身份索引和所述第一应用的应用信息,生成二维码信息,并将该二维码信息返回给所述第一应用;
身份请求接收单元,配置为从第一业务方接收身份请求信息,所述身份请求信息由所述第一业务方通过扫描所述二维码信息对应的二维码而生成,所述身份请求信息包括所述二维码信息,以及所述第一业务方的业务索引信息,所述业务索引信息对应于所述第一业务方预先向所述注册平台提交的业务注册信息;
确定单元,根据所述身份请求信息中包含的所述二维码信息,确定所述身份索引和所述第一应用的应用信息,以及根据所述业务索引信息,确定所述第一业务方的业务注册信息,其中包括第一业务方的标识信息,所述第一业务方需要的第二身份信息,以及所述第一业务方的公钥;
第二请求发送单元,配置为向所述第一应用发送第二请求,所述第二请求包含所述身份索引,所述第一业务方的标识信息,所述第二身份信息,以及所述第一业务方的公钥;
身份信息接收单元,配置为从所述第一应用接收安全身份信息,所述安全身份信息包括所述第一业务方的标识信息,以及加密信息,所述加密信息由所述第一应用利用所述第一业务方的公钥,对所述身份索引对应的用户的第二身份信息进行加密而得到;
加密信息发送单元,配置为根据所述第一业务方的标识信息,将所述加密信息发送至所述第一业务方。
根据第六方面,提供一种获取安全身份信息的装置,该装置部署于需要安全身份信息的业务方,包括:
二维码读取单元,配置为读取用户通过第一应用展示的用户二维码,获得对应的二维码信息,所述二维码信息由注册平台根据所述用户的身份索引和所述第一应用的应用信息而生成,其中所述身份索引基于经过第三方可信核验源核验过的所述用户的第一身份信息的至少一部分而生成;
身份请求发送单元,配置为向所述注册平台发送身份请求信息,所述身份请求信息包括所述二维码信息,以及本业务方的业务索引信息,所述业务索引信息对应于本业务方预先向所述注册平台提交的业务注册信息,所述业务注册信息包括,本业务方的标识信息,本业务方需要的第二身份信息,以及本业务方的公钥;
加密信息接收单元,配置为从注册平台接收加密信息,所述加密信息由所述第一应用利用所述公钥,对所述用户的第二身份信息进行加密而得到;
解密单元,配置为对所述加密信息进行解密,获得所述用户的第二身份信息。
根据第七方面,提供了一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行第一方面到第三方面的方法。
根据第八方面,提供了一种计算设备,包括存储器和处理器,其特征在于,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现第一方面到第三方面的方法。
通过本说明书实施例提供的方法和装置,在需要身份核验的情况下,用户通过可信应用来展示注册平台为其生成的二维码,业务方通过扫描该二维码从注册平台获得所需的身份信息。在请求生成二维码之前,可信应用首先将用户的身份信息发到第三方核验源进行核验,如此保证了提供身份信息的准确性和权威性。并且在以上过程中,通过注册平台来实现不同业务方与不同可信应用之间的互联互通,如此,业务方无需关注用户使用哪个应用来提供身份信息,核验更加灵活和便捷。
具体实施方式
下面结合附图,对本说明书提供的方案进行描述。
图1为本说明书披露的一个实施例的实施场景示意图。根据图1的实施例,在线下需要进行身份核验或提供身份信息的场景下,用户并不需要直接将身份信息提供给需要安全身份信息的业务方(也就是前述的场景商户),而是通过可信应用交由权威的第三方核验源进行身份核验。核验通过之后,由支持各种应用的、统一的注册平台生成用户二维码,经由可信应用进行展示。业务方通过扫描用户二维码,经由注册平台得到所需的用户身份信息。
具体地,在用户需要进行身份核验或提供安全身份信息的情况下,用户可以调用可信应用中的电子身份核验服务。此时,可信应用可以获取用户的身份信息,例如包括姓名,身份证信息,人脸信息等,将这些信息发往第三方核验源进行核验。在核验通过之后,可信应用基于已核验的信息向注册平台进行注册,从而获得针对该用户的二维码。用户于是可以通过可信应用展示该二维码。需要安全身份信息的业务方扫描该二维码,基于该二维码,经由注册平台向可信应用发出针对该用户的身份请求,请求获取所需的身份信息;接着,可信应用经由注册平台向业务方返回所需的身份信息。如此,可信应用将用户的身份信息交由第三方核验源核验之后,与注册平台交互,请求并获得二维码,之后经由注册平台提供业务方所需的身份信息。而业务方在扫描用户二维码之后,通过与注册平台交互,获取可信应用提供的经核验的身份信息。下面描述以上过程的具体实现步骤。
图2示出根据一个实施例的获取安全身份信息的方法。如图2所示,该方法至少涉及可信应用,核验源,注册平台和业务方。
核验源,又称为可信核验源或第三方核验源,是提供可信身份信息核验服务的第三方。第三方核验源通常掌握着可信的数据库,配置了可信电子身份的核验策略,通常支持可信凭证,根据提供的用户信息验证是否真实准确,并且其核验结果被认为是准确有效的。上述核验源例如包括,公安一所目前搭建的CTID网证平台,人口库等等。
业务方,或称为场景商户,是线下应用场景中需要安全身份信息的业务应用方。业务方原本需要线下根据实体证件确认用户身份,在确定了用户可信身份信息后,根据业务逻辑开展服务,如需要身份核验的酒店、行政办理大厅、网吧等等。
可信应用,是受到场景商户和第三方核验源信任的应用。该可信应用与可信核验源进行对接,通过签名确保双方的可信性。可信应用例如是支付宝。
注册平台负责维护业务方的注册,可信应用的注册,以及进行注册信息与码串的映射和解析。注册平台可以对接若干个可信应用,以及许多个业务方。
在进行图2所示的向业务方提供安全身份信息的过程之前,一般地,业务方需要预先向注册平台进行注册。具体而言,在注册阶段,业务方向注册平台提交业务注册信息,业务注册信息至少包括,业务方标识,需要验证的身份信息,公钥信息,还可以包含其他信息,例如一些描述信息等。
注册平台针对业务方提交的业务注册信息,生成业务索引,或称为业务令牌(token),将业务索引与业务注册信息绑定,换而言之,将业务索引与业务注册信息相关联、相对应地进行存储。之后,注册平台可以将业务索引返回给业务方,于是,业务方可以在其本地存储注册平台为其分配或为其生成的业务索引,以备后续与注册平台交互时使用。
下面描述用户通过可信应用进行身份核验,进而向某个业务方提供安全身份信息的过程。
可以理解,用户通常是自然人,也是电子核验身份的对象,如支付宝的用户。当用户在线下遇到需要身份核验的场景时,例如入住酒店需要核验身份时,取代于将身份证提供给酒店前台,用户可以向可信应用发出核验请求,调用电子身份核验服务。也就是,如图2所示,在步骤S201,可信应用接收到来自用户的、用于请求身份核验的请求。例如,在一个例子中,用户可以打开支付宝,进入“卡包”业务,点击相应选项,发起核验请求。
在步骤S202,可信应用获取核验所需的身份信息,此处称为第一身份信息。
需要理解,本文中的“第一”,“第二”仅仅是为了表述的清楚而对类似概念进行的标记和区分,并不具有其他限定作用。
在不同实施例中,第一身份信息可以包括,姓名,身份证号,民族,证件有效期,人脸照片,驾驶证信息等等中的一项或多项,具体内容可以根据核验源的要求,和/或可信应用的业务设定,和/或用户发出核验请求时所选择的场景或行业而不同。
在一个实施例中,该步骤S202中获取核验所需的第一身份信息可以包括,通过可信应用的客户端所在的终端,采集第一身份信息。例如,在一个例子中,可以通过终端上的摄像头采集人脸信息;在另一例子中,可以通过终端的NFC功能和其上的控件,读取身份证信息。
在另一实施例中,该步骤S202中获取核验所需的第一身份信息可以包括,通过可信应用的客户端,接收用户的输入信息,例如输入信息可以包括,用户姓名,身份证号等等。
在又一实施例中,该步骤S202中获取核验所需的第一身份信息可以包括,读取可信应用中存储的用户身份信息。例如,用户可以预先将其姓名、身份证号存储在可信应用客户端或服务端。如此,在步骤202,可以直接提取可信应用已经存储的用户身份信息,来减少用户手工输入的次数,提升用户便捷度。
以上实施例可以结合使用。例如,在一个例子中,可以通过终端的NFC功能和相应控件,读取用户的二代身份证,获取姓名、身份证号、证件有效期,并通过终端的摄像头采集人脸照片,作为第一身份信息。
在另一例子中,可以通过客户端接收用户手工输入的姓名、身份证号,并通过摄像头采集人脸照片,作为第一身份信息。
在一个实施例中,该步骤S202中获取核验所需的第一身份信息可以包括,读取预先生成的可信凭证。该可信凭证可以是用户预先向可信核验源申请,可信核验源对用户身份进行高安全级别验证之后,为用户颁发的凭证,其作用类似于电子身份证。申请和生成可信凭证的过程在后续结合其他实施例进行具体描述。
一般地,预先生成的可信凭证可以存储在用户终端的安全存储区中,或存储在本应用中,或存储在其他应用中。在用户已经具有可信凭证的情况下,在步骤S202中,可以读取该预先生成的可信凭证,作为第一身份信息的一部分。例如,在可信凭证存储于用户终端的安全存储区的情况下,可以从该安全存储区中读取该可信凭证;在可信凭证存储于本应用中的情况下,可以直接读取该可信凭证;在可信凭证存储在其他应用中的情况下,可以通过调用该其他应用读取该可信凭证。
该实施例可以与以上的实施例进一步组合使用。例如,在一个例子中,可以通过终端的NFC功能和相应控件,读取用户的二代身份证,获取姓名、身份证号、证件有效期;通过终端的摄像头采集人脸照片;以及读取可信凭证,将这些信息共同作为第一身份信息。
在另一例子中,可以通过客户端接收用户手工输入的姓名、身份证号,通过摄像头采集人脸照片,以及读取可信凭证,将这些信息共同作为第一身份信息。
如此,在步骤S202,可信应用通过多种方式,获取多种内容的第一身份信息。
然后,在步骤S203,可信应用将获得的第一身份信息发送给第三方核验源进行核验。这个过程中,可信应用和核验源可以通过签名和验签建立信任关系,确保数据的安全有效。
在接收到第一身份信息后,在步骤S204,核验源对该第一身份信息进行核验。
在一个实施例中,核验源保存完整的用户信息。这种情况下,核验源通过将第一身份信息与保存的用户信息直接比对,来进行用户身份核验。
在另一实施例中,核验源为了避免遭受攻击从而批量泄露用户信息,因此可以配置策略,仅保存用户信息的哈希值。这种情况下,核验源对接收到的用户身份信息进行同样的哈希运算,比较运算的哈希值和存储的哈希值,以此进行用户身份核验。进一步地,核验源可以在一定时间间隔内删除接收到的用户信息,以增加安全性。
在核验之后,在步骤S205,核验源向可信应用返回核验结果。核验结果可能对应有两种模式。在鉴别模式下,核验源反馈的是核验通过/核验失败的核验结果,在信息模式下,核验源可以返回某些信息,例如用户的民族信息。
尽管图2中仅示出了一个核验源,但是实际上,核验源也可以有多个。在这样的情况下,可以根据各个核验源的核验要求,将第一身份信息分为对应的多个组,将各组信息发送给对应的核验源,从各个核验源接收各自的核验结果。
在核验通过的情况下,在步骤S206,可信应用基于经过核验的第一身份信息生成身份索引,利用该身份索引向注册平台发起注册。换而言之,可信应用向注册平台发送注册信息,以请求针对该用户进行二维码注册,该注册信息中包含该用户的身份索引。
在一个实施例中,可信应用可以将经过核验的第一身份信息本身作为所述身份索引;或者,可以将经过核验的第一身份信息的一部分作为身份索引。在另一实施例中,可信应用可以对经过核验的第一身份信息进行加密或哈希操作,将操作结果作为身份索引;或者,对经过核验的第一身份信息的一部分进行加密或哈希操作,将操作结果作为所述身份索引。
在一个实施例中,可信应用还在注册信息中包括超时时间,以便使得注册平台可以根据超时时间更新二维码,从而支持动态二维码的生成。
下表示例性示出注册信息的例子。在该例子中,注册信息包含身份索引和超时时间,其中身份索引是对用户的身份证号和姓名(可以是第一身份信息的一部分)进行加密获得。
接着,在步骤S207,注册平台接收到可信应用发来的注册信息后,根据注册信息中的身份索引和发起注册的可信应用的应用信息,生成二维码信息。可以理解,每个二维码可以对应一个码串,该码串可以映射为二维码。因此,此处的二维码信息既可以是二维码本身,也可以是二维码对应的码串。
在一个实施例中,注册平台从注册信息中提取出身份索引,在该身份索引基础上加入发起注册的可信应用的应用信息,由此生成一个码串,并映射为二维码。该码串或该二维码都可以作为上述二维码信息。
具体地,在一个例子中,注册平台生成的二维码信息可以包括URL地址,该URL指向上述身份索引和可信应用的应用信息。在另一例子中,注册平台对用户的身份索引和可信应用的应用信息进行编码,得到一个编码码串作为二维码信息;由此,二维码信息中装载有用户的身份索引和可信应用的应用信息。
接着,在步骤S208,注册平台将二维码信息返回给可信应用。
需要说明的是,如前所述,在注册信息中包括超时时间的情况下,可以支持动态二维码。在这样的情况下,注册平台可以每隔所述超时时间,重新生成二维码信息,也就是更新二维码信息,然后再次发送给可信应用。
可信应用接收到二维码信息后,就可以通过客户端展示对应的二维码。于是,在步骤S209,需要安全身份信息的业务方可以扫描该二维码,来请求获得安全身份信息。
可以理解,二维码中都会携带该二维码的生成方的信息,例如标识或地址。因此,业务方扫描上述二维码之后,可以按照常规方式解析该二维码,确定出生成该二维码的注册平台。此外,业务方还可以获取到二维码信息。但是需要理解,上述二维码信息是注册平台根据一定规则,基于身份索引和应用信息进行编码、映射等各种操作而生成的,业务方虽然可以读取到二维码对应的码串,但是不能从中解析中用户信息和应用信息。因此,业务方仍然需要与注册平台交互,来获得所需身份信息。
相应地,在步骤S210,业务方向解析出的注册平台发送身份请求信息。具体地,业务方通过解析二维码确定出注册平台,可以获取到二维码信息。另一方面,如前所述,业务方在预先向注册平台注册时,会收到注册平台为其生成的业务索引信息(例如token),该业务索引信息与业务方提交的业务注册信息相对应。于是,业务方可以将业务索引信息,连同二维码信息一起,组合成身份请求信息;然后,按照解析出的注册平台的平台地址,将该身份请求信息发送到注册平台。
在步骤S211,注册平台接收到业务方发来的身份请求信息后,对该请求进行解析。具体地,注册平台可以从上述身份请求信息中,提取出业务方的业务索引信息以及二维码信息。
对于身份请求信息中包含的业务索引信息,注册平台可以根据该业务索引信息确定出对应的业务注册信息,其中至少包括,业务方的标识信息,需要验证的身份信息(以下称为第二身份信息),以及业务方的公钥。
对于身份请求信息中包含的二维码信息,注册平台根据生成该二维码的规则所对应逆规则,对其进行进一步解析,从中确定出用户的身份索引和可信应用的应用信息。
具体地,如前所述,在一个例子中,二维码信息中可以包括URL地址。在这样的情况下,在步骤S211,注册平台确定该URL地址指向的身份索引和可信应用的应用信息。
在另一例子中,二维码信息包括装载有用户身份索引和可信应用的编码码串。在这样的情况下,在步骤S211,注册平台通过解码的方式,从二维码信息中解析得到用户的身份索引和可信应用的应用信息。
如此,注册平台一方面获取到请求获取身份信息的业务方的信息(标识信息,需要的第二身份信息,公钥等),一方面从二维码信息中确定出所请求的用户,以及该用户所在的可信应用。于是,在步骤S212,注册平台将这些信息进行综合,向可信应用发出一个请求,在此称为第二请求。该第二请求中至少包含,用户的身份索引,业务方的标识信息,所需的第二身份信息,以及业务方的公钥。也就是通过第二请求告知可信应用,哪个业务方,需要哪个用户的哪些身份信息。
下表示出在一个实施例中,第二请求中包含的具体内容。
在上表的例子中,第二请求中包含了业务方标识,业务方公钥,针对的用户的身份索引,以及业务方需要的身份信息(第二身份信息),具体地,所需身份信息包括,身份证号,姓名,和人脸信息。
在接收到这样的第二请求后,在步骤S213,可信应用根据第二请求中的信息,生成安全身份信息。具体地,可信应用首先根据第二请求中包含的身份索引,确定对应的用户。如前所述,身份索引是可信应用基于用户的第一身份信息生成的,在一个实施例中,可信应用可以存储有身份索引与用户的对应关系。如此,可信应用可以基于该对应关系,确定出身份索引所对应的用户。然后,可信应用可以获取该用户的第二身份信息。一般地,第二身份信息与第一身份信息相对应,或者是第一身份信息的一部分。由于第一身份信息已经经过核验源的核验,因此此处获得的第二身份信息是可信赖的身份信息。接着,可信应用利用业务方的公钥,对获得的用户的第二身份信息进行加密,得到加密信息。
然后,可信应用将如此得到的加密信息,连同之前接收到的业务方的标识信息,作为安全身份信息,发送到注册平台,如步骤S214所示。
注册平台接收到可信应用发来的安全身份信息后,在步骤S215,将其中的加密信息发送给业务方。具体地,在一个实施例中,注册平台对安全身份信息进行解析,从中提取出加密信息,和业务方的标识信息。由于各个业务方也提前在注册平台进行了注册,因此注册平台可以根据业务方的标识信息确定出业务方的目的地址。于是,注册平台按照该目的地址,将加密信息发送至业务方对应的终端。
业务方接收到上述加密信息后,在步骤S216,对该加密信息进行解密,从而获得用户的第二身份信息。可以理解,该加密信息是可信应用利用业务方的公钥对用户的第二身份信息进行加密得到的,业务方本地存储有与该公钥对应的私钥。公钥与私钥是成对的秘钥,可以用于对另一秘钥加密的数据进行解密。因此,在一个实施例中,业务方利用自身的私钥,对接收到的加密信息进行解密,从而获得用户的第二身份信息。
在获得用户的第二身份信息之后,业务方就可以根据其业务逻辑开展服务,例如网吧可以判断用户年龄是否达到标准,酒店可以基于用户姓名和身份证号进行入住登记,等等。
通过以上描述可以看到,在线下需要进行身份核验或者提供身份信息的场景下,用户可以不必将身份证件交给业务方的工作人员,而是可以通过可信应用来展示二维码。业务方通过扫描该二维码而获得所需的身份信息。在该过程中,引入了公共的注册平台,来实现不同业务方与不同可信应用之间的互联互通。各个可信应用和各个业务方都向该注册平台进行注册,发出各种请求,注册平台根据请求生成二维码,维护注册信息与码串的映射和解析,并将可信应用提供的身份信息转发至业务方。并且,在请求生成二维码之前,可信应用首先将用户的身份信息发到第三方核验源进行核验,如此还保证了提供身份信息的准确性和权威性。
如本领域技术人员所知,一般地,可信应用包含客户端和服务端。客户端例如是移动终端上安装的App(例如支付宝App),或者PC机上的应用软件客户端,还可以是线下机具加载的软件,例如酒店配备的专用PC中安装的专用软件。在图2所示的方法中,可信应用与用户的交互均通过客户端进行。例如,在步骤S201,用户通过客户端发出核验请求,例如点击客户端界面中的相应选项。在一个实施例中,客户端将该核验请求转发到服务端。在步骤S202,根据一种实施方式,可以通过客户端采集或接收用户的第一身份信息的至少一部分。如前所述,在一些实施方式中,步骤S202也可以由服务端来执行,此时服务端通过读取预先存储的身份信息(包括可信凭证和/或其他身份信息)来获得第一身份信息。此外,在可信应用接收到注册平台的二维码信息后,也通过客户端来展示二维码。其他的步骤,即可信应用与核验源的交互步骤,以及与注册平台的交互步骤,均是通过服务端来执行。
图3示出根据另一个实施例的获取安全身份信息的方法。相比于图2所示的方法,图3的方法还包括了用户从第三方可信核验源申请获得可信凭证的可选步骤,以及可信应用对用户进行鉴权和访问控制的可选步骤。
如前所述,可信凭证是由可信核验源为用户颁发的用以证明其身份的电子凭证。图3的步骤S101到S105示出在一个实施例中,生成可信凭证的过程。
如图所示,首先在步骤S101,用户通过可信应用申请获取可信凭证。
然后,在步骤S102,可信应用采集用户的核验身份信息。核验身份信息根据可信核验源的核验要求而设置。一般来说,颁发可信电子凭证时的身份验证是高安全级别的验证,因此需要全面的身份信息。可以利用多种方式来采集用户的核验身份信息。
在一个实施例中,在该步骤S102,通过终端的NFC功能以及相应的控件,读取用户身份证的卡信息和身份内容信息,其中卡信息是身份证物理卡片本身的信息,用于标识和区分实体卡,例如二代身份证芯片中的DN号。而身份内容信息是身份证上可读可视的信息,例如身份证上显示的用户姓名,身份证号,有效期等等。另外,还利用摄像头采集人脸信息。将这些信息共同作为上述的核验身份信息。
在另一实施例中,接收用户手工输入的驾驶证相关信息,作为上述核验身份信息。
在又一实施例中,通过终端的NFC功能以及相应的控件,读取用户身份证的卡信息,例如芯片DN号;通过用户手工输入方式采集身份证号、姓名、民族信息;利用摄像头采集人脸信息。将这些信息共同作为上述的核验身份信息。
然后,在步骤S103,可信应用将核验身份信息发送给核验源。
接着,在步骤S104,核验源基于核验身份信息生成可信凭证。
在一个实施例中,核验源对用户的核验身份信息进行哈希,由此生成可信凭证。在另一实施例中,每个向核验源申请可信凭证的申请请求具有一个序列号,核验源将该序列号与核验身份信息进行组合,对组合的结果进行哈希,由此生成可信凭证。
然后,在步骤S105,核验源将生成的可信凭证返回给可信应用。
尽管在以上的图示中仅示出一个核验源,但是核验源也可以是多个。下面以2个核验源为例,说明多个核验源的情况。
在核验源包括第一核验源和第二核验源的情况下,可以将核验身份信息划分为第一核验源需要的第一核验信息,和第二核验源需要的第二核验信息。在步骤S103,将第一核验信息发送至第一核验源,将第二核验信息发送至第二核验源。
例如,在一个例子中,第一核验源为公安一所CTID平台,第二核验源为人口库。相应地,第一核验信息可以包括身份证卡信息,身份证号、姓名、人脸信息等,第二核验信息可以包括民族信息。于是,可以将身份证卡信息,身份证号、姓名、人脸信息等发送到公安一所CTID平台,将民族信息发送到人口库进行校验。
各个核验源校验之后会生成各自的凭证,返回给应用。于是,在步骤S104,可信应用从第一核验源接收第一凭证,从第二核验源接收第二凭证。进一步地,可信应用将所述第一凭证和第二凭证合并,从而生成用户所需的可信凭证。
另外,需要说明的是,在图3的示例中,用户申请可信凭证所利用的可信应用,与后续在业务方场景中展示二维码的可信应用为同一应用。然而,这并不是必须的。用户可以通过另一应用来申请获得可信凭证。
在一个实施例中,用户通过第一应用按照图2所示的方法展示二维码,提供身份信息;在此之前,用户通过第二应用申请获得可信凭证。该第二应用可以是其他与核验源对接的可信应用,例如银行开户核身时,所采用的专用应用。
在一个实施例中,第二应用所在的终端配备有专用的机具,可以便利地采集用户的核验身份信息。例如,银行***配备有身份证读卡机,可以读取身份证的卡信息,配备有专用摄像头,采集人脸信息。在这样的情况下,第二应用可以利用专用的机具来采集核验身份信息,发送到核验源校验,并生成可信凭证。
第二应用获取到可信凭证后,可以将其保存在用户终端的安全存储区中,或提供安全接口API,供其他应用调用。
在图2所示的步骤S202中,第一应用需要读取可信凭证的情况下,第一应用可以从用户终端的安全存储区中读取该可信凭证,或者通过API调用第二应用,读取该可信凭证。
需要理解,一般来说,可信凭证的申请和生成,是在用户请求身份核验之前预先进行的,并且是可选的。在用户请求身份核验之后,只是利用该可信凭证作为需要核验的第一身份信息的一部分。
在一个实施例中,在用户根据业务方的要求,请求身份核验的情况下,可信应用本身首先对用户进行鉴权和访问控制,从应用的层面判断用户是否有权限进行该身份核验。
如图3所示,在步骤S201,用户向可信应用发出核验请求,例如打开支付宝,进入“卡包”业务,调用其中的电子身份证。
在步骤S2011,可信应用向用户发出应用鉴权请求,例如向用户呈现要求用户输入鉴权信息的界面。鉴权信息例如可以是,账户密码,人脸,指纹等等。
接着,在步骤S2012,接收用户输入的鉴权信息,例如用户手工输入账户密码,或者用摄像头拍摄人脸,或者录入指纹,等等。
然后,在步骤S2013,可信应用基于用户录入的鉴权信息,对用户的本次操作进行应用鉴权。例如,对比用户本次录入的信息与之前在可信应用中记录的信息是否相同。
如果应用鉴权没有通过,则拒绝用户接入。在一个实施例中,还向用户返回提示信息,例如“不具备访问权限”或者“登录失败”。
在应用鉴权通过的情况下,执行后续步骤。这包括,在步骤S202,获取第一身份信息,以及后续的步骤S203-S216。这些步骤的执行方式与图2所示的相同,在此不再赘述。
如前所述,在图2的方法中,通过公共注册平台,实现与多个应用和多个业务方的互联互通。实际上,该注册平台可以与某个特定应用的服务端位于同一物体实体中,例如集成到支付宝服务器中。但是,注册平台仍然可以接收其他应用的注册信息,为其生成二维码。
图4示出根据另一实施例的获取安全身份信息的方法。在图4的实施例中,注册中心与某个特定应用位于同一物理实体中,因此简单地示出为可信应用+注册平台。下文中又将可信应用和注册平台共同所在的实体称为统一服务端。
在这样的情况下,注册平台仍然可以对接多个可信应用,包括本地的特定应用,和其他应用。各个可信应用仍然通过注册信息向注册平台发起针对某个用户身份核验的注册请求。在一个实施例中,注册信息可以包括一个特定字段(以下称为第一字段),用于标示发起请求的可信应用是否为注册平台本地的可信应用。
假定注册平台接收到来自第一应用的注册信息,该注册信息包括第一字段。在第一字段具有第一值(例如值为1)的情况下,指示出第一应用即为注册平台本地的特定应用,在第一字段具有第二值(例如值为0)的情况下,指示出第一应用不是本地的特定应用。
如果第一字段具有第二值,也就是,注册平台接收到的注册信息来自于非本地的可信应用,那么就按照图2所示的通信交互方式,执行后续步骤。
如果所述第一字段具有第一值,也就是,注册平台接收到的注册信息来自于本地的可信应用,那么注册平台与可信应用之间的交互都可以在本地执行,也就是如图4所示在统一服务端内部执行。
具体地,在注册平台生成二维码之后,可以在本地将二维码信息提供给可信应用的应用逻辑。因此,图2中的步骤S206到S208,可以在统一服务端内部执行,并在图4中示出为生成二维码的步骤。
在注册平台从业务方接收到身份请求信息之后,可以在本地将该请求提供给可信应用的应用逻辑。可信应用在其应用逻辑中准备好安全身份信息后,注册平台在本地从可信应用的应用逻辑获取该安全身份信息。也就是说,图2中的步骤S211到S214,可以在统一服务端内部执行,如图4所示。
除此之外的其他步骤,例如S201到S205的身份核验步骤,以及与业务方的交互步骤,与图2所示的相同,不再赘述。
通过图2到图4所示的实施例中的方法,在需要身份核验的情况下,用户通过可信应用来展示注册平台为其生成的二维码,业务方通过扫描该二维码从注册平台获得所需的身份信息。在请求生成二维码之前,可信应用首先将用户的身份信息发到第三方核验源进行核验,如此保证了提供身份信息的准确性和权威性。并且在以上过程中,通过注册平台来实现不同业务方与不同可信应用之间的互联互通,如此,业务方无需关注用户使用哪个应用来提供身份信息,核验更加灵活和便捷。
在以上的获取安全身份信息的过程中,涉及可信应用,注册平台和业务方的多方交互。下面分别描述以上各方的装置构成。
图5示出根据一个实施例的提供安全身份信息的装置的示意性框图,该装置部署于可信应用服务端。如图5所示,该装置500包括:
第一信息获取单元51,配置为响应于来自于用户的、用于请求身份核验的第一请求,获取核验所需的第一身份信息;
第一信息发送单元52,配置为将所述第一身份信息发送至第三方可信核验源进行核验;
注册信息发送单元53,配置为向注册平台发送用于进行注册的注册信息,所述注册信息包括所述用户的身份索引,所述身份索引基于经过核验的所述第一身份信息的至少一部分而生成;
二维码接收单元54,配置为接收注册平台返回的二维码信息,用于展示对应的二维码以供扫描;
第二请求接收单元55,配置为接收注册平台发送的第二请求,所述第二请求包含所述身份索引,扫描了所述二维码的第一业务方的标识信息,所述第一业务方所需要的第二身份信息,以及所述第一业务方的公钥;
身份信息生成单元56,配置为生成安全身份信息,所述安全身份信息包括所述第一业务方的标识信息,以及加密信息,所述加密信息是利用所述第一业务方的公钥,对所述身份索引对应的所述用户的第二身份信息进行加密得到的;
身份信息发送单元57,配置为将所述安全身份信息发送至所述注册平台,以使得注册平台根据所述第一业务方的标识信息将所述加密信息路由至所述第一业务方。
在一个实施例中,所述装置500还包括鉴权单元(未示出),配置为:向所述用户发出可信应用的应用鉴权请求;接收用户输入的鉴权信息;基于所述鉴权信息进行应用鉴权。在这样的情况下,所述第一信息获取单元51配置为,在所述鉴权单元进行的应用鉴权通过的情况下,获取所述第一身份信息。
在一个实施例中,所述第一信息获取单元51配置为,通过可信应用的客户端所在的终端,采集所述第一身份信息。
进一步地,该第一信息获取单元51可以通过终端上的摄像头采集人脸信息;和/或,通过终端的NFC功能和其上的控件,读取身份证信息。
在又一实施例中,所述第一信息获取单元51配置为,通过可信应用的客户端,接收用户的输入信息,所述输入信息包括,用户姓名,身份证号。
在另一个实施例中,所述第一信息获取单元51还可以读取预先生成的可信凭证。
根据一种实施方式,装置500还可以凭证获取单元50,上述可信凭证通过凭证获取单元50预先生成,该凭证获取单元50配置为:获取用户的核验身份信息;将所述核验身份信息发送至第三方可信核验源;以及,接收第三方可信核验源基于所述核验身份信息生成的所述可信凭证。
根据一种实施方式,第三方可信核验源包括第一核验源和第二核验源;所述凭证获取单元50配置为:
获取第一核验信息和第二核验信息作为核验身份信息;
将所述第一核验信息发送至所述第一核验源,将所述第二核验信息发送至第二核验源;
从所述第一核验源接收第一凭证,从所述第二核验源接收第二凭证;
将所述第一凭证和第二凭证合并,从而生成所述可信凭证。
在一个实施例中,装置500还包括注册信息生成单元(未示出),该单元通过以下方式生成身份索引:
将经过核验的第一身份信息作为所述身份索引;
将经过核验的第一身份信息的一部分作为所述身份索引;
对经过核验的第一身份信息进行加密或哈希操作,将操作结果作为所述身份索引;
对经过核验的第一身份信息的一部分进行加密或哈希操作,将操作结果作为所述身份索引。
在一个实施例中,身份信息生成单元56配置为,根据所述身份索引,确定对应的用户;获取所述用户的第二身份信息;利用第一业务方的公钥,对所述用户的第二身份信息进行加密,得到所述加密信息。
图6示出根据一个实施例的获取安全身份信息的装置的示意性框图,该装置部署于注册中心。如图6所示,该装置600包括:
注册信息接收单元61,配置为接收来自第一应用的注册信息,所述注册信息包括第一应用中的用户的身份索引,所述身份索引基于经过第三方可信核验源核验过的所述用户的第一身份信息的至少一部分而生成;
二维码生成单元62,配置为根据所述身份索引和所述第一应用的应用信息,生成二维码信息,并将该二维码信息返回给所述第一应用;
身份请求接收单元63,配置为从第一业务方接收身份请求信息,所述身份请求信息由所述第一业务方通过扫描所述二维码信息对应的二维码而生成,并包括所述二维码信息以及第一业务方的业务索引信息,其中所述业务索引信息对应于所述第一业务方预先向所述注册平台提交的业务注册信息;
确定单元64,根据所述身份请求信息中包含的所述二维码信息,确定所述身份索引和所述第一应用的应用信息,以及根据所述业务索引信息,确定第一业务方的业务注册信息,其中包括所述第一业务方的标识信息,所述第一业务方所需要的第二身份信息,以及所述第一业务方的公钥;
第二请求发送单元65,配置为向所述第一应用发送第二请求,所述第二请求包含所述身份索引,所述第一业务方的标识信息,所述第二身份信息,以及所述第一业务方的公钥;
身份信息接收单元66,配置为从所述第一应用接收安全身份信息,所述安全身份信息包括所述第一业务方的标识信息,以及加密信息,所述加密信息由所述第一应用利用所述第一业务方的公钥,对所述身份索引对应的用户的第二身份信息进行加密而得到;
加密信息发送单元67,配置为根据所述第一业务方的标识信息,将所述加密信息发送至所述第一业务方。
在一个实施例中,二维码生成单元62所生成的二维码信息包括:
URL地址,该URL指向所述身份索引和所述第一应用的应用信息;或者
编码码串,其中装载有所述身份索引和所述第一应用的应用信息。
根据一种实施方式,所述确定单元64配置为,根据二维码信息中包括的URL地址,确定所述URL地址指向的身份索引和所述第一应用的应用信息;或者,对二维码信息中包括的编码码串进行解析,得到所述身份索引和所述第一应用的应用信息。
根据一个实施例,注册信息接收单元61所接收的注册信息还包括超时时间;在这样的情况下,所述二维码生成单元62配置为,每隔所述超时时间,重新生成二维码信息。
在一个实施例中,所述加密信息发送单元67配置为:
从身份信息接收单元66所接收的安全身份信息中提取出第一业务方的标识信息,以及加密信息;
根据所述第一业务方的标识信息确定出第一业务方的目的地址;
按照所述目的地址,将所述加密信息发送至所述第一业务方对应的终端。
根据一种实施方式,装置600与特定应用的服务端(例如图5的装置500)位于同一物体实体中。
在这样的情况下,注册信息接收单元61所接收的注册信息包括第一字段,在所述第一字段具有第一值的情况下,指示出第一应用为与装置600位于同一物理实体的所述特定应用,在所述第一字段具有第二值的情况下,指示出所述第一应用不是所述特定应用。
在一个实施例中,所述第一字段具有第一值,即,装置600与第一应用的服务端位于同一物理实体中,在这样的情况下,所述二维码生成单元62配置为,在本地将所述二维码信息提供给所述第一应用的应用逻辑;所述第二请求发送单元65配置为,在本地将第二请求提供给所述第一应用的应用逻辑;并且,所述身份信息接收单元66配置为,在本地从所述第一应用的应用逻辑获取所述安全身份信息。
图7示出根据一个实施例的获取安全身份信息的装置的示意性框图,该装置部署于需要安全身份信息的业务方。如图7所示,该装置700包括:
二维码读取单元71,配置为读取用户通过第一应用展示的用户二维码,获得对应的二维码信息,所述二维码信息由注册平台根据所述用户的身份索引和所述第一应用的应用信息而生成,其中所述身份索引基于经过第三方可信核验源核验过的所述用户的第一身份信息的至少一部分而生成;
身份请求发送单元72,配置为向所述注册平台发送身份请求信息,所述身份请求信息包括所述二维码信息,以及本业务方的业务索引信息,所述业务索引信息对应于本业务方预先向所述注册平台提交的业务注册信息,所述业务注册信息包括,本业务方的标识信息,本业务方需要的第二身份信息,以及本业务方的公钥;
加密信息接收单元73,配置为从注册平台接收加密信息,所述加密信息由所述第一应用利用所述公钥,对所述用户的第二身份信息进行加密而得到;
解密单元74,配置为对所述加密信息进行解密,获得所述用户的第二身份信息。
在一个实施例中,上述身份请求发送单元72配置为:
通过解析所述用户二维码,确定所述注册平台的平台地址;
将所述二维码信息,所述本业务方的业务索引信息组合成为所述身份请求信息;
按照所述平台地址,将所述身份请求信息发送到所述注册平台。
根据一个实施例,所述解密单元74配置为,利用本业务方的私钥,对所述加密信息进行解密。
根据另一方面的实施例,还提供一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行结合图2到图4所描述的方法。
根据再一方面的实施例,还提供一种计算设备,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现结合图2到图4所述的方法。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。
以上所述的具体实施方式,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施方式而已,并不用于限定本发明的保护范围,凡在本发明的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括在本发明的保护范围之内。