上图是用户发送请求的示意图。中间的浅灰色区域显示了核心请求，包括目标容器 ID，函数名称，参数，以及调用者的身份或主体。而深灰色区域显示的则是包含认证信息、签名和公钥的封套。如图左侧所示，调用者的主体是通过散列法从公钥中得出的。这种技术在区块链领域被广泛使用，例如比特币或以太坊地址就是如此。此外，图中右侧部分显示了作为数字签名方案中的消息的请求内容是如何通过签名与公钥绑定的。当互联网计算机收到这样的请求时，它既要检查签名在指定的公钥下是否有效，也要检查公钥和调用者主体之间的关系。

为了确保信息确实是由信息中指定的调用者发送的，容器不必理会这些技术细节。如果一切都检查完毕，互联网计算机会评估容器上的指定功能，但如果其中一项检查失败，请求就会被放弃。

以下是关于我们使用的身份格式的一些细节。我们从DER格式的公钥开始，用SHA-224对其进行散列，从而得到一个28字节的字符串。我们会添加一个字节，用于区分来自公钥的身份主体和我们在互联网计算机中其他地方使用的身份主体，例如容器。这29个字节是以用户委托书的内部二进制表示的。当把一个委托人转换为其文本表示时，我们首先要预加一个CRC-32错误检测码。然后，使用Base32编码产生的字符串，最后建立每组5个字符的组，并用破折号隔开。我们选择这种格式是为了支持在有适当错误检测的情况下，可以轻松复制粘贴，同时仍然允许ASCII表示法中的字符少于64个，以便与互联网协议（如DNS）兼容。

到目前为止，我们所看到的方案在结构上还是有点不灵活的。它们将用户的身份主体与单一的加密密钥进行绑定，但这种限制会使用户很难与来自不同设备的容器进行交互，因为需要在这些设备之间共享相同的加密密钥，既繁琐又不安全。相反，我们在不同的加密密钥之间使用了授权。如上图所示，你可以看到从黄色密钥到橙色密钥的委托。这种委托包括被委托的密钥，即橙色的钥匙；一些额外的参数，如过期或委托范围的限制；以及委托密钥的签名，即黄色密钥。

当用橙色密钥签署请求时，用户可以使用来自黄色密钥的委托，以便使用来自黄色密钥的身份。此外，委托的强大之处在于，可组合性。例如，橙色密钥可以将授权扩展到紫色密钥。这种结构与公钥基础设施和X.509非常类似，但这并不是巧合，我们向其进行了借鉴，并使用了更轻量级的数据结构。

委托的一个具体应用与网络认证有关。网络认证是万维网联盟（W3C）的一个最新标准，主要针对网络应用的双因素认证。该标准的动机是，如前所述，密码有严重的安全缺陷。它们经常在钓鱼邮件、恶意软件以及黑客攻击发生时，成为网络犯罪分子的猎物。 (责任编辑：admin)