DID解析

## Abstract DID 标识符是一种自我授权的数字身份,DIDs完全由DID subject控制且独立于任何中心化的机构等。DIDs可以解析成DID documents,DID documents是简单的描述特定DID的文档。

1.Introduction

DID Resolution(解析)是一个通过给定的DID获得一份DID document的过程。任何DID都可以被施加读创建、废弃、读以及更新4种操作。对于这些操作的具体细节取决于对应的DID method。

在DID resolution的基础上可以进行DID URL dereferencing(DID URL 寻址)来通过一个给定的DID URL检索到特定资源的一种表示。任何一颗进行这个解析过程的硬件/软件被称为DID Resolver。

注意:特定的DID method规范中定义了与DID的DID registry进行交互的具体步骤以及实际操作。(DID中只是定义了一个基础模版)

1.1 Conformance

规定了本篇文档用词语法的一致性。

1.2 术语

Binding 一个实际的机制,描述了一个Client如何 invoke 一个DID Resolver的具体机制。

Client 调用DID解析器的硬件/软件,以此来执行DID Relolution或是DID URL Dereferencing算法。这个调用是通过一个Binding完成的。

DID Relolution 一个将DID以及其额外的参数视为输入的一部分并且返回一个DID Document或是DID Resolution Result作为输出。这个算法依赖于特定的DID method中的Read操作。

DID Resolution Result一个DID Resolution或是DID URL Dereferencing返回结果(返回一个document)的包装。可能包含一个DID document以及其他的内容。

DID URL Dereferencing一个算法,接受一个DID URL的额外参数作为输入并返回一个DID文档或是一个DID Resolution Result或是资源的其它类型作为输出。

Service Endpoint 某个document中的service endpoint可以使别的文档发现他自己服务端点。(自己的service endpoint向外界提供服务)。servcie endpoint可以是任何类型的、subject希望公布的服务。

Verifiable Read 一个DID method特定的Read方法在DID Resolver和DID Registry之间获得DID Docuent的高可信度实现。在适应该DID method的条件下,拥有获取资源结果的完整性以及正确性的保证。

3.Resolving a DID

该部分介绍了DID resolution的输入以及算法,并且介绍了解析后的返回结果(document和DID resolution result)。该算法依赖于特定的DID method中实现的Read方法。

通用接口如下:

resolve ( did, input-options )

3.1 Input

DID Relolution的输入包括一个DID以及相关的输入参数。

3.1.1 method-name

method name是DID输入的重要部分。作为一个DID标识符的一部分,它定义了特定的方法的执行。

3.1.2 result-type

可能的value是以下两种:

  • did-document
  • resolution-result

3.1.3 version-id

3.1.4 version-time

3.1.5 no-cache

可能的值:
-“false”
-“true”

3.2 Algorithm

一个DID解析器必须实现如下的DID Resolution算法要求。
1、验证输入的DID是否合法。2、决定输入的DID中的DID method是否被该DID解析器支持。3.通过输入DID的method中的Read方法,由指定的DID Registry中通过DID获取对应的DID document。4、验证输出的合法性。5.如果输出是DID document类型或是null,返回结果。如果返回结果(result-type)是resolution-result,构建一个DID Resolution Result包装并且将DID document作为元数据填充进去,最后返回该result。

4 Dereferencing a DID URL

该部分定义了DID URL Dereferncing的算法:

dereference ( did-url, input-options )

4.1 Input

4.1.1 DID URL

4.1.2 result-type

vales:

  • did-document
  • relolution-result

4.1.3service-type

service-type输入参数可以被一个客户端使用,用来从一个DID Document中选择特定的服务。

4.1.4 follow-redirect

4.2 Algorithm

DID解析器想要实现DID URL引用算法必须实现以下3步:
1、解析一个DID。同DID resolution算法首先进行DID解析,然后将参数传递。
2、引用Primary resource。分离Fragment,对主要DID URL解析。
3、引用secondary resource(仅在输入的DID中包含一个Fragment时才会引用二级次元)执行次级资源解析。

4.3 Dereferencing the Primary Resource

1.如果输入的DID URL中包括generic matrix parameter(以下简称为GMP) service并且带有可选的DID Path、DID Query的话:

EXAMPLE 1
did:example:1234;service=agent/profile?query

1.1 从被解析的DID document中,选择一个id属性匹配input DID URL 中service GMP值的service endpoint,这个service endpoint被称为input service endpoint。

-1.2 执行Service Endpoint Construction算法(具体见第七章)
1.2.1 从input service endpoint 中读取到serviceEndpoint属性的值,这个值被称为input service endpoint URL。
1.2.2 将input DID URL 和input service endpoint URL传递进Service Endpoint Construction 算法中。
1.2.3 上述过程产生的结果被称为output service endpoint URL。

  • 1.3 返回 output service endpoint URL

2.另一方面,如果input DID URL包含method-specific matrix parameters:

EXAMPLE 2
did:example:1234;example:object=myprofile

把如何取值这个input DID URL的工作委托给合适的DID method进行。

3.如果input DID URL 不含DID Path 也不含DID Query:

EXAMPLE 3
did:example:1234

那么直接返回解析到的DID document

  1. 如果input DID URL包含一个DID path and/or DID query

    EXAMPLE 4
    did:example:1234/custom/path?customquery

  • 4.1 适合的DID method中也许会指示如何处理这个input DID URL。
  • 4.2 client也许能够以application-specific的方式来处理这个input DID URL

4.4 Dereferencing the Secondary Resource

如果DID URL包含一个DID Fragment
[fragment 教程](https://www.jianshu.com/p/2c07fbb52b45)
,那么取值这个被URL标定的资源不是依赖于URI scheme,而是依赖于primary资源的media type。
换句话说,也就是dereferencing the primary resource 的result。

1.如果说Dereferencing the primary resource的结果是一个解析完成的DID document,并且这个document带有MIME typeapplication/did+ld+json并且input DID URL
包括一个DID Fragment

EXAMPLE 5
did:example:1234#keys-1

1.1 从被解析的DID document中,选择id属性匹配input DID URL的JSON-LD object,例如一个public key或是一个service endpoint。这被称作输出资源。 从DID文档中选择JSON-LD Object必须要考虑相关的IRIs和已经解析的文档的基本IRI。
1.2 返回output resource

2.如果result of dereferencing the primary resource 是一个 output service endpoint URL,并且input DID URL包括一个DID Fragment:

EXAMPLE 6
did:example:1234;service=agent/profile?query#frag

2.1将DID Fragment添加到output service endpoint URL后,换句话说,output service endpoint URL继承了DID Fragment。

3.如果非以上两种情况,取值二级资源按照primary resource中的media type中定义的方式。

4.5 Additional Features

4.5.1 Redirect
一个服务端点可能本身会含有一个serviceEndpoint属性并且该属性的值就是一个DID。这种情况下,一个DID解析子进程会被启动来访问最终的service endpoint。

EXAMPLE 7

1
2
3
4
5
{
"id": "did:example:123456789abcdefghi#hub1",
"type": "HubService",
"serviceEndpoint": "did:example:xyz"
}

4.5.2 Proxy
一个DID document可能包含一个“proxy”服务类型,该服务会提供一个影射用来解析一个最终的service URL。

EXAMPLE 8

1
2
3
4
5
{
"id": "did:example:123456789abcdefghi",
"type": "ProxyService",
"serviceEndpoint": "https://mydomain.com/proxy"
}

4.5.3 JSON Pointer

4.5 Examples

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
EXAMPLE 9
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:example:123456789abcdefghi",
"publicKey": [{
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"publicKeyPem": "-----BEGIN PUB...0101010..END PUB -----\r\n"
}],
"service": [{
"id": "did:example:123456789abcdefghi#agent",
"type": "AgentService",
"serviceEndpoint": "https://agent.example.com/8377464"
}, {
"id": "did:example:123456789abcdefghi#hub",
"type": "HubService",
"serviceEndpoint": "https://hub.example.com/.identity/did:example:0123456789abcdef/"
}, {
"id": "did:example:123456789abcdefghi#messages",
"type": "MessagingService",
"serviceEndpoint": "https://example.com/messages/8377464"
}]
}
  • 给出如下的input DID URL以及上面的DID document:

    EXAMPLE 10
    did:example:123456789abcdefghi#keys-1

之后dereferencing a DID URL算法的输出result如下:

1
2
3
4
5
6
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"publicKeyPem": "-----BEGIN PUB...0101010..END PUB -----\r\n"
}
  • 给定如下的input DID URL 以及同样的DID document。

    EXAMPLE 12
    did:example:123456789abcdefghi;service=messages/some/path?query#frag

result of the dereferencing a DID URL 是一个output service endpoint URL:

EXAMPLE 13
https://example.com/messages/8377464/some/path?query#frag

5. DID Resolution Architectures

5.1 Method Architectures

DID解析架构中包括在一个DID上执行Read 操作,这个操作是由特定的DID决定的。

根据DID method定义的Read操作的不同,DID Resolver和DID registry间的互相操作可以被实现为可验证Read和不可验证Read。

一个Verifiable Read操作需要建立Read操作结果的完整性、正确性、可信性。他可以被实现成多种方式。

  • 通过一个本地的、可信网络的主机来访问DID registry。在blockchain-based DID method中,一个全节点的block chain可能会运行在本地网络主机上来实现Verifiable Read。
  • DID Resolver可能远程链接DID registry但是有一些方法来验证Read 操作返回的result。在blocckchain-based DID method,即使不能获得blockchain全节点,也可以通过一个轻量级的客户端处理metadata来验证Read操作返回的result的可信性。
  • 通过secure channel访问。

一个 Unverifiable read无法提供内容的正确性、完整性、安全性保证。

一个DID resolver 必须实现一个Verifiable Read 方法,对于Unverifiable read方法则不做要求。

一个DID resolver必须支持至少一个DID method的解析算法。

5.2 Reslover Architectures

DID Resolution 和 DID URL Dereferencing 被定义成抽象功能。这些算法倍DID resolvers实现。一个DID resolver 通过一个Binding调用一个client。Binding定义了这些抽象方法是如何通过固定的程序或是通信接口实现的。Binding包括Local Binding和Remote Binding(例如HTTP Binding)。

5.2.1 Proxied Resolution
一个DID 解析器可能会调用另一个DID解析器,此时他作为一个代理,作为一个client,选择一个合适的Binding来调用第二个DID resolver。然后第一个resolver传递给第二个resolver输入,并从第二个resolver那里接受到执行结果返回给最初的client。

5.2.2 Client-Side Dereferencing
暂缺

6 DID Resolution Result

这一部分定义了一个用来以某种方式呈现指定结果的数据结构。该结果为Resolving a DID或是Dereferencing a DID URL的返回的result。一个DID resolution result中包括了一个DID document或是其他的一些数据作为metadata。

6.1 Example

EXAMPLE 14: Example DID Resolution Result

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
"@context": "https://www.w3.org/ns/did-resolution/v1",
"didDocument": {
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:sov:WRfXPg8dantKVubE3HX8pw",
"service": {
"type": "xdi",
"serviceEndpoint": "http://127.0.0.1:8080/xdi"
},
"authentication": {
"type": "Ed25519SignatureAuthentication2018",
"publicKey": ["did:sov:WRfXPg8dantKVubE3HX8pw#key-1"]
},
"publicKey": [{
"id": "did:sov:WRfXPg8dantKVubE3HX8pw#key-1",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}]
},
"resolverMetadata": {
"driverId": "did:sov",
"driver": "HttpDriver",
"retrieved": "2019-06-01T19:73:24Z",
"duration": 1015
},
"methodMetadata": {
"nymResponse": {
"result": {
"data": "{\"dest\":\"WRfXPg8dantKVubE3HX8pw\",\"identifier\":\"V4SGRU86Z58d6TV7PBUe6f\",\"role\":\"0\",\"seqNo\":11,\"txnTime\":1524055264,\"verkey\":\"H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV\"}",
"type": "105",
"txnTime": 1.524055264E9,
"seqNo": 11.0,
"reqId": 1.52725687080231475E18,
"identifier": "HixkhyA4dXGz9yxmLQC4PU",
"dest": "WRfXPg8dantKVubE3HX8pw"
},
"op": "REPLY"
},
"attrResponse": {
"result": {
"identifier": "HixkhyA4dXGz9yxmLQC4PU",
"seqNo": 12.0,
"raw": "endpoint",
"dest": "WRfXPg8dantKVubE3HX8pw",
"data": "{\"endpoint\":{\"xdi\":\"http://127.0.0.1:8080/xdi\"}}",
"txnTime": 1.524055265E9,
"type": "104",
"reqId": 1.52725687092557056E18
},
"op": "REPLY"
}

6.2 DID Document

result结果主体为一个document

6.3 Resolver Metadata

6.4 Method Metadata

7. Service Endpoint Construction

这个部分定义了Service Endpoint的输入以及输出算法,并返回一个service endpoint URL作为输出。这个算法在DID URL Dereferencing期间当service endpoints被选择的时候启用。

7.1 Input

Service Endpoint Construction算法的输入是一个input DID URL 和一个input service endpoint URL。并且该算法的输入要求如下:

  • input DID URL 和input service endpoint URL 可以同时拥有path部分。
  • input DID URL 和 input service endpoint URL 不能同时拥有query部分
  • input DID URL 和input service endpoint URL不能同时拥有fragment部分。
  • input service endpoint URL 一定是一个 HTTP(S)URL。

7.2 Algorithm

  • Initialize a string output service endpoint URL to the value of the input service endpoint URL
  • If the output service endpoint URL has a query component, remove it.
  • If the output service endpoint URL has a fragment component, remove it.
  • Append the path component of the input DID URL to the output service endpoint URL.
  • If the input service endpoint URL has a query component, append ? plus the query to the output service endpoint URL.
  • If the input DID URL has a query component, append ? plus the query to the output service endpoint URL.
  • If the input service endpoint URL has a fragment component, append # plus the fragment to the output service endpoint URL.
  • If the input DID URL has a fragment component, append # plus the fragment to the output service endpoint URL.
  • Return the output service endpoint URL.

7.3 Example

Given the following input service endpoint URL:

https://example.com/messages/8377464

And given the following input DID URL:

did:example:123456789abcdefghi;service=messages/some/path?query#frag

Then the output service endpoint URL is:

https://example.com/messages/8377464/some/path?query#frag

8 Binding

8.1 HTTP(S) Binding

这一部分是关于一个DID resolver通过一个HTTP(s)endpoint暴露(exposes)DID resolution以及DID URL dereferencing功能(包括各种输入参数和输出数据)

具体执行步骤如下:
1.通过将input DID 或是input DID URL 追加到 DID Resolver HTTP(s)endpoint末尾来构建一个HTTP(s)请求。
2.在这个http请求上执行http get请求。
3.如果输入DID不存在,响应404回复错误码。
4.如果输入的DID存在,那么:

  • http 响应状态码设成200.
  • hhtp response 要包含content-type header。这个header的值一定是application/did+ld+json
  • http response body 一定要包含 解析得到的DID document或者是其他的输出资源作为DID resolution或是DID URL dereferencing 功能的返回结果。

5.如果input DID 存在并且 result是一个servcie endpoint URL:

  • http response status code 一定是 303
  • http response 一定要包含一个location header,header的值一定是output service endpoint URL。

8.2 Example

Given the following DID Resolver HTTP(S) endpoint:

https://uniresolver.io/1.0/identifiers/

And given the following input DID:

did:sov:WRfXPg8dantKVubE3HX8pw

Then the request HTTP(S) URL is:

https://uniresolver.io/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw

The HTTP(S) Binding can be invoked as follows:

EXAMPLE 15: Example curl call to a DID Resolver via HTTP(S) Binding
curl -X GET https://uniresolver.io/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw

9.Errors

10. Security and Privacy Considerations