§ 0一句话与边界
让一个心理人的「我是谁、我做过什么」能在不同机构、不同工具之间被验证，而不必把人和数据锁进任何一家平台。
本协议只搬运「职业身份与经历」，不搬运「来访者」。明确不做：案源分配、咨询师排名、竞价、流量售卖；支付、结算、佣金、抽成；个案记录、案例原文、诊断细节的存储与交换；来访者身份、联系方式、对话内容的任何字段；咨询质量评价、疗效评分、「好评率」；中心化账号体系（不要求任何人向心也注册）；区块链、代币、积分或任何可交易资产。
§ 1五条不变量
任何后续修改如果破坏其中一条，就不是 v0 的演进，是另一个协议。
| 编号 | 不变量 | 含义 |
|---|---|---|
| I1 | 可离线验证 | 验证一张凭证，不需要访问心也的任何服务器，不需要联网。只需要：凭证本身 + 签发者公钥 + 一份吊销列表快照。 |
| I2 | 吊销可近似，但不可假装 | 离线时无法得知最新吊销状态，结论只能是 UNKNOWN，不允许输出 VALID。把「没查到吊销」当成「有效」是最常见的伪安全。 |
| I3 | 最小披露 | 一条声明一张凭证。要证明「我有 120 小时督导」，就只出示这一张，不出示资质、出生年份、隶属机构。 |
| I4 | 不依附 | 签发与验证必须能被任何一方独立实现。心也消失、停止服务、改主意，已签发的凭证仍然可验。 |
| I5 | 人是主体，机构只是签发者 | 凭证属于个人，可随人迁移到任何机构。机构只能吊销自己签发的那部分，不能吊销别人给的，也不能扣住一个人的全部历史。 |
§ 2两种主体，两种根
个人：did:hy:pk:<base32(sha256(公钥))>。由个人自持的密钥派生；换机构、换工具、换手机号，标识不变。私钥在个人手里，心也不持有、不代管、不能代替本人签署。丢失私钥等于丢失该标识的控制权——恢复靠社交恢复（3 个已知主体联署声明新公钥接管旧标识，v0 不强制实现）。
机构：did:hy:org:<域名>。以机构自己的域名作为身份根；有域名、有备案，就能有身份，不需要向任何人申请。域名转让时原 did 作废，新主体需重新签发凭证，不提供域名继承。
为什么不用统一 ID：统一 ID 意味着发号的人拥有否决权，可以让你「不存在」。本协议的身份是自证的——验证方验的是密钥与域名，不是一张来自中心的名单。
§ 3凭证与八类声明
一条可验证的声明就是一张凭证。v0 的最小结构包含：版本、类型、凭证 id、签发者、主体、claim（kind / value / unit / period / scope）、签发时间、有效期、证据引用、吊销列表地址与索引，以及签名段。
数字必须带口径。没有 period 与 scope 的时长是假数据，验证方应判 INVALID。
不合并：不同签发者的督导时长不自动相加，加总属于应用层，不属于协议层。
不推断：有 supervision.provided 不意味着有资质；有资质不意味着在执业。每条声明独立成立。
一条声明一张凭证：要出示 120 小时督导，就只出示那张 supervision.received，其余留在本人手里。v0 不做零知识证明，拆开签已经满足最小披露。
| kind | 含义 | unit | 备注 |
|---|---|---|---|
| identity.practitioner | 本人在执业 | — | 最低门槛，任何心理人都可自签或机构签 |
| qualification.registration | 注册资质 | — | scope 写清资质名称与发证机关 |
| training.hours | 培训学时 | hour | 必须带 period 与课程 scope |
| supervision.received | 接受督导时长 | hour | scope 区分个体 / 团体 |
| supervision.provided | 提供督导时长 | hour | 同上 |
| practice.hours | 个案时数 | hour | 不带任何来访者信息 |
| affiliation.org | 机构隶属 | — | expires_at 必填，隶属有时效 |
| attestation.peer | 同行评审 / 带教 | — | scope 写清评审形式 |
§ 4签名与规范化
- 规范化：RFC 8785 (JCS)。签名前把除 sig 外的全部字段按 JCS 序列化。
- 算法：Ed25519，v0 只此一种，不接受算法协商——协商是攻击面。
- 编码：base64url，无填充。覆盖范围：sig 之外的所有字段，包括 revocation。
- kid 指向签发者公钥文档里的具体密钥；时间一律 UTC，Z 结尾，秒级，不接受本地时区与相对时间。
- 验证方必须先验签名，再读内容。顺序反了，等于信任未验证的输入。
§ 5密钥发现
托管商默认不给跨域响应头，等于默认把「可离线验证」打折。这不是部署细节，是协议义务——一致性测试 T11 就是它的测试向量。
| 项目 | v0 规定 |
|---|---|
| 机构公钥 | https://<domain>/.well-known/heartye-keys.json，包含 issuer、keys（kid / alg / public_key / not_before / not_after） |
| 草案期锚定 | 首次发布尚无上一把钥匙，以 fingerprint 字段对外公布（base32(sha256(公钥原始字节))），由验证方带外比对；DNS TXT 锚定是 1.0 的硬要求 |
| 跨域读取 | 公钥文档与吊销列表必须允许跨域读取；2026-10-27 实测：网关型静态托管默认不返回 Access-Control-Allow-Origin，需在自定义域名路由层注入 |
| 个人公钥 | 随凭证出示（subject 即公钥哈希），不需要另行发布 |
| 离线缓存 | 验证方缓存公钥文档、吊销列表与 fetched_at；缓存过期不改变签名有效性，但会改变吊销结论 |
§ 6吊销
签发者发布 https://<domain>/.well-known/heartye-revoked.json，包含版本、签发者、发布时间、ttl（秒）、条目（index / cred_id / reason / revoked_at），以及签名。
| reason | 含义 |
|---|---|
| issuer_error | 签发错误 |
| fraud | 伪造材料 |
| superseded | 被新凭证替代 |
| withdrawn | 本人要求撤回 |
- 列表本身必须签名。验不过签名，或根本没签名，验证方一律按 UNKNOWN 处理——否则谁都能伪造一份「什么也没吊销」的列表，吊销机制等于不存在。
- ttl 是签发者的承诺：超过 ttl 未刷新，验证方必须降级为 UNKNOWN。
- 吊销列表按 index 增量拉取，允许只同步新增部分。
- 没有「永久有效」的凭证——expires_at 为 null 的凭证仍受吊销约束。
§ 7验证结果：四种结论，一种拒绝
铁律：UNKNOWN 不得显示为绿色，不得显示为「有效」，不得用「✓」图标。界面上必须写出「吊销状态同步于 YYYY-MM-DD HH:mm」。写不出时间，就是 UNKNOWN。
这条不是为了严谨好看。一旦允许「查不到就当有效」，整套互认就变成了盖章生意。
| 结论 | 条件 | 能否对第三方声称 |
|---|---|---|
| VALID | 签名正确 + 未过期 + 吊销列表在 ttl 内且未命中 | 可以 |
| EXPIRED | 签名正确 + 已过期 | 不可以（可展示历史） |
| REVOKED | 吊销列表命中 | 不可以 |
| UNKNOWN | 签名正确，但吊销状态无法确认（离线 / 缓存超 ttl / 列表拉取失败） | 不可以 |
| INVALID | 签名错、字段缺、口径不全、issuer 与密钥不匹配 | 不可以 |
§ 8最小数据格式
两套台账：hy.appointment（预约）与 hy.supervision（督导）。只规定字段与口径，不规定软件。
| hy.appointment 字段 | 类型 | 必填 | 说明 |
|---|---|---|---|
| id | string | ✓ | 稳定标识，不随导出变化 |
| date | YYYY-MM-DD | ✓ | 本地日期 |
| start / end | HH:mm | ✓ | 本地时间 |
| tz | IANA | ✓ | 如 Asia/Shanghai |
| mode | online | offline | ✓ | 线上 / 线下 |
| place | string | 仅线下，写城市 / 区，不写门牌 | |
| status | requested | booked | completed | cancelled | ✓ | 预约状态 |
| note | string | 不得含来访者身份与对话内容 |
§ 8.1督导台账与硬规则
| hy.supervision 字段 | 类型 | 必填 | 说明 |
|---|---|---|---|
| date | YYYY-MM-DD | ✓ | 发生日期 |
| hours | number | ✓ | 0.25 粒度 |
| form | individual | group | peer | ✓ | 个体 / 团体 / 同侪 |
| role | received | provided | ✓ | 接受 / 提供 |
| supervisee_ref | string | 代号，非真名 | |
| case_ref | string | 代号，非编号，非姓名 | |
| topic | string | 主题词，不含个案细节 | |
| supervisor | did:hy:* | 有则可互认，无则仅本人留存 |
- 导出格式：CSV (UTF-8 with BOM) / .xlsx / JSON，三种至少实现一种完整的。
- 时间一律带时区；跨时区不换算，保留原始 tz。
- 不得包含：来访者姓名、手机号、微信、住址、身份证、诊断编码、对话原文。
- 导出文件由客户端本地生成，不经过任何服务器中转。
- 台账可整份带走。迁移不需要申请、不需要审批、不需要对方同意。
§ 9治理与版本
版本：<major>.<minor>。0.x 草案期允许破坏性修改；1.0 起 minor 只增不改，破坏性变更必须 major。验证方声明支持的版本区间，不支持的凭证判 INVALID 并注明原因。
变更提案（HYP）：任何机构、任何个人都可以提，必须包含动机、兼容性影响、参考实现、迁移方式。1.0 之后，任何两个独立实现的机构同意，提案即可进入候选——心也不是唯一的批准者。
谁能签发：v0 不规定谁有权签发资质，只规定两件事——签发者身份可验证；签发者必须公开自己的签署标准（签了什么、依据什么、有效期多久）。心也不做发证垄断，也不做白名单——白名单一旦存在，就变成了「只有被承认的人才算人」。
§ 10一致性测试（T1–T11）
| 编号 | 输入 | 期望 |
|---|---|---|
| T1 | 合法凭证 + 新鲜公钥 + 新鲜吊销列表 | VALID |
| T2 | 同上，但改动 claim.value 一位 | INVALID |
| T3 | 合法但已过期 | EXPIRED |
| T4 | 在吊销列表中 | REVOKED |
| T5 | 吊销列表超过 ttl | UNKNOWN |
| T6 | 吊销列表拉取失败（离线） | UNKNOWN |
| T7 | 缺 period 或 scope 的时长声明 | INVALID |
| T8 | issuer 域名与公钥文档域名不一致 | INVALID |
| T9 | 台账含疑似手机号字段 | 导出应被拒绝并提示 |
| T10 | 吊销列表未签名 / 签名为伪造 | UNKNOWN |
| T11 | 在别的域名页面里跨域 fetch 公钥文档 / 吊销列表 | 应能读到（响应含 Access-Control-Allow-Origin）；读不到即不满足 §5 |
§ 11实现状态（诚实律）
诚实交代：以上「已上线」只说明工具可用，不说明互认已经在机构之间发生。真正的闭环需要第二家机构用自己的实现签发、验证，并跑通 T1–T11；在那之前，我们不宣称闭环完成。
| 组件 | 状态 |
|---|---|
| lib/hip.js（JCS / Ed25519 / 四态判定） | ✅ 已实现，T1–T10 自测通过 |
| T11 跨域可读 | ✅ 2026-10-27 在 www.heartye.cn 自定义域实测通过 |
| 公开验签页 /verify/credential/ | ✅ 已上线：不登录、浏览器本地验签 |
| 成员控制台「互认身份」 | ✅ 已上线：本机生成密钥、DID、凭证夹、导出与备份 |
| 机构签发台 /issue/credential/ | ✅ 已上线：浏览器内生成机构密钥、签发凭证、重签吊销列表；私钥不上传 |
| DNS TXT 锚定 | ⏳ 1.0 才要求；v0 用 fingerprint 带外比对 |
| 外部机构独立实现 | ⏳ 尚无第二家实现者——闭环未完成，不以「已闭环」对外表述 |
§ 12未决问题
不装完整。这些还没想清楚，写出来比假装想清楚了更有用。
- 私钥丢了怎么办——社交恢复的具体阈值与争议处理（3 人联署够不够？联署人串通怎么办）。
- 团体督导的时长怎么算——2 小时团体、8 个人，每人算 2 小时还是 0.25 小时。行业没有统一口径，协议不替行业决定，但必须要求签发者写明。
- 跨机构隶属冲突——一个人同时属于两家机构，且两家都签了 affiliation.org。当前允许并存，是否需要显式声明主属，待议。
- 机构域名失效——域名到期 / 被查封，历史凭证是否随之失效。当前结论：签名仍有效，但密钥文档不可达，判 UNKNOWN。这可能过于严格。
- 中文姓名与重名——凭证里是否放姓名。倾向：不放，放代号；姓名属于应用层。
- 监管对接——若未来主管部门要求报送，用哪一层实现、是否破坏最小披露。倾向：单列报送适配层，不进核心协议。
§ 13变更记录
| 版本 | 日期 | 变更 |
|---|---|---|
| 0.1 | 2026-10-27 | 首版草案。确立五条不变量、两种主体、八类声明、四种验证结论、两套台账格式；补入 2026-10-27 跨域实测（T11）。 |
| 0.1.1 | 2026-10-27 | 增补 §11 实现状态：成员凭证夹与机构签发台上线；仍不宣称闭环完成。 |
- RFC 8785 · JSON Canonicalization Scheme (JCS)。
- RFC 8032 · EdDSA（Ed25519）。
- W3C DID Core 1.0（did 语法参考，不采用其区块链绑定）。
- 协议原件：仓库 docs/心也互认协议-v0.md（变更逐条记录）。
合规声明：本页为公开技术规范草案，不构成任何资质认定、医疗建议或执业许可。协议只搬运职业身份与经历，不搬运来访者数据；协议文本未冻结，修订以新版本公示。
引用本文CITE
引用本文CITE THIS DOCUMENT
心也. (2026). 心也互认协议 v0 (HY-OPEN-009, HIP-0.1). 心也图书馆. https://lib.heartye.cn/doc/heartye-hip-v0/
@techreport{heartye:HY-OPEN-009,
title = {心也互认协议 v0},
author = {心也},
institution = {心也图书馆},
type = {公开文书},
number = {HY-OPEN-009},
year = {2026},
month = {10},
note = {草案 · 公开征求意见中},
url = {https://lib.heartye.cn/doc/heartye-hip-v0/},
language = {zh-CN}
}格式为纯文本，可直接粘贴。引用时请保留文号与版本号——它们是这份文书唯一的身份。