私设
尽管在安全中早有告诫：
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。
然而手动轮换是不可能做到不断更换却不影响前溯的签名有效性的：我们没有一个保存一切签名记录的日志，也不考虑设置一个：这引入了额外的参与者。
- 一个新的考虑:Rekor，可用于透明度日志，可考虑的类型包括
ssh及minisgn，思路未知。
然后是泄露考虑，只要还掌握这多数平台的控制权，一旦泄露后就可以删除各平台的ariadne-identity认证，从而使此身份失效并且重新建立。为了给签名提供时效性，验证方可以对分发的mini_sign_pub_key定期验证。但这也意味着，任何时刻只有一个pubkey的签名得到承认，之前轮换掉的签名将废弃，毕竟我们不管理minisign的私钥安全性，只能假定轮换即泄露。 如果有对于minisign的透明度日志，那么可以添加失效时间的记录，对日志上有效时间的日志签名可以验证当时未失效。
作为分离的两个设计，ariadne-identity和 minisign 终究是分离的，这也是设计的一种组合式的思路，而非集成。代价就是不可能集成密钥管理，但可以在客户端或者说使用者侧实现整合，比如用脚本轮换 minisign私钥并自动将之前的公钥及其有效期发出~~（没有规定方案）~~ 现在可以考虑集成Rekor日志。
为这一思路考虑，利用了我已经构建的ariadne-identity的服务端并且编写了minisign的个人实现（仅作为参考），并在个人的客户端中集成。
现状：
当然一切都还远远没有实现，这仍然是手动的系统，通过一些包装或许会作为我个人的签名分发体系。
更新了我的ariadne-identity库，现在可以支持验证我的aspe中的全部claim了，包括：
- Github
- Forgejo
- Misskey
- Dns
- OpenPGP
- Matrix
- Telegram
其中Matrix的验证需要在keyoxide房间的账户的accessToken。 添加了 (关于openpgp，官方keyoxide的js库中验证有错误，不支持在注解中使用hash的proof，因此在keyoxide中无法验证我的aspe中的openpgp的claim)。
aspe-client-go中现在支持使用ed2519的ssh密钥文件作为密钥。
支持使用代理(ssh-agent)的方法获取密钥用于签名asp jwt（密钥管理安全），支持类型为ssh-ed25519
支持使用piv card签名asp jwt，支持p256及ed25519
aspe-server-go添加了age_pub_key，现在扩展字段有mini_sign_pub_key和age_pub_key两个，涵盖了签名和加密。
在aspe-client-go中，也可以get获取并验证aspe，并且获取扩展字段。
TODO:
- 结构化打印获取
aspe profile，稳定输出(json?)，从而便于脚本集成。
keyoxide-rs-web: 手动修改doip-rs库以在简化的实现上部署验证实例，思路是cloudflare worker+wasm+htmx。