DID 模型与语法

• 5.3 通用(generic)DID参数名
• 5.4 特定于Method的DID参数
• 5.5 Path
• 5.6 Query
• 5.7 Fragment
• 5.8 Normalization
• 5.9 Persistence（持久性）

• 6.DID Documents
  • 6.1 Context
  • 6.2 DID Subject
  • 6.3 Public Keys
  • 6.4 Authentication
  • 6.5 Authorization and Delegation
  • 6.6 Service EndPoints
  • 6.7 Created
  • 6.8 Updated
  • 6.9 Proof
• 7 DID Document Syntax
  • 7.1 JSON
  • 7.2 JSON-LD
• 8 DID Methods
  • 8.1 DID Method Schemes
  • 8.2 DID Operations
  • 8.3 Unique DID Method Names
• 9. DID Resolvers
• 10 Security Considerations
  • 10.3 Binding of Identity

5.3 通用(generic)DID参数名

部分DID参数是独立于DID methods之外的，在所有DID中起到相同的作用。另一部分DID参数是与特定的DID method相关的。但是与特定DID method相关的参数在所有的支持该参数的DID method中应保持同样的操作方式。

下表是通用DID参数

Generic DID Parameter name	Description
hl	DID document中添加完整性保护的资源哈希值
service	DID document中通过service ID 标识一个Service
version-id	标志一个待解析的DID文档的特定版本
version-time	标志一个待解析的DID文档的时间戳

将一个DID参数添加到一个DID URL中意味着这个参数成为了URL的一部分。或者可以通过传递某些参数给DID解析器来执行，这些参数便不是DID URL的一部分。类似于http中的URL后缀以及http请求头参数。

注意：
1.成为URL中一部分的参数应该用来标识特定的资源，而传递给解析器的参数用于如何使用这些资源。
2.如果已经存在明确的、合适的特定URI，不要再画蛇添足通过给URI添加参数达到相同的功能。例如DID的query语句。
3.如果一个参数可以传递给解析器执行，就没有必要再附加在原来的DID中。

5.4 特定于Method的DID参数

一个方法特定的DID参数，在使用时必须加上方法前缀。例如一个method为did:foo:，方法名为bar，那么它将如下表示：

did:foo:21tDAKCERh95uGgKbJNHYp;foo:bar=high

一个方法特定的参数名字可能在另一个方法中也被定义:

did:example:21tDAKCERh95uGgKbJNHYp;foo:bar=low

方法特定的参数也许会和通用参数放在一起（没有特定顺序要求）

did:example:21tDAKCERh95uGgKbJNHYp;service=agent;foo:bar=high

DID的方法命名空间以及该方法对应的基于特定方法的参数都可以包含冒号，可以由此来构造分层次的参数名：

did:foo:baz:21tDAKCERh95uGgKbJNHYp;foo:baz:hex=b612

5.5 Path

一个通用的DID Path和一个URI是相同的，必须同ABNF规则一致。一个DID Path用于通过一个service endpoint寻找可用资源。一个特定的DID scheme可能会有特定的DID PATH规范，相较于通用的Path规则限制也更加严格。

did:example:123456/path

5.6 Query

一个通用的DID Query和一个URL query是相同的而且遵守同样的规则。一个DID query用来通过一个service endpoint寻找可用资源。同Path，你的自定义scheme的DID可以对query加以更加严格的设置。

did:example:123456?query=true

5.7 Fragment

DID通用Fragment与URL是一样的，用于标识次级资源。（URL，URL标识主要次元。）建议fragment只用于通用的、与方法无关的参数。

did:example:123456#oidc

5.8 Normalization

注意DID语法的规则化（大小写缩进等要与主要互联网规则接轨）

5.9 Persistence（持久性）

一个DID应当是持久且不变的，并且应当和它的持久不变的DID subject绑定，且这个绑定关系也是永久的。

一个DID可能会同时被绑定到多个注册机构，为了便于维持其持久性，DID method应当仅仅将DIDs和DID methods绑定到稳定的DID注册机构。

6.DID Documents

6.1 Context

@context属性确保两个系统在同一个DID基础上交换数据时所用的术语和协议可以互相理解。
@context标签必须以w3开头，可以包含一个或多个：

{
  "@context": "https://www.w3.org/ns/did/v1"
}

若是特定的DID method中想要自定义context，不要去覆盖DID中通用的context。

6.2 DID Subject

DID subject is the entity identified by the DID and described by the DID document.
DID subjetc is denoted with id property,it is the entity that the DID document is about;

{
  "id": "did:example:21tDAKCERh95uGgKbJNHYp"
}

6.3 Public Keys

公钥被用作数字签名加密等，也可以用于DID中CRUD操作的验证身份等。

如果一个DID document包含一个pulickey属性，那么它的值必须是一个数组，数组中的每个条目都要包含type，controller以及特定的公钥属性。可选一个id属性。

id属性必须是一个URL，publickey数组中的id属性是不能重复的，controller必须是一个合法的DID，同时这个DID具有他的私钥。

以下是一个various public key 实例

  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/v1"],
  "id": "did:example:123456789abcdefghi",
  
  "publicKey": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }, {
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:pqrstuvwxyz0987654321",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }, {
    "id": "did:example:123456789abcdefghi#keys-3",
    "type": "Secp256k1VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
  }],
  
}

一个key可能背一个DID document 引用或是嵌入，如下中authentication 属性所示。

{


  "authentication": [
    //这个key是通过DID引用的
    "did:example:123456789abcdefghi#keys-1",
    //这个key是嵌入进authentication中的。
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],


}

6.4 Authentication

身份认证是用于DID controller证明他们与一个DID有联系的机制。身份认证和授权管理分开是因为DID controllers可能希望在不必要提供证明的情况下更新相关的document。

DID document 如果包括一个authentication属性，该属性的值应当是一个具有各种验证方法的数组。每个方法可能是内嵌的或是引用的。如下就是一个含有三个验证方法（都是key）的authentication：

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  
  "authentication": [
    
    "did:example:123456789abcdefghi#keys-1",
    
    "did:example:123456789abcdefghi#biometric-1",
    
    
    
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  
}

6.5 Authorization and Delegation

6.6 Service EndPoints

DID document 的一个主要目的就是启用service endpoints的发现功能。一个service endpoint可以是任意的DID subject想要通知的类型。可以实现包括去中心化身份管理以及身份认证授权等。

一个DID document可以包括一个service属性，它的值必须是一个service endpoints的数组，包括type，serviceEndpoint属性。建议添加一个id属性，且id属性为URI格式。

{
  "service": [{
    "id": "did:example:123456789abcdefghi#openid",
    "type": "OpenIdConnectVersion1.0Service",
    "serviceEndpoint": "https://openid.example.com/"
  }, {
    "id": "did:example:123456789abcdefghi#vcr",
    "type": "CredentialRepositoryService",
    "serviceEndpoint": "https://repository.example.com/service/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#xdi",
    "type": "XdiService",
    "serviceEndpoint": "https://xdi.example.com/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#agent",
    "type": "AgentService",
    "serviceEndpoint": "https://agent.example.com/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#hub",
    "type": "IdentityHub",
    "publicKey": "did:example:123456789abcdefghi#key-1",
    "serviceEndpoint": {
      "@context": "https://schema.identity.foundation/hub",
      "type": "UserHubEndpoint",
      "instances": ["did:example:456", "did:example:789"]
    }
  }, {
    "id": "did:example:123456789abcdefghi#messages",
    "type": "MessagingService",
    "serviceEndpoint": "https://example.com/messages/8377464"
  }, {
    "id": "did:example:123456789abcdefghi#inbox",
    "type": "SocialWebInboxService",
    "serviceEndpoint": "https://social.example.com/83hfh37dj",
    "description": "My public social inbox",
    "spamCost": {
      "amount": "0.50",
      "currency": "USD"
    }
  }, {
    "id": "did:example:123456789abcdefghi#authpush",
    "type": "DidAuthPushModeVersion1",
    "serviceEndpoint": "http://auth.example.com/did:example:123456789abcdefg"
  }]
}

6.7 Created

创建时间属性

6.8 Updated

6.9 Proof

一个proof属性根据DID subject，DID controller来加密验证 DID document的完整性。

{
  "proof": {
    "type": "LinkedDataSignature2015",
    "created": "2016-02-08T16:02:20Z",
    "creator": "did:example:8uQhQMGzWxR8vw5P3UWH1ja#keys-1",
    "signatureValue": "QNB13Y7Q9...1tzjn4w=="
  }
}

7 DID Document Syntax

7.1 JSON

DID data modal可以通过合理的映射被编码成为js 对象来表示。（通过映射值属性成为JSON类型）。

7.2 JSON-LD

JSON-LD是一个JSON的升级版，主要用于序列化链接数据，可以由JSON平滑过渡，适用于JSON-based数据存储引擎。
@id @type 关键词等同于id和type，为开发者以JSON惯用的格式使用这份指南提供了基础。
数据类型如integers,datas,URLs等，是自动类型，可以提供强类型保证。
@protected标签意味着被该标签标识的地方不可以被覆盖。

8 DID Methods

8.1 DID Method Schemes

一个DID method 规范必须精确的定义一种 method-specific DID scheme，并被一个单词所标识。

这个方法名会成为DID的一部分，所以名字需要简短并能反应该方法的作用。

DID method规范必须要致命如何生成关于该method的DID的method-specific-id，他必须在没有中心化机构介入的情况下生成。并且这个method-specific-id应当是全局唯一的，由他引出的DID也应当是全局唯一的。

一个DID method应当尽可能减少可能生成的DID的种类的个数。

8.2 DID Operations

为了在一个特定的DID registry上充分发挥DID 和DID document的作用，一个DID method规范应当指明客户端如何采用每个CRUD操作，指明client和DID registry之间相互交互操作的测试以及构建。这些操作可以使得所有的操作需求一个CKMS加密密钥管理系统。

• Create
• Read/Vreify
• Update
• Deactivate

8.3 Unique DID Method Names

如果新建一个DID Method，注意不能与已有的同名

9. DID Resolvers

10 Security Considerations

10.3 Binding of Identity

10.3.1 证明一个DID和DID document间的Control
签名是一种允许DID document变成加密可验证形式的方法。对于它自身而言，一个在一个自签名的DID document上的可验证签名不提供对一个DID的证明，他仅证明了：

• DID document 自它被注册起没有被篡改。
• DID controller（s）控制着在这个签名被创建的时候生成这个签名的私钥。
  想要证明对一个DID的控制，也就是证明一个DID和描述它的DID document的绑定关系，需要如下两步：