CN116250210A

CN116250210A - 用于网络化的数据交易的认证和授权的方法、装置和计算机可读介质

Info

Publication number: CN116250210A
Application number: CN202180059415.4A
Authority: CN
Inventors: G·多尼; I·叶尔马科夫; I·什卡波; O·克罗扎克
Original assignee: Secores
Current assignee: Secores
Priority date: 2020-05-27
Filing date: 2021-05-27
Publication date: 2023-06-09
Also published as: US20240171408A1; US11876915B2; WO2021243043A1; EP4158875A1; JP2023527811A; KR20230040959A; CA3180131A1; US20210377045A1

Abstract

一种用于用密码方式链接分离的认证和授权进程以在需要组或集团权限结构时支持数据交易签名的方法和装置。该装置提供安全的、可扩展的模型来表示在进行分布式账本技术交易时在实体上下文中的权限。该方法支持用于分离链接的认证和授权进程的一系列用密码方法，这些链接的认证和授权进程包括分割密钥加密、多方计算、多签名授权和去中心化智能合约授权逻辑的执行。该方法支持用于授权的多个模型，该多个模型包括组织结构、包括投票的共识模型，以及工作流进程。

Description

用于网络化的数据交易的认证和授权的方法、装置和计算机可读介质

相关申请数据

本申请要求在2020年5月27日提交的美国临时申请号63/030,416的优先权，该专利申请的全部公开以引用方式并入本文。

技术领域

本发明涉及用于用密码方式链接针对计算网络上的数据交易的分离的认证和授权进程的用密码方法。

背景技术

分布式账本技术(DLT)(在本文中也称为“去中心化网络”)诸如区块链网络被设计成不可靠的和匿名的。公钥/私钥组合被用于说明操作称为“钱包”的网络地址及其所包含的数据/数值的权限。这允许执行权限为去中心化的，不需要验证执行交易的一方，并且不需要额外的中介。去中心化执行权限是DLT最强大和引人注目的特征之一。在DLT网络上对权限进行最容易识别且常见的说明是在个体用私钥对交易进行签名以将数值(例如，令牌)从他们的钱包发送到由另一方控制的钱包时发生的。这与传统的银行账本技术(关系数据库技术或更新的NoSQL***)形成对比，传统的银行账本技术将中间业务逻辑与用于认证和授权客户端的机制紧密地结合在一起。通过将认证进程与业务逻辑(其通常被封装在“智能合约”中)分离，DLT很可能实现创造性的用户体验和金融产品。

然而，许多数据交易是在实体的权限下执行的，或者通过某一进程而非个体来授权。执行某些功能或采取某些动作的权限是由实体基于个体的权力和资格而委托给个体的。有时权限被委托给其他实体，这些实体继而将权限委托给个体。例如，律师事务所、经纪人或过户代理人可被委托权限以代表实体行动。对应的合伙人、注册委托人或负责人可被授权以代表这些实体为特定目的而行动。在大多数国家的企业法律下，并如公司的企业章程和规章中进一步规定的，公司的单个高级职员被自动委托执行某些类型的职能的权限。虽然这些职能是在实体的权限下执行的，但通常是由自然人和非个人实体(NPE)(诸如机器进程)依据由实体委托的权限来执行动作。该权限仅驻留在上下文中(在实体的范围内)，并且通常是临时的(例如，只要个体被分配给实体)。使个体能够表达由实体委托的执行提出的任务的权限(例如，对交易进行签名)需要将认证(即，正确标识个体)和授权(即，验证个体在组上下文中的权力)分离。

例如，实体的审计官可基于与公司财务部门的附属关系而具有向外部实体发起支付(但通常不是放款)的权限。执行该动作的权限可能不会扩展到公司外部(例如，审计官可能没有为其他公司发起支付的权限)，仅在个体任职期间存在，并且通常是可能需要批准或需要与对提出的交易的批准相关联的其他任务的多步进程的一部分。

在组上下文中，多方可具有代表实体进行数据交易(诸如操作实体所拥有的数值)的权限。在传统的DLT环境中，授权多个个体对交易进行签名需要每个这样的个体提供对私钥的访问，因此造成了问责失败(不可能识别谁实际执行了该动作)，增加了盗窃或恶意导致安全漏洞的概率，并且即使将他们的附属关系从组中移除，也无法提供移除个体行使权限的能力的机制。简而言之，一旦私钥已知，它就已经受到损害。

不幸的是，对公钥/私钥交易签名的依赖(诸如在DLT环境中)合并了大多数集团动作中存在的两个重要概念：认证和授权。使用公钥/私钥对交易进行签名用于认证(确保执行者是公共地址的所有者)并授权(说明执行职能的权力)签名者。由于这些概念被合并，所以无法在不牺牲认证(通过共享密钥)或授权(不能够区分参与人的权力和角色)的情况下在去中心化网络上执行对集团职能来说重要的许多集团结构和细微差别。

基于角色的访问控制(RBAC)如活动目录或LDAP，以及访问控制列表(ACL)是用于在企业上下文中授予权限的传统技术。然而，这些授权技术依赖于集中管理的身份管理、角色定义和基础设施。这种集中化导致与外部企业的集成具有挑战性，并且导致金融服务市场的碎片化。此外，将这些集中式机制与去中心化网络集成是重大的技术挑战。

用于在多方(组/实体)上下文中提供权限的其他已知机制包括多签名钱包和用于权限表达的多方计算(MPC)方法。对于这两种技术，组权限结构反映在平面结构中，使得组的任何成员或成员的任何组合能够对交易进行签名，从而表达组的权限。虽然这些模型可结合所公开的具体实施来使用，但是他们本身缺乏管理权限结构的灵活性，并且不提供将可能涉及嵌套组、顺序进程或临时权限的复杂集团权限结构与提出交易的个体链接起来的方法。

除此之外，这些方法不会用密码方式绑定第三方认证或授权技术与交易上下文中权限的链上表达。可使用非连接的认证和授权步骤，但提出的交易可能执行之前被改变而损害***的完整性。

此外，这些MPC和多签名方法不提供可将宽范围的授权***和技术结合到用密码签名事件中或可认为其在提出的交易的上下文中的框架。

总之，传统授权进程的显式集中化基于技术方法创建了人工边界“围墙花园”，该人工边界会损害与企业外部实体的有效协作。在具有许多互连企业的全球金融***中，“围墙花园”导致贸易结算和对帐延迟，导致效率严重低下，并且使合规复杂化—使监管变得被动而非主动。除此之外，授权的集中化损害了分布式账本***的一个主要优点，即权限的去中心化表达，从而限制了该突破性技术的潜力。由于没有方法将去中心化认证集成到交易签名进程中的授权，DLT所提供的访问便捷性和快速创新渠道丧失。

发明内容

所公开的具体实施通过包括在去中心化网络环境的上下文内用于用密码签名进程中的认证和授权的分离机制来克服上述限制。如本文所用，术语“认证”指的是用于直接或间接地确认签名者的身份的任何技术。认证的示例包括提供公钥和私钥、用户名和口令、钱包/秘密、用于标识的生物特征技术以及用于认证的其他已知技术。如本文所用，术语“授权”指的是用于验证被认证的一方和/或多方的权限(使用实体内的个体的角色、实体内的组、业务进程或批准链、LDAP或活动目录组、社交媒体组或好友列表等)以进行提出的状态改变(交易)的任何技术。

传统的分布式账本技术(DLT)在对交易进行用密码方式签名时不分离这些不同的业务需求，即认证和授权。然而，所公开的具体实施提供了新颖的计算机架构、数据模型、进程和算法，以便通过在提出的交易的上下文中用密码方式链接每个进程、单独地考虑每个进程并且要求每个组件成功批准状态改变(或对状态改变进行签名)，来允许在去中心化环境内将用密码方式链接的认证进程和授权进程作为不同步骤来完成。

在所公开的具体实施中，执行者(即，交易的发起者，诸如个体)被认证，提出必须使用分离但用密码方式链接的进程授权的交易，以对交易进行签名并发起交易。公开了用于用密码方式链接认证和授权(A&A)的技术的若干具体实施，包括：使用解密钱包秘密所需的已加的密访问令牌和密钥片段来链接A&A进程；向通过加密访问令牌链接的认证和授权服务分配单独的多方计算(MPC)或多签名(multisig)批准权力；或者使用基于智能合约的授权来实现对已认证的签名者的链上授权。对于后者，认证和授权进程是分离的，但通过用于在去中心化环境中直接发起的交易的签名上下文来链接。另选地，链接可通过访问令牌完成，该访问令牌是直接或间接规定由可信实体生成用于网络发起的交易的进程或线程的发起者的安全上下文的对象。一个所公开的具体实施涉及利用表示认证、授权和其他(如果期望)进程的片段加密交易签名秘密。所公开的具体实施提供了具有增加的安全性和灵活性的交易***。

本发明的第一方面为一种用于代表实体在去中心化计算机网络上执行数据交易的方法，其中执行者代表实体进行交易的权力通过执行者认证进程来确定，该执行者认证进程用密码方式链接到实体授权进程但与该实体授权进程分离，该方法包括：认证该执行者；响应认证该执行者，创建用密码方式签名的数据包(访问令牌)，该用密码方式签名的数据包提供执行者ID、可选地表示上下文的实体ID、认证服务ID，从而建立用于交易的发起者的认证上下文；验证认证上下文以执行业务逻辑包括；在实体的上下文中制定提出的数据交易，并且在某些包括具体实施中包括已加密的访问令牌；通过确认认证上下文(在某些具体实施中，通过检查包括的访问令牌)和执行者代表实体执行提出的交易的权力使用分离的授权进程来授权交易；代表实体执行数据交易，包括对数据交易进行签名，以提供完成认证步骤、创建步骤、验证步骤、定义步骤和授权步骤的用密码保证；以及将已签名的数据交易记录在去中心化计算机网络的去中心化账本上。

本发明的第二方面为一种用于代表实体在去中心化计算机网络上执行数据交易的***，其中执行者代表实体进行交易的权力被确定、在新颖的智能合约结构中被捕获。智能合约(即，存储在去中心化账本中的可执行代码)表示实体和封装的组织结构和进程，经由智能合约代理链接到智能合约钱包(即，具有代表实体进行交易的权限的合约)，执行者通过对提出的交易进行签名(对认证的等价物进行签名)来激活钱包，并且通过实体的封装授权进程来授权交易，使得代表实体执行提出的交易。

本发明的第三方面为一种方法，通过该方法，变化的交易签名进程(分割密钥加密、多方计算、多签名等)可被替换，以在提出的交易的上下文中影响分离的认证和授权进程的用密码方式链接。认证、交易制定和授权必须发生在用密码方式链接的进程中，以避免恶意或错误元素加入而损害每个元素的完整性。

本发明的第四方面为一种用于加入宽范围的授权进程的方法，该宽范围的授权进程可独立使用或结合起来使用，并且包括基于复杂业务结构、选举和投票、可配置业务进程和工作流以及可编辑策略的授权。

本发明的第五方面为其上存储有指令的计算机可读介质，这些指令在由计算机处理器执行时，使得该计算机处理器执行上述方法。

附图说明

图1是在传统DLT***中对交易进行签名的示意图。

图2a是在去中心化网络环境中将认证和授权的分离的示意图。

图2b是根据所公开的具体实施的用密码方式链接认证和授权的进程的UML图示。

图3是根据所公开的具体实施的认证和授权的示例的数据流程图。

图4a是根据所公开的具体实施的示出消息传输协议的数据流程图。

图4b是根据所公开的具体实施的提供关于在签名序列中的参与者之间的信息交换的更多细节的UML图示。

图5示出了根据所公开的具体实施的架构和MPC创建序列。

图6示出了根据所公开的具体实施的MPC签名序列。

图7示出了根据所公开的具体实施的MPC恢复序列。

图8示出了根据所公开的具体实施的用于将签名权限委托给NPE的进程。

图9是根据所公开的具体实施的代理钱包的示意图。

图10示出了根据所公开的具体实施的由智能合约产生并表示实体的“实体令牌”。

图11示出了根据所公开的具体实施的组钱包的链上具体实施的基本结构。

图12示出了根据所公开的具体实施的链上授权模型的所公开的具体实施。

图13示出了根据所公开的具体实施的授权模型数据模式和数据模型。

图14示出了根据所公开的具体实施的对象关系数据模型。

图15a示出了根据所公开的具体实施的通过共识来完成授权的架构。

图15b是提供关于图15a的选举注册表和投票注册表的数据结构的更多细节的数据模式图。

图16是可使用所公开的具体实施来管理的示例性业务进程的流程图。

图17示出了根据所公开的实施方案的去中心化工作流***的架构。

具体实施方式

所公开的具体实施提供了一种用密码方式保安全的模型来扩展传统授权方法(RBAC和ACL)，以提供与去中心化环境(诸如分布式账本技术)的无缝集成。

大多数DLT技术使用非对称加密来对交易进行签名。这要求签名者出示公钥(地址)和私钥(秘密)，以便对交易进行签名。

图1示意性地示出了传统的DLT数据交易。每个DLT交易都是由发起者授权的状态改变，该发起者准备交易102并在将其发送到网络以供执行之前用从私钥导出的公钥104(通常称为“钱包”或“地址”)对其进行签名。在传统的DLT***中，签名动作既将发起者认证为地址所有者，又授权交易。

在这个简单模型中，认证和授权模型是同义的。因此，当影响网络上的交易时，该模型没有方法考虑交易的性质、交易可能归属的权限结构等。所以，虽然其简单性是具有变革性的，但这种基本方法损害了管理集团数值所需的重要原则，从而使区块链网络在集团上下文中的价值最小化。图1示出了在网络上执行交易的基本步骤(认证、授权和交易制定/签名/发布)。该图示出了这些进程和他们在基本区块链交易上一样是不可分离的。在本公开中，该模型的基本模式将被分割为用密码方式链接，但是分离的认证和授权步骤，并且在如下所公开的一系列具体实施中变化。

如上所述，许多金融交易发生在组上下文中。例如，设想公司的雇员使用集团资源来购买计算机。如果通过DLT实施，则公司拥有的数值将作为数据结构存储在集团钱包中以支持促进集团目标的交易。为了影响期望的交易，雇员将需要被给予集团地址的私钥(该行动将损害钱包中所有的数值)或向已经访问过该私钥的某人咨询。具有访问权限的一方将需要在发起交易之前确认雇员的身份、地位和进行交易的权力。在任何情况下，具有签名权限的个体(或多个个体)即使离开公司也不能可靠地与权限分离，因为他们已经访问过该秘密。

此外，权限结构可以与交易本身的签名分离，因为权限可以取决于交易。例如，雇员可以具有代表公司花费1,000美元的权限，但不能花费1,000,000美元。建立与已签名的交易分离(并且因此不可变的)的权限的任何模型都有在权限被授予之后交易被修改的安全风险(网络或内部人士)。

在去中心化***中在组上下文中表示个体权限的可扩展模型需要用于在用密码方式链接交易发起者的认证时与在组权限的上下文中的提出的交易的授权分离的具体实施。在分离认证和交易授权时进行的这种链接具有组上下文之外的许多应用(例如，个体之间的权限委托、非个人实体(NPE)的授权(即，代表用户行动的机器进程))，这些应用在这里未强调，但在本技术的公开中进行了设想。如上所述，所公开的具体实施包括将复杂授权结构结合到简单交易签名方法中的用密码方法，从而允许在去中心化计算平台内在组(或其他)上下文中表达各种权限结构。

图2a示意性地示出了根据所公开的具体实施的作为DLT***上的交易执行方法的认证和授权的分离。在202处，使用公钥/私钥或其他已知技术诸如登录/口令或生物特征等来认证发起者。提出了一种交易，并且释放了交易签名所需的用密码组件，如下所详细公开的。在204处，评估在组(或其他实体)的上下文中的提出的交易的授权，如下所详细公开的。如果授权，则存在发布交易所需的组件。可以类似的方式加入其他所需的授权进程，诸如来自会计***的批准。一旦所有用密码组件都在适当位置，就可发布具有所需签名的有效交易以在网络上执行，从而，在206处，使得在组或实体的权限下发起交易。如果根据组进程移除发起者的权限，则为了对交易进行签名，不能产生足够的用密码元素。该进程的技术细节在下面公开。

图2b是根据若干所公开的具体实施的用密码方式链接认证和授权的进程的总体UML图示。在随后的章节中详细公开了特定的认证模型、授权框架和签名技术。为了行使组权限(解密并操作组钱包)，发起者—自然人(或人的子组)参与包括用密码方式链接的认证和一个或多个授权进程的进程。访问令牌和共享秘密用于绑定认证和各种授权进程。

如图2b所示，在1处，执行者(例如，个体或个体的子组)认证(例如通过传统的集中式机制)并接收可包括关联到期日期的访问令牌。在2处，执行者通过对称为交易引擎的应用程序接口(API)、事件总线或其他计算进程的计算机网络请求来发起交易。引擎确认访问令牌，使用对称加密技术(AES-256或类似的技术)利用共享秘密对访问令牌进行加密。在3处，交易引擎调用进程、交易构建器以使用目标分布式账本的期望语法来制定交易。交易有效载荷将包括已加密的访问令牌。交易构建器将指定期望交易的所需签名。在4处，交易引擎确认访问令牌与指定签名方之间的链接，并向交易签名服务(TSS)发起请求。在5处，TSS发起针对交易构建器指定的每个所需签名的授权进程。每个签名者具有指定的签名提供者。在6处，提供者使用所公开的具体实施中的任何一个具体实施来执行链接的授权进程，所公开的具体实施包括分割密钥加密、多方计算、多签名或自主签名技术。随后更详细地公开了每种具体实施。作为一般模式，签名提供者向指定的授权提供者咨询签名钱包。在7处，授权服务接收提出的交易的有效载荷，解密该有效载荷以获得并确认访问令牌，然后通过咨询一个或多个授权进程(稍后公开特定的具体实施)来审查提出的交易以验证发起者代表实体影响交易的权力，并且如果被批准，则服务提供所需组件来使得提供者能够对交易进行签名并将已签名的交易返回给TSS。在8处，TSS将所需签名组合成单一有效载荷，并返回给交易引擎以用于发布到目标网络或分布式账本。

每个具体实施在已签名的交易的上下文中将组的权限链接到个体、进程或授权的子组，而不向执行者提供对去中心化网络内的组的权限源(其私钥)的直接访问。只要分配(例如，成员资格、角色或进程)有效，执行者就可仅行使组的权限。当一方行使权限时，委托链说明如何获得该权限，并提供关于在什么上下文中哪个成员行使该权益的可追溯性。由个体或组运行的进程可用于管理委托链(成员资格列表)。这些权限结构可存在于链下或链上。在传统的去中心化网络中，在实体的权限下行动的所有执行者将必须访问实体秘密密钥，并且将没有关于执行者中的哪个执行者对任何特定交易进行了签名的证据。

可用于链接分离的认证和授权进程的一个具体实施是使用对称加密(诸如高级加密标准(AES)-256或相关方法)来加密实体钱包的秘密(即，其签名密钥)，其中用于加密/解密钱包的密钥由若干片段组成。然后将这些片段分配给正在链接的进程，在这种情况下为认证、交易制定和授权进程。每个进程必须贡献其片段以产生表达组权限(即，对交易进行签名并影响交易)所需的密钥。

为了分离签名进程，使用对称加密来加密秘密。所有(两个或更多)密钥片段必须存在，以便基于在下面给出的算法来解密用于对交易进行签名的秘密：

key'＝SHA(认证进程片段^授权进程片段^其他保护密钥)

EncryptedSecret＝AES(秘密,密钥’)

其中：

密钥’(key')通过将散列算法应用于2个或更多个片段来形成，

SHA为安全散列算法或类似的散列技术，并且

AES为高级加密标准或类似的对称加密技术

这些密钥片段被单独存储，每个片段仅可被对应的进程访问，并提供进程之间的用密码链接。具体实施可使用密钥加密密钥将进程链接到其存储的片段。

EncryptedFragment＝AES(进程片段,进程密钥加密密钥)

为了解密代表实体对交易进行签名所需的秘密，必须提供所有密钥片段以重新创建密钥’。因此，每个进程必须独立完成，以便产生解密签名秘密所需的片段。这个方法确保认证和授权进程的独立完成，并且使得一系列授权方法能够在如下所述的去中心化计算环境内共同或独立使用。

为了利用密钥片段技术，用户使用公知的“链下”方法(诸如，用户名/口令、多因素和生物特征)进行认证(对身份的证明)，并且从可信认证源接收访问令牌，即，链下用密码方式签名的数据包。使用这个访问令牌，用户通过***提出交易，该***确认访问令牌，制定待签名的交易，用与授权服务(访问上下文)共享的秘密对称地加密访问令牌，制定提出的交易，并且提供表示制定的交易的源的密钥片段。单独地，授权服务使用共享秘密解密访问上下文以获得访问令牌，确认访问令牌，验证发起者在组上下文中执行交易的权力，并且如果被批准，则提供用于解密用于对交易进行签名的秘密的第二片段。根据需要将这些片段与其他片段组合在一起，以在交易签名的上下文中提供对认证和授权的证明。

与用户的凭证绑定的访问令牌仅在会话中可用。发起者必须主动参与执行权限，并且不能被冒充。用于加密片段的加密密钥可存储在***具体实施处生成、“人手不能接触”并且仅可通过涉及多个独立执行者的批准进程来访问的库中。一旦***恢复，这种访问产生唯一的警报并且导致密钥轮换。

该技术提供了安全性优点、职责分离、分割知识和双重控制。所公开的具体实施的唯一结构提供了额外的优点。例如，身份和交易组件可为物理上分离且独立开发的服务，从而减少涉及损坏***或数据盗窃的内部人士威胁和攻击向量。为了进一步确保分离，可能独立实体可拥有并且托管授权和交易制定服务。

在提出的交易的上下文中链接认证和授权进程实现了用于去中心化交易的非常强大的模型、基于风险的认证。对于基于风险的认证，执行者的认证级别可取决于他们正在尝试的交易的性质。例如，如果执行者提出10美元的交易，则授权进程可能不需要任何特别的认证技术。然而，如果执行者从外国提出1,000,000美元的交易，则授权***可能需要额外级别的认证，诸如生物特征，或甚至带外批准。由于没有在用密码上下文中链接认证、交易制定和授权进程，用于该工作流的可扩展去中心化模型是具有挑战性的、脆弱的并且容易受到网络攻击。

图3示出了根据所公开的具体实施的认证和授权的示例。为了行使组权限(解密和操作组钱包)，自然人(或人的子组)必须获得至少2个不同的密钥片段，包括：1)保护密钥片段(其表示认证进程)；和2)实体密钥片段(其表示授权进程)

如图3所示，在1处，执行者(例如，个体或个体的子组)认证(例如通过传统的集中式机制)并接收可包括关联到期日期的访问令牌。在2处，交易制定进程确认访问令牌(制定交易，并且提供表示成功认证进程的保护密钥片段，从而在去中心化环境内完成认证)。在3处，存储用户的凭证并且生成用户加密密钥。在4处，授权服务验证访问令牌并且确定发起者代表该组行动的权力。如果被授权，则提供授权(用户/实体)片段。可以通过提供额外的密钥片段来表示额外的进程。在5处，交易签名服务(IDataProtector)组合片段以解密钱包的秘密。服务使用钱包私钥来对交易进行签名。注意钱包签名可以使用单密钥、多签名、MPC方法或其他传统方法。

图4a示出了一个示例性具体实施的架构和消息传输协议，其中个体(执行者)在获得操作组(在该示例中为部门)钱包的权限之后作为经纪公司(实体)的代理人对交易进行签名。在认证和接收了到期的访问令牌之后，在402处，执行者通过提供访问令牌数据结构来向身份服务器请求部门密钥片段以授权该请求。在404处，身份服务器确认访问令牌，从访问令牌数据结构中解析实体Id和用户Id，并且确认用户有权访问部门密钥片段。在406处，身份服务器使用密钥加密密钥解密部门片段，并且在408处，将已解密的部门片段发送给执行者。在410处，使用加密密钥、保护密钥和部门片段来解密部门钱包的签名密钥，并且在412处，使用钱包和已解密的秘密来提交交易。在414处，向分布式账本发布包括发起者标识符的已签名的交易。该标识符允许审核员看到例如“发起者代表部门XYZ采取动作”。

在所公开模式的额外的具体实施中，多方计算(MPC)可用于分离涉及交易签名的认证和授权进程。MPC签名技术对于本领域普通技术人员来说是公知的，因此本文不进行详细描述。通常，MPC技术在数学上分割交易签名，使得没有一方或进程可以产生对交易进行签名所需的秘密，但是共同担任批准者的多方可以产生签名权限。本公开使用MPC技术的用密码链接特性并使用本公开的新颖的模式分割影响分离的认证与授权进程之间的交易的能力。在所公开的具体实施中，MPC交易批准权限可在多个服务之间进行分割。例如，一个负责形成提出的交易的服务通过使用由认证服务器(如先前具体实施所述)产生的到期的访问令牌来确认发起者的认证状态。一旦被确认，服务制定提出的交易，使用对称加密和共享秘密(访问上下文)加密访问令牌，将访问令牌添加到交易有效载荷，并且向交易签名服务(或其他通信信道)发布不可变有效载荷及其批准以用于向一个或多个授权服务(批准者)传输消息。单独的授权服务检索交易签名服务消息，使用共享秘密解密访问上下文以获得访问令牌，认证访问令牌和交易源，使用一个或多个进程检查交易是否被授权，并且使用第二MPC签名批准交易。可以应用额外片段来进一步确认交易。当且仅当存在足够的片段时，交易才被签名。

图4b是提供关于在签名序列中的参与者之间的信息交换的更多细节的UML图示。在1处，发起者使用移动设备经由身份和授权服务来进行认证以获得访问令牌。在2处，发起者代表实体向交易引擎提交提出的支付(示出了标称有效载荷)。在3处，交易引擎利用共享秘密来确认、加密访问令牌，并且构建包括实体钱包和已加密的访问令牌的目标分布式账本的有效载荷。在4处，交易引擎对交易进行签名并将其提交给MPC提供者(经由交易签名服务)。在5处，提供者通知所需的批准者(包含授权服务)。在6处，授权服务使用共享秘密来解密并确认访问令牌，确认发起者代表实体的权力。在7处，如果有效，则授权服务器批准提供MPC签名。在8处和9处(可选的)，可使用相同的模式来参与其他批准服务。在10处获得所有批准之后，在11处，将已签名的交易返回给交易引擎以用于发布到网络或分布式账本。

多方计算(MPC)可用来分离认证和授权进程。图5示出了根据所公开的具体实施的架构和MPC创建序列。架构500包括身份和策略引擎502、交易引擎504、MPC提供者506、API模块508、客户端恢复服务510和交易签名服务514。这些组件中的每个组件都将在下面结合所公开的具体实施的各种操作来更详细地描述。如下所述，客户端恢复服务510允许钱包的独立操作。此外，可触发警报向利益相关人通知钱包操作。各种钱包可为“库钱包”，即，用于对交易进行签名或批准的硬件设备。如下所述，钱包可以公知的方式作为服务提供。

如图5所示，在1处，执行者经由身份服务使用移动App登录以接收访问令牌。在2处，执行者使用移动App经由交易引擎API请求交易。此时，由交易引擎确认执行者的访问令牌。在3处，交易引擎构建所请求的交易，即，该交易引擎以目标分布式账本所需的模式创建提出的交易的有效载荷。在4处，交易引擎向交易签名服务发布提出的交易。交易包括在利用交易引擎与期望的身份和策略(授权)引擎之间共享的秘密加密的访问令牌。注意：基于“主机”，不同钱包可具有不同策略服务器。在5处，对于指定的钱包，交易签名服务向MPC签名服务发布交易(第一批准)。其他提供者(多签名、自签名或HSM、分割密钥)可通过遵循相同模式来添加。在6处，MPC签名服务请求来自授权服务(身份和策略引擎)的批准。在7处，授权服务解密并确认访问令牌的合法性，咨询管理交易的策略(如果有的话)。如果被授权，则授权服务批准交易以满足X个标准中的2个标准。如果授权失败，则失败原因被记录为拒绝。如果需要，诸如对于库钱包，在8处，执行者使用独立批准服务(通常在移动设备上)批准交易。根据特定应用的需要，可以包括其他批准服务。在9处，一旦获得所需的批准，提出的交易就被签名并被返回给交易签名服务。在10处，将已签名的交易发送到交易引擎以用于发布，并且，在11处，将已签名的交易发布到去中心化账本，诸如区块链账本。

对于库功能，执行者的独立签名服务可用交易签名服务注册。每个服务确认钱包创建。然后，组钱包可供已将权力分配给组的各方从移动App中进行使用。可使用X签名序列(对于库)中的2个签名或X签名序列中的3个签名对钱包进行签名。交易引擎和身份策略引擎两者可被要求签名以发起交易。策略通过身份/策略引擎的签名来实施。

图6示出了根据所公开的具体实施的MPC签名序列。在1处，用户经由已经接收到用户的访问令牌的身份服务使用移动App登录。在2处，用户使用移动App经由交易引擎的API请求交易。用户的访问令牌由交易引擎确认。在3处，交易引擎经由MPC提供者发起交易事件，使用对称加密技术(诸如，高级加密标准AES-256)和共享秘密加密访问令牌，并且在4处，根据需要向交易签名服务发布包括提出的交易、已加密的访问令牌和其他元数据的事件。该步骤表示认证和交易制定进程。在5处，身份和策略引擎的身份服务检测来自交易签名服务的签名事件，使用包括访问令牌的共享秘密来解密交易有效载荷，确认访问令牌的合法性，确认用户/数据交易发起者在组和/或交易的上下文中的权限，并且如果被批准，则对交易进行签名(批准)以满足X个标准中的2个标准。如果需要(例如，对于库钱包)，用户可被要求使用独立的签名服务(例如，在移动设备上)来对交易进行签名。库钱包是使用所公开的交易签名模式的钱包，该模式要求由执行者或另一方独立于认证和授权进程进行的额外带外批准。这种签名可以涉及已知的基于硬件的签名机制。

图7示出了根据所公开的具体实施的由客户端恢复服务实现的MPC恢复序列。可使用X签名序列中的2个签名或X签名序列中的2个签名来恢复钱包。如果每个客户端恢复服务都签名，则可在没有用户参与的情况下发起交易。此外，恢复不需要通过绕过本文所公开的认证和授权技术用身份或交易引擎操作来实现业务连续性。对于库钱包，用户也可被要求使用独立的签名服务来对提出的交易进行签名。在一个或两个客户端恢复服务节点发生故障或丢失的情况下，可以使用引擎签名器。如图7所示，在1处，客户端恢复服务中的任一节点发起恢复交易(通常向新地址传递数值)。在2处，独立节点确认恢复交易并对该恢复交易进行签名。如果需要(例如，对于库钱包)，用户可以在3处使用独立的签名服务来对交易进行签名。

钱包的签名权限也可委托给非个人实体(NPE)。例如，该技术可以用于定期支付、过桥交易(诸如抵押)或基于进程的交易，诸如托管钱包(即，连接到因特网的钱包)的热门功能。

图8示出了用于将签名权限委托给NPE的进程。在1处，用户经由身份服务使用移动App登录并将其身份令牌发送到身份服务。在2处，用户使用移动App(或其他客户端设备)创建触发器，该触发器指定要执行的任务和可使用用户权限的事件、时间或间隔。触发器通过API发送到交易引擎，被存储并用于向NPE分配职责。向交易签名服务发布触发器创建事件，包括用共享秘密加密的访问令牌和触发器有效载荷。触发器发布事件可由身份和策略引擎检测。身份和策略引擎使用共享秘密解密访问令牌，确认访问令牌是由表示授权用户的身份源发布的。一旦确认，NPE在触发器上下文中代表用户行动的权限的委托被存储在3处的签名存储器中包含以下数据的记录中：触发器、发起者和委托的NPE标识符以及其他数据。触发器可以在任何时间被发起者移除。然后，在4处，NPE在触发器的上下文中经由身份服务进行注册(登录)。身份服务在分配的触发器的上下文中确认委托状态。然后，NPE接收反映该权限的访问令牌。

当基于相关联的时间或检测到的事件激活触发器时，NPE通常通过调用在5处的交易引擎API来执行分配的任务。交易引擎确认NPE的访问令牌并制定提出的交易数据结构。在6处，交易引擎经由MPC提供者发起交易事件并将向交易签名服务发布该交易。身份和策略引擎的身份服务检测来自总线的签名事件，验证访问令牌、触发器和委托的合法性，确定是否使用了该组的权限来授权交易，并且如果被批准，则对交易进行签名以满足X个标准中的2个标准。如果需要(例如，对于库钱包)，则可要求组指定的用户使用独立的签名服务来对交易进行签名。

除此之外，如图2b所示，在以上流程中，其他签名技术诸如multisig模型可替代MPC。在这种情况下，用于认证和授权进程的签名使用multisig而不是MPC技术。

相关但流程与图2b不同的模式(分离的但用密码方式链接的认证和授权进程)为一次，其中认证和所有授权方法都在链上发生。该模式不需要已加密的访问令牌来链接认证和授权步骤，因为智能合约授权进程仅可在已认证的钱包交易的上下文中发生。

新颖的智能合约(即，存储在去中心化账本上的可执行代码)的具体实施允许创建合约钱包(即，封装钱包并因此可用于作为表示用户或实体的钱包代理而发起交易的智能合约)，允许将发起者(对交易进行签名的钱包)的认证与在智能合约或其他源中编码的授权进程分离。这样，具有分配的钱包的个体可从表示实体的权限的智能合约钱包发起交易。在这种情况下，通过发起对提出的交易或其他状态改变进行钱包签名来执行认证，并且通过在智能合约或其他源中编码的进程来执行授权。例如，该技术可用于基于提出的交易的性质来确定发起者(签名钱包)是否为具有权限的组的已授权成员。

在每个所公开的具体实施中，最终结果为已签名的交易，其中发起者已使用用密码方式链接的分离进程进行了认证和授权，以防止未授权数据的加入。授权进程可使用由访问令牌链接的传统计算进程在“链上”(例如，通过经由由去中心化虚拟机执行的智能合约)或“链下”进行。这些技术可被组合用于混合链上/链下授权。换句话说，对钱包进行签名的权限可使用所述的链下具体实施，而使用“链上”授权步骤，会连续发生另外的授权步骤。

一旦认证和授权步骤已被分离但在交易上下文中被链接，就有可能加入在去中心化交易的上下文中有用的许多不同的授权形式和方法，尤其是那些涉及集团权限结构的形式和方法。公开了去中心化授权方法的各种具体实施，其可与上述任何提出的链接方法共同使用或单独使用。

在一个所公开的具体实施中，组结构(即，组以及组、成员和/或角色间的关系)被记录在链上(存储在分布式账本上)或链下(存储在集中式数据存储器中)。发起者代表实体行动的权限可从这些组结构中导出以确定执行者是否被授权进行提出的交易。如果使用链上模型进行授权，则通过实体的合约钱包执行交易，该实体的合约钱包是使得交易能够如同交易是通过公钥/私钥进行签名的那样来执行的新颖结构。

所公开的具体实施可将分离的认证进程与共识授权或投票模型组合。在该具体实施中，已认证用户提出交易并发起投票，已授权成员(通常为用密码令牌持有人)投出他们的投票，使用智能合约中的可配置方法对投票进行计数，并且如果被授权，则使用如先前具体实施中教导的相关联合约钱包来发起交易。

所公开的具体实施可使用在分布式账本上存储和配置的业务进程。所公开的数据结构允许涉及一个或多个步骤的可配置业务进程被***授权进程中用于提出的交易。这些具体实施可以单独或共同使用。除此之外，如美国专利申请序列号16/143,058(其公开内容被并入本文)中所述的去中心化策略实施点可被***或与其他所公开的授权技术结合使用，以确定提出的交易是否被授权。所公开的具体实施提供了一种包括DLT本地企业认证和授权模型的链上方法，这些模型在所有级别都为去中心化，从而解锁DLT***的全部潜力。

在另一个具体实施中，智能合约用于封装持有组数值并表示组权限的钱包。这些已封装的钱包(“代理钱包”)用于代表组执行交易。在该具体实施中，认证可使用上述方法中的任一种方法来进行，从而产生在组上下文中提出的已签名的交易。咨询在组上下文中评估发起者的权限的外部智能合约，并且如果被授权，则经由代理钱包发起交易。该序列包含用密码方式链接的分离的认证(用于对交易进行签名)和授权(经由授权智能合约)进程的所公开模式。如果被批准，则代表实体使用IContractWallet执行交易，如下所述。

如图9所示，IContractWallet(代理)用于允许外部合约在没有钱包秘密的情况下操作钱包。用于实现代理钱包的示例性代码在下面给出。

IContractWallet接口

pragma solidity>＝0.6.0<0.7.0；

/**

@title合约钱包

被设计成由令牌或智能合约包装器操作

@notice可持有ERC-20、ERC-721、ERC-1400令牌和以太币。

*/

abstract contract IContractWallet{

/**

@notice传输以太币

@param to以太币接收者地址

@param value待传输的数值

@param data(可选的)用于策略实施的额外数据

*/

function etherTransfer(

address to,

uint value,

bytes calldata data)

external

virtual

returns(bool)；

/**

@notice传输ERC-20或与ERC-20向后兼容的令牌

@param token将传输的令牌地址

@param to接收者地址

@param value待传输的数值

@param data(可选的)用于策略实施的额外数据

*/

function erc20Transfer(

address token,

address to,

uint value,

bytes calldata data

)

external

virtual

returns(bool)；

/**

@notice传输ERC-721或与ERC-721向后兼容的令牌

@param token将传输的令牌地址

@param to接收者地址

@param tokenId要传输的ERC-721令牌id

@param data(可选的)用于策略实施的额外数据

*/

function erc721Transfer(

address token,

address to,

uint tokenId,

bytes calldata data

)

external

virtual

payable；

/**

@notice传输ERC-1400或与1400向后兼容的令牌

@param token将传输的令牌地址

@param partition分区

@param to接收者地址

@param value待传输的数值

@param data(可选的)用于策略实施的额外数据

*/

function erc1400TransferByPartition(

address token,

bytes32 partition,

address to,

uint value,

bytes calldata data

)

external

virtual

returns(bytes32)；

}

IContractWallet是一种包装智能合约的接口，该智能合约使得能够创建并操作钱包(例如，区块链地址)，这些钱包在已签名的上下文内操作但不需要密钥。这些钱包模拟用户在这些令牌交易中持有的钱包，或者钱包执行的其他交易是允许的。可以上述方式将操作钱包的权限委托给第三方智能合约(创建IContractWallet的合约)，在这种情况下为表示实体并授权发起者代表实体与代理钱包进行交易的合约。

图10示出了由智能合约产生并表示实体的“实体令牌”。实体令牌为不可替代的(例如，ERC-721)令牌，其表示经由实体注册表智能合约发布的个体、组或非个人实体(NPE)。这些令牌可以被分配IContractWallet，如前一章节所述。实体注册表合约可以咨询授权进程以基于包括评估签名者的角色或与实体的附属关系在内的逻辑来确定发起者执行交易的权力。

图11示出了在单笔交易中实现认证和组授权分离的组钱包的链上具体实施的基本结构。在一个示例中，个体对交易进行签名以移动实体#1的钱包中的数值。实体注册表向授权模块1104的授权合约咨询，以基于个体与实体的附属关系来确定该个体是否有权力移动实体钱包中的数值。在另一个示例中，个体提出交易注册表1106中的交易。个体经由实体2令牌对交易进行签名。实体注册表1102向授权模块1104咨询以执行该交易。实体注册表接口描述代码的一个示例在下面给出。

/>

/>

/>

/>

图12示出了链上授权模型的所公开的具体实施，其中授权模块1104包括成员资格、角色和职能注册表。这些数据结构(例如表格)通过I成员资格接口进行访问，并且包含个体与实体之间和之中的链接。当个体尝试操作实体钱包、对提出的交易进行签名或证明数据时，实体注册表智能合约咨询策略引擎1202和/或授权模块1204以评估个体在组上下文中执行交易的权限。

图13示出了用于链上或链下具体实施的授权模型数据模式和数据模型。该模式和数据模型支持任何类别的实体，诸如成员资格模块1302中所示的那些。这些关系用于确定个体代表实体行动的权限。实体表格中的盐属性1303用于生成以上述方式解密和操作实体拥有的钱包所需的密钥片段。例如，实体定义可包括个体、组或非个人体实体。实体关系可以被嵌套。换句话说，组可以包含另一个组，而该另一个组还具有另外的组。授权可以从组(上下文)内的角色导出或可以经由成员资格被分配给实体。成员资格为实体/角色/实体链接，但是它也可以被表达为实体/角色、实体/组或甚至实体/实体(社交媒体)。授权结构的示例包括：

·Dan(实体-个体)为Securrency(实体-组)的CEO(角色)

·Dan(实体-个体)为Securrency金融部门(实体-组)的成员(角色-默认)

·Securrency金融(实体-组)为Securrency(实体-组)的一个部门(角色)

·Dan(实体-个体)为Securrency工程部门(组)的成员[角色，隐含的]

·Dan(实体-个体)是Securrency***[实体-组，隐含的]的管理员(角色)

·Dan(实体-个体)经由领英[角色，隐含的]连接到John(实体-个体)

权限的委托可以从成员资格属性导出。例如：

·Securrency(实体-组)是Dan(实体-个体)的经纪人(角色)

·具有期限：

·Dan在度假时具有对John的批准权限(到期的权限)

·Dan为安全办公室的值夜人员(到期的权限)

使用该数据模型和模式，用多个模型管理实体上下文中的权限是可能的。例如，可由组管理人员集中分配权限，任何成员可以添加另一名成员，或者通过与其他组和/或实体的附属关系添加另一名成员。对于成员资格类型也存在各种可能性，诸如单向信任(未经同意添加成员)和双向信任(两个实体均须同意添加)。实体可见性可变化。例如，组可仅对组的成员可见，或者成员可对于组中的其他成员是隐藏的。可仅通过邀请或基于其他条件来加入组。

图14中示出了用于评估个体代表实体行动的权限的对象关系数据模型。在1402处，例如，I部门实体(名称：谷歌金融部门)和I个体实体(名字：Dan，姓氏：Doney)之间的链接可以是经由将角色(名称：审计官)与成员资格相关联的成员资格链接的。基于该成员资格和角色，作为该链接的结果，已链接的实体可被授权执行特定职能(名称：发款)。当使用该链接授权交易时，可以通过成员资格标识符来实现问责，并且可以通过数据模型链接来追踪权限的出处。如果通过分层成员资格嵌套了权限，则可以使用多级标识符。

为了创建图14的数据模型，需完成以下步骤：

链下

■经由批准进程将职能分配给实体；

■验证代理人有能力证明实体执行职能的资格；

■经由成员资格服务将实体(个体、组、NPE)分配给上代实体；

■经由该链接将权限(执行职能的权力)从上代实体委托给子代实体；

■当实体出示证明成员资格的凭证时，他们接收到包含密钥片段和用于问责的成员资格标识符的令牌。该令牌也可以包含可用于进一步限制对某些组职能的访问的角色。实体无权直接访问片段、标识符或角色；

■组权限被表达为公钥/私钥对。可使用multisig、MPC方法或密钥片段的组合来对交易进行批准(签名)以解密私钥，如上所公开的；

■可通过呈现包含继而用于解密私钥并实现该动作的片段的令牌来行使组权限。

链上：

■经由批准进程将职能分配给实体；

■验证代理人有能力证明实体执行职能的资格；

■部署表示代表实体(组)执行一个或多个职能的权限的实体令牌；

■经由成员资格注册表将实体(个体、组、NPE)分配给上代实体；

■通过经由实体注册表智能合约(参见图12的元素1202)对I授权或I证明数据结构进行签名来向组呈现个体凭证，成员实体可行使组权限。

除此之外，所公开的具体实施可利用处于用密码方式链接的认证和授权模式(其被描述为本公开的基本模式)的共识授权模型。共识钱包遵循与组钱包相同的分离模式，即，发起者通过认证(对发起交易进行签名)提出交易，参与独立的授权进程(在这种情况下是共识或投票模型)，并且如果被授权，则经由合约钱包来执行交易。虽然使用不可替代的令牌(例如，ERC-721)的具体实施是可能的，但更普遍的具体实施与可替代的令牌相关联，诸如ERC-20令牌，其中授权人为投出授权投票的令牌持有人。ERC-20令牌被设计成具有许多所有者，并且，除其他之外，基于特定钱包拥有的份额百分比来反映所有权等。图15示出了通过共识来完成授权的架构。图15a的架构包括选举注册表1502数据库和投票注册表1504数据库。

如上所述，令牌智能合约被分配智能合约钱包。令牌发布者或其他授权方可提出交易。然后，该方使用共识智能合约发起选举。如果特别的投票权重或法定人数技术是期望的，则选举可使用自定义智能合约来对投票进行计数。然后，令牌持有人经由钱包对交易进行签名来投出投票。投票的计数结果通常与股份所有权和投票权力成比例。如果选举通过，则使用IContractWallet来授权并执行提出的交易。

集团管治通常涉及对某些类别的股东(令牌持有人)进行投票。在这种情况下，可使用不可替代的令牌，该不可替代的令牌表示资产或实体并且链接一个或多个可替代的令牌，每个可替代的令牌表示一个股份类别。不可替代的实体令牌控制关于每个股份类别投票的重要性的逻辑。进行对主题的选择以决定集团实体是否应当执行某个动作。由合格的股东投出投票(通常与股份所有权成比例，但其他管治模型也是可能的)，并对结果进行计数。如果基于集团规章的必要条件得以满足，则实体可以采取该动作。

区块链和其他去中心化技术提供了加速和扩展该进程的机会。先前所示的集团钱包模型的变体为其中成员举行选举以行使权限的共识钱包。另一种变体为由特定类别的令牌持有人基于股份所有权来行使集团权限的选举。

由于选举和投票收集智能合约是分离的，因此表示实体的令牌智能合约可结合共识智能合约来执行某些交易，允许合约逻辑升级，或者使用已建立的代理技术来代表其所表示的集团实体行使其他权限。由智能合约表示的实体具有允许组员(令牌持有人)对是否升级其智能合约进行投票的共识进程的案例是该模式的特别新颖且意义重大的具体实施。

图15b是提供关于选举注册表和投票注册表的数据结构的更多细节的数据模式图。选举注册表存储关于提出的选举的细节以授权交易。提出的交易通过项目Id字段中的外部密钥来识别。选举中合格的投票人由令牌(外部密钥令牌Id)及其分布或由令牌指定的其他模型(例如，如由不同具体实施中所公开的成员资格职能定义的集团成员)来确定。

还示出了关于选举的其他细节，包括开始和结束日期以及投票人说明。未示出内容包括其他选项，诸如共识模型(例如，大多数、多数、股份加权共识等)或法定人数要求。在选项表格中呈现了对于特定选举而言投票人可用的选项。交易批准的默认选项为批准和不批准。投票注册表包含选举的结果，因为合格的投票人通过调用投票API或使用合格的钱包对投票交易进行签名来投出他们的投票。一旦达到法定人数，选举注册表将基于选举结果来批准或拒绝提出的交易。

此外，去中心化工作流授权可被加入到本公开的基本模式中，该去中心化工作流授权是在交易的上下文中分离但用密码方式链接的认证和授权。去中心化工作流授权遵循与共识钱包相同的分离模式，即发起者或经由触发器委托的非个人实体通过认证(对发起交易进行签名)提出交易，参与独立的授权进程(在这种情况下为工作流进程)，并且如果被授权，则经由合约钱包来执行交易。一些进程可能不使用提出的交易或合约钱包，而是执行作为更大的交易上下文的一部分的授权进程。

工作项目智能合约用于在提出的授权移动通过可配置的集团进程时产生表示状态的令牌。通常，职能的执行(或执行动作的权限的接收)经受涉及任务或批准的序列的进程，从而涉及序列中的多个实体。这些序列被称为“工作流”。“工作项目”为包含状态信息的数据元素，以遵循工作流序列来完成。工作流由一个或多个任务和连接任务的路由组成，从而基于工作项目和任务结果来允许不同序列。

所公开的具体实施包括允许工作流管理的非集中化的上述新颖技术、架构和数据结构。该技术使用智能合约来执行工作流状态管理并且存储和执行进程(工作流)。非集中化业务进程的存储和执行的优点类似于非集中化支付的优点。例如，非集中化能够去中介化，从而允许各方之间协调以跨越组织边界完成进程，并且不依赖于集团***。

图16是根据所公开的具体实施的捕获集团进程的示例的工作流图示的流程图。该工作流包括一项或多项任务和用于连接任务的路由，每项任务具有类型。例如，任务类型可包括：边界任务(例如，开始和停止)、手动任务(例如，批准)、决策任务(例如，基于工作项目属性的自动状态改变)；以及路由(任务之间的连接器)。

工作流可被捕获并被表示为存储在分布式账本上的映射，并且由包括在分布式账本上执行的智能合约的去中心化工作流引擎执行。每个工作项目都通过该流程处理。当项目进入任务时，可向交易签名服务发布事件，并且可通知受影响的和/或其他利益相关人。这些实体可以选择用于工作项目的路由(状态改变)，用其钱包进行签名以导致状态改变，从而基于配置移动到下一任务。例如，路由选择可被一个或多个实体批准或拒绝。由于工作流为去中心化的，因此工作流不需要依赖于集中式***，并且可以从任何钱包执行。

每个工作项目都可对应于不可替代的(例如，ERC-721)令牌，即，工作项目注册表智能合约中的状态记录。每个令牌都表示在工作流中进行的特定项目或职责的进程的当前状态。任务是存储在任务注册表中的工作流内的特定状态。手动任务(由人类执行的那些任务)由人类执行，并且由负责方使用钱包密钥对来签名。自动任务(决策点或其他自动化处理)可以经由可配置的智能合约来执行。任务由表示状态改变的路由来连接。工作流是由流程管理员设计和监视的进程的任务和路由的组合。

如图16所示，在1602处，执行者(部门主管)提出购买，诸如制造装备的购买。提出的账本交易表示购买。在1604处，另一个执行者(审计官)审查1604处的支持数据，诸如定价、递送、类似装备的现有库存或任何其他相关数据。在1606处，审计官可通过基于对以上述方式确定的行动的权限对该账本交易进行签名来批准账本交易，并因此批准提出的购买。如果购买价格大于10,000美元(美国)，则在该示例中，在1608处，通知CFO并向其提供审查并对批准交易进行签名以进行购买的机会。在该示例中，如果购买价格大于100,000美元(美国)，则在1610处，需要CEO批准。一旦获得所有批准，在1612处，通知董事会，并且在1624处顺利完成该工作流，使得执行提出的交易，以允许进行装备的购买。在分布式账本上追踪所有任务，并且可基于对如本文所述的行动的权限来获得各种签名。可基于如在工作项目注册表中追踪的对应令牌来追踪每个工作项目的每种状态。

图17示出了根据所公开的实施方案的去中心化工作流***的架构。账本交易经由交易注册表1702提出，并且被路由用于经由工作流引擎1704进行批准，方法是参考(项目字段中的)提出的交易、指定的工作流、当前任务和任务状态连同关于流程发起的时间、最后状态改变和其他数据的其他元数据在工作项目注册表中创建工作项目。工作项目注册表1706为控制流处理并经由工作项目令牌(如上所述)维持工作流中的项目的当前状态的智能合约。交易注册表1708存储各种工作流定义。工作流为存储在路由注册表1710中的零个至许多个路由的集合，这些路由链接任务注册表中的任务。任务为描述导致工作项目的状态改变的批准、智能合约执行指令或决定。在完成任务时，工作项目注册表通过将执行路由到由可用路由定义的下一个任务以使得能够处理提出的项目(交易)来实现工作流。各种用户可以管理或设计工作流、任务或路由。自动任务可以执行由认证代理测试和部署的智能合约。

下面的注释代码是描述该进程的代码的示例。

///<概括>

///该接口用于描述进程(通过路由链接的任务组合)。

///</概括>

public interface IWorkflow:IItem

{

///<概括>

///ReferenceId应该由具有对象的所有接口使用，这些对象通常通过其外部标识符来知晓。

///</概括>

[CanBeNull]

string ReferenceId{get；}

///<概括>

///或者，这是要显示的用户友好名称(displayName)。

///</概括>

string Name{get；}

///<概括>

///提供者的名称。

///</概括>

[CanBeNull]

string Provider{get；}

ITask Initial{get；}

ITask Final{get；}

}

Task

///<概括>

///该接口用于管理任务(在进程中执行的动作)。

///</概括>

public interface ITask:IItem

{

///<概括>

///</概括>

[CanBeNull]

string ReferenceId{get；}

///<概括>

///或者，这是要显示的用户友好名称(displayName)。

///</概括>

string Name{get；}

///<概括>

///定义处理方法的任务类型。

///</概括>

TaskType TaskType{get；}

///<概括>

///负责执行任务的实体(空是指可通过触发器或委托进行分配)///使用已分配的实体创建任务需要该实体的签名

///</概括>

[CanBeNull]

IEntity Entity{get；}

///<概括>

///提供者的名称。

///</概括>

[CanBeNull]

string Provider{get；}

}

///<概括>

///该接口用于描述路由(基于输入链接路由的流控制器)。

///</概括>

public interface IRoute:IItem

{

///<概括>

///</概括>

[CanBeNull]

string ReferenceId{get；}

///<概括>

///或者，这是要显示的用户友好名称(displayName)。

///</概括>

string Name{get；}

///<概括>

///路由所绑定到的进程

///</概括>

IWorkflow Workflow{get；}

///<概括>

///在路由被遍历的情况下要发起的任务

///</概括>

ITask Task{get；}

///<概括>

///为遍历路由而完成的任务

///</概括>

ITask Source{get；}

///<概括>

///用于定义路由是否为任务的默认出站路径

///</概括>

bool IsDefault{get；}

///<概括>

///提供者的名称。

///</概括>

[CanBeNull]

string Provider{get；}

}

Workitem

///<概括>

///接口用于描述工作项目。工作项目用于追踪在任务和/或进程中的状态。

///</概括>

public interface IWorkitem:IItem

{

///<概括>

///</概括>

[CanBeNull]

string ReferenceId{get；}

///<概括>

///或者，这是要显示的用户友好名称(displayName)。

///</概括>

string Name{get；}

///<概括>

///定义正被执行的任务的状态。

///</概括>

TaskState State{get；}

///<概括>

///正被执行的任务。

///</概括>

ITask Task{get；}

///<概括>

///负责执行当前任务的实体(当所有任务都完成时为空)///</概括>

[CanBeNull]

IEntity Entity{get；}

///<概括>

///任务所属的进程。

///对于在进程(自组网)外执行的工作项目，可为空。

///</概括>

[CanBeNull]

IWorkflow Workflow{get；}

///<概括>

///正通过任务或流程进行处理的项目。

///对于不具有正被处理的对象的任务，可为空。

///</概括>

[CanBeNull]

IItem Item{get；}

///<概括>

///导致生成子工作项目的工作项目。

///用于具有嵌入式工作流的工作流并用于并行任务。

///对于不是从其他工作项目导出的工作项目，可为空。

///</概括>

[CanBeNull]

IWorkitem Parent{get；}

///<概括>

///工作流提供者的名称。

///</概括>

[CanBeNull]

string Provider{get；}

}

///<概括>

///该接口用于表示触发器(导致任务被执行的基于时间或事件的信号)。

///</概括>

public interface ITrigger:IItem

{

///<概括>

///</概括>

[CanBeNull]

string ReferenceId{get；}

///<概括>

///或者，这是要显示的用户友好名称(displayName)。

///</概括>

string Name{get；}

///<概括>

///触发器类型

///</概括>

TriggerType TriggerType{get；}

///<概括>

///触发器的状态(启用/禁用)

///</概括>

TriggerStatus Status{get；}

///<概括>

///与触发器相关联的项目

///</概括>

IItem Item{get；}

///<概括>

///在触发器被触发的情况下要执行的任务

///</概括>

ITask Task{get；}

///<概括>

///在触发器被触发的情况下要执行的任务

///</概括>

[CanBeNull]

IWorkflow Workflow{get；}

///<概括>

///提供者的名称。

///</概括>

[CanBeNull]

string Provider{get；}

///<概括>

///触发器被触发的次数。

///</概括>

int Counter{get；}

///<概括>

///用于存储额外的数据

///</概括>

[CanBeNull]

string OtherData{get；}

}

所公开的具体实施可以由利用软件和/或固件编程的各种计算设备来实现，以提供所公开的由硬件实现的可执行代码的功能和模块。软件和/或固件可以作为可执行代码存储在一个或多个非暂态计算机可读介质上。计算设备可以经由一个或多个电子通信链路可操作地连接。例如，可以至少部分地经由网络诸如因特网和/或其他网络来建立此类电子通信链路。

给定计算设备可以包括被配置为执行计算机程序模块的一个或多个处理器。计算机程序模块可以被配置为使得与给定计算平台相关联的专家或用户能够与***和/或外部资源进行交互。作为非限制性示例，给定计算平台可以包括服务器、台式计算机、笔记本计算机、手持式计算机、平板计算平台、智能手机、游戏机和/或其他计算平台中的一者或多者。

各种数据和代码可以存储在电子存储设备中，该电子存储设备可以包括电子地存储信息的非暂态存储介质。电子存储装置的电子存储介质可以包括与计算设备集成地(即，基本上不可移除)提供的***存储装置和/或经由例如端口(例如，USB端口、火线端口等)或驱动器(例如，磁盘驱动器等)可移除地连接到计算设备的可移除存储装置中的一者或两者。电子存储装置可以包括光学可读存储介质(例如，光盘等)、磁性可读存储介质(例如，磁带、磁性硬盘驱动器、软盘驱动器等)、基于电荷的存储介质(例如，EEPROM、RAM等)、固态存储介质(例如，闪存驱动器等)和/或其他电子可读存储介质中的一者或多者。

计算设备的处理器可以被配置为提供信息处理能力，并且可以包括数字处理器、模拟处理器、被设计成处理信息的数字电路、被设计成处理信息的模拟电路、状态机和/或用于电子地处理信息的其他机构中的一者或多者。如本文所用，术语“模块”可以指执行属于该模块的功能的任何组件或组件集合。这可以包括在处理器可读指令的执行期间的一个或多个物理处理器、处理器可读指令、电路、硬件、存储介质或任何其他组件。

尽管为了说明的目的，已经基于当前被认为是最实用且优选的具体实施详细描述了本技术，但是应当理解的是，此类细节仅仅是为了该目的，并且本技术不限于所公开的具体实施，而是相反，旨在覆盖所附权利要求的精神和范围内的修改和等同布置。例如，应当理解的是，本技术设想了，在可能的范围内，任何具体实施的一个或多个特征可以与任何其他具体实施的一个或多个特征组合。

可以为在签名交易的上下文中的用密码方式链接但程序上分离的认证和授权实现额外的另选结构和功能设计。因此，虽然已经示出和描述了具体实施和示例，但是应当理解的是，本发明不限于本文所公开的精确构造和组件。在不脱离所附权利要求中限定的本发明的精神和范围的情况下，可以对本文所公开的方法和装置的布置、操作和细节进行各种修改、改变和变更。

Claims

1.一种用于代表实体在去中心化计算机网络上执行数据交易的方法，其中执行者代表所述实体进行所述交易的权力通过执行者认证进程来确定，所述执行者认证进程用密码方式链接到实体授权进程但与所述实体授权进程分离，所述方法包括：

认证所述执行者；

响应于认证所述执行者，创建用密码方式签名的数据包，所述用密码方式签名的数据包提供执行者ID、可选地表示所述认证的范围的实体ID，以及认证服务ID，从而建立用于所述交易的认证上下文；

验证所述认证上下文；

在所述实体的上下文中制定提出的数据交易；

通过确认所述执行者代表所述实体执行所述提出的交易的权力来授权所述交易；

代表所述实体执行所述数据交易，包括对所述数据交易进行签名，以提供完成认证步骤、创建步骤、验证步骤、定义步骤和授权步骤的用密码保证；以及

将已签名的数据交易记录在所述去中心化计算机网络的去中心化账本上。

2.根据权利要求1所述的方法，其中所述执行者为单个人或一组人。

3.根据权利要求1所述的方法，其中所述数据交易表示金融交易。

4.根据权利要求1所述的方法，其中所述用密码方式签名的数据包包括基于时间的期限。

5.根据权利要求4所述的方法，其中使用所述用密码方式签名的数据包的共享秘密的非对称加密来链下链接认证和授权进程。

6.根据权利要求4所述的方法，其中所述认证包括导致发布用密码方式签名的数据包的轻量级目录访问协议(LDAP)认证、活动目录认证、生物特征认证和口令认证中的至少一者。

7.根据权利要求1所述的方法，其中认证所述执行者包括所述执行者使得在所述交易的所述用密码上下文中用从与所述执行者相关联的用密码钱包导出的签名来对所述提出的交易进行签名。

8.根据权利要求1所述的方法，其中对所述数据交易进行签名包括分割密钥加密、用于加密私钥的片段、与外部进程相关联的多签名方法、与外部进程相关联的多方计算方法和/或通过被处理以确定授权的链上钱包交易进行签名中的至少一者。

9.根据权利要求1所述的方法，其中所述授权基于实体组织结构和角色。

10.根据权利要求9所述的方法，其中所述实体组织结构包括多个级别，并且级别标识符用于通过实体结构提供权限。

11.根据权利要求1所述的方法，其中所述授权基于组投票。

12.根据权利要求1所述的方法，其中所述授权基于工作流自动化。

13.根据权利要求1所述的方法，其中至少一个钱包由智能合约封装，从而表示至少一个组的组权限，并且其中所述至少一个钱包用于代表所述至少一个组执行交易。

14.根据权利要求1所述的方法，其中至少一个工作流被表示为存储在所述去中心化账本上并且经由去中心化工作流引擎执行的映射，所述去中心化工作流引擎包括在所述去中心化引擎上执行的智能合约，所述工作流包括工作项目、路由和任务，并且所述工作项目中的每个工作项目在所述去中心化账本上具有对应的不可替代的令牌，由此任务批准者能够在所述工作流内选择用于所述工作项目的路由。

15.一种用于代表实体在去中心化计算机网络上执行数据交易的***，其中执行者代表所述实体进行所述交易的权力通过执行者认证进程来确定，所述执行者认证进程用密码方式链接到实体授权进程但与所述实体授权进程分离，所述***包括：

至少一个计算机处理器；和

至少一个存储器设备，所述存储器设备操作地耦接到所述至少一个计算机处理器并存储所述至少一个计算机处理器上的指令，所述指令在由所述至少一个计算机处理器执行时，使得所述至少一个计算机处理器执行以下方法：

认证所述执行者；

响应于认证所述执行者，创建用密码方式签名的数据包，所述用密码方式签名的数据包提供执行者ID、实体ID、认证服务ID，从而建立用于所述交易的用密码上下文；

验证所述用密码上下文；

在所述实体的上下文中制定提出的数据交易；

16.根据权利要求15所述的***，其中所述执行者为单个人或一组人。

17.根据权利要求15所述的***，其中所述数据交易表示金融交易。

18.根据权利要求15所述的***，其中所述用密码方式签名的数据包包括基于时间的期限。

19.根据权利要求18所述的***，其中使用所述用密码方式签名的数据包的共享秘密的非对称加密来链下链接认证和授权进程。

20.根据权利要求8所述的***，其中所述认证包括导致发布用密码方式签名的数据包的轻量级目录访问协议(LDAP)认证、活动目录认证、生物特征认证和口令认证中的至少一者。

21.根据权利要求15所述的***，其中认证所述执行者包括所述执行者使得在所述交易的所述用密码上下文中用从与所述执行者相关联的用密码钱包导出的签名来对所述提出的交易进行签名。

22.根据权利要求15所述的***，其中对所述数据交易进行签名包括分割密钥加密、用于加密私钥的片段、与外部进程相关联的多签名方法、与外部进程相关联的多方计算方法和/或通过被处理以确定授权的链上钱包交易进行签名中的至少一者。

23.根据权利要求15所述的***，其中所述授权基于实体组织结构和角色。

24.根据权利要求23所述的***，其中所述实体组织结构包括多个级别，并且级别标识符用于通过实体结构提供权限。

25.根据权利要求15所述的***，其中所述授权基于组投票。

26.根据权利要求15所述的***，其中所述授权基于工作流自动化。

27.根据权利要求15所述的***，其中至少一个钱包由智能合约封装，从而表示至少一个组的组权限，并且其中所述至少一个钱包用于代表所述至少一个组执行交易。

28.根据权利要求14所述的***，其中至少一个工作流被表示为存储在所述去中心化账本上并且经由去中心化工作流引擎执行的映射，所述去中心化工作流引擎包括在所述去中心化引擎上执行的智能合约，所述工作流包括工作项目、路由和任务，并且所述工作项目中的每个工作项目在所述去中心化账本上具有对应的不可替代的令牌，由此任务批准者能够在所述工作流内选择用于所述工作项目的路由。