可独立完成验证
intramedial-verifyJavaScript 与 TypeScript零依赖，只使用 WebCrypto。它可以在不发起任何网络调用的情况下，根据您所传入的那个密钥集来验证一份回执，也可以先获取已经发布的密钥，然后再进行验证。如果某个运行时并不支持 Ed25519，它就会返回 unsupported_runtime，而不会对这份回执作出任何判定。
- 许可证
验证其实只是一项操作：使用一把公钥，去检查针对回执的规范化形式所生成的那一个 Ed25519 签名。两个彼此完全独立的实现，在拿到同一份回执和同一把密钥的时候，会得出完全相同的结果。而这项操作所需要的一切内容，都已经全部公开发布了出来。
ledger-bundles-keys.jsonRFC 8785 · RFC 8032开放的验证，并不能让每一份回执都因此成为真实的。一个有效的签名可以证明是谁对哪些字节进行了签名，以及在此之后没有任何内容发生过变化；但是对于那些报告类的事实，它并不能证明该事实确实曾经发生过。 一份回执所不能够证明的内容 →
每一行都说明了目前实际存在的内容。对于那些尚未发布的内容，我们会如实地加以说明，并指出目前就能使用的替代方式。对于那些尚未发布的条目，我们并不承诺任何具体的日期。
| 条目 | 许可证 | 位置 | 状态 |
|---|---|---|---|
JavaScript 与 TypeScript 验证程序@intramedial/verifier | MIT | npm | 目前尚未正式发布 |
这两个程序库所验证的是同样的两类内容：来自任何一个工具的回执，以及附带 Merkle 包含证明的签名制品包。两者会返回完全相同的失败原因，并且都固定使用同一个经过签名的测试向量，因此一旦在规范化或者编码方面出现了任何偏差，就会导致其中任何一个测试套件运行失败。
intramedial-verifyJavaScript 与 TypeScript零依赖，只使用 WebCrypto。它可以在不发起任何网络调用的情况下，根据您所传入的那个密钥集来验证一份回执，也可以先获取已经发布的密钥，然后再进行验证。如果某个运行时并不支持 Ed25519，它就会返回 unsupported_runtime，而不会对这份回执作出任何判定。
两个验证程序所实现的那种线上传输格式，已经被完整地写成了一份规范性的规格说明，版本为 v1，并且采用 MIT 许可证。它之所以公开，是为了让验证能够在完全无需信任我们自己的验证程序的情况下进行。它的内容目前已经发布在文档之中；而这份规范本身，则计划在之后迁移到属于它自己的、独立的公开仓库之中。
ledger-bundlesmodule docsno licence stated公开的文档资料七个经过签名的成员，以及“消息体的类型必须与信封的类型保持相同”这一条规则。
用于为回执进行签名的那些 Ed25519 公钥，无需任何身份验证即可公开获取，允许跨源请求，并且可以被缓存一个小时。旧的密钥会一直保持在发布状态，因此旧的回执可以一直持续通过验证。而私钥则被保管在 AWS KMS 之中，从来都不会被导出到其他任何地方。
https://intramedial.com/.well-known/ledger-bundles-keys.json网站上的那个 JWK 密钥集。它会重定向到 API 路由；请让您的客户端跟随重定向。https://ledger-bundles.api.intramedial.com/.well-known/ledger-bundles-keys.json同一个密钥集，位于 API 主机上。/api/v1/ledger-bundles/anchors一份由某把固定的一次性密钥进行签名的已知答案回执，被完整地印在了文档之中，并且被固定在两个验证程序各自的测试套件里。在您使用真实的回执来信任您自己的实现之前，请务必先用这份回执对它进行一次测试。
{
"ok": true,
"kind": "notarian-bundle"
}一个小型的组合式 Action，它会使用 git 来读取已经检出的那个提交，在运行器上计算提交信息的哈希值，然后申请一份经过签名的 commit.attest 回执。提交信息的文本内容永远都不会离开这个运行器。
github.enforcehosted module公开的文档资料它的源代码已经在 MIT 许可证之下全部完成，但是目前还没有正式发布。在它正式发布之前，任何引用了它的工作流都会在设置步骤之中失败，因此目前请您改用文档中所提供的那个 curl 步骤。这个步骤所完成的是完全相同的工作。
各类智能体和编程助手，都会在一些可以预测的地址上查找描述文件。这些文件全部都是公开的，与 MCP 服务器一样由同一套操作定义生成，并且不需要任何账户就能获取。所有内容均以线上服务器的实际应答为准；如果某个文件与文档之间存在任何差异，则以文档中的说明为准。
/.well-known/mcp/server.jsonMCP 服务器的名称、那个可以流式传输的 HTTP 端点，以及它所接受的各种登录方式。
/.well-known/mcp/tools.json全部工具及其输入模式和输出模式，与 tools/list 所返回的内容完全一致。
/.well-known/agent-card.json网关智能体的身份、它所支持的传输方式，以及每一项操作所对应的一项能力，专供 A2A 客户端使用。
仓库中的源码比本页上面所列的更多。其中没有任何内容已作为包发布或有文档说明，因此没有安装步骤。我们列出它，是为了日后不会出现意外。
mcp-server stdio目前尚未正式发布这是回执格式的第二个、彼此独立的 Python 实现，它与签发方所使用的代码之间，没有任何共享的部分。
adapters/packages/mcp-server/目前还没有一个可以用来提交议题或者拉取请求的公开仓库；每一个软件包都计划在之后迁移到属于它自己的公开仓库之中。在那之前，您可以使用以下这些目前已经存在的沟通渠道与我们联系。
出现在某个验证程序、密钥集或格式之中。请以私密方式发送电子邮件给我们，在我们有时间修复之前，请不要公开相关细节。
将一份回执粘贴到验证程序之中即可。整个检查都会在您自己的浏览器中运行；唯一的一次网络请求，就是下载那些公开的密钥。
Python 验证程序@intramedial/adapter-framework | MIT | PyPI | 目前尚未正式发布 |
回执与制品的格式规范，版本 v1ledger-bundles | 未作说明 | 目前在文档中；计划设立自己的独立仓库 | 公开的文档资料 |
公开发布的签名密钥ledger-bundles-keys.json | 公开数据 | intramedial.com 和 api.intramedial.com | 目前尚未正式发布 |
一个已知答案的测试向量no public vector | 未作说明 | 文档，以及两个验证程序各自的测试套件 | 目前尚未正式发布 |
commit.attest GitHub Actiongithub.enforce | 未作说明 | 计划发布到 GitHub | 公开的文档资料 |
MCP 与各类服务发现清单文件server.json · tools.json | 未作说明 | intramedial.com/.well-known | 公开的文档资料 |
如果您安装了某个使用以上这些名称之一的软件，而它并不是来自一个您所信任的发布者，那么请您不要使用它。
cd verifier npm install && npm run build npx intramedial-verify bundle.json --keys keys.json
verifyNotarianBundleWithKeys()verifyTopsSealWithKeys()verifyAuditChainExport()verifyArtifactWithKeys()在获取密钥的时候，如果网络出现了故障，就会直接抛出异常，因此网络错误永远都不会被当作对这份回执的判定结果报告出来。
adapter-frameworkPython同样的这些函数，采用蛇形命名法，并且只使用标准库来编写，其中还包括一个小巧且完全自成一体的 Ed25519 验证程序，因此整个信任面只需要几个您可以亲自从头到尾阅读的文件，就能够完全容纳下来。
adapters/packages/adapter-framework用 npm run build 构建
cd adapters npm install npm run build
okkindreasondetails严格遵循 RFC 8785：键的排列顺序、数字形式、转义方式，以及必须予以拒绝的内容。
针对规范化字节的 Ed25519 签名、不带填充的 base64url 编码，以及密钥 ID 的推导方式。
每一个工具的消息体所包含的那些成员，其中也包括监视摘要。
与回执同级、但类型开放的一种格式，专门用于各类合规方面的制品。
带有域前缀的叶节点哈希与内部节点哈希，以及一个包含证明是如何进行折叠计算的。
密钥集在哪里提供、它所带有的响应头，以及为什么密钥轮换是增量式的。
四个具体的步骤，以及所有可以由机器读取的那些失败原因。
增量式的变更会让 v1 验证程序继续保持正常工作；v1 文档将永远按照 v1 的规则来进行验证。
移除 signature 字段，将其余的部分全部序列化为规范化的形式，然后针对这些 UTF-8 字节来验证那个 Ed25519 签名。下方所展示的内容，正是那个测试向量所对应的规范化字符串。
{
"bundleId": "lb_20261101_wnam_01",
"workspaceId": "ws_acme",
"jurisdiction": "wnam",
"scope": "default",
"recordCount": 4820,
"merkleRoot": "8f1c2a9e...",
"signingKeyId": "lb-wnam-2026-10",
"ed25519Signature": "base64-signature",
"otsProof": null
}/api/v1/ledger-bundles/snapshot当前处于有效状态的签名密钥的元数据。{
"kty": "OKP",
"crv": "Ed25519",
"x": "…",
"kid": "…",
"alg": "EdDSA",
"use": "sig",
"jurisdiction": "wnam"
}curl -sSL https://ledger-bundles.api.intramedial.com/.well-known/ledger-bundles-keys.json -o keys.json jq -r '.keys[].kid' keys.json
为获得最强的核查，请获取一次密钥，把它的 kid 和 x 存入您自己的记录，并对照该副本验证。上述每个位置都由我们提供服务，因此相互比较只能防范某一条路由出问题，而不能防范 Intramedial 本身被入侵。 签名密钥以及密钥的轮换 →
| 输入 | 判定 |
|---|---|
| 完全按照发布原样的回执以及密钥集 | ok: true |
| 同一份回执，但是其中的 byteLength 被改成了 5 | ok: false |
| 同一份回执，但是使用了一个不同的密钥 ID | ok: false |
| 一个只包含版本号字段的对象 | ok: false |
该向量的消息体只是用于演示的测试材料。它的密钥是一把测试密钥，不会为任何真实内容签名。
verifier/test · runtime/ledger-bundles/test{
"repo": "acme/payments",
"actorDid": "did:web:acme.example:agent:billing",
"sha": "9fceb02d0ae598e95dc970b74767f19372d61af8",
"action": "write"
}reposhaaction该 Action 只会发送一个 Authorization 请求头，因此它只能适用于工作区的密钥，而并不适用于个人访问令牌（PAT）。
/openapi.json以 OpenAPI 文档形式描述的 REST 接口，可用于生成带类型的客户端。
/llms.txt一份关于本网站以及每一个文档页面的纯文本地图，专门为各类语言模型而编写。
/AGENTS.md一份 Markdown 文档，逐一描述了每一项操作，并且都附有示例。
curl -s https://intramedial.com/.well-known/mcp/server.json | jq .endpoints curl -s https://intramedial.com/.well-known/mcp/tools.json | jq '.tools[].name'
这些文件没有声明任何许可证。它们描述的是一项托管服务，也就是位于 mcp.intramedial.com 的 MCP 服务器，而不是一个需要您安装的软件包。
contracts 包目前尚未正式发布一个适用范围更加广泛的离线验证程序，专门用于平台上其他各种类型的签名证据，例如各类制品包，以及采用哈希链方式的导出文件。
contracts/各个智能体框架的适配器目前尚未正式发布一个基础软件包，以及针对每一个智能体框架各一个的专用软件包，用来将某个框架的一次运行过程转换为相应的证明请求。这些框架都属于它们各自的作者；只有这些适配器才是我们自己的。
adapters/packages/有了格式规范和测试向量，就足以编写出一个验证程序。请告诉我们您的实现，我们可以和您一起使用测试向量对它进行检查。
标准格式的安全联系信息文件，已经发布在 /.well-known/security.txt 这个地址上。
目前尚未正式发布拉取请求：已经列入计划之中。当各个公开仓库正式建立之后，本页会附上指向它们的链接，并且说明各项贡献将会如何获得授权。