【5】核心属性

5. 核心属性

DID 与 DID 文档关联。DID 文档使用数据模型表达，并可序列化为表示形式。以下章节定义 DID 文档中的属性，包括其是否为必选属性。这些属性描述了 DID 主题与属性值之间的关系。

下表列出了本标准定义的核心属性的参考信息，包括预期值和是否为必选。表中的属性名称链接到规范定义和每个属性的详细描述。

注意：不同类型映射中的属性名称

属性名称 id、type 和 controller 可能出现在不同类型的映射中，且约束条件可能有所差异。

DID 文件属性

属性	是否必选？	限制值
id	是	符合 3.1 DID 句法规则的字符串。
alsoKnownAs	否	符合[RFC3986]URI 规则的一组字符串。
controller	否	符合 3.1 DID 句法规则的一个字符串或一组字符串。
verificationMethod	否	符合验证方法属性中规则的一组验证方法映射。
authentication	否
assertionMethod	否	一组符合验证方法属性规则的验证方法映射或符合 3.2 DID URL 语法的字符串集合。
keyAgreement	否
capabilityInvocation	否
capabilityDelegation	否
service	否	符合服务属性中规则的一组服务端点映射。

验证方法属性

属性	是否必选？	限制值
id	是	符合 3.2 DID URL 语法规则的字符串。
controller	是	符合 3.1 DID 语法规则的字符串。
type	是	字符串
公钥JWKpublicKeyJwk	否	表示符合 [RFC7517] 的 JSON 网络密钥的映射。有关其他限制，请参阅 publicKeyJwk 的定义。
公钥MultibasepublicKeyMultibase	否	符合 [MULTIBASE] 编码公钥的字符串。

服务属性

属性	是否必选？	限制值
id	是	符合 [RFC3986] URI 规则的字符串。
type	是	字符串或一组字符串。 符合 [RFC3986] 中 URls、映射或集合规则的字符串
serviceEndpoint	是	由一个或多个符合 [RFC3986] URls 和/或映射规则的字符串组成。

5.1 标识符

本节描述 DID 文档如何包含 DID 主题和 DID 控制器的标识符。

5.1.1 DID 主题

特定 DID 主题的 DID 通过 DID 文档中的 id 属性表示。

• id

  id的值必须是符合 3.1 DID 语法规则的字符串，并且必须存在于 DID 文档的数据模型根映射中。

例10
{
    
    
  "id": "did:example:123456789abcdefghijk"
}

id 属性仅在 DID 文档的顶层映射中存在时才表示 DID 主题的 DID。

注意：中间表示

DID 方法标准可以创建不包含 id 属性的 DID 文档中间表示，例如在 DID 解析器执行 DID 解析时。然而，完全解析的 DID 文档始终包含有效的 id 属性。

5.1.2 DID 控制器

DID 控制器是授权更改 DID 文档的实体。授权 DID 控制器的过程由 DID 方法定义。

• controller

  controller 属性不是必选的，如果选择，其值必须是一个或多个符合 3.1 DID 语法规则的字符串。相应的 DID 文档应该包含明确允许使用特定验证方法进行特定目的的验证关系。

当 DID 文档中存在 controller 属性时，其值表示一个或多个 DID。这些 DID 的 DID 文档中包含的任何验证方法都应被视为已授权，因此满足这些验证方法的证明应被视为等同于 DID 主题提供的证明，并代表授权更新 DID 文档的 DID 控制器。

例11：带有控制器属性的 DID 文档
{
    
    
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3",
}

注意：授权与认证

请注意，controller 值提供的授权与 5.3.1 认证中描述的认证是分开的。这对于密钥恢复尤其重要，例如在密钥丢失的情况下，DID 主题不再能访问其密钥，或者在密钥泄露的情况下，DID 控制器的可信第三方需要覆盖攻击者的恶意活动。有关威胁模型和攻击向量的详细信息，请参阅 9. 安全考虑。

5.1.3 别名

一个 DID 主题可以出于不同目的或在不同时间拥有多个标识符。可以使用 alsoKnownAs 属性来声明两个或多个 DID（或其他类型的 URI）引用同一个 DID 主题。

• alsoKnownAs

  alsoKnownAs 属性不是必选的，如果选择，其值必须是一个集合，其中每个项目都是符合 [RFC3986] 的 URI。

这种关系表示该标识符的主题也可以由一个或多个其他标识符标识。

注意：等价性和别名

应用程序可以选择在 alsoKnownAs 关系在相反方向上被互换的情况下，将由 alsoKnownAs 关联的两个标识符视为等价。如果不具有这种逆向关系，最好不要将它们视为等价。换句话说，alsoKnownAs 断言的存在并不能证明该断言是真实的。因此，强烈建议请求方获得 alsoKnownAs 断言的独立验证。

鉴于DID主体可能出于不同目的使用不同的标识符，因此对这两种标识符之间的强等价性或合并两个相应DID文档的信息的期望，并不一定合适，即便存在相互关系。

5.2 验证方法

DID 文档可以表达验证方法，例如加密公钥，用于认证或授权与 DID 主题或相关方的交互。例如，加密公钥可以用作数字签名的验证方法；在这种用法中，它验证签名者可以使用关联的加密私钥。验证方法可能包含多个参数。例如，一组五个加密密钥中，任何三个都需要参与加密阈值签名。

• verificationMethod

  verificationMethod 属性不是必选的，如果选择，其值必须是一组验证方法，其中每个验证方法使用映射表示。 验证方法映射必须包含 id、type、controller 和由 type 值确定并在 5.2.1 验证材料中定义的特定验证材料属性。验证方法可以包含其他属性。验证方法应该在 DID 规范注册中心 [DID-SPEC-REGISTRIES] 中注册。

• id

  验证方法的 id 属性值必须是符合第 3.2 节 DID URL 语法规则的字符串。该值表示取消引用到已识别验证方法的 DID URL。

  • type

    属性的值必须是引用一个验证方法类型的字符串。为了最大限度地实现全球互操作性，验证方法类型应该在 DID 规范注册中心 [DID-SPEC-REGISTRIES] 中注册。该值表示所使用的验证方法套件的类型。

  • controller

    controller 属性的值必须是符合 3.1 DID 语法规则的字符串。该值表示拥有用于认证验证方法的秘密加密材料的 DID 控制器或 DID 代理。

例12：验证方法的结构
{
    
    
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "verificationMethod": [{
    
    
    "id": ...,
    "type": ...,
    "controller": ...,
    "publicKeyJwk": ...
  }, {
    
    
    "id": ...,
    "type": ...,
    "controller": ...,
    "publicKeyMultibase": ...
  }]
}

注意：验证方法控制器与 DID 控制器

当关系主题是 DID 文档时，controller 属性的语义与关系主题是验证方法（例如加密公钥）时相同。由于密钥无法自我控制，并且密钥控制器无法从 DID 文档推断，因此需要明确表达密钥控制者的身份。不同之处在于，验证方法的 controller 值不一定是 DID 控制器。DID 控制器使用 DID 文档最高级别（数据模型中的顶层映射）的 controller 属性表示；请参阅 5.1.2 DID 控制器。

5.2.1 验证材料

验证材料 是指用于执行 验证方法 的任何信息。 验证方法 的类型用于确定其与相关过程的兼容性。 验证材料属性 的示例包括 publicKeyJwk 或 publicKeyMultibase。 加密套件规范 负责指定 验证方法 类型及其对应的验证材料。 例如，请参考 JSON Web Signature 2020 和 Ed25519 Signature 2020。有关 DID 可用的所有注册 验证方法 类型及其相关验证材料，请参阅 DID 规范注册表 [DID-SPEC-REGISTRIES]。

为了提高互操作实现的可能性，本规范限制了 DID 文档中表达验证材料的格式数量。 实现者需要实现的格式越少，他们支持所有格式的可能性就越大。 这种方法试图在易于实现和支持历史上广泛部署的格式之间取得微妙的平衡。 下面列出了两种支持的验证材料属性：

• publicKeyJwk

  publicKeyJwk 属性不是必选的，如果选择，其值 必须 是一个表示符合 [RFC7517] 的 JSON Web Key 的映射。 该映射 不能 包含 “d” 或注册模板中描述的私有信息类的任何其他成员。 建议 使用 JWKs [RFC7517] 表示其公钥的验证方法使用 kid 的值作为其片段标识符。 建议 将 JWK kid 值设置为公钥指纹 [RFC7638]。 有关具有复合密钥标识符的公钥示例，请参见示例 13 中的第一个密钥。

• publicKeyMultibase`

  publicKeyMultibase 属性不是必选的。 此功能是非规范性的。 如果存在，其值 必须 是 [MULTIBASE] 编码公钥的字符串表示。

请注意，[MULTIBASE] 规范尚未成为标准，可能会发生变化。 在某些情况下，可以使用此数据格式定义 publicKeyMultibase 来表达公钥，但未定义 privateKeyMultibase 以防止意外泄露私钥。

验证方法不得包含同一材料的多个验证材料属性。 例如，使用 publicKeyJwk 和 publicKeyMultibase 同时在验证方法中表达密钥材料是不被允许的。

下面显示了一个包含使用上述两种属性的验证方法的 DID 文档示例。

例13: 使用 publicKeyJwk 和 publicKeyMultibase 的验证方法
{
    
    
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "verificationMethod": [{
    
    
    "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "type": "JsonWebKey2020", // external(property value)
    "controller": "did:example:123",
    "publicKeyJwk": {
    
    
      "crv": "Ed25519", // external(property value)
      "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ", // external(property value)
      "kty": "OKP", // external(property value)
      "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A" // external(property value)
    }
  }, {
    
    
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020", // external(property value)
    "controller": "did:example:pqrstuvwxyz0987654321",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }],
 ... 
}

5.2.2 参考验证方法

验证方法可以嵌入到或引用自与各种验证关系关联的属性中，如 5.3 验证关系中所述。引用验证方法允许它们被多个验证关系使用。

如果验证方法属性的值是一个映射，则该验证方法被嵌入，其属性可以直接访问。然而，如果该值是一个 URL 字符串，则该验证方法是通过引用包含的，其属性需要从 DID 文档的其他位置或另一个 DID 文档中检索。这是通过反引用 URL 并搜索结果资源中的具有匹配 URL 值的 id 属性的验证方法映射来完成的。

例14：嵌入和引用验证方法
{
    
    
...

  "authentication": [
    // 此密钥被引用，可能被多个验证关系使用
    "did:example:123456789abcdefghi#keys-1",
    // 此密钥被嵌入，仅可用于身份验证
    {
    
    
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2020", 
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
    }
  ],

...
}

5.3 验证关系

验证关系表达了 DID 主题与验证方法之间的关系。

不同的验证关系允许关联的验证方法用于不同目的。 验证者可以通过检查所使用的验证方法是否包含在 DID 文档的相应验证关系属性中来确定验证尝试的有效性。

DID 主题与验证方法之间的验证关系在 DID 文档中是明确的。 不与特定验证关系关联的验证方法不能用于该验证关系。 例如，身份验证属性值中的验证方法不能用于与 DID 主题进行密钥协商协议 - 需要使用密钥协商属性的值。

DID 文档不使用验证关系表达被撤销的密钥。 如果引用的验证方法不在用于反引用的最新 DID 文档中，则该验证方法被视为无效或已撤销。 每种 DID 方法规范都应详细说明如何执行和跟踪撤销。

以下部分定义了几种有用的验证关系。 DID 文档可以包含其中任何一个或其他属性来表达特定的验证关系。 为了最大限度地提高全球互操作性，任何使用的此类属性都应在 DID 规范注册表 [DID-SPEC-REGISTRIES] 中注册。

5.3.1 身份验证

身份验证验证关系用于指定预期如何对 DID 主题进行身份验证，例如登录网站或参与任何类型的挑战-响应协议。

authentication 身份验证属性是可选的。 如果存在，关联值必须是一组一个或多个验证方法。 每个验证方法可以嵌入或引用。

例15: 含三个验证方法的认证属性
{
    
    
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "authentication": [
    // 此方法可用于身份验证为 did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // 此方法 *仅适用于* 身份验证，不得用于任何其他证明目的，
    // 因此其完整描述在此嵌入，而不是仅使用引用
    {
    
    
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
    }
  ],
  ...
}

一旦身份认证成功，后续操作由 DID 方法或其他应用决定。特定 DID 方法可能认为，以 DID 控制器的身份认证足以更新或删除 DID 文档。但其他 DID 方法可能要求使用不同的密钥或验证方式来执行这些操作。换言之，认证之后的处理不在数据模型的范围内，由 DID 方法和应用自行定义。

这对于任何需要验证认证实体是否持有有效认证证明的认证验证器都很有用。当验证器接收到包含认证证明的数据（特定协议格式）且该数据表明实体由 DID 标识时，验证器会使用 DID 文档中列出的验证方法（例如公钥）来验证该证明。

需要注意的是，DID 文档中的 authentication 属性所指明的验证方法仅用于认证 DID 主题。要认证不同的 DID 控制器，需使用控制器关联实体（如 5.1.2 DID 控制器定义）的 DID 文档和对应的认证验证关系进行认证。

5.3.2 断言

assertionMethod 验证关系用于指定 DID 主题预期如何表达声明，例如用于颁发可验证凭证 [VC-DATA-MODEL]。

• assertionMethod
  assertionMethod 属性不是必选的，如果选择，关联值必须是一组一个或多个验证方法。每个验证方法可以嵌入或引用。

例如，在验证者处理可验证凭证期间，此属性很有用。在验证过程中，验证者通过检查用于断言证明的验证方法是否与相应 DID 文档中的 assertionMethod 属性关联，来检查可验证凭证是否包含由 DID 主题创建的证明。

例16：包含两个验证方法的断言方法属性
{
    
    
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "assertionMethod": [
    // 此方法可以采用与did:...fghi算法类似的方式进行密钥协商
    "did:example:123456789abcdefghi#keys-1",
    // 此方法仅限于密钥协商使用，不会用于任何其他验证关系，因此其完整描述嵌入此处，而非仅使用引用
    {
    
    
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2020", // external(property value)
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
    }
  ],
  ...
}

5.3.3 密钥协商

密钥协商验证关系用于指定实体如何生成加密材料，以便传输意图发送给DID主题的机密信息，例如建立与接收方的安全通信通道。

• keyAgreement
  密钥协商属性不是必选的，如果选择，关联值必须是一组一个或多个验证方法。每个验证方法可以嵌入或引用。

该属性的一个使用示例是加密意图发送给DID主题的消息。在这种情况下，对方使用验证方法中的加密公钥信息来包装接收方的解密密钥。

Example 17: Key agreement property containing two verification methods
{
    
    
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  ...
  "keyAgreement": [
    // 此方法可以采用与did:...fghi算法类似的方式进行密钥协商
    "did:example:123456789abcdefghi#keys-1",
    // 此方法仅限于密钥协商使用，不会用于任何其他验证关系，因此其完整描述嵌入此处，而非仅使用引用
    {
    
    
      "id": "did:example:123#zC9ByQ8aJs8vrNXyDhPHHNNMSHPcaSgNpjjsBYpMMjsTdS",
      "type": "X25519KeyAgreementKey2019", 
      "controller": "did:example:123",
      "publicKeyMultibase": "z6LSn6p3HRxx1ZZk1dT9VwcfTBCYgtNWdzdDMKPZjShLNWG7"
    }
  ],
 ... 
}

5.3.4 能力调用

能力调用验证关系用于指定 DID 主题可能用来调用加密能力的验证方法，例如更新 DID 文档的授权。

• capabilityInvocation
  能力调用属性不是必选的，如果选择，关联值必须是一组一个或多个验证方法。每个验证方法可以嵌入或引用。

该属性在以下情境中尤为重要：当去中心化身份（DID）主体需访问一个需要授权的受保护HTTP API时。为实现对HTTP API的授权，DID主题使用与特定URL相关联的能力。能力的调用可通过多种形式表达，例如作为一条置于HTTP头中的数字签名消息。

提供 HTTP API 的服务器是能力的验证者，它需要验证被调用的能力所引用的验证方法是否存在于 DID 文档的 capabilityInvocation 属性中。验证者还会检查所执行的操作是否有效，以及能力是否适用于正在访问的资源。如果验证成功，服务器已通过加密方式确定调用者有权访问受保护的资源。

Example 18: Capability invocation property containing two verification methods
{
    
    
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "capabilityInvocation": [
    // 此方法可以采用与did:...fghi算法类似的方式进行密钥协商
    "did:example:123456789abcdefghi#keys-1",
    // 此方法仅限于密钥协商使用，不会用于任何其他验证关系，因此其完整描述嵌入此处，而非仅使用引用
    {
    
    
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2020", 
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
    }
  ],
  ...
}

5.3.5 能力委派

capabilityDelegation验证关系用于指定DID主题可能用来将加密能力委派给另一方的机制，例如将访问特定HTTP API的权限委派给下属。

• capabilityDelegation

  能力委派属性不是必选的，如果选择，关联值必须是一组一个或多个验证方法。每个验证方法可以嵌入或引用。

一个该属性有用的示例是，当 DID 控制者选择将其访问受保护 HTTP API 的能力委托给其他方时。为了委托这一能力，DID 主题将使用与 capabilityDelegation 验证关系相关联的验证方法来对该能力进行加密签名，并将其转交给另一个 DID 主题。受委托方随后将以类似于 5.3.4 能力调用所描述的方式使用该能力。

Example 19: Capability Delegation property containing two verification methods
{
    
    
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "capabilityDelegation": [
     // 此方法可以采用与did:...fghi算法类似的方式进行密钥协商
    "did:example:123456789abcdefghi#keys-1",
    // 此方法仅限于密钥协商使用，不会用于任何其他验证关系，因此其完整描述嵌入此处，而非仅使用引用
    {
    
    
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2020", 
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
    }
  ],
  ...
}

5.4 服务

服务用于 DID 文档中，表达与 DID 主题或关联实体进行通信的方式。服务可以是 DID 主题希望宣传的任何类型的服务，包括用于进一步发现、身份验证、授权或交互的去中心化身份管理服务。

出于隐私考虑，不建议通过服务公开信息，例如社交媒体账户、个人网站和电子邮件地址。关于隐私问题的进一步探讨可以参见 10.1 保持个人数据私密性 和 10.6 服务隐私。与服务相关的信息通常是特定于服务的。例如，与加密消息服务相关的信息可以表达在消息开始之前如何建立加密连接。

服务使用下述 service 属性来表达：

• service

  service 属性不是必选的，如果选择，关联的值必须是一组服务，其中每个服务通过一个映射来描述。每个服务映射必须包含 id、type 和 serviceEndpoint 属性。每个服务扩展可以包含附加属性，并且可以进一步限制与扩展相关的属性。

  • id

    id 属性的值必须是符合 [RFC3986] 的 URI。符合要求的生产者不得生成具有相同 id 的多个服务条目。符合要求的解析器如果检测到具有相同 id 的多个服务条目，必须生成错误。

    • type

      type 属性的值必须是字符串或字符串集。为了最大程度地提高互操作性，服务类型及其关联属性应在 DID 规范注册表 [DID-SPEC-REGISTRIES] 中注册。

    • serviceEndpoint

      serviceEndpoint 属性的值必须是字符串、映射，或由一个或多个字符串和/或映射组成的集合。所有字符串值必须是符合 [RFC3986] 的有效 URI，并根据 RFC3986 中的规范化和比较规则及其适用的 URI 方案规范中的任何规范化规则进行规范化。

关于服务的隐私和安全性考虑的更多信息，请参见 10.6 服务隐私、10.1 保持个人数据私密性、10.3 DID 文档相关性风险 和 9.3 身份验证服务端点。

Example 20: Usage of the service property
{
    
    
  "service": [{
    
    
    "id":"did:example:123#linked-domain",
    "type": "LinkedDomains", // external(property value)
    "serviceEndpoint": "https://bar.example.com"
  }]
}