Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
本规范描述了一种数据模型，可用于描述一个或多个已识别 实体，例如一个或多个人和/或组织，这些实体被认为会执行 特定操作，例如签发或验证可验证凭证。该 数据模型支持发布或直接共享此类 信息，提供一种可通过密码学验证并保护隐私的 机制，持有者可通过该机制证明其所使用 凭证对应的 实体在特定生态系统中受到认可。该 规范旨在与现有的“信任基础设施” 互操作，例如 X.509 证书颁发机构列表和 ETSI 信任服务列表，同时 支持使用可验证凭证构建新的去中心化生态系统。
本节描述本文档在发布时的 状态。当前 W3C 出版物列表以及本技术报告的最新修订版可在 W3C 标准与草案 索引中找到。
这是一个实验性规范，并且正在定期修订。它 不适合用于生产部署。
本文档由可验证凭证工作 组作为 首次公开工作草案发布，并使用 推荐 标准轨道。
作为 首次公开工作草案发布并不意味着 获得 W3C 及其成员的认可。
这是一份草案文档，可能会在任何时候被其他 文档更新、替换或废止。除作为正在进行中的工作外， 不宜引用本文档。
本文档由一个根据 W3C 专利 政策运行的组制作。 W3C 维护一份 任何专利披露的公开列表， 这些披露与该组的交付物相关；该页面还包含 披露专利的说明。实际 知晓某项专利并认为该专利包含 基本权利要求的个人， 必须按照 W3C 专利政策第 6 节披露该信息。
本文档受 2025 年 8 月 18 日 W3C 流程文档约束。
可验证凭证 生态系统依赖于验证者 判断某个特定签发者是否被认可执行某项 特定操作的能力，例如签发某种类型的可验证凭证。 从历史上看，这种判断通常是通过 带外流程、双边协议或专有注册表完成的，而这些机制 难以被自动发现、查询或推理。随着可验证凭证 越来越多地部署于教育、医疗保健、 金融服务和政府等领域，用于表达和传达对执行已知 操作的实体的认可的标准化、可互操作 机制已经变得至关重要。如果没有这样的机制，生态系统参与者 将被迫构建定制的“信任基础设施”，从而导致碎片化、 集成成本增加，并形成跨境和跨部门 互操作的障碍。
本规范通过定义一种数据模型来应对表达已识别实体
及其所执行操作的挑战，例如人员和组织，以及签发
和验证等操作；任何
实体都可以使用该模型以可验证凭证的形式发布或共享认可信息。
该模型并不强制使用单一中央注册表，而是允许
任何实体——政府机构、行业联盟、标准
组织，甚至单个个人——签发
VerifiableRecognitionCredential，声明其知晓一个或多个
被认可执行特定操作的实体。这种设计使
重叠、竞争且互补的“信任注册表”网络能够共存，
允许生态系统参与者选择其信任的实体，并在多个注册表之间
进行推理。本规范还支持与现有“信任基础设施”
互操作，例如 X.509 证书颁发机构列表
和 ETSI 信任服务列表，允许现有的已识别实体信息
被引用并组合进新的去中心化生态系统。
. 本文档的其余部分组织如下：
RecognizedEntity、RecognizedAction 和
VerifiableRecognitionCredential
类型及其属性和完整示例。
除标记为非规范性的章节外，本规范中的所有编写指南、图表、示例和注释均为非规范性内容。除此之外，本规范中的所有内容都是规范性的。
本文档中的关键词 MAY、MUST、OPTIONAL 和 SHOULD 应按照 BCP 14 [RFC2119] [RFC8174] 中的描述解释，且仅当它们以此处所示的全 大写形式出现时才如此解释。
一致性 文档是指数据模型的任何具体表达， 其符合本规范中的规范性陈述。具体来说， 本文档第 2. 数据模型节中的所有相关规范性陈述MUST被强制执行。
一致性处理器是指以软件和/或硬件 实现、用于生成或消费 一致性文档的任何算法。一致性处理器在消费 非一致性文档时MUST产生错误。
本文档还包含含有 JSON 和 JSON-LD 内容的示例。其中一些
示例包含对 JSON 无效的字符，例如内联
注释（//）以及使用省略号（...）表示
对示例价值不大的信息。实现者如希望将这些信息作为有效 JSON 或
JSON-LD 使用，应注意移除此类内容。
以下各节概述本规范用于可验证签发者和验证者列表的 数据模型。
本节描述的数据模型是基于本文所评估的 各种既有技术输入构建的，其中包括来自 EBSI Trusted Issuer Registry、ETSI TS 119 612、eSSIF-Lab TRAIN、Trust over IP Foundation Trust Registry Protocol，以及 Rebooting the Web of Trust 输入 文档的内容。本节描述的数据模型能够表达 这些其他规范中描述的许多概念，但并非全部。
本工作的统一数据模型可以表示为服务提供者列表， 这些服务提供者代表提供凭证签发或验证等服务的 实体或组织。该数据模型还包括 列表运营者描述的详细信息。
本节中的属性可以添加到
VerifiableRecognitionCredential 中发现的对象，如第
2.4 VerifiableRecognitionCredential节所定义。本节列出的每个通用
属性都是OPTIONAL的；任何值都不要求由
签发者提供。
| 属性 | 描述 |
|---|---|
| id | 以全局无歧义方式标识实体的 URL。此属性的值 在 可验证凭证数据模型 v2.0 规范的 第 4.4 节：标识符 中定义。 |
| type |
实体的类型。此属性的值在
可验证凭证数据模型
v2.0 规范的
第 4.5 节：类型
中定义。如果实体是签发者并签发可验证
凭证，则 type 属性MUST为
RecognizedIssuer。
|
| name | 实体的人类可读名称。此属性的值在 可验证凭证数据模型 v2.0 规范的 第 4.6 节：名称 与描述 中定义。 |
| legalName | 组织或实体的正式法定名称，即在法律 机构注册的名称，可能不同于常用名称。该值MUST为 字符串。 |
| image | 表示实体视觉标识符的 URL 或图像数据，例如 徽标、照片或图标。该值MUST为 URL。 |
| url | 指向与该实体相关联的主要网站或 Web 资源的 URL。该值MUST为 URL。 |
| sameAs | 一个或多个 URL，指向其他上下文或系统中的同一实体， 从而支持跨不同平台的交叉引用和验证。 每个值MUST为 URL。 |
| description | 提供实体详细信息的人类可读描述。此属性的值 在 可验证凭证数据模型 v2.0 规范的 第 4.6 节：名称 与描述 中定义。 |
| digestMultibase | 一个或多个密码学摘要，用于验证与该实体相关联的 资源完整性。此属性的值 在 可验证凭证数据模型 v2.0 规范的 第 5.3 节：相关资源的完整性 中定义。 |
已识别
实体是指被 VerifiableRecognitionCredential 的签发者
认可为执行特定操作的任何实体。
| 属性 | 描述 |
|---|---|
| id | 以全局无歧义方式标识实体的 URL。此属性的值 在 可验证凭证数据模型 v2.0 规范的 第 4.4 节：标识符 中定义。 |
| type |
type 属性MUST为
RecognizedEntity。此属性的值
在 可验证凭证数据模型
v2.0 规范的
第 4.5 节：类型
中定义。
|
| recognizedTo | 该已识别实体预期执行的 特定操作，如第 2.3 RecognizedAction节所定义。如果该 已识别实体预期执行多于 一个操作，则此属性可以出现多 次。 |
| recognizedIn |
一个对象，其中包含对已识别实体文档的引用，该文档
包含这个特定已识别实体以及
其已知执行的操作。该对象的 id 值MUST为
URL。该对象的
type 值MUST符合
可验证凭证数据模型
v2.0 规范中定义的
类型值空间，并且SHOULD为
EtsiTrustServiceList、
x509CertificateAuthorityList 或 VerifiableRecognitionCredential。
|
第 2.1 通用属性节中的属性可以在 上述属性之外包含。
具有 EtsiTrustServiceList type 属性的
recognizedIn MUST符合
Electronic
Signatures and Infrastructures (ESI); Trusted Lists 规范。具有
x509CertificateAuthorityList type 属性的列表MUST符合
Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
规范。
具有 VerifiableRecognitionCredential type 属性的列表MUST符合
本规范。
已识别 操作是指已识别实体预期执行的 操作。
| 属性 | 描述 |
|---|---|
| type |
type 属性MUST为
RecognizedAction。
|
| action |
一个字符串，
指定要执行的操作名称，例如
issue 或 verify。
|
| recognizedBy | 一个 URL，或包含第 2.1 通用属性节中的属性的对象，表示 执行认可任务的实体。 |
| outputValidation |
outputValidation
属性的值MUST为一个或多个数据
模式，这些模式为验证者提供足够
信息，以判断所提供的数据是否符合所提供的模式。每个验证器MUST
指定其 type（例如 JsonSchema）以及 id
属性，该属性MUST为标识模式文件的 URL。
具体的类型定义决定每个数据模式的精确
内容。如果存在多个模式，则有效性
按照每个关联 type
属性所概述的处理规则确定。
|
当一个可验证 认可凭证 被发布时，它MUST是一个符合 可验证凭证数据模型 v2.0中定义的 可验证凭证， 并表达后续章节中指定的数据模型。它描述了 封装已识别 实体的可验证凭证 格式。
已识别实体在可验证凭证中表达， 使持有者能够将其直接提供给 验证者。这种 机制有时称为“证书装订”，它通过 确保验证者无需联系 签发者来 获取认可凭证，从而提高 持有者的隐私。 不过，即使其真实性可以验证，验证者也可能 选择忽略由持有者提供的认可凭证，例如当其希望获得该认可凭证的更新 版本时。
| 属性 | 描述 |
|---|---|
| id |
包含一组已识别实体的可验证
凭证MAY
表达 id 属性，以便其他系统更容易检索它。
|
| type |
包含一组已识别实体的可验证
凭证MUST
表达一个包含
VerifiableRecognitionCredential
值的 type 属性。
|
| issuer | 可验证 凭证的签发者， 如可验证凭证数据模型规范 第 4.76 节：签发者中所定义。该对象MAY还包含第 2.1 通用属性节中列出的其他 属性。 |
| validFrom | 凭证生效的最早时间点。此属性 在可验证凭证数据模型规范的 第 4.6 节：有效期中定义。 |
| validUntil | 凭证有效的最晚时间点。此属性 在可验证凭证数据模型规范的 第 4.6 节：有效期中定义。 |
| credentialSubject |
一组一个或多个 RecognizedEntity 对象，如第
2.2 RecognizedEntity节所定义。
|
以下示例展示了可验证认可凭证如何在 多种用例中使用。下面第一个示例用于 发布某个特定国家中一组已知大学的信息。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": [
"VerifiableCredential",
"VerifiableRecognitionCredential"
],
"issuer": {
"id": "did:web:learning-commission.example",
"type": "RecognizedIssuer"
},
"validFrom": "2025-01-01T00:00:00Z",
"validUntil": "2030-01-01T00:00:00Z",
"credentialSubject": [{
"id": "did:web:university.example",
"type": "RecognizedEntity",
"name": "Example Tech",
"legalName": "Example Polytechnic University",
"image": "https://university.example/logo.png",
"url": "https://www.university.example/",
"description": "A university providing a great education in Utopia Valley.",
}, {
"id": "did:web:college.example",
"type": "RecognizedEntity",
"name": "Exemplar Community College",
"legalName": "Community College of Examples and ",
"image": "https://college.example/graphics/ecc.png",
"url": "https://college.example/",
"description": "The backbone of learning in the Utopia community.",
}],
"proof": {
"type": "DataIntegrityProof",
"created": "2026-04-10T20:08:22Z",
"verificationMethod": "did:web:accreditor.example#issuance-key-1",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"
}
}下一个示例用于发布某个特定类型的可验证凭证的一组已知签发者 信息。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": [
"VerifiableCredential",
"VerifiableRecognitionCredential"
],
"issuer": {
"id": "did:web:learning-commission.example",
"type": "RecognizedIssuer"
},
"validFrom": "2025-01-01T00:00:00Z",
"validUntil": "2030-01-01T00:00:00Z",
"credentialSubject": [{
"id": "did:web:university.example",
"type": "RecognizedEntity",
"name": "Example Tech",
"legalName": "Example Polytechnic University",
"image": "https://university.example/logo.png",
"url": "https://www.university.example/",
"description": "A university providing a great education in Utopia Valley.",
"recognizedTo": {
"type": "RecognizedAction",
"action": "issue",
"recognizedBy": "did:web:learning-commission.example",
"outputValidation": {
"id": "https://learning-commission.example/credentials/bachelors.json",
"type": "JsonSchema",
"digestMultibase": "uEiBZl963sknNAHgPyslVv6VztZpfWQoRvW1htfx-UwirFo",
}
}
}, {
"id": "did:web:college.example",
"type": "RecognizedEntity",
"name": "Exemplar Community College",
"legalName": "Community College of Examples and ",
"image": "https://college.example/graphics/ecc.png",
"url": "https://college.example/",
"description": "The backbone of learning in the Utopia community.",
"recognizedTo": {
"type": "RecognizedAction",
"action": "issue",
"recognizedBy": "did:web:learning-commission.example",
"outputValidation": {
"id": "https://learning-commission.example/credentials/associates.json",
"type": "JsonSchema",
"digestMultibase": "uEiWQoRvpfWW1htfsknNAHgPyslVv6VztZpfwirFoBZl963",
}
}
}],
"proof": {
"type": "DataIntegrityProof",
"created": "2026-04-10T20:08:22Z",
"verificationMethod": "did:web:accreditor.example#issuance-key-1",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"
}
}下面的最后一个示例用于发布关于某个实体的信息，该实体 发布符合欧盟 ETSI 信任服务列表的内容 [ETSI-TRUST-LISTS]。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": [
"VerifiableCredential",
"VerifiableRecognitionCredential"
],
"issuer": "did:web:ec.europa.example",
"validFrom": "2025-01-01T00:00:00Z",
"validUntil": "2030-01-01T00:00:00Z",
"credentialSubject": [{
"id": "did:web:ec.europa.example",
"type": "RecognizedEntity",
"name": "Utopian Commission",
"legalName": "The Utopian Commission",
"image": "https://ec.europa.example/logo.png",
"url": "https://ec.europa.example/",
"recognizedIn": {
"id": "https://ec.europa.example/tsl/lotl.xml",
"type": "EtsiTrustServiceList",
"name": "Utopian Commission List of the Lists"
}
}],
"proof": {
"type": "DataIntegrityProof",
"created": "2026-04-10T20:08:22Z",
"verificationMethod": "did:web:ec.europa.example#issuance-key-1",
"cryptosuite": "ecdsa-rdfc-2019",
"proofPurpose": "assertionMethod",
"proofValue": "z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"
}
}本节详细说明将本规范部署到生产环境时的一般隐私考量 以及具体隐私影响。
建议读者在阅读本节之前，先熟悉 可验证凭证规范的隐私考量一节 中提供的一般隐私建议。实现者应将该 规范中提供的一般警告应用于本规范所提供的每项具体 特性。
VerifiableRecognitionCredential 会公开列出具名组织和
人员及其标识符、法定名称、URL 和图像。跨多个列表聚合
这些信息会导致对已识别实体进行画像和监视。
本节应讨论发布丰富描述的实体信息所带来的风险，
尤其是针对个人的风险，并为签发者提供最小化披露的指导。
例如，发布给私有组的一份已识别
实体列表，如果任何组成员决定将信息发布到私有组之外，
该列表就可能脱离该组。
建议指出，选择性披露在这里并不能提供太多保护，因为
它要求参与者诚实。
由持有者提供认可凭证，比让验证者联系签发者以获取认可凭证， 更能保护隐私。
VerifiableRecognitionCredential 可能揭示私有或敏感生态系统的
成员结构，例如医疗保健凭证签发者或
金融服务提供商。发布或广泛共享此类凭证
可能暴露哪些实体参与该生态系统，这可能具有
商业敏感性，或造成被定向攻击的风险。本节应讨论
何时以及如何限制描述敏感生态系统的认可凭证的分发，
也可能建议限制认可凭证的分发并不可行，
因而为敏感生态系统创建此类凭证可能是一种反模式。
一般而言，如果你构建具有特定成员关系的
某些列表，它可能会对
个人产生负面影响（关联伤害）——无论是否有意。
实现者在处理本规范所描述的数据时，应注意 若干安全考量。忽视或不理解本节的影响 可能导致安全漏洞。
建议读者在阅读本节之前，先熟悉 可验证凭证规范的安全考量 一节中提供的一般 安全建议。
虽然本节试图突出一组广泛的安全 考量，但它并非完整列表。建议实现者在使用本规范所概述的技术 实现关键任务系统时，寻求 安全和密码学专业人士的建议。
当持有者
接收 VerifiableRecognitionCredential 并将其
与他人共享时，存在该凭证未经过适当审查的风险。
恶意或疏忽的行为者可能制作一个 VerifiableRecognitionCredential，
将欺诈性或已受损实体列为已识别签发者或
验证者，并在生态系统中以点对点方式传播它。接收者如果
未经独立验证就接受并依据此类凭证采取行动，
可能会在不知情的情况下接受来自不可信来源的可验证凭证，
从而使自己和他人暴露于欺诈、数据泄露或凭证
伪造风险之中。本规范的去中心化性质虽然是一项优势，
但会放大这种风险：一个未经审查的凭证被广泛共享，
便可能迅速破坏生态系统中许多参与方的信任假设。
为减轻这些危险，部署方应在依据任何
VerifiableRecognitionCredential 行事或进一步共享之前，独立验证其
密码学完整性和来源。这包括确认该凭证的
签发者
是实现者在给定认可域中有既定
理由信任的一方，并确认该凭证
未过期或未被撤销。实现者不能仅依赖
某个对等方已经接受某个凭证这一事实作为其有效性的证据。
相反，验证者需要独立于接收
VerifiableRecognitionCredential 来审查认可凭证的签发者
以及已识别操作，
并且只有在对签发实体建立信任之后，才能依赖凭证中的信息。
恶意行为者可能创建一个 VerifiableRecognitionCredential，通过使用相似的
issuer 标识符或名称来模仿知名认可机构。
手动将 VRC 添加到其软件中、但未将签发者标识符与已知信任根
进行独立验证的验证者，可能会被欺骗
而接受欺诈性认可声明。本节应讨论如何
检测和防止签发者冒充，以及通过权威的带外方式验证签发者
标识符的重要性。
请注意，与协议和用户交互进行适当绑定（例如
个人收到来自 origin 的请求）。如果钱包
能传达如下信息将会很好：“我有一个来自
你信任的某人、针对此 origin/issuer 的认可凭证”（如果检查了
绑定请求与 origin 的关系——例如使用 TLS），并且这与 VRC 中的
issuer 相关联。本节最好讨论协议如何将这类
信息绑定在一起，以帮助个人避免落入骗局。
具有过长 validUntil 期限的认可凭证，可能会在
已识别实体被暂停、撤销或
遭到入侵很久之后仍在流通。相反，过短的有效期会造成运营
负担。本节应讨论如何适当选择有效期，以及
将有效期与健全撤销机制配套的重要性。
本节还应涉及组织/个人终止存在的情况。期限应有多长
取决于列表规模和多样性——列表越大，
时间线越短（24-48 小时？）；列表越小，时间线越长
（数周到数月）。需要能够在合理
时间范围内添加实体。生态系统可能需要列表聚合者——认证机构
可能会有更长的期限。本节应解释
设置更长期限的理由——为什么要超过 24-48 小时？
outputValidation 属性通过 URL 引用外部模式文件。如果
这些 URL 未受到 digestMultibase 或其他完整性检查保护，
攻击者在入侵模式宿主后，就能在不
使认可凭证失效的情况下修改验证规则，导致验证者接受
不再符合预期模式的凭证。本节应讨论
对所有外部引用资源使用内容完整性保护的重要性。
recognizedIn 属性允许认可凭证链接到其他
注册表，例如 ETSI 信任服务列表、X.509 证书颁发机构列表
或其他 VerifiableRecognitionCredential。如果验证者不
强制深度限制或独立验证链中的每个链接，
较低层级注册表中已受损或恶意的条目就可能被传递性信任。
本节应讨论遍历链式认可
结构的安全实践，以及无界传递信任的风险。
action 属性是自由形式字符串（例如 issue、
verify）。如果生态系统内没有
对允许的操作值进行严格治理，已识别
实体可能会呈现声称具有宽泛或未定义操作的凭证，
而验证者可能以比预期更宽松的方式解释这些凭证，从而导致
超出签发者意图的未授权使用。本节应讨论
对操作词汇进行生态系统级治理的重要性，以及验证者应如何
处理无法识别的操作值。
本节为非规范性内容。
本规范在设计时考虑了现有“信任
基础设施”技术，其中三种在下文描述。本规范
定义的数据模型能够表达这些技术中
许多概念，并被设计为通过
recognizedIn 属性与它们互操作。
本节为非规范性内容。
欧洲电信标准协会（ETSI）在 [ETSI-TRUST-LISTS] 中定义了 信任服务列表（TSL）的格式， 该格式在欧盟范围内用于发布可信服务提供者列表——即 被授权根据 eIDAS 法规签发电子签名、电子印章、时间戳和其他 信任服务的实体。每个欧盟成员国都会发布一个 国家 TSL，欧盟委员会则发布列表之列表（LoTL）， 其中引用每个国家 TSL，形成定义明确的层级化信任 联邦。
ETSI 信任服务列表与本规范共享若干概念目标： 二者都描述被认可执行特定 操作的实体，将这些实体与标识元数据相关联，并意图 在验证期间由依赖方消费。然而，本 规范在若干关键方面不同于 ETSI 信任服务列表：
本节为非规范性内容。
X.509 [RFC5280] 是一项公钥基础设施（PKI）标准， 定义证书和证书链的格式。证书 颁发机构（CA）是被信任用于签发 X.509 证书的实体，这些证书将 公钥绑定到身份。对 CA 的信任通常通过 将其纳入浏览器或操作系统信任存储——一份经过策划的 根 CA 列表——或通过可追溯到此类根的证书链来建立。
X.509 CA 基础设施和本规范都处理这样一个问题： 判断给定实体是否可以在给定上下文中被依赖，以执行特定 操作。然而，本规范在若干关键方面不同于 X.509 CA 列表：
VerifiableRecognitionCredential，并在其
生态系统内共享它，而无需中央把关者批准。
本节为非规范性内容。
ISO/IEC 18013-5 定义了移动驾驶执照（mDL），这是一项 将驾驶执照表达为移动文档（mDocs）的标准。作为该 生态系统的一部分，该标准定义了 Verified Issuer Certificate Authority List （VICAL），它是一种已签名的数据结构，包含一组 被认可为有权签发 mDL 的证书颁发机构实体。依赖方 使用 VICAL 来判断所呈现 mDL 的签发者是否在其 管辖范围内受信任。
VICAL 概念和本规范共享同一目标，即使依赖方能够 判断某个凭证签发者是否在 特定生态系统中受到认可。然而，本规范在若干关键方面 不同于 mDL VICAL：
RecognizedAction 结构明确捕获
已识别实体被授权执行的操作，以及这些操作所针对的凭证模式，
从而支持更细粒度的授权。
本节为非规范性内容。
工作组感谢以下个人对社区作出的重要 贡献：TBD
本规范的工作得到了由 Christopher Allen、Joe Andrieu 和 Erica Connell 推动的 Rebooting the Web of Trust 社区的支持。由 Phil Windley、Kaliya Young、Doc Searls 和 Heidi Nobantu Saul 推动的 Internet Identity Workshop 的参与者， 也通过大量工作会议支持了本工作的完善，这些会议 旨在围绕本规范进行教育、辩论和改进。
工作组感谢以下个人审阅 本规范并提供反馈（按字母顺序排列）：