私设
尽管在安全中早有告诫：
Don’t roll your own crypto.
但是有时终究有一种“天启”的感觉想要实现些什么，尽管必须声明：这一切都没有经过审查，一切责任自负。
签名私设
那么就来幻想一下我设想的一种工具链接方式吧：
基本的元素是minisign，最简化的签名方案，实际上就是最简化的安全的实行的数字签名即可；
然后是密钥分发和身份认证问题：
- 按我设想，结合Keyoxide来实现这一点，这是延续非中心化的身份认证的可能。 我知道延续当前更通行的PGP的形式也许更现实，但是ariadne-identity的概念我认为非常值得单独设计，这是一种简洁的可能，而这允许我们完全简单地全部实现整个设计而不依赖复杂的PGP绑定。
方案即在apse的ProfileJwsPayload中允许携带自定义的字段（这方面还需要改写aspe的server和client来保证可传递），而我们指定的就是mini_sign_pub_key的字段，完全按照pub文件的格式存储（出于简单起见）。
从而允许一个二级的签名公钥分发。
为什么不直接使用签名ariadne-identity-profile的密钥呢？这就是考虑到密钥轮换了，即身份与具体单个签名密钥分离，实际上参考Signal的设计，甚至可以考虑一次性密钥用于比如前向保密的密钥交换意图，但这不是Keyoxide系统考虑的问题了。
我们只涉及一种最简单的思路，即提供最简单的供应链和包管理的签名可能，且不需要集成于PGP或SSH等工具，最重要的是方便快速轮换，弃用密钥，尽管这比不了现代的供应链签名体系：比如sigstore。 然而手动轮换是不可能做到不断更换却不影响前溯的签名有效性的：我们没有一个保存一切签名记录的日志，也不考虑设置一个：这引入了额外的参与者。
然后是泄露考虑，只要还掌握这多数平台的控制权，一旦泄露后就可以删除各平台的ariadne-identity认证，从而使此身份失效并且重新建立。为了给签名提供时效性，验证方可以对分发的mini_sign_pub_key定期验证。但这也意味着，任何时刻只有一个pubkey的签名得到承认，之前轮换掉的签名将废弃，毕竟我们不管理minisign的私钥安全性，只能假定轮换即泄露。
作为分离的两个设计，ariadne-identity和 minisign终究是分离的，这也是设计的一种组合式的思路，而非集成。代价就是不可能集成密钥管理，但可以在客户端或者说使用者侧实现整合，比如用脚本轮换 minisign私钥并自动将之前的公钥及其有效期发出（没有规定方案）。
为这一思路考虑，利用了我已经构建的ariadne-identity的服务端并且编写了 minisign的个人实现（仅作为参考），并在个人的客户端中集成。
现状：
当然一切都还远远没有实现，这仍然是手动的系统，通过一些包装或许会作为我个人的签名分发体系。