CN113545000B - 交付时交互的分散式处理 - Google Patents

交付时交互的分散式处理 Download PDF

Info

Publication number
CN113545000B
CN113545000B CN201980093326.4A CN201980093326A CN113545000B CN 113545000 B CN113545000 B CN 113545000B CN 201980093326 A CN201980093326 A CN 201980093326A CN 113545000 B CN113545000 B CN 113545000B
Authority
CN
China
Prior art keywords
node
authorization
proxy
request message
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201980093326.4A
Other languages
English (en)
Other versions
CN113545000A (zh
Inventor
S·盖达姆
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
Original Assignee
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa International Service Association filed Critical Visa International Service Association
Publication of CN113545000A publication Critical patent/CN113545000A/zh
Application granted granted Critical
Publication of CN113545000B publication Critical patent/CN113545000B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0478—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload applying multiple layers of encryption, e.g. nested tunnels or encrypting the content with a first key and then with at least a second key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种方法包括由用户装置生成用于交互以从资源提供商获得资源的初始授权请求消息。所述用户装置将所述初始授权请求消息发送给代理网络中的第一节点，其中所述第一节点处理所述初始授权请求消息并且基于所述初始授权请求消息的所述处理将路由消息发送给所述代理网络中的第二节点，所述第二节点先前与所述资源提供商相关联。然后，所述用户装置从所述第二节点接收并且存储预授权批准指示符(PAAI)。在由所述资源提供商的代理交付所述资源时，所述用户装置发送包括所述预授权批准指示符的授权请求消息，其中所述代理装置还处理所述授权请求消息并且将其发送给所述代理网络以由授权实体进行授权。

Description

交付时交互的分散式处理
相关申请交叉引用
无。
背景技术
用于处理用户与资源提供商(例如，商家)之间的交易的系统和方法是已知的。例如，在支付交易的情况下，用户(例如，消费者)可以浏览商家的网站以寻找商品，将商品添加到推车，将对应于用户在发行方(例如，将支付凭证发行给用户的银行)的账户的用户的支付凭证(例如，主账号(PAN)数据)输入到所述网站，并且将待发送的订单提交到托管商家网站的商家服务器。然后，商家服务器可以将交易详情(包括支付凭证)转发到与商家相关联的支付网关。支付网关可以充当中间方以促进支付交易。然后，支付网关可以将请求授权的授权请求消息发送给发行方。然后，发行方可以生成授权响应消息，并且经由支付网关将所述授权响应消息发送给商家服务器。
在支付交易的一些方法中，在实际拥有商品并有机会验证商品处于可接受状态之前，用户可能不需要向商家进行支付。这种类型的支付交易模型可称为“交付时支付”(POD)。交付时支付有助于减小交易意外减少的可能性。这可能发生在用户接收商品的情况下，但稍后可能会变得混淆并且否认实际上已接收的商品。此外，在一些地方，商家可以将商品的交付委托给交付代理，由此在交付时，交付代理促进商品的实际支付。在一些情况下，当商品在待交付的运输途中时，它们可能部分损坏甚至不可运输。在此类情况下，用户可能不希望为商品进行支付和/或可能拒绝交付，在这种情况下，交付代理和商家必须协商以确定谁承担费用。
关于常规交付时支付类型的系统和方法，还存在与数据安全和处理效率有关的许多技术问题。此类问题由本发明的实施例来解决。
发明内容
实施例包括改进的方法、系统和计算机，其可以对交付交易上实施改进的交互(例如，支付)。
一个实施例包括一种方法，包括：由节点的代理网络中的第一节点从用户装置接收用于交互以从资源提供商获得资源的初始授权请求消息，所述初始授权请求消息包括交互标识符、用户数据和授权胶囊(capsule)，所述授权胶囊与授权实体相关联并且包括风险策略、所述用户的加密凭证、分别与所述代理网络中的所述节点相关联的多个重新加密密钥以及分别与所述重新加密密钥相关联的多个节点标识符；由所述第一节点使用所述用户数据和所述授权胶囊中的所述风险策略执行认证；由所述第一节点使用所述交互标识符和所述授权胶囊中的所述节点标识符确定所述多个重新加密密钥中的重新加密密钥，所述重新加密密钥与所述节点的代理网络的第二节点相关联；由所述第一节点并且利用与所述第二节点相关联的所述重新加密密钥对所述加密凭证进行重新加密以形成重新加密凭证；以及由所述第一节点向所述代理网络中的所述第二节点发送路由消息，所述路由消息包括所述重新加密凭证和所述交互标识符，其中所述第二节点随后使用所述第二节点的秘密密钥对所述重新加密凭证进行解密以获得明文凭证，然后生成预授权请求消息并且将其发送给授权实体以供批准，其中所述预授权请求消息在后续授权请求消息之前请求预授权，所述后续授权请求消息将在所述资源交付时由所述资源提供商的代理的代理装置发送。
另一实施例包括一种节点的代理网络中的第一节点，所述第一节点包括：处理器；以及耦合到所述处理器的计算机可读介质。所述计算机可读介质包括可由所述处理器执行以用于实施方法的代码。所述方法包括：从用户装置接收用于交互以从资源提供商获得资源的初始授权请求消息，所述初始授权请求消息包括交互标识符、用户数据和授权胶囊，所述授权胶囊与授权实体相关联并且包括风险策略、所述用户的加密凭证、分别与所述代理网络中的所述节点相关联的多个重新加密密钥以及分别与所述重新加密密钥相关联的多个节点标识符；使用所述用户数据和所述授权胶囊中的所述风险策略执行认证；使用所述交互标识符和所述授权胶囊中的所述节点标识符确定所述多个重新加密密钥中的重新加密密钥，所述重新加密密钥与所述节点的代理网络的第二节点相关联；利用与所述第二节点相关联的所述重新加密密钥对所述加密凭证进行重新加密以形成重新加密凭证；以及向所述代理网络中的所述第二节点发送路由消息，所述路由消息包括所述重新加密凭证和所述交互标识符，其中所述第二节点随后使用所述第二节点的秘密密钥对所述重新加密凭证进行解密以获得明文凭证，然后生成预授权请求消息并且将其发送给授权实体以供批准，其中所述预授权请求消息在后续授权请求消息之前请求预授权，所述后续授权请求消息将在所述资源交付时由所述资源提供商的代理的代理装置发送。
另一实施例包括一种方法，包括：由代理网络中的第二节点生成一对密码密钥，所述一对包括公钥和秘密密钥；由所述第二节点将所述一对的密码密钥发布到所述代理网络，其中授权实体从所述代理网络提取所述密码密钥，并且利用所述授权实体的秘密密钥和所述密码密钥生成重新加密密钥；由所述代理网络中的所述第二节点从所述代理网络中的第一节点接收路由消息，所述路由消息包括重新加密凭证和交互标识符，其中所述重新加密凭证是利用所述重新加密密钥进行加密的明文凭证，并且所述交互标识符对应于从资源提供商获得资源的交互，所述交互标识符包括对应于用户装置的用户装置标识符；由所述第二节点使用所述第二节点的所述秘密密钥对所述重新加密凭证进行解密以获得所述明文凭证；由所述第二节点并且基于所述交互标识符生成预授权请求消息，所述预授权请求消息包括所述明文凭证和对应于所述交互的交互数据；以及由所述第二节点将所述预授权请求消息发送给所述授权实体以供批准，其中所述预授权请求消息在后续授权请求消息之前请求预授权，所述后续授权请求消息将在所述资源交付时由所述资源提供商的代理的代理的代理装置发送。
另一实施例包括一种方法，包括：由用户装置生成用于交互以从资源提供商获得资源的初始授权请求消息；由所述用户装置向代理网络中的第一节点发送所述初始授权请求消息，其中所述第一节点随后处理所述初始授权请求消息并且基于所述初始授权请求消息的所述处理将路由消息发送给所述代理网络中的第二节点，所述第二节点先前与所述资源提供商相关联；由所述用户装置从所述代理网络中的所述第二节点接收预授权批准指示符(PAAI)；由所述用户装置存储所述预授权批准指示符；在由所述代理交付所述资源时，由所述用户装置向所述资源提供商的代理的代理装置发送包括所述预授权批准指示符的授权请求消息，其中所述代理装置还处理所述授权请求消息并且将其发送给所述代理网络以由授权实体进行授权。
在具体实施方式和附图中描述了关于本公开的实施例的其它细节。
附图说明
图1示出了描绘根据实施例的用于从资源提供商获得资源的示例性消息交换过程的流程图。
图2示出描绘根据实施例的可供应到用户装置上的示例性认证胶囊的图式。
图3示出描绘根据实施例的代理网络的示例性节点的框图。
图4示出描绘根据实施例的示例性用户装置的框图。
图5示出描绘根据实施例的用于从资源提供商获得资源的示例性消息交换过程的流程图。
图6示出描绘根据实施例的用于从资源提供商获得资源的另一示例性消息交换过程的流程图。
具体实施方式
处理交付时支付类型的交易的现有系统和方法存在许多挑战。例如，在一些情况下，用户可能不信任具有用户的个人信息(例如，PII/PAN数据)的商家，但仍然希望与商家执行交易。此外，即使用户的支付凭证在被发送给与商家相关联的支付网关时可以被加密(例如，使用银行的公钥)，支付网关也可能仍然需要联系银行服务器以(例如，使用银行的秘密密钥)对支付凭证进行解密以用于交易的进一步处理。例如在多个支付网关与多个银行服务器之间协调以管理每笔交易的此流程时，此在线组件显著增加了复杂性并且增加了基础设施要求(例如，支付网关联系银行服务器以对每笔交易的支付凭证进行解密)。另一个问题是，即使所有支付网关依赖于单个代理(在支付网关与银行之间)来促进此在线组件，所述单个代理也能够随着时间积累关于用户的个人信息(例如，购物模式)，这减少了用户隐私。单个代理也可能成为处理电子商务交易(例如，降低可靠性)的单点故障。
另一挑战在于处理涉及交付时支付的交易的方法。虽然交付时支付可以降低用户的风险，但这些类型的支付布置(例如，商家、交付代理与用户之间)比常规电子商务交易更复杂，因为它们可以包括或产生代理保险、结算延迟和现金处理程序。另外，类似于上述第一问题，用户在支付时可能不信任具有个人信息的商家的交付代理。当用户希望在支付时使用特定支付类型(例如，信用卡、密码货币、数字钱包等)时，又存在另一问题。交付代理维护多个机构(例如，代理装置上的多个应用程序)以便处理不同类型的支付可能是耗时且容易出错的。
实施例可以包括能够促进处理用户(例如，消费者)与资源提供商(例如，商家)之间的交易的方法和系统。在实例中，操作例如移动电话或笔记本电脑之类的用户装置的用户希望通过使用特定支付方法(例如，信用卡、借记卡)从商家的网站购买商品。此外，用户希望在由商家的交付代理(例如，交付人员)交付时对商品进行支付。可以采用包括三个阶段的方法来促进处理此实例交易。在第一(部署)阶段，可以采用用户与商家之间的中间实体并且可以将组件部署到多个实体。在第二阶段中，基于在第一阶段中部署的基础设施，用户可以向商家下订单，并且在第二阶段中请求来自授权实体(例如，银行)的预授权。最后，在稍后的第三阶段，当将商品交付到用户时，并且基于先前接收到的预授权批准，用户(经由交付代理装置)可以请求授权以完成支付交易。
更详细地转到第一阶段，首先，商家服务提供商(例如，支付网关)可以是与商家以及可选的用户支付装置(例如，信用卡)的发行方具有预先存在的关系的中间方。在这种情况下，支付网关可以被称为“目标支付网关”。目标支付网关可以操作计算机并且将计算机注册到包括多个节点的代理网络中，由此代理网络的每个节点对应于由(或代表)不同支付网关操作的一个或多个计算机。代理网络(PN)可以共同被配置成维护区块链，其中代理网络的每个节点都参与维护区块链。(有关区块链技术的更多详情的实例，请参阅J.Yli-Huumo、D.Ko、S.Choi、S.Park、K.Smolander。区块链技术的当前研究在哪里？——系统评论，在PLoS ONE上，11(10):e0163477，2016年)另外，代理网络的每个节点可以包括可信执行环境(TEE)，由此所述可信执行环境确保在可信执行环境内执行或操作的代码和数据在机密性和完整性方面受到保护。第二，作为注册的一部分，目标支付网关可以生成一对密码密钥，并且将所述一对的密码密钥发布到代理网络，使得发行方可以访问密码密钥(例如，公钥)。第三，发行方可以使用目标支付网关的公钥和发行方的私钥(也可以称为秘密密钥)，生成与目标支付网关相关联的重新加密密钥(RK)，并且将所述RK发布到代理网络。同时，在第四步骤中，用户可以在经由商家的网站发起交易之前，下载应用程序(例如，移动银行应用程序或钱包应用程序)并且将其安装到用户的用户装置上，所述用户装置对应于用户在发行方的账户。在安装/设置过程期间，发行方可以向用户装置提供数据容器对象，所述数据容器对象可以是“授权胶囊”(AC)。授权胶囊可以包含由发行方确定的风险策略(例如，关于用户行为数据、交易金额上限等的策略)、RK的白名单(例如，由发行方生成并且与代理网络中的特定节点相关联的每个RK)、多个节点标识符(例如，分别与白名单中的RK相关联的每个节点标识符)，以及用户的加密凭证(例如，加密PII/PA数据)。在实施例中，明文凭证可能已经使用发行方的公钥进行加密以形成密文(CT)。授权胶囊本身可以由发行方使用与代理网络中的一个或多个节点共享的共享密码密钥进行加密，并且还可以与用户的用户装置上的特定用户装置和应用程序相关联。在第五步骤中，商家的交付代理还可以将应用程序(例如，交付时支付应用程序)安装在代理装置上。代理装置可以是移动装置，所述移动装置被配置成与用户装置通信并且将交易数据发送给代理网络/从代理网发送交易数据。在第六步骤中，商家服务器可以下载并且安装应用程序(例如，JavaScript更新)，以便能够支持利用代理网络的交易。
在部署阶段之后的第二阶段(例如，预授权阶段)中，并且继续上述实例，用户在商家网站上下订单并且请求来自发行方的预授权以对订单进行支付。在第二阶段的第一步骤中，用户选择商家网站上的商品以添加到购物车。第二，用户提交订单(例如，点击网站上的按钮)。第三，商家服务器接着将订单信息发送给代理网络，由此所述订单信息包括代理网络的特定节点(例如，目标支付网关节点)与商家相关联的标识。代理网络的接收节点接收订单信息，生成交互标识符(例如，对应于特定交易详情和目标支付网关节点)，并且将交互标识符发送回到商家服务器。接收节点还将交互标识符发送给代理网络中要存储的每个节点以供将来参考。第四，商家网站显示编码交互标识符的快速响应(QR)码。第五，用户经由用户装置扫描QR码以完成结账。第六，扫描QR码提示用户装置将交互标识符、加密用户元数据(例如，使用代理网络的共享密码密钥进行加密的行为度量、用户名/密码等)作为初始授权请求消息发送给代理网络以及在第一阶段中设置在用户装置上的授权胶囊。第七，代理网络的第一节点从用户装置接收数据，并且执行若干操作，所述若干操作中的一个或多个可以在第一节点的可信执行环境内执行。这些操作包括(使用代理网络的共享密码密钥)对授权胶囊和用户元数据进行解密，以及基于授权胶囊和用户元数据内的风险策略认证交易，由此认证过程生成认证证明。在认证之后，第一节点接着可以将认证证明记录到区块链(并且将证明发送给其它代理网络节点以用于记录)，确定目标支付网关的RK是在授权胶囊中的RK的白名单内发现的，并且通过使用与目标支付网关相关联的RK对授权胶囊内的CT进行重新加密。基于交互标识符，第一节点路由到目标支付网关(例如，也可以称为“第二节点”)、重新加密CT(即，CT')和交互标识符。第八，目标支付网关使用目标支付网关的秘密密钥对CT'进行解密以输出明文凭证。第九，基于交互标识符和明文凭证，第二节点(例如，经由中间支付网络)将预授权请求消息发送给授权实体，并且接收包括预授权批准指示符(PAAI)(例如，其可以是预批准或拒绝的证明)的预授权响应。第十，在由目标支付网关接收到预授权响应时，目标支付网关将响应记录到区块链(并且将响应发送给其它代理网络节点以记录到每个节点的相应区块链)，并且将预授权批准指示符发送给用户装置。在接收到预授权批准指示符时，商家网站可以显示预授权已被批准并且订单已由商家的交付代理发出以供将来交付的确认。用户装置还可以保存预授权批准指示符以便在交付时供将来参考。
在预授权阶段之后的第三阶段(例如，交付阶段和授权阶段)中，并且继续上述实例，交付代理将商品交付给用户，由此用户验证商品处于可接受状态，并且请求来自授权实体的授权。在第三阶段的第一步骤中，交付代理将商品发送给用户。在交付之前，代理装置可能已经从商家服务器接收到关于交易的信息(例如，交易金额、购物车信息)。在交付时，用户装置在用户的装置上启动移动银行应用程序，所述移动银行应用程序最初在阶段二中用于提交初始授权请求消息，并且移动银行应用程序又在用户装置上显示QR码。QR码可以(例如，经由交易信息，例如先前存储在用户装置上的预授权批准指示符)与先前放置在阶段二中的订单相关联。然后，交付代理装置扫描正在显示的QR码，这使得用户装置上的移动银行应用程序提示用户签名(例如，数字签名)。在一些情况下，在接收到用户签名之前，如果商品在运输途中部分损坏，则交付代理具有将原始价格降到用户与交付代理之间协定的新价格的选项。第二，所述用户装置从用户接收数字签名以继续授权支付。第三，代理装置从用户装置接收包括用户的数字签名、预授权批准指示符和与移动银行应用程序相关联的授权胶囊(或授权胶囊标识符)的授权请求消息。第四，代理装置处理从用户装置接收的授权请求消息，并且基于从用户装置接收的信息、代理的数字签名和其它交易信息(例如，先前由代理装置从商家服务器接收的)向代理网络发送后续授权请求消息。第五，代理网络的第三节点(其可以是与第二阶段中的第一节点相同或不同节点)从代理装置接收后续授权请求消息并且执行若干操作，类似于由第一节点在阶段二的第七步骤中执行的操作。在完成那些操作时，第三节点将重新加密凭证(CT')连同交互标识符一起路由到第二节点(例如，目标支付网关)。第六，并且类似于阶段二的第八步骤，第二节点使用第二节点的秘密密钥对CT'进行解密以输出明文凭证。第七，基于交互标识符和明文凭证，第二节点(例如，经由中间支付网络)将授权请求消息发送给授权实体，并且接收授权响应。第八，在接收到授权响应后，目标支付网关将授权响应发送给代理装置和/或用户装置，以确认支付已被批准或拒绝。
实施例对常规系统进行了改进并且提供若干技术优势。第一，实施例提供了一种用于用户执行与商家的交易的方法，而无需向不可信方(例如，商家、交付代理、中间代理节点(例如，第一、第三节点))揭示用户个人信息(例如，用户凭证，例如PII/PAN数据)。例如，交易流程的一个方面(例如，使用上述实例，第二阶段的步骤一至六，以及第三阶段的步骤一至三)是用户不需要直接向商家或交付代理揭示其凭证。替代地，如上文所解释，用户获得对应于其订单的交互标识符，并且基于交互标识符继续经由代理网络获得交易的预授权。另一技术优势是，用户可以使用更广泛的应用程序来执行交易(例如，包括用户可能不信任的支付凭证、购物车信息等的应用程序)。这部分是因为可以使用仅由代理网络的节点已知的密码密钥对授权胶囊和用户数据进行加密。
另一技术优势涉及降低基础设施复杂性，同时维护用户隐私。例如，与可能需要在线组件的解决方案相反，在所述解决方案中每个支付网关联系银行服务器以对每笔交易的加密支付凭证进行解密(增加基础设施成本)，本公开利用重新加密密钥来降低基础设施复杂性。例如，当用户装置将加密凭证发送给代理网络(例如，第二阶段的步骤六)时，接收加密凭证的任何中间节点(例如，阶段二中的第一节点、步骤七和阶段三中的第三节点、步骤五)都能够对加密凭证进行重新加密，而无需首先在线联系单独的银行服务器以将凭证解密为明文形式。这可以使将凭证解密为明文形式所需的在线发送的消息总数减少至少两个(即，将解密请求消息发送给银行服务器，并且从银行服务器接收解密凭证)。当考虑到多个支付网关到银行服务器的集成、每次集成发生的大量用户交易以及向银行服务器进行在线调用所需的每次交易数据传输时，即使将每个交易中发生的消息总数减少很小的数量，这可产生显著的总体效率增益。此外，本公开避免了多个支付网关到银行服务器集成的基础设施复杂性。另外，在实施例中，银行不需要与任何中间方(例如，第一节点、第三节点)或目标支付网关(例如，第二节点)共享其秘密密钥，以便使得目标支付网关能够对重新加密凭证进行解密。
此外，如上文所提及，虽然单个代理解决方案减少了维护集成多个支付网关和银行服务器以对支付凭证进行解密的在线组件的基础设施复杂性，但它也带来了挑战(例如，允许单个代理累积用户个人信息，并且增加了成为单点故障的风险)。然而，在相对于单个代理解决方案的改进(例如，由此单个代理可以通常处理用户认证和支付凭证的重新加密)中，本公开描述了节点的分散式、支持区块链的代理网络，其确保没有单个节点会跨越多个支付网关累积用户私人信息(例如，购物模式)。另外，由于认证过程(例如，阶段二、步骤七)出现在节点的可信执行环境中，因此在认证期间，用户的个人信息不会暴露于代理网络的潜在受损节点。此外，受损代理网络节点的操作系统(OS)可能发生的任何篡改(例如，删除可信执行环境之外的节点存储装置中的区块链记录中的条目)都会很容易被参与维护区块链分类账的其它节点检测到。因此，利用分散式代理网络以按这种方式处理交易有助于提高交易完整性，同时维护用户隐私。这还有助于降低基础设施的复杂性，同时避免使单个代理节点成为单点故障的风险(即确保系统可用性以处理交易)。此外，本公开提供了在交付时支付类型的交易的上下文中的元素的唯一组合(例如，利用维护区块链的节点的分散式代理网络，每个节点都配备有以代表代理网络中的另一节点执行加密凭证的重新加密，并且使用可信执行环境内的授权胶囊的风险策略执行认证)。
另一技术优势涉及降低与交付时支付类型的交易相关联的交易风险和复杂性。例如，安装在代理装置上的单个交付时支付应用程序可以被配置成接收各种数字支付类型(例如，数字钱包、信用卡、密码货币等)。同时，分散式代理网络的每个节点被配置成根据具有由代理网络使用的标准化格式的交互标识符，将交易路由到适当的目标支付网关并且处理所述交易。因此，交付代理不再需要在代理装置上维护多个支付应用程序，由此每个应用程序处理不同的支付机制，这容易出现处理错误并且是耗时的。另一技术优势是，即使用户稍后可能(例如，错误地)认为商品未被交付/接收，代理网络的记录机构也向用户和商家提供更稳定的交易历史信息，以减少意外交易纠纷的情况。最后，另一技术优势是商家为实现交付时支付交易(例如，在商家网站上)而执行的基础设施升级步骤是最少的，从而减少了采用的障碍。具体地说，商家可以简单地下载并且安装热模块替换件(例如，JavaScript更新)，所述热模块替换件使商家服务器能够经由代理网络处理交付时支付交易。
在论述本公开的一些实施例的细节之前，对一些术语的描述可有助于理解各种实施例。
“用户装置”(例如，移动通信装置或由用户使用的移动装置)可以包括可由用户传送和操作的任何合适的电子装置。所述用户装置还可以将远程通信能力提供到网络。用户装置可以包括显示器、存储器、处理器、计算机可读介质以及任何其它合适的组件。用户装置可以使用移动电话(无线)网络、无线数据网络(例如3G、4G或类似网络)、Wi-Fi、蓝牙、蓝牙低功耗(BLE)、Wi-Max或可以提供对例如因特网或专用网络之类的网络的访问的任何其它通信介质。用户装置的实例包括移动电话(例如蜂窝电话)、PDA、平板计算机、上网本、膝上型计算机、可穿戴装置(例如，手表)、例如汽车和摩托车之类的车辆、个人音乐播放器、手持式专用读取器等。用户装置可包括用于执行此类功能的任何合适的硬件和软件，并且还可以包括多个装置或组件(例如，当装置通过网络共享(tether)到另一装置而远程访问网络时-即，使用另一装置作为调制解调器时-两个装置结合在一起可被视为单个移动装置)。
“非接触”通信可以是在两个装置之间交换数据而无需这两个装置物理耦合的通信。在不限制前述内容的一般性的情况下，“非接触”通信可以包括通过近场通信(NFC)收发器、例如QR码之类的机器可读代码、激光、射频、红外线通信或例如蓝牙、蓝牙低功耗(BLE)、Wi-Fi、iBeacon等其它射频或无线通信协议进行的数据发送。
“访问装置”可以是用于提供对某物的访问的任何合适的装置。访问装置可以采用任何合适形式。访问装置的一些实例包括销售点(POS)装置、蜂窝电话、PDA、个人计算机(PC)、平板PC、手持式专用读取器、机顶盒、电子现金出纳机(ECR)、自动柜员机(ATM)、虚拟现金出纳机(VCR)、查询一体机、安全系统、访问系统、网站等等。访问装置可使用任何合适的接触式或非接触式操作模式，以向用户装置发送或从其接收数据或者与用户装置相关联。在访问装置可以包括POS终端的一些实施例中，可使用任何合适的POS终端并且其可以包括读取器、处理器和计算机可读介质。读取器可包括任何合适的接触或非接触操作模式。例如，示例性读卡器可以包括射频(RF)天线、光学扫描器、条形码阅读器或磁条阅读器以与用户装置交互。
“资源提供商”可以是在交易期间提供资源(例如，商品、服务、对安全数据的访问、对位置的访问等等)的实体。例如，资源提供实体可以是商家、场所运营商、建筑物所有者、政府实体等。“商家”通常可以是参与交易且可以出售商品或服务或提供对商品或服务的访问的实体。
“认证数据”可以包括适于认证实体的任何数据。认证数据可以从用户或用户操作的装置获得。从用户获得的认证数据的示例可以包括PIN(个人标识号)、生物计量数据、密码等。可以从装置获得的认证数据的示例可以包括装置序列号、硬件安全元件标识符、装置指纹、电话号码、IMEI号等。认证数据还可以包括其它用户元数据，所述其它用户元数据包括行为属性(例如，用户购买的频率、典型交易金额等)。
“访问数据”可以包括任何合适的数据，所述数据可用于访问(或获得)资源或创建可访问资源的数据。在一些实施例中，访问数据可以是支付账户的账户信息。账户信息可以包括PAN、支付令牌、到期日期和验证值(例如，CVV、CVV2、dCVV、dCVV2)等。在一些实施例中，访问数据可以存储在用户装置上(例如，呈明文形式或使用密码密钥进行加密)以供稍后用于获得资源。在将访问数据用于交付时支付类型的交易中的实例中，访问数据可以不止一次地用于获得资源(例如，获得预授权，并且稍后在交付商品时获得授权)。
“访问请求”可以包括访问资源的请求。资源可以是物理资源(例如，商品)、数字资源(例如，电子文档、电子数据等)或服务。通常，在交付时支付交易中，资源可以是由资源提供商的代理交付的物理资源。在一些情况下，可以通过发送包括访问请求数据的访问请求消息来提交访问请求。通常，与请求方相关联的装置可以将访问请求消息发送给与资源提供商相关联的装置。
“访问请求数据”可以包括关于访问请求或与访问请求相关的任何信息。访问请求数据可以包括访问数据。访问请求数据可以包括可用于处理和/或验证访问请求的信息。例如，访问请求数据可以包括与参与处理访问请求的实体(例如，资源提供商计算机、处理服务器计算机、授权计算机等)相关联的细节，例如实体标识符(例如，名称等)、与实体相关联的位置信息和指示实体类型的信息(例如，类别代码)。示例性访问请求数据可以包括指示访问请求量、访问请求位置、接收到的资源(例如，产品、文档等)、关于接收到的资源的信息(例如，大小、量、类型等)、资源提供实体数据(例如，资源提供商数据、文档所有者数据等)、用户数据(例如，用户凭证)、访问请求的日期和时间、用于进行访问请求的方法(例如，接触、非接触等)，以及其它相关信息。
“凭证”可以是充当价值、所有权、身份或权限的可靠证据的任何合适的信息。凭证可以是一串数字、字母或任何其它合适的字符，以及可用作确认的任何对象或文件。凭证的示例包括价值凭证、标识卡、认证文件、访问卡、口令和其它登录信息等。凭证的其它示例包括主账号(PAN)、个人可标识信息(PII)，例如姓名、地址和电话号码等。
“授权实体”可以是通常使用授权计算机来授权请求的实体。授权实体可以是发行方、政府机构、文件存储库、访问管理员等。“发行方”通常可以包括维护用户账户的商业实体(例如，银行)。发行方还可向用户发行存储在蜂窝电话、智能卡、平板电脑或笔记本电脑等用户装置上的支付凭证。
“支付网关”(PG)可以包括可以充当支付交易前端的一个或多个计算机。在一些情况下，支付网关可以从商家获得信息(例如，凭证、金额和其它信息)以进行处理并且将所述信息发送给下游实体，例如收单方、支付处理器或发行方。在一些情况下，支付网关可以是支付处理网络内的中间实体，所述中间实体通过在支付门户(例如，网站、手机)与授权实体之间传送信息来促进支付交易。支付网关通常提供为资源提供商授权信用卡或进行直接支付处理的资源提供商服务。因此，资源提供商(例如，商家)可以与特定支付网关相关联，并且特定支付网关可以与附属于一个或多个授权实体。
“授权请求消息”可以是请求对交易的授权的消息。在一些情况下，授权请求消息可以是发送给支付处理网络(例如，支付网关)和/或支付卡的发行方以请求授权交易的电子消息。授权请求消息可以符合ISO 8583，所述ISO8583是用于交换与由用户使用支付装置或支付账户进行的支付相关联的电子交易信息的系统的标准。授权请求消息可以包括可与支付装置或支付账户相关联的发行方账户标识符。授权请求消息还可以包括对应于“标识信息”的额外数据元素，仅作为实例包括：服务代码、CVV(卡验证值)、dCVV(动态卡验证值)、到期日期等。
“授权响应消息”可以是对授权请求消息的电子消息回复。在一些情况下，授权响应消息由发行金融机构或支付处理网络生成。授权响应消息可以包括(只作为示例)以下状态指示符中的一个或多个：批准-交易被批准；拒绝-交易不被批准；或呼叫中心-响应等待更多信息，商家必须呼叫免费授权电话号码。授权响应消息还可以包括授权代码，所述授权代码可以是信用卡发行银行响应于电子消息中的授权请求消息(直接地或通过支付处理网络)返回给商家的访问装置(例如，POS设备)和/或指示交易被批准的用户装置的代码。所述代码可以充当授权的证据。
“服务器计算机”通常是功能强大的计算机或计算机集群。例如，服务器计算机可以是大型主机、小型计算机集群或充当单元的一组服务器。在一个示例中，服务器计算机可以是耦合到网络服务器的数据库服务器。
“处理器”可以包括任何合适的一个或多个数据计算装置。处理器可以包括一起工作以实现期望的功能的一个或多个微处理器。处理器可以包括CPU，所述CPU包括足以执行用于执行用户和/或系统生成的请求的程序组件的至少一个高速数据处理器。CPU可以是微处理器，例如AMD的Athlon、Duron和/或Opteron；IBM和/或摩托罗拉(Motorola)的PowerPC；IBM和索尼(Sony)的Cell处理器；英特尔(Intel)的Celeron、Itanium、Pentium、Xeon和/或XScale；和/或类似处理器。
“存储器”可以是可存储电子数据的任何合适的一个或多个装置。合适的存储器可包括非瞬态计算机可读介质，其存储可由处理器执行以实现所要方法的指令。存储器的实例可包括一个或多个存储器芯片、磁盘驱动器等。此类存储器可使用任何合适的电气、光学和/或磁性操作模式来操作。
“可信执行环境”(TEE)可以是计算环境内的安全区域(例如，保留存储器)。具体地说，可信执行环境提供隔离的执行环境(例如，与在计算环境中执行的OS并行运行)，所述隔离的执行环境确保在可信执行环境内执行的应用程序的完整性以及在可信执行环境内处理的数据的机密性。换句话说，不在可信执行环境内执行的OS和/或不可信应用程序不得篡改在可信执行环境执行的代码。
“应用程序”可以是用于特定目的的计算机程序。应用程序的实例可以包括银行应用程序、数字钱包应用程序、忠诚度奖励应用程序等。在一些实施例中，应用程序可以与由资源或服务提供商维护的用户账户(例如，银行账户、忠诚度奖励账户)相关联。
“交互标识符”可以是用于标识实体之间的唯一交互的一系列字符。在实例中，交互可以在用户(例如，消费者)与资源提供商(例如，商家)之间，例如涉及购买商品。交互还可以涉及可以利用交互标识符来标识交互的其它中间实体(例如，支付网关、授权实体)。交互标识符可以包括例如字母、数字、符号之类的字符。为了标识唯一交互，交互标识符可以利用动态数据元素(例如，随着每个交互而改变)。例如，它可以涉及随机生成的数字(例如，密码随机数)、一天中的时间或任何合适的形式。交互标识符还可以包括(例如，连接)除动态数据元素之外的其它信息，例如，包括用于将交互标识符路由到特定目的地或确定其它交互处理步骤的信息。
“交互数据”可能是与特定交互相关联的数据。这可仅以举例的方式包括与消费者的采购订单有关的交易信息，例如购物车信息、交易金额和/或商家信息。所述交互数据还可以包括与涉及处理交互的中间方(例如，商家的交付代理)有关的信息等。
“授权胶囊”可以是可用于处理交互的数据和/或代码的容器。授权胶囊可以使用密码密钥(例如，使用由多个实体共享的公共/秘密密钥配对的公钥进行加密)进行加密或签名。授权胶囊可以利用任何合适的数据结构或数据结构(例如，数据阵列、字符串、表格等)的组合。授权胶囊内的数据可用于执行特定交互(例如，用户与商家之间的商品购买)的认证。例如，包括在授权胶囊内的数据成分可以包括支付凭证，例如PII/PAN数据、路由信息、用于处理与交互有关的数据的密码密钥、用于执行交互认证的策略数据等。授权胶囊中的每个数据成分可以被加密或呈明文格式。授权胶囊内的代码可以是包含可由处理器执行的指令的软件。在一些实例中，代码可用于对授权胶囊的数据成分中的一个或多个执行操作。授权胶囊内的代码还可用于(例如，通过限定代码内的开始点和结束点)限定授权胶囊内的代码和/或数据的部分，所述部分仅可在可信执行环境中访问。仅作为实例，授权胶囊可以限定对应于授权实体的策略执行功能的代码的一部分，所述一部分仅在可信执行环境中执行。
“接收节点”可以是计算装置(例如，服务器计算机)，其被配置成接收和处理对应于发起交互的请求的消息。在一个例子中，接收节点可以是连接到其它节点的网络的节点。在此实例中，网络的一个或多个节点可以被配置成作为接收节点操作。被配置成作为接收节点操作的节点还可以被配置成执行其它功能(例如，执行对交互的认证)。接收节点可以接收与交互有关的信息(例如，如交易金额、购物车信息、商家信息、支付网关信息之类的交互数据)，并且生成对应于交互的交互标识符。在节点的网络内存在接收节点的情况下，所述接收节点还可以负责将消息发送给网络的其它节点，使得在接收到包含交互标识符的消息时，网络的另一节点可以适当地处理所述消息。这种处理可以涉及例如将交互标识符与特定交互相关联和/或生成后续消息并且将其路由到适当的目的地(例如，网络中的另一节点或授权实体)。
“路由消息”可以是由节点网络的节点发送给网络内的另一节点的消息。路由消息可以包括用于处理交互的信息，包括交互数据、交互标识符、用户凭证或其它合适的信息。发送路由消息的节点可以首先从外部实体接收节点网络(例如，用户装置)的消息(例如，用于交互的授权请求消息)。基于来自外部实体的第一消息内的信息(例如，交互标识符)，节点可以确定网络中哪个节点应是路由消息的目标目的地。在一些实例中，节点可以在将路由消息发送给目标目的地节点之前进一步处理消息。
现在将更详细地描述本公开的一些实施例的细节。为了清楚起见，在后续图示中示出特定数目个组件。然而，应理解，本公开的实施例可以包括多于一个的每种组件。此外，每个图示中的组件可以经由任何合适的通信介质(包括因特网)使用任何合适的通信协议来进行通信。
图1示出描绘根据实施例的涉及部署和使用RK以从资源提供商获得资源的消息交换过程的流程图100。具体地说，图1步骤S110-S122描绘上文所描述的第一(即，部署)阶段的方面，由此RK由授权实体(AE)105创建，RK与代理网络101中的特定节点(例如，第二节点104)相关联，并且授权实体105将RK发布到代理网络101。随后，授权实体105向用户装置102提供先前由授权实体105生成的多个RK。步骤S124-S138还描绘在第二(即，预授权)和/或第三(即，授权)阶段期间使用RK的过程。
在步骤S110处，授权实体105(例如，如银行之类的发行方)根据特定代理重新加密(PRE)方案生成密码密钥对(例如，公钥和秘密密钥)。应理解，尽管将在以下步骤中论述特定代理重新加密方案(即，Ateniese、Fu、Green和Hohenberger，2005年(“AFGH”))，但其它代理重新加密方案是众所周知的，并且任何合适的代理重新加密方案可用于实现目前公开的实施例。(有关AFGH的更多详情，请参阅G.Ateniese、K.Fu、M.Green和S.Hohenberger。使用到安全分布式存储装置的应用程序的改进代理重新加密方案。在NDSS中，第29-43页，2005年)作为另一合适的代理重新加密方案的非限制性实例，Blaze、Bleumer和Strauss，1998年的(“BBS”)方案也可用于实现本公开。(有关BBS的更多详情，请参阅M.Blaze、G.Bleumer和M.Strauss。可编辑方案和原子代理加密图。可转换协议和原子代理密码术。在EUROCRYPT'98中，LNCS的第1403卷，第127-144页，1998年。)更详细地讲AFGH代理重新加密方案的使用，所述方案需要随机生成器g∈G1和Z＝e(g，g)∈G2(其中G1、G2是具有双线性映射e:G1xG2→G2的两组素数阶q)。因此，授权实体105的公钥(PKAE)和秘密密钥(SKAE)可以分别表示为一对：(PKAE，SKAE)＝(ga，a)，其中a在中随机选择。
在步骤S112处，节点的代理网络101中的第二节点104根据步骤S110的特定代理重新加密(PRE)方案生成一对密码密钥(例如，公钥和秘密密钥)。应理解，在一些实施例中，步骤S112可以在步骤S110之前。在一些实施例中，第二节点104可以是对应于例如支付网关之类的支付处理网络中的中间服务的计算机(或计算机服务器)。第二节点104可以与一个或多个商家(图1中未示出)具有提供所述服务的关系。此外，在一些实施例中，第二节点104可以附属于特定发行方105(例如，被批准以代表发行方认证交易)。例如，发行方可以向其客户提供支付网关104作为服务。在其它情况下，支付网关104可以由单独的第三方服务提供商提供，但与发行方105具有隶属关系。(下文图3论述关于代理网络101的节点(例如，第一节点103、第二节点104)的其它细节。)回到步骤S112，并继续上文引入的AFGH重新加密方案，第二节点(N2)104生成公钥(PKN2)和秘密密钥(SKN2)，其可以分别表示为一对：(PKN2,SKN2)＝(gb，b)，其中b在中随机选择。
在步骤S114处，第二节点104将公钥(PKN2)发布到代理网络101，使得授权实体105能够提取公钥(PKN2)。在一些实施例中，授权实体105与代理网络101通信连接，使得授权实体105能够提取由代理网络节点104公布的公钥(PKN2)。在实例中，代理网络101可以操作充当密钥媒介(未示出)的节点。当代理网络的节点(例如，第二节点104)将公钥(PKN2)发送给媒介时，所述媒介又将发送新公钥(PKN2)可用于向媒介注册的授权实体的通知。应理解，可以使用任何合适的机构将公钥(PKN2)发布到授权实体105。
在步骤S116处，授权实体105根据特定代理重新加密方案的特性生成重新加密密钥(RKAE→N2)。代理重新加密方案的算法利用RKAE→N2将在一个实体(例如，授权实体105的PKAE)的公钥下加密的加密消息(例如，支付凭证)转换成在另一个实体(例如，第二节点104的PKN2)的公钥下加密的加密消息。以此方式，第二节点104能够在不知道授权实体105的秘密密钥的情况下对加密消息的内容进行解密。继续AFGH方案实例，授权实体105可以通过使用对(SKAE，PKN2)作为对输出RKAE→N2的代理重新加密RK生成函数的输入来生成RKAE→N2。例如，RKAE→N2可以如下计算：RKAE→N2＝(gb)1/a＝gb/a。应理解，在一些实施例中，例如使用不同PRE方案，可以使用不同输入生成RK。例如，在BBS PR方案下，可以使用第二节点104的秘密密钥(SKN2)生成RK。在次情况下，第二节点104可能需要先前已经与授权实体105共享SKN2。在任一情况下，RKAE→N2可以从授权实体105的私钥和第二节点104的密码密钥(例如，AFGH方案下的公钥(PKN2)、BBS方案下的私钥(SKN2))导出。
在步骤S118处，授权实体105可以将RKAE→N2发布到代理网络101。例如，授权实体105可以将RKAE→N2发送给密钥媒介节点(上文描述，未示出)以供存储。在一些实施例中，授权实体105可以专用于本地服务器，用于存储由授权实体105生成的待检取并且用于稍后提供到用户装置的RK(例如，步骤S122)。任何合适的存储机构可用于执行本公开的实施例。
在步骤S120，授权实体105可以使用授权实体105的公钥(PKAE)对明文消息(m)进行加密，所述明文消息可以表示用户的明文凭证(例如，PII/PAN数据)。在一些实施例中，在执行步骤120(未示出)之前，用户可能已经将应用程序(例如，授权实体105的移动银行应用程序)下载并且安装到用户装置102上。作为应用程序设置过程的一部分，用户可以输入对应于用户在授权实体105的账户的个人信息，并且将所述信息发送给授权实体105，以便向用户装置102提供访问数据，所述访问数据可稍后用于使用用户装置105进行交易。在将所述个人信息发送给授权实体105时，所述授权实体105可以检取对应于用户账户的用户凭证，然后在步骤S120中将用户凭证加密成密文(CT)。继续将AFGH方案作为实例，密文可以表示为对：
CT＝(Zr*m，gra)，其中m∈G2，并且r是中的随机数。
在步骤S122处，授权实体105可以将CT和RK的白名单(例如，包括RKAE→N2等)作为设置过程的一部分发送给用户装置102，(例如，用户可能在移动银行应用程序的设置期间发起，如上文所论述)。更具体地说，授权实体105可以使在用户装置102上设置授权胶囊(AC)，下面将参考图2进一步讨论。在实例中，授权实体105可以首先从存储由授权实体105发布的RK的代理网络的密钥媒介提取RK(例如，步骤S118)。接下来，授权实体105可以将提取的RK包括到RK的白名单中(白名单是授权胶囊的部分)，由此白名单中的每个RK可以分别对应于代理网络101中与授权实体105相关联(例如，附属)的节点。在实例中并且仅出于说明目的，可以允许授权实体105与日本和美国(美国)，但不与韩国的用户和商家进行交易。因此，授权实体105可能附属于在日本和美国运营的支付网关，但不附属于在韩国运营的支付网关。因此，在将授权胶囊内的RK的白名单提供到用户装置102时，授权实体105可以仅包括对应于授权实体105先前为其生成RK的美国和日本的支付网关的节点的RK。在另一实例中，授权实体105可以附属于使用密码货币处理交易的支付网关，而另一支付网关可以处理涉及信用卡的交易。授权实体105可以附属于两个支付网关，以支持更广范围的交易支付，因此对应于两个支付网关节点(例如，RKAE→N1、RKAE→N2)的RK可以包括在白名单内。如上所述，除了RK的白名单之外，授权实体105还可以在授权胶囊内提供先前在步骤S120中生成的CT。然后，授权胶囊可以存储在用户装置102上，以供稍后用于进行交易。
在完成步骤S122之后，应理解，在图1的流程图100的此时，第一阶段(即部署阶段)已经完成。具体地说，每个授权实体105可能已经生成一个或多个RK并且将其发布到代理网络101(例如，步骤S116、S118)，每个RK是基于授权实体105的秘密秘钥(例如，SKAE)和由代理网络101中的节点(例如，第二节点104)发布的密码密钥(例如，PKN2)生成的。此外，已经为用户装置102提供了包含RK白名单和加密凭证(CT)的授权胶囊。在下面描述的后续步骤S124-S138中，主要关注如何使用先前在较早步骤中部署的RK来执行交易。应理解，尽管下面描述的步骤S124-S138侧重于交付时支付交易的预授权阶段，但是在将资源交付给用户后的后续授权阶段期间可以采取类似的步骤(如下面参考图5和6进一步描述的)。
在步骤S124处，通过将初始授权请求消息发送给代理网络101中的第一节点103，用户装置102在交付时支付交易中从授权实体105发起对预授权的请求。初始授权请求消息包含交互标识符(其可标识与交易中涉及的商家相关联的第二节点104)、在步骤S122中提供到用户装置上的授权胶囊和其它用户数据(例如，用户行为元数据)。应理解，第一节点103可以表示代理网络101的任何节点。换句话说，已加入代理网络101的任何节点可以被配置成接收和处理从用户装置102发送的初始授权请求消息，如下面进一步解释。
在步骤S126处，第一节点103通过使用授权胶囊中的风险策略和在初始授权请求消息内发送的用户数据来执行认证(下面参考图2进一步论述)。
在步骤S128中，在确认步骤S126中的认证成功时，第一节点103可以通过使用RKAE→N2对CT进行重新加密。作为初步步骤，第一节点103可以首先确定第二节点104的RK是否在包括在授权胶囊中的RK白名单中被找到。例如，进行交易的商家可以与已加入代理网络101的韩国支付网关(例如，作为第二节点104操作)相关联。在接收到初始授权请求消息时，即使在步骤S126中执行的认证可能成功，第一节点也可以确定白名单不包含对应于授权实体105和第二节点104的RKAE→N2。在此实例中，第一节点103接着可以通过任何合适的机制(例如，将故障消息返回到用户装置)终止交易。然而，在另一实例中(例如，第二节点104在日本操作并且附属于授权实体105)，当确定在白名单中找到RKAE→N2时，第一节点103可以通过使用RKAE→N2执行重新加密。继续上文引入的AFGH代理重新加密方案，重新加密算法可以产生新的CT(即CT')作为输出，并且可以由以下等式表示为一对：
CT'＝(Zr*m，e(gra，RKAE→N2))＝(Zr*m，e(gra，gb/a)＝(Zr*m，Zrb)；
在步骤S130处，部分地基于包括在交互标识符内的路由信息(例如，将第二节点104标识为目标支付网关)，第一节点103将包括CT'和交互标识符的路由消息发送给第二节点104。
在步骤S132处，在从第一节点103接收到CT'和交互标识符时，第二节点104可以通过使用第二节点104的秘密密钥(SKN2)对CT'进行解密以输出原始消息(m)(例如，明文凭证)。继续上文引入的AFGH代理重新加密方案，解密算法可以对CT'进行解密，如以下表示中描绘的：
m＝(Zr*m)/(Zrb)1/b；
如上所述，应理解，本公开的技术优势在于，第二节点104不需要首先获得授权实体的秘密密钥(SKAE)，以便对CT'进行解密以获得m。这促进了对中间方(例如，商家、交付代理、第一节点103)隐藏加密的个人信息的过程，同时仍然允许第二节点104对加密凭证进行解密。这样就不需要复杂的基础设施来支持对银行服务器的在线调用以对加密凭证进行解密。
在步骤S134处，第二节点104可以将包含支付凭证(例如，PII/PAN数据)和其它交易信息(例如，从交互标识符导出的)的预授权请求消息发送给授权实体105。预授权请求消息可以采用授权请求消息的形式，但在后续授权请求之前是初始授权请求。
在步骤S136处，授权实体105处理预授权请求消息并且将预授权响应消息发送给第二节点104(例如，包含对应于预授权批准或拒绝证明的预授权批准指示符(PAAI))。
在步骤S138处，第二节点104将预授权响应消息转发到用户装置102和商家网站(未示出)。如上文所提及，应理解，尽管参考交付时支付交易的预授权过程描述了步骤S124-S138，但是在将资源交付给用户后的后续授权阶段期间可以采取类似的步骤(如下面参考图5和6进一步描述的)。关于上述系统组件和/或操作(例如，认证过程)的其它详情将参考后续图示进一步解释。
图2示出描述根据实施例的可被提供到用户装置102上的认证胶囊(AC)的框图200。在图2中，AC 202包括四个组件：认证策略204、RK的白名单206、节点标识符的列表207(每个节点标识符分别与白名单206的RK相关联)以及加密凭证214。认证胶囊202本身可被构造成数据容器的形式，其可对应于任何合适的数据结构(例如，认证胶囊202的每个组件的一个或多个阵列或表格)。在一些实施例中，认证胶囊202可对应于包含指令(例如，代码)和数据的应用程序，由此代码可以由(例如，代理网络节点的)处理器执行以执行涉及组件204、206、207、214中的一个或多个的操作。在一些实施例中，认证胶囊202可以包括限定应用程序内的数据和/或代码的可信部分和不可信部分的代码。例如，可信部分可以限定代码和数据的私有区(例如，“飞地(enclave)”)，所述代码和数据的内容受保护并且不能被飞地本身之外的任何进程读取或保存，并且只能在可信执行环境中执行和/或访问(下面将参考图3中代理网络节点的可信执行环境进一步讨论)。例如，认证胶囊202可以包括基于用户元数据并且使用授权实体105的认证策略204来执行用户认证的模块。认证胶囊202认证模块可确定此功能(包括其操作的数据)仅可在可信执行环境内执行，从而确保数据隐私和代码执行的完整性。
此外，在一些实施例中，认证胶囊202本身可以使用由代理网络101的每个节点共享的密码密钥进行加密或签名。在实例中，代理网络101的每个节点可以共享公共/秘密密钥配对(其不同于图1中描述的重新加密过程中使用的公共/秘密密钥或RK)。在将认证胶囊202提供到用户装置102期间(例如，图1，步骤S122)，授权实体105可以使用代理网络的公钥对认证胶囊202进行加密。稍后，当用户可以将认证胶囊202发送给第一节点103(例如，图1，步骤S124)时，第一节点103可以接着使用由代理网络101中的节点共享的秘密密钥对认证胶囊202进行解密。
进一步详细地转到认证胶囊202的组件，认证策略204可以包括授权实体105在向用户装置102提供认证胶囊202时确定的一个或多个用户认证策略。这些认证策略可包括例如动态用户认证(例如，经由令牌、生物计量ID、用户名/密码等)、商家的白名单/黑名单(例如，经由商家代码(MCC))、金额限制检查(例如，设置最高批准购买价的阈值)、速度检查(例如，设置一段时间内最多购买次数的阈值)、邻近性/背景检查(例如，阻止特定区域内的交易)、应用程序/装置绑定验证(下文将进一步讨论)以及针对用户行为度量的验证(例如，基于用户元数据)等策略。任何合适的认证策略204可用于执行本公开的实施例。
在一些实施例中，可以对照用户数据(例如，用户元数据)验证用户行为度量，所述用户数据可以与认证胶囊202一起(例如，由图1中的代理网络101的第一节点103，步骤S124)接收。在一些实施例中，用户元数据可以由移动银行应用程序存储在用户装置102上。仅作为实例，用户元数据可以包括数据，例如平均交易价格、每天购买的频率、经常购买的商家的类型、按时支付信用账单的能力等。应理解，用户元数据也可以进行加密(例如，使用由代理网络101中的节点共享的密码密钥)。次密钥可以与用于对认证胶囊202进行加密的密码密钥相同或不同。
转到由RKAE→N1 208、RKAE→N2 210和RKAE→N3 212表示的嵌入在认证胶囊202中的RK206的列表，所述列表可对应于上文参考图1论述的RK的白名单，步骤S122。因此，多个RK208、210和212中的每一个分别与代理网络中附属于授权实体105的节点相关联(例如，每个节点对应于由授权实体105批准为授权支付网关的不同支付网关)。在一些实施例中，可以基于先前由授权实体105创建的一个或多个RK(例如，针对代理网络101的多个节点执行步骤S116-S118)在提供认证胶囊202期间(例如，图1，步骤S122)创建白名单。
此外，认证胶囊202可以包含多个节点标识符207，每个节点标识符207分别与白名单206的RK相关联。具体地说，在一些实施例中，白名单206的RK条目和节点标识符207列表的条目可以例如以{pg_id，pg_rk}的形式配对在一起，分别对应于与RK相关联的特定支付网关和RK本身。例如，第一节点103可以在初始授权请求内从用户装置102接收交互标识符和认证胶囊202。交互标识符可以表示为支付网关节点标识符(例如，具有pg_id＝“N2”的第二节点104)和临时数(例如，random_nonce||pg_id)的连接。第一节点103可以确定交互标识符内的支付网关节点标识符(pg_id)是否与列表207内的节点标识符列表(例如，N2 220)的支付网关节点标识符匹配。如果存在匹配，则第一节点103可以使用白名单206中的相关联RK对加密凭证214(例如，RKAE→N2 210)进行重新加密。
在一些实施例中，加密凭证214可以对应于使用授权实体105的公钥进行加密的明文凭证。例如，这可以包括PII，例如用户人口统计资料和账单地址，以及PAN数据。如先前参考图1所论述的，步骤S120，明文凭证可以由授权实体105进行加密，并且接着提供到用户装置102以供稍后进行重新加密(参见图1，步骤S122、步骤S128)。
在一些实施例中，应用程序绑定/装置绑定216可以对应于认证策略204、RK的白名单206、节点标识符列表207和针对特定应用程序(例如，用户装置上的移动银行应用程序)和/或用户装置(例如，IMEI号、SIM卡等)的加密凭证214的绑定，以防止对认证胶囊202的攻击。在一些实施例中，认证胶囊202的组件还可以用授权实体的105的私钥进行数字签名。
图3示出描述根据实施例的代理网络101的示例性节点的框图。图3中描绘的代理节点300可以是被配置成根据特定上下文执行各种角色(例如，生成一对密码密钥，将初始授权请求消息处理为接收节点，将认证和重新加密作为第一或第三节点103，或者对加密凭证进行解密并且将预授权(或授权)请求发送给作为第二节点104的授权实体105)的计算机。应理解，已经提供到代理网络101的任何节点可以被配置为执行这些角色，而不管所述节点是否可以附属于授权实体105。
节点300可以包括可耦合到系统存储器303B和外部通信接口303C的处理器303A。计算机可读介质303D还可以操作性地耦合到处理器303A。数据库303E还可以与处理器303A进行操作性通信。数据库303E可以包含访问数据，例如已提交到由代理网络101的每个节点300维护的区块链的记录。数据库303E还可以包含可参考特定交易存储的数据(例如，认证胶囊)，和/或来自先前交易的认证结果的历史(例如，认证证明，下面进一步论述)。数据库303E还可以包含特定交互标识符与一个或多个数据(例如，目标支付网关标识符、商家装置/接口标识符、代理装置标识符、发行方标识符、用户装置标识符、来自特定用户装置的认证胶囊(或认证胶囊标识符)和/或例如电话号码、IP地址、装置标识符之类的用户装置标识符等)之间的映射。
计算机可读介质303D可以包括若干软件模块，所述若干软件模块包括通信模块303D-1、动态数据元素生成模块303D-2和注册模块303D-3、认证模块303D-4、审计模块303D-5以及加密/解密模块303D-6。计算机可读介质303D还可以包括可信执行环境(TEE)303F，其可以执行软件模块中的一个或多个。
可信执行环境303F可以使用任何合适的机制来实施。作为非限制性实例，根据本公开的实施例的因特尔软件保护扩展(SGX)解决方案可用于实施可信执行环境。应理解，与可由OS或在OS内运行的进程访问的计算机可读介质303D的非可信执行环境部分相反，可信执行环境303F受到保护，如上文所描述。因此，在实例中并且参考图3，在节点300的OS内执行的非可信处理可以不读取或篡改由正在可信执行环境303F中执行的认证模块303D-4(也可以称为“认证飞地”)执行的代码或数据(例如，风险策略、用户数据)。应理解，图3中描绘为在可信执行环境303F内的模块仅用于说明性目的，并且在一些实施例中，任务和/或数据处理的不同组合可以在可信执行环境303F内执行。与可能需要单个可信代理或需要在银行服务器PG之间集成的复杂基础设施的现有解决方案(上文所论述)相反，本公开的一个技术优势是，节点300可能不附属于特定发行方，但是仍然可以信任它来认证发行方的策略。以此方式，本公开在提供用户隐私和交易完整性方面比现有解决方案具有更大的灵活性。
转到计算机可读介质303D的特定模块，通信模块303D-1可以包括使处理器303A生成消息、转发(或路由)消息、重新格式化消息和/或以其它方式与其它实体进行通信的代码。在一个实例中，节点300的通信模块303D1(操作为接收节点)可以从商家服务器接收交互标识符的请求。通信模块303D-1可以接着处理请求并且调用动态数据元素生成模块303D-2以生成交互标识符(下文论述)。在另一实例中，节点300的通信模块303D-1(操作为第一节点103)可以从用户装置102接收初始授权请求消息，并且使用认证胶囊202调用认证模块303D-4作为输入。在又一实例中，节点300的通信模块303D-1(作为第二或第三节点103操作)可以从代理装置接收授权请求消息，并且使用认证胶囊202调用认证模块303D-4作为输入。
在一些实施例中，为了将消息路由到代理网络101中的另一节点，发送节点首先以接收节点可以解译的格式使消息格式化。具体地，在初始化阶段期间，每个节点可以将特定映射上传到代理网络101，由此映射指定节点请求消息以特定格式(例如，XML、JSON格式)传递。通信模块303D-1还可负责更新脚本(例如JavaScript)以使商家能够将交付时支付服务集成到商家的结账服务中。例如，支付网关可以为商家准备更新的JavaScript以下载并且执行热模块替换件。商家网站可以接着使用此网站与代理网络交互，例如通过为特定交易请求交互标识符(处理)。
动态数据元素生成模块303D-2可以包括使处理器303A生成动态数据元素的代码。动态数据元素在以下意义上是动态的：其可随着每个交互而改变，并且对于欺诈者很难浏览(skim)，例如随机生成的数字(例如，随机数)、一天中的时间、GPS坐标等。在本发明的实施例中，动态数据元素可以与特定交互(例如，交易)相关联以生成唯一标识符。例如，接收节点可以从商家接收请求，所述请求包括用户购物车信息(例如，被订的物品)和商家预先与其存在关联的支付网关(即，目标支付网关)。基于此信息，动态数据元素生成模块303D-2可以生成与交互相关联的动态数据元素。如上文所述，动态数据元素可以是形式为pg_id||随机数的串接字符串，其中“pg_id”对应于目标支付网关的节点标识符(例如，第二节点104)，并且“随机数”是对应于交互的随机唯一数字(例如，交易信息)。如上所述，此动态数据元素和对应的关联可以存储在数据库303E中。
注册模块303D-3可以包括使处理器303A将节点300注册到代理网络101中的代码。例如，通过调用注册模块303D-3并且提供数字签名和第三方(例如，第二节点104)的公共/秘密密钥(例如，PKN2、SKN2)作为输入，实体(例如，操作支付网关的第三方支付服务提供商)可以注册节点300。第三方支付网关的秘密密钥可以稍后用于对重新加密认证胶囊202(例如，图1的步骤S132)进行解密。在实例中，注册模块303D-3可以与代理网络的媒介节点建立安全连接，由此所述媒介可以验证第三方签名和公钥(PKN2)，并且向节点300提供注册证书。代理媒介还可以共享代理网络公共/秘密密钥对(在代理网络101的节点当中共享)，所述代理网络公用/秘密密钥对可以由任何节点300使用以对认证内核202或例如在初始授权请求消息内接收到的加密用户数据进行解密。在一些实施例中，一个或多个秘密密钥(例如，第三方支付网关秘密密钥或共享代理网络秘密密钥)可以与可信执行环境303F的飞地内的节点300OS隔离。
认证模块(例如，飞地)303D-4可以包括使处理器303A接收认证胶囊202和用户数据(例如，装置属性、用户行为数据度量)并且基于认证胶囊202中指定的用户数据和认证策略204执行认证算法的代码。在执行认证之前，认证模块303D-4(例如，通过调用加密/解密模块303D-6)可以例如使用(在注册期间由节点300接收的)代理网络节点的共享秘密密钥对认证胶囊202和用户数据进行解密。以此方式，授权实体105的所有用户数据和认证策略204可以保持私密和防篡改。在认证过程成功完成之后，认证模块303D-4可以通过调用加密/解密模块303D-6并且使用白名单206内的适当RK作为输入来发起对CT 214的重新加密。如先前所论述，认证模块303D-4可以基于交互标识符和节点标识符的列表207确定适当的RK。在认证过程完成时，认证模块303D-4还可以产生认证证明，并且调用审计模块303D-5(下文所论述)以将认证证明记录到区块链。认证证明可以是任何合适的数据形式(例如，使用代理网络节点的共享密码密钥进行数字签名)。
审计模块303D-5可以包括使处理器303A从认证模块303D-4接收认证证明并且将认证证明记录到区块链的代码。记录过程可以包括在本地将认证证明记录(例如，到数据库303E)，以及将记录发送给维护区块链的其它节点，使得每个节点的审计模块303D-5向区块链提交认证证明。
应理解，对于给定交易，可能有多个记录提交到区块链。例如，参考图1，第一节点103可以在步骤S126处记录认证证明。稍后，在步骤S136处从授权实体105接收到预授权时，第二节点104还可以记录对区块链的预授权响应(例如，预授权批准指示符)。另外，在交付时支付交易中，在资源交付之后发送的后续认证过程和授权请求消息(参考图6作进一步论述)可以分别使记录以与上述类似方式提交到区块链。在一些实施例中，记录条目可以包含包括数字签名(例如，由审计模块303D-5生成的标识符、对应于认证胶囊202的标识符、认证证明以及目标支付网关(例如，第二节点104)的RK的散列)的数据。在一些实施例中，记录条目中不存在敏感个人信息(例如，PII/PAN数据、用户行为数据)。
还应理解，虽然可信执行环境303F提供应用程序的隔离执行和资产的保密性(例如，秘密密钥)，但外部存储机构(例如，数据库303E)可能没有这样做。因此，存在节点300可能受损的风险，而不可信的过程可能篡改或删除先前存储的一些区块链记录。如果未校正，这可能会给认证过程303D-4带来问题，这可能取决于记录的策略合规性(例如，速度检查、争议解决等)。因此，本实施例的技术优势之一是，通过使分散式代理网络101的每个节点维护区块链，当单个受损节点300尝试向其它节点提交欺诈性认证证明时，尝试提交欺诈性认证证明的单个受损节点将容易被其它节点发现。这可以通过例如对区块链进行定期审计的代理网络的媒介节点来实现。任何合适的审计机构可用于执行本公开的实施例。因此，即使代理网络101的节点可能受损，区块链也能为交易保真性提供更大的保证。
在本发明的实施例中，加密/解密模块303D-6可以包括用于对数据进行加密的任何合适的加密/解密算法。如上文参考图1所述，加密/解密模块303D-6可以包括代理重新加密算法(例如，BBS、AFGH等)，用于生成密码密钥，以及进行重新加密和解密。此外，合适的数据加密/解密算法可以包括DES、三重DES、AES等。加密模块303D-6可以利用对称或不对称加密技术对数据进行加密和/或验证。例如，这些算法可以用来对认证胶囊202或作为初始授权请求消息的一部分从用户装置102接收的用户数据，或作为后续授权请求消息的一部分从代理装置接收的用户数据进行解密。算法还可用于将加密数据(例如，认证胶囊202、交互标识符)路由到代理网络中的另一节点。加密/解密模块303D-6还可以存储可以与此类加密/解密算法一起使用的加密密钥。例如，由加密/解密模块303D-6可以使用的密码密钥可以安全地存储在可信执行环境303F中。
图4示出描绘根据实施例的可以对应于图1的用户装置102的用户装置的框图400。
用户装置102可以包括用于处理用户装置102的处理器102A(例如，微处理器)以及允许用户查看信息的显示器102G。用户装置102还可包括输入元件102E(例如，触摸屏、键盘、触摸垫、生物计量传感器等传感器，等)、扬声器102H和麦克风102F，其中的每一者以操作方式耦合到处理器102A。非接触元件接口102I、天线102D、存储器102C和计算机可读介质102B也可以操作方式耦合到处理器102A。
计算机可读介质102B和存储器102C可存在于主体102J内。主体102J可以呈外壳或其它结构的形式。在一些情况下，存储器102C可以是安全元件，和/或还可存储例如访问数据的信息，所述访问数据包括令牌、PAN、票证等。存储器102C中的信息可由用户装置102使用天线102D或非接触元件接口102I发送给另一装置。用户装置102可将天线102D用于无线数据传送(例如，使用例如IEEE(电子工程师协会)802.11的无线连网协议)或移动电话通信(例如，3G、4G和/或LTE)。非接触元件接口102I的天线102K可被配置成用于在由不同无线协议指定的频率下发送和接收无线信号，所述不同无线协议例如NFC(近场通信)、BLE(低功耗蓝牙)、RFID(射频标识符)或任何其它合适形式的短程或中程通信机制。
在一些实施例中，非接触元件接口102I以具有相关联的无线传递(例如，数据发送)元件的半导体芯片(或其它数据存储元件)的形式实施，所述无线传递元件例如天线。经由蜂窝网络发送的数据或控制指令可以应用于非接触元件接口102I。非接触元件接口102I能够使用短程无线通信能力传递和接收数据。因此，用户装置102能够经由蜂窝网络(或任何其它合适的无线网络，例如互联网或其它数据网络)或任何短程通信机制传达和传送数据或控制指令。
计算机可读介质102B可以包括可由处理器执行以用于实施根据实施例的方法的代码。例如，计算机可读介质102B可以包括可由处理器102A执行以用于实施方法的代码，所述方法包括：由用户装置生成用于交互以从资源提供商获得资源的初始授权请求消息；由所述用户装置向代理网络中的第一节点发送所述初始授权请求消息，其中所述第一节点随后处理所述初始授权请求消息并且基于所述初始授权请求消息的所述处理将路由消息发送给所述代理网络中的第二节点，所述第二节点先前与所述资源提供商相关联；由所述用户装置从所述代理网络中的所述第二节点接收预授权批准指示符(PAAI)；由所述用户装置存储所述预授权批准指示符；在由所述代理交付所述资源时，由所述用户装置向所述资源提供商的代理的代理装置发送包括所述预授权批准指示符的授权请求消息，其中所述代理装置还处理所述授权请求消息并且将其发送给所述代理网络以由授权实体进行授权。
计算机可读介质102B可以包含一个或多个服务提供商应用程序102B-1。服务提供商应用程序102B-1可以与处理器102A协作，允许用户装置102与各种服务提供商计算机(例如，代理网络101中的节点、代理装置交付时支付应用程序、商家访问装置等)进行通信。每个应用程序可提供由其相应服务提供商提供的功能。服务提供商应用程序的实例可以包括数字钱包应用程序、支付应用程序(例如，由银行或支付处理网络设计和维护的移动银行应用程序)以及商家应用程序(例如，使用户能够参与忠诚度奖励)。在一些实施例中，特定服务提供商应用程序102B-1可以支持多个支付选项(例如，信用卡、借记卡、密码货币等)。每个服务提供商应用程序102B-1又可以与一个或多个授权胶囊102B-2相关联。在实例中，数字钱包应用程序可以支持具有不同发行方105的多个支付选项，因此，对于每个支付选项，可以在用户装置102上设置不同的认证胶囊102B-2。此外，特定的认证胶囊102B-2可以在设置过程期间与多个服务提供商应用程序102B-1相关联(步骤S122，图1)。在实例中，“银行1”(例如，授权实体105)可以在用户装置102上设置认证胶囊102B-2。“银行1”可以与装置上的不同应用程序(例如，“社交媒体应用程序1”、“社交媒体应用程序2”)相关联，并且每个应用程序均可经由“银行1”支持交付时支付。因此，在设置过程期间，可以允许用户选择哪些应用程序应链接到由“银行1”提供的认证胶囊102B-2。使得用户可以使用其在“银行1”处的账户经由其中一个应用程序执行支付。
图5示出描绘根据实施例用于在交付时支付交易中从资源提供商获得资源的消息交换过程的系统图和方法。如上文所论述，本公开的实施例可以三个不同阶段执行。参考图1-4描述第一(例如，部署)阶段的各个方面(例如，RK创建、在用户装置102上提供认证胶囊202、代理网络101中的节点的注册和初始化)。图5的系统图500描绘根据本公开的实施例的包括用于执行第二(例如，预授权)阶段的多个组件的系统。
在一些实施例中，系统500包括由用户502使用的用户装置516。购物车504可以对应于由用户502添加的待购买商品的列表或分组。在一个实施例中，资源提供商(例如，商家)界面506可以对应于由用户远程访问的商家网站。在其它实施例中，商家界面506可以对应于位于商家商店的访问装置。访问装置可以连接到商家服务器或用于用户和/或商家交互的其它显示器。交付时支付按钮508可以对应于商家网站上显示的按钮，用户502可以按下所述按钮以在交付时支付交易中发起预授权请求。
先前参考图1和图3，代理网络510可以对应于代理网络101。在代理网络510内，接收节点512可以是代理网络510的节点，其接收和处理来自商家的交互标识符请求，以提供对交易的处理。QR码514可以对应于由商家显示(例如，在商家网站、访问装置或其它连接的商家显示器上)的从接收节点512接收的交互标识符的表示。等待屏幕518可以对应于例如在网站上的商家界面上显示的“等待”消息，同时等待完成预授权。第一节点520可以对应于接收并且处理来自用户装置516的初始授权请求消息的代理网络510的节点。第二节点522可以对应于代理网络510的节点，所述节点是附属于商家界面506的目标支付网关(例如，商家与之具有代表商家处理交易的预先存在的关系的支付网关)。授权实体524可以对应于附属于第二节点522的授权实体105(例如，目标支付网关)，并且可以是用户502用于执行交易的支付卡的发行方。成功屏幕526可以对应于在确认预授权已完成时，显示在例如由授权实体524提供的移动银行应用程序102B-1内的用户装置516上的“成功”消息。成功屏幕528可以对应于在确认预授权已完成时，例如在商家界面506上显示的“成功”消息，所述消息例如在网站上显示。
图5还描绘根据本公开的实施例的用于执行交付时支付交易的第二(例如，预授权)阶段的方法。
在步骤530处，资源提供商(例如，经由商家网站或现场访问装置)可以从用户502接收将商品添加到购物车504的指示(例如，按钮点击)。
在步骤532处，资源提供商可以从用户接收用户提交预授权请求(例如，下订单)的指示。例如，在将商品添加到购物车之后，用户可以使用发行方524选择支付方法，用户已经具有与所述发行方建立了账户(例如，由“银行1”发行的“信用卡1”)。此时，用户可能已经在其用户装置516上安装或升级了服务提供商应用程序102B-1，其与商家网站上选择的在交付时支付方法508相关联，使得授权实体524已将认证胶囊202提供到用户装置516。
在步骤534处，商家界面506(例如，经由商家服务器)将包含订单信息的消息发送给代理网络510以获得交互标识符。订单信息可以包括例如已订购商品的列表、商家用作处理交易的商家服务的目标支付网关的标识(例如，pg_id值)、商家的认证凭证、交易金额、交易类型(例如，交付时支付)等详情。代理网络510的接收节点512接收此消息。在一些实施例中，接收节点512可以是目标支付网关，其已经由代理网络510中的另一节点基于支付网关标识符转发消息。在这种情况下，目标支付网关可以认证商家的凭证，由此目标支付网关节点522接着调用动态数据元素生成模块303D-2以生成交互标识符，并且存储与交互标识符相关联的交易详情(例如，交易金额、购物车信息)以供将来处理。目标支付网关可以接着将交互标识符发送给代理网络510中的每个节点以进行存储(例如，数据库303E)以用于将来的消息路由。在其它实施例中，接收节点512可以是代理网络510中的任何节点，所述代理网络已被委派认证商家的凭证、生成与交易详情相关联的交互标识符以及将交互标识符发送给代理网络510中的每个节点的角色。在任一情况下，一旦创建交互标识符并且将其传播到代理网络510中的每个节点，然后接收节点512可以将交互标识符发送回到商家界面506。
在步骤536处，商家界面506可以接着显示交互标识符，以便用户装置516接收作为输入。在一些实施例中，交互标识符可以音频、文本或任何其它合适的形式显示，由此用户装置516可以接收交互标识符。
在步骤538处，用户装置516接收经由商家界面506显示的交互标识符(例如，扫描QR码514)。在一些实施例中，商家界面506可以在处理预授权的同时显示“等待”消息518。在一些实施例中，用户装置516还可以显示“等待”消息。“等待”消息可以任何合适形式显示。
在步骤540处，用户装置516基于在步骤538中接收到交互标识符，将初始授权请求发送给代理网络510。在实例中，在步骤538中，服务提供商应用程序102B-1用于扫描QR码514。服务提供商应用程序102B-1识别交互标识符与交付时支付交易相关联，并且发送初始授权请求，所述初始授权请求可以包括若干元素。在一些实施例中，初始授权请求可以包括在用户装置上提供的交互标识符、加密用户数据(例如，元数据)和加密认证胶囊202。用户数据可以包括例如由服务提供商应用程序102B-1存储的用户行为数据和用户偏好的历史。用户数据还可以包括用户认证数据(例如，用户名/密码、生物计量数据、PIN)和/或装置认证数据(装置序列号、硬件安全元件标识符、装置指纹、电话号码、IMEI号码等)。
在步骤542处，代理网络510的第一节点520接收初始授权请求，基于初始授权请求执行认证，将认证证明记录到区块链，在认证胶囊202中对加密凭证214进行重新加密，并且最终将包括重新加密凭证和交互标识符的路由消息发送给第二节点522(例如，目标支付网关)。在一些实施例中，第一节点可以首先在可信执行环境303F中调用加密/解密模块303D-6，以使用代理网络510的共享密码密钥对用户数据和认证胶囊202进行解密。在执行解密之后，第一节点520可以在可信执行环境303F内调用认证模块303D-4，以使用解密用户数据和解密认证胶囊202内的认证(风险)策略204执行认证。认证过程可以输出认证证明，在输出时调用审计模块303D-5以将认证证明记录到区块链。如上文所述，第一节点520可以接着结合节点标识符207的列表和RK206的白名单使用交互标识符(例如，random_nonce||pg_id)以基于匹配支付网关标识符确定正确的RK。如果在白名单中找不到支付网关标识符，则第一节点520可以将错误消息返回到用户装置516和/或商家界面506，并且终止交易。这将指示由商家使用的支付网关没有得到授权实体524的支持。然而，如果存在匹配，则第一节点520可以例如通过调用加密/解密模块303D-6以利用参考图1描述的代理重新加密方案中的一个对加密凭证214进行重新加密。在重新加密凭证214之后，第一节点520可以将包括重新加密凭证和交互标识符的路由消息发送给第二节点522。在一些实施例中，第一节点510还可以将认证胶囊202发送给代理网络510中的其它节点，稍后用于快速检取和认证(例如，图6，步骤630)。
在步骤544处，第二节点522可以从第一节点520接收包括重新加密凭证和交互标识符的路由消息，并且使用第二节点522的秘密密钥对重新加密凭证进行解密以获得明文凭证(例如，PII/PAN数据)。在一些实施例中，第二节点522可以通过调用加密/解密模块303D-6以利用参考图1描述的代理重新加密方案对重新加密凭证进行解密。在一些实施例中，由第二节点522从第一节点520接收的交互标识符还可以包含用户装置标识符(例如，在步骤540处，其可以从用户装置发送的用户数据导出)。
在步骤546处，第二节点522可以基于交互标识符和明文凭证将预授权请求消息发送给授权实体524。授权实体524可以确定交易是否被授权，并且可以生成预授权响应消息并且将其发送回到第二节点522。第二节点可以从授权实体524接收预授权响应。
在一些实施例中，第二节点522可以使用交互标识符从数据库303E检取关于交易的信息(例如，在步骤534处由接收节点512接收和存储的)。所述预授权请求消息又可以包括与所述交互标识符和所述明文凭证相关联的交易信息。授权实体524可以接收预授权请求消息，并且发送包括预授权批准指示符(PAAI)的预授权响应。预授权批准指示符可以对应于将在第三阶段期间使用的预授权证明。预授权批准指示符可以任何合适形式(例如，使用授权实体524的公钥签名的授权代码)表示。在一些实施例中，预授权批准指示符还可以包含交互标识符，以用于稍后由用户装置516检取。(如本文所论述，预授权批准指示符可以与预授权响应互换使用。)应理解，授权实体524可以是发行正在使用的支付卡的发行方(例如，银行)，或发行方的代表实体(例如，信用卡协会)。
在步骤548处，在从授权实体524接收到预授权响应时，第二节点522可以通过调用审计模块303D-5将预授权批准指示符记录到区块链。如上所述，可以由代理网络使用这些记录定期对区块链执行审计，以确保区块链分类账的完整性。第二节点522可以接着基于先前接收的用户装置标识符将预授权批准指示符发送给用户装置516。第二节点522还可以将对应于预授权批准指示符(例如，预批准的批准/拒绝)的消息发送给商家界面506。在接收到预授权批准指示符时，商家界面506可以向用户显示“成功”消息528。另外，用户装置516还可以显示“成功”消息526。用户装置516还可以将预授权批准指示符存储到装置516(例如，存储在存储器102C内)。
在上述过程和其它过程中，由第二节点522和授权实体524接收的所述标识符可以从一个格式转换到另一个格式。例如，由第二节点522接收的消息可以呈HTTP消息格式，并且呈ISO 8532消息格式的新的授权请求消息可以用来与授权实体524进行通信。
图6示出描绘根据实施例的用于在交付时支付交易中从资源提供商获得资源的消息交换过程的系统图和方法图。图6的系统图600描绘根据本公开的实施例的包括用于执行第三(例如，交付和授权)阶段的多个组件的系统。
在一些实施例中，系统600包括由用户604(其可对应于用户502)使用的用户装置606(其可对应于用户装置516)。在启动服务提供商应用程序102B-1时，用户装置606可以显示被描绘在用户装置606上显示的QR码。用户装置606可以随后显示用户同意屏幕608。根据此用户同意屏幕608，用户可以同意支付并且输入数字签名。在一些实施例中，如下文所论述，用户同意屏幕608可以显示修改的交易金额(例如，如果商品在运输途中受损，并且交付代理将原始价格降低到降低的价格)。代理交付时支付应用程序610对应于在交付代理602的代理装置(例如，移动装置)上运行的应用程序。在一些实施例中，代理交付时支付应用程序610可以显示用于扫描QR码的扫描屏幕。在一些实施例中，代理交付时支付应用程序610可以显示价格调整屏幕，从而允许交付代理将原始价格修改为降低的价格。代理交付时支付应用程序610还可以允许交付代理602查看交易详情以及输入数字签名。代理交付时支付应用程序610还能够接收和处理不同类型的认证胶囊202以发送给代理网络611，每个认证胶囊对应于不同的发行方(例如，银行、密码货币支付账户发行方等)。以此方式，交付代理可以使用单个代理交付时支付应用程序610以处理来自用户604的多种类型的交易。如前所述，这种使用单个代理交付时支付应用程序610处理多种类型交易的方法通过减少代理604在其移动装置上管理不同支付机制耗费的时间并且降低处理支付交易时出现错误的风险，为现有方法(可能需要不同应用程序)提供了技术优势。
代理网络611可以对应于图5的代理网络510。第三节点612可以对应于代理网络611的节点，所述节点接收并且处理来自代理交付时支付应用程序610的授权请求消息。第二节点614(例如，目标支付网关)可以对应于图5的第二节点522。授权实体616可以对应于图5的授权实体524。成功屏幕618可以对应于在确认授权已完成时，显示在例如由授权实体524提供的移动银行应用程序102B-1内的用户装置606上的“成功”消息。成功屏幕620可以对应于例如在确认授权已完成时，在代理交付时支付应用程序610上显示的“成功”消息。
图6还描绘根据本公开的实施例的用于执行交付时支付交易的第三(例如，授权)阶段的方法。
在步骤622处，在交付代理602将商品交付给用户604时，用户装置606可以启动移动银行应用程序102B-1，所述移动银行应用程序最初提交预授权请求(例如，步骤540)并且存储预授权批准指示符(步骤548)。在一些实施例中，在交付之前，代理交付时支付应用程序610可以从商家服务器506接收关于交易的信息(例如，交易金额、订单信息、交易标识符、商家服务器标识符、目标支付网关节点标识符)。此信息稍后可以由代理交付时支付应用程序610使用(例如，步骤628)，以将授权请求交到代理网络611。回到用户装置606，在启动时，移动银行应用程序102B-1又可以在用户装置606上显示QR码。QR码可以对应于先前放置在阶段二中的订单(例如，经由交易信息，例如先前存储在用户装置上的预授权批准指示符)。在实例中，在由代理交付时支付应用程序610扫描QR码之前，在一些商品可能在运输途中受损(或丢失)的情况下，代理602可能同意降低价格。代理可以更新代理装置602上的价格(未示出)。因此，在代理交付时支付应用程序610扫描用户装置606上的QR码时，移动银行应用程序102B-1可以提示用户604进行签名(例如，数字签名)。如参考图5所论述，任何合适的机制可用于在用户装置606与代理交付时支付应用程序610之间传送交易信息。
在步骤624处，用户装置606从用户604接收数字签名以继续授权支付。在实例中，用户选中用户同意屏幕608中的方框以指示其签名。在一些实施例中，用户同意屏幕608可以指示价格已被更新(例如，“原始：100美元，更新的价格：50美元”)。
在步骤626处，代理交付时支付应用程序610从用户装置606接收用户的604数字签名、交易的预授权批准指示符、用户数据(例如，包括用户装置标识符、用户认证数据、用户行为数据度量等)以及与移动银行应用程序102B-1相关联的认证胶囊202。如前所述，在一些实施例中，代理网络611的节点可能已经存储了认证胶囊202的副本(例如，在步骤542处由第一节点512发送)。在这种情况下，用户装置606可以仅发送对应于认证胶囊的认证胶囊标识符(例如，ac_id值)。在实例中，认证胶囊标识符可以对应于认证胶囊202的散列，所述散列使用任何合适的机制执行。
在步骤628处，代理装置(例如，代理交付时支付应用程序610)向代理网络611发送授权请求消息(其也可以被称为“后续授权请求消息”，其意味着所述授权请求消息是在步骤546中由第二节点522最初发送的预授权请求消息之后。在一些实施例中，所述授权请求消息可以包含若干要素，包括用户604数字签名、代理602数字签名、用户数据、第二交互标识符、预授权批准指示符以及认证胶囊202(或认证胶囊标识符)。在一些实施例中，第二交互标识符可以包括例如在步骤622中由代理交付时支付应用程序610先前从商家服务器接收的交易信息。在一些实施例中，可以(例如，使用代理网络611的共享密码密钥)对授权请求消息的一个或多个元素进行加密。
在步骤630处，第三节点612从代理交付时支付应用程序610接收授权请求消息并且执行若干操作。这些操作可以类似于由图5的第一节点520在步骤542处执行的操作。具体地说，第三节点612可以对认证胶囊202和用户数据进行解密，并且针对认证策略204执行认证。如上文所论述，第三节点612可以直接从代理交付时支付应用程序610接收认证胶囊202，或基于从代理交付时支付应用程序610接收的认证胶囊标识符从数据库303E检取认证胶囊202。在一些实施例中，可以再次执行认证(除了步骤542中的认证之外)，以提供交易安全性的额外度量。认证过程可以再次输出认证证明，将所述认证证明记录到区块链。另外，第三节点612还可以验证用户604和交付代理602的数字签名。第三节点612还可以验证先前在步骤548中被记录到区块链的预授权批准指示符。第三节点612可以接着以与步骤542中所述的类似方式对加密凭证214进行重新加密。最后，第三节点612可以将路由消息发送给第二节点614，包括重新加密凭证和第二交互标识符的路由消息(例如，其可以对应于第二交互标识符中包括的元素中的一个或多个和/或在步骤628中由第三节点612之前从代理装置610接收的用户数据)。应理解，在一些实施例中，第三节点612可以是与第一节点512相同的节点，或可以是不同节点。此外，第二节点(即，目标支付网关)也可能是与第一节点512(阶段二中)或第三节点612(阶段三中)相同的节点，在这种情况下，就不需要将消息路由到代理网络611中的另一节点。在此情况下，可以在同一第二节点614上执行加密凭证214的重新加密和解密。
在步骤632处，并且类似于步骤544，第二节点614可以从第三节点612接收包括重新加密凭证和第二交互标识符的路由消息，并且使用第二节点522的秘密密钥对重新加密凭证进行解密以获得明文凭证(例如，PII/PAN数据)。
在步骤634处，类似于步骤546，基于第二交互标识符和明文凭证，第二节点614将授权请求消息发送给授权实体616，并且接收(最终)授权响应。在一些实施例中，所述授权请求消息可以包括预授权批准指示符、明文凭证和交互数据(例如，基于第二交互标识符的交易信息)。然后，第二节点614可以将授权响应记录到区块链。
在步骤636处，在从授权实体616接收到授权响应时，第二节点614可以将授权响应发送给代理交付时支付应用程序610和/或用户装置606，以确认支付已被批准或拒绝。在一些实施例中，代理交付时支付应用程序610可显示“成功”屏幕，和/或代理交付时支付应用程序610还可显示“成功”屏幕。在一些实施例中，第二节点614可以将授权响应发送给代理交付时支付应用程序610，所述代理交付时支付应用程序继而可以使用任何合适的机制(例如，扫描包含响应的QR码)将响应转发到用户装置606。
在一天结束时或任何其它合适的时间段，在一些实施例中，结算过程可以发生在与商家相关联的银行、授权实体616与支付处理网络之间。
应理解，本公开的任何实施例都可以使用硬件(例如，专用集成电路或现场可编程门阵列)和/或使用计算机软件以控制逻辑的形式实施，其中通用可编程处理器是模块化的或集成的。如本文所使用，处理器包括单核处理器、在同一集成芯片上的多核处理器，或在单个电路板上或网络化的多个处理单元。基于本文提供的公开内容和教导，本领域普通技术人员将知道并理解使用硬件以及硬件和软件的组合来实施本公开内容的实施例的其它方式和/或方法。
本申请中描述的任何软件组件或功能可实施为使用例如Java、C、C++、C#、Objective-C、Swift等任何合适的计算机语言或例如Perl或Python等脚本语言使用例如常规的或面向对象的技术的由处理器执行的软件代码。软件代码可作为一系列指令或命令存储在计算机可读介质上以供存储和/或传送，合适的介质包括随机存取存储器(RAM)、只读存储器(ROM)、例如硬盘驱动器或软盘的磁性介质，或例如光盘(CD)或数字通用盘(DVD)的光学介质、快闪存储器等。计算机可读介质可以是此类存储或传送装置的任何组合。
此类程序还可以使用适应于经由包括互联网的符合多种协议的有线、光学和/或无线网络进行发送的载波信号来编码和传送。因此，根据本公开的实施例的计算机可读介质可以使用以此类程序编码的数据信号来创建。以程序代码编码的计算机可读介质可与兼容装置一起封装或与其它装置分开提供(例如，通过因特网下载)。任何此类计算机可读介质可以驻存在单个计算机产品(例如，硬盘驱动器，CD或整个计算机系统)之上或其内部，并且可以存在于系统或网络内的不同计算机产品上或其内部。计算机系统可以包括监视器、打印机，或用于向用户提供本文所提及的任何结果的其它合适的显示器。
以上描述是说明性的且不是限制性的。在本领域的技术人员阅读了本公开后，本公开的许多变化将变得显而易见。因此，本公开的范围不应参考以上描述来确定，而是应参考待决的权利要求以及其完整范围或等效物来确定。
在不脱离本公开的范围的情况下，来自任何实施例的一个或多个特征可以与任何其它实施例的一个或多个特征组合。
除非明确指示有相反的意思，否则“一(a)”、“一个(an)”或“所述”的叙述旨在指示“一个或多个”。
上文提及的所有专利、专利申请、公开案和描述都出于所有目的以全文引用的方式并入。并非承认它们是现有技术。

Claims (24)

1.一种方法，包括：
由节点的代理网络中的第一节点从用户装置接收用于交互以从资源提供商获得资源的初始授权请求消息，所述初始授权请求消息包括交互标识符、用户数据和授权胶囊，所述授权胶囊与授权实体相关联并且包括风险策略、所述用户的加密凭证、分别与所述代理网络中的各节点相关联的多个重新加密密钥以及分别与所述重新加密密钥相关联的多个节点标识符；
由所述第一节点使用所述用户数据和所述授权胶囊中的所述风险策略执行认证；
由所述第一节点使用所述交互标识符和所述授权胶囊中的所述节点标识符确定所述多个重新加密密钥中的重新加密密钥，所述重新加密密钥与所述节点的代理网络的第二节点相关联；
由所述第一节点并且利用与所述第二节点相关联的所述重新加密密钥对所述加密凭证进行重新加密以形成重新加密凭证；以及
由所述第一节点向所述代理网络中的所述第二节点发送路由消息，所述路由消息包括所述重新加密凭证和所述交互标识符，其中所述第二节点随后使用所述第二节点的秘密密钥对所述重新加密凭证进行解密以获得明文凭证，然后生成预授权请求消息并且将其发送给所述授权实体以供批准，其中所述预授权请求消息在后续授权请求消息之前请求预授权，所述后续授权请求消息将在所述资源交付时由所述资源提供商的代理的代理装置发送。
2.根据权利要求1所述的方法，其中所述代理网络包括多个通信连接的节点，所述多个包括所述第一节点和所述第二节点，其中所述多个中的每个节点被配置成维护区块链。
3.根据权利要求2所述的方法，其中所述授权胶囊和所述用户数据是使用由所述多个节点中的每个节点共享的密码密钥进行加密的，所述认证包括：
由所述第一节点并且利用所述密码密钥对所述授权胶囊进行解密；
由所述第一节点并且利用所述密码密钥对所述用户数据进行解密；
由所述第一节点并且基于对所述授权胶囊进行解密和对所述用户数据进行解密来验证所述用户数据满足所述风险策略的要求；
由所述第一节点并且基于所述验证生成认证证明；以及
由所述第一节点将所述认证证明记录到所述区块链，其中所述记录包括向所述多个节点中的每个节点发送所述认证证明，其中每个节点还记录所述认证证明。
4.根据权利要求2所述的方法，其中所述交互标识符是由所述多个节点中的接收节点生成并且由所述用户装置接收的动态数据元素，所述动态数据元素对应于所述交互和所述第二节点，其中所述资源提供商与所述第二节点具有预先存在的关联，其中所述接收节点将所述交互标识符发送给要存储的所述多个节点中的每个节点，并且其中所述第一节点基于所述交互标识符将所述路由消息发送给所述第二节点。
5.根据权利要求2所述的方法，其中所述多个节点中的每个节点包括可信执行环境(TEE)，所述认证在所述第一节点的所述可信执行环境内执行。
6.根据权利要求1所述的方法，其中所述加密凭证是使用所述授权实体的公钥进行加密的明文凭证，并且所述多个重新加密密钥中的每个重新加密密钥是从所述授权实体的秘密密钥和所述代理网络的分别相关联的节点的密码密钥导出的，其中所述重新加密是在不首先将所述加密凭证解密成明文凭证的情况下执行的。
7.根据权利要求1所述的方法，其中所述后续授权请求消息包括预授权批准指示符(PAAI)，所述预授权批准指示符响应于从所述授权实体接收到预授权响应而已经由所述第二节点发送给所述用户装置，其中所述预授权批准指示符随后存储在所述用户装置上。
8.根据权利要求7所述的方法，其中所述多个节点中的第三节点在从所述代理装置接收到所述后续授权请求消息时，部分地基于所述预授权批准指示符认证所述后续授权请求消息。
9.一种节点的代理网络中的第一节点，所述第一节点包括：
处理器；以及
耦合到所述处理器的计算机可读介质，所述计算机可读介质包括能由所述处理器执行以用于实施方法的代码，所述方法包括：
从用户装置接收用于交互以从资源提供商获得资源的初始授权请求消息，所述初始授权请求消息包括交互标识符、用户数据和授权胶囊，所述授权胶囊与授权实体相关联并且包括风险策略、所述用户的加密凭证、分别与所述代理网络中的各节点相关联的多个重新加密密钥以及分别与所述重新加密密钥相关联的多个节点标识符；
使用所述用户数据和所述授权胶囊中的所述风险策略执行认证；
使用所述交互标识符和所述授权胶囊中的所述节点标识符确定所述多个重新加密密钥中的重新加密密钥，所述重新加密密钥与所述节点的代理网络的第二节点相关联；
利用与所述第二节点相关联的所述重新加密密钥对所述加密凭证进行重新加密以形成重新加密凭证；以及
向所述代理网络中的所述第二节点发送路由消息，所述路由消息包括所述重新加密凭证和所述交互标识符，其中所述第二节点随后使用所述第二节点的秘密密钥对所述重新加密凭证进行解密以获得明文凭证，然后生成预授权请求消息并且将其发送给所述授权实体以供批准，其中所述预授权请求消息在后续授权请求消息之前请求预授权，所述后续授权请求消息将在所述资源交付时由所述资源提供商的代理的代理装置发送。
10.根据权利要求9所述的第一节点，其中所述代理网络包括多个通信连接的节点，所述多个节点包括所述第一节点和所述第二节点，其中所述多个中的每个节点被配置成维护区块链。
11.根据权利要求10所述的第一节点，其中所述授权胶囊和所述用户数据是使用由所述多个节点中的每个节点共享的密码密钥进行加密的，所述认证包括：
利用所述密码密钥对所述授权胶囊进行解密；
利用所述密码密钥对所述用户数据进行解密；
基于对所述授权胶囊进行解密和对所述用户数据进行解密来验证所述用户数据满足所述风险策略的要求；
基于所述验证生成认证证明；以及
将所述认证证明记录到所述区块链，其中所述记录包括向所述多个节点中的每个节点发送所述认证证明，其中每个节点还记录所述认证证明。
12.根据权利要求10所述的第一节点，其中所述交互标识符是由所述多个节点中的接收节点生成并且由所述用户装置接收的动态数据元素，所述动态数据元素对应于所述交互和所述第二节点，其中所述资源提供商与所述第二节点具有预先存在的关联，并且其中所述第一节点基于所述交互标识符将所述路由消息发送给所述第二节点。
13.根据权利要求10所述的第一节点，其中所述多个节点中的每个节点包括可信执行环境(TEE)，所述认证在所述第一节点的所述可信执行环境内执行。
14.根据权利要求9所述的第一节点，其中所述加密凭证是使用所述授权实体的公钥进行加密的明文凭证，并且所述多个重新加密密钥中的每个重新加密密钥是从所述授权实体的秘密密钥和所述代理网络的分别相关联的节点的密码密钥导出的，其中所述重新加密是在不首先将所述加密凭证解密成明文凭证的情况下执行的。
15.根据权利要求9所述的第一节点，其中所述后续授权请求消息包括预授权批准指示符(PAAI)，所述预授权批准指示符响应于从所述授权实体接收到预授权响应而先前已经由所述第二节点发送给所述用户装置，其中所述预授权批准指示符随后存储在所述用户装置上。
16.根据权利要求15所述的第一节点，其中所述多个节点中的第三节点在从所述代理装置接收到所述后续授权请求消息时，部分地基于所述预授权批准指示符认证所述后续授权请求消息。
17.一种方法，包括：
由代理网络中的第二节点生成一对密码密钥，所述一对包括公钥和秘密密钥；
由所述第二节点将所述一对的密码密钥发布到所述代理网络，其中授权实体从所述代理网络提取所述密码密钥，并且利用所述授权实体的秘密密钥和所述密码密钥生成重新加密密钥；
由所述代理网络中的所述第二节点从所述代理网络中的第一节点接收路由消息，所述路由消息包括重新加密凭证和交互标识符，其中所述重新加密凭证是利用所述重新加密密钥进行加密的明文凭证，并且所述交互标识符对应于从资源提供商获得资源的交互，所述交互标识符包括对应于用户装置的用户装置标识符；
由所述第二节点使用所述第二节点的所述秘密密钥对所述重新加密凭证进行解密以获得所述明文凭证；
由所述第二节点并且基于所述交互标识符生成预授权请求消息，所述预授权请求消息包括所述明文凭证和对应于所述交互的交互数据；以及
由所述第二节点将所述预授权请求消息发送给所述授权实体以供批准，其中所述预授权请求消息在后续授权请求消息之前请求预授权，所述后续授权请求消息将在所述资源交付时由所述资源提供商的代理的代理装置发送。
18.根据权利要求17所述的方法，其中所述代理网络包括多个通信连接的节点，所述多个包括所述第一节点和所述第二节点，其中所述多个中的每个节点被配置成维护区块链。
19.根据权利要求18所述的方法，还包括：
由所述第二节点从所述授权实体接收包括来自所述授权实体的预授权批准指示符(PAAI)的预授权响应；以及
由所述第二节点将所述预授权批准指示符记录到所述区块链，其中所述记录包括向所述多个节点中的每个节点发送所述预授权批准指示符，其中每个节点还记录所述预授权批准指示符；以及
由所述第二节点基于所述用户装置标识符将所述预授权批准指示符发送给所述用户装置。
20.根据权利要求18所述的方法，还包括：
由所述第二节点从所述多个节点中的第三节点接收第二路由消息，所述第二路由消息是基于由所述代理装置发送并且由所述多个中的所述第三节点接收的所述后续授权请求消息生成的，所述第二路由消息包括所述重新加密凭证和第二交互标识符，所述第二交互标识符对应于所述交互；
由所述第二节点使用所述第二节点的所述秘密密钥对所述重新加密凭证进行解密以获得所述明文凭证；
由所述第二节点并且基于所述第二交互标识符生成授权请求消息，所述授权请求消息包括所述明文凭证和对应于所述第二交互标识符的交互数据；以及
由所述第二节点向所述授权实体将所述授权请求消息发送给所述授权实体以用于授权；
由所述第二节点从所述授权实体接收授权响应；
由所述第二节点将所述授权响应记录到所述区块链，其中所述记录包括向所述多个节点中的每个节点发送所述授权响应，其中每个节点还记录所述授权响应；以及
由所述第二节点将所述授权响应发送给所述代理装置。
21.一种方法，包括：
由用户装置生成用于交互以从资源提供商获得资源的初始授权请求消息；
由所述用户装置向代理网络中的第一节点发送所述初始授权请求消息，其中所述第一节点随后处理所述初始授权请求消息并且基于所述初始授权请求消息的所述处理将路由消息发送给所述代理网络中的第二节点，所述第二节点先前与所述资源提供商相关联；
由所述用户装置从所述代理网络中的所述第二节点接收预授权批准指示符(PAAI)；
由所述用户装置存储所述预授权批准指示符；
在由所述代理交付所述资源时，由所述用户装置向所述资源提供商的代理的代理装置发送包括所述预授权批准指示符的授权请求消息，其中所述代理装置还处理所述授权请求消息并且将其发送给所述代理网络以由授权实体进行授权。
22.根据权利要求21所述的方法，其中用户装置通信连接到所述资源提供商的资源提供商界面，所述初始授权请求消息包括基于检测到由所述资源提供商界面呈现的快速响应(QR)码获得的交互标识符。
23.根据权利要求21所述的方法，其中在由所述代理交付所述资源时，所述用户装置向所述代理装置呈现第二QR码，所述第二QR码基于所述预授权批准指示符导出，并且其中所述代理装置基于检测到所述第二QR码处理和发送所述授权请求消息。
24.一种用户装置，包括：
处理器；以及
计算机可读介质，其包括能由所述处理器执行以实施根据权利要求21至23中任一项所述的方法的代码。
CN201980093326.4A 2019-04-30 2019-04-30 交付时交互的分散式处理 Active CN113545000B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2019/029802 WO2020222777A1 (en) 2019-04-30 2019-04-30 Decentralized processing of interactions on delivery

Publications (2)

Publication Number Publication Date
CN113545000A CN113545000A (zh) 2021-10-22
CN113545000B true CN113545000B (zh) 2023-12-26

Family

ID=73029120

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980093326.4A Active CN113545000B (zh) 2019-04-30 2019-04-30 交付时交互的分散式处理

Country Status (5)

Country Link
US (1) US12003495B2 (zh)
EP (1) EP3963821A4 (zh)
CN (1) CN113545000B (zh)
SG (1) SG11202108635XA (zh)
WO (1) WO2020222777A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12008549B2 (en) * 2019-07-22 2024-06-11 Visa International Service Association Federated custodian
US11354652B2 (en) * 2019-08-14 2022-06-07 Visa International Service Association System, method, and computer program product for authenticating a user for a transaction
US20210312443A1 (en) * 2020-04-03 2021-10-07 Ebay Inc. Orchestration engine for transactions
US11405216B2 (en) * 2020-05-07 2022-08-02 Adp, Inc. System for authenticating verified personal credentials
US20220407921A1 (en) * 2021-06-18 2022-12-22 Bank Of America Corporation Data processing transactions between disparate systems using a universal processor
CN113379419B (zh) * 2021-06-25 2022-08-16 远光软件股份有限公司 交易信息的访问方法、系统及计算机设备
CN114900354B (zh) * 2022-05-05 2023-08-29 国网山东省电力公司德州供电公司 一种面向能源数据的分布式身份认证和管理方法及系统
CN114785687B (zh) * 2022-06-15 2022-10-21 成都卓杭网络科技股份有限公司 一种基于golang语言的服务器热更新方法、服务器及可读介质
US11954679B2 (en) 2022-06-28 2024-04-09 Visa International Service Association System and method for implementing enhanced payment on delivery

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6625734B1 (en) * 1999-04-26 2003-09-23 Disappearing, Inc. Controlling and tracking access to disseminated information
US9503452B1 (en) * 2016-04-07 2016-11-22 Automiti Llc System and method for identity recognition and affiliation of a user in a service transaction
CN109118199A (zh) * 2011-02-16 2019-01-01 维萨国际服务协会 快拍移动支付装置，方法和系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130339232A1 (en) 2005-10-06 2013-12-19 C-Sam, Inc. Widget framework for securing account information for a plurality of accounts in a wallet
US9105027B2 (en) * 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US9231758B2 (en) * 2009-11-16 2016-01-05 Arm Technologies Israel Ltd. System, device, and method of provisioning cryptographic data to electronic devices
KR102255458B1 (ko) * 2013-07-15 2021-05-25 비자 인터네셔널 서비스 어소시에이션 보안 원격 지불 거래 처리
US20150095238A1 (en) 2013-09-30 2015-04-02 Apple Inc. Online payments using a secure element of an electronic device
WO2019070512A1 (en) 2017-10-06 2019-04-11 Mastercard International Incorporated DISTRIBUTION SYSTEMS AND ASSOCIATED METHODS

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6625734B1 (en) * 1999-04-26 2003-09-23 Disappearing, Inc. Controlling and tracking access to disseminated information
CN109118199A (zh) * 2011-02-16 2019-01-01 维萨国际服务协会 快拍移动支付装置，方法和系统
US9503452B1 (en) * 2016-04-07 2016-11-22 Automiti Llc System and method for identity recognition and affiliation of a user in a service transaction

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Proxy Re-Encryption: Analysis of constructions and its application to secure access delegation;David Nuñez, Isaac Agudo, Javier Lopez;Journal of Network and Computer Applications;第87卷;第193-209页 *

Also Published As

Publication number Publication date
US12003495B2 (en) 2024-06-04
EP3963821A4 (en) 2022-05-04
US20220131845A1 (en) 2022-04-28
SG11202108635XA (en) 2021-09-29
WO2020222777A1 (en) 2020-11-05
CN113545000A (zh) 2021-10-22
EP3963821A1 (en) 2022-03-09

Similar Documents

Publication Publication Date Title
US11876905B2 (en) System and method for generating trust tokens
US11240219B2 (en) Hybrid integration of software development kit with secure execution environment
CN113545000B (zh) 交付时交互的分散式处理
US11847643B2 (en) Secure remote payment transaction processing using a secure element
US12008088B2 (en) Recurring token transactions
US11170379B2 (en) Peer forward authorization of digital requests
RU2663476C2 (ru) Защищенная обработка удаленных платежных транзакций, включающая в себя аутентификацию потребителей
AU2017214412A1 (en) Systems and methods for code display and use
US12003500B2 (en) Token processing system and method
WO2020091841A1 (en) Account assertion
WO2023229571A1 (en) Secure and privacy preserving message routing system
Islam et al. A PKI Enabled Authentication Protocol for Secure E-Payment Framework

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant