idnits 2.17.1 draft-liu-bid-protocol-specification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 10, 2022) is 805 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Y. Liu 2 Internet Draft Z. Li 3 Intended status: Experimental B. Zhang 4 Expires: August 10, 2022 J. Guo 5 China Academy of Information and Communications Technology W. Shi 6 J. Xie 7 February 10, 2022 9 BID Protocol Specification 10 draft-liu-bid-protocol-specification-00 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may not be modified, 16 and derivative works of it may not be created, and it may not be 17 published except as an Internet-Draft. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on July 10, 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. 49 Abstract 51 This document provides an overview of the principles and 52 specifications of the BID (Blockchain-based Identifier) and its 53 relationship with BIF (National Collaborative & Innovative 54 Infrastructure of Blockchain and Industrial Internet) services. BID 55 serves not only as the data carrier of the BIF, but also as the 56 native address of the BIF-core blockchain. BID is also a method 57 added to the distributed identifier DID registry. 59 Table of Contents 61 1. Introduction...................................................2 62 1.1. Conventions Used in This Document.........................3 63 2. BID Identifier.................................................3 64 3. BID Documentation..............................................4 65 4. BID Method.....................................................8 66 4.1. Create....................................................8 67 4.2. Update....................................................8 68 4.3. Read......................................................8 69 4.4. Deactivate................................................8 70 4.5. Recovery..................................................8 71 5. Security Considerations........................................8 72 5.1. Security Consideration....................................8 73 5.2. Privacy Consideration.....................................9 74 6. IANA Considerations............................................9 75 7. References.....................................................9 76 7.1. Normative References......................................9 77 7.2. Informative References....................................9 78 8. Acknowledgments................................................9 80 1. Introduction 82 Decentralized identifiers (DIDs) [W3C-DID] are a new type of 83 identifier that enables verifiable, decentralized digital identity. 84 A DID refers to any subject (e.g., a person, organization, thing, 85 data model, abstract entity, etc.) as determined by the controller 86 of the DID. In contrast to typical, federated identifiers, DIDs have 87 been designed so that they may be decoupled from centralized 88 registries, identity providers, and certificate authorities. 89 Specifically, while other parties might be used to help enable the 90 discovery of information related to a DID, the design enables the 91 controller of a DID to prove control over it without requiring 92 permission from any other party. DIDs are Uniform Resource 93 Identifiers (URIs) that associate a DID subject with a DID document 94 allowing trustable interactions associated with that subject. 96 BID is an exploration of new identification system research 97 conducted by China Academy of Information and Communication 98 Technology (CAICT) according to W3C DIDs specification. Its purpose 99 is to build a set of independent rights controllable, data and 100 privacy security, flexible and easy to use new identification 101 systems. According to the W3C DIDs specification, BID is a new 102 distributed identifier based on blockchain, which is oriented to 103 various entities (people, things, organizations, etc.) and digital 104 objects, and provides Self-Sovereign Identity (SSI) services for 105 people, devices, and virtual objects. It can be used for the owner 106 to prove his control via the BID and the authentication without 107 relying on other external organizations. BID is permanent, globally 108 resolvable, cryptographically verifiable, and decentralized. 109 Compared with traditional domain names and industrial Internet 110 identifiers, it does not rely on centralized institutions, but 111 completes the registration, resolution and distribution of 112 identifier through blockchain. 114 According to the W3C naming conventions, the BID namespace is "bid". 115 DID must be prefixed with "did:bid". According to the DID 116 specification, this string must be lowercase. The remainder of the 117 DID is generated by a specific algorithm. Take a BID identifier: 118 did:bid:efTtY5Gr73N1cdjeKrx4mA3LGRSrLTeR. BID is built on the BIF- 119 core blockchain as the base module, ensuring natural credibility due 120 to the trusted attributes designed into the data model. Each BID 121 identifier corresponds to a DID document, which is a JSON object 122 that stores information about the identifier. 124 1.1. Conventions Used in This Document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 127 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 128 this document are to be interpreted as described in RFC 2119 129 [RFC2119]. 131 2. BID Identifier 133 BID is structured as following: 135 AC code encode 136 ^ ^ 137 | | 138 +--+ | 139 | | | 140 did:did : byo1 : efTtY5Gr73N1cdjeKrx4mA3LGRSrLTeR 141 | | | | | 142 +--+--+ | +--------------+-------------+ 143 | | | 144 v v v 145 prefix encryption postfix 147 A BID is a simple text string consisting of there parts: 1) the 148 "did:bid" URI scheme identifier, 2) AC code, 3) the BID method- 149 specific identifier. 151 The generic BID scheme is a URI scheme conformant with [RFC3986]. 152 The ABNF definition can be found below, which uses the syntax in 153 [RFC5234] and the corresponding definitions for ALPHA and DIGIT. 154 All other rule names not defined in the ABNF below are defined in 155 [RFC3986]. All BIDs MUST conform to the BID Syntax ABNF Rules. 157 The BID Syntax ABNF Rules. 159 = "did:bid:" acsn ":" method-specific-id 161 = 4(alpha / digit) 162 ; Autonomous Consensus System Number 164 < method-specific-id > = (22,42)(alpha / digit) 166 Steps taken to generate BID address is specified as following: 168 1. Generate public-private key pair according to the chosen 169 encryption method. 171 2. Compute hash of public key. 173 3. Obtain length of hash and encode method corresponding to 174 determine the length of required byte array size. Obtain the new 175 byte array after trimming off the trailing bytes. 177 4. Add encode method at the front of the byte array obtained from 178 the previous step. 180 5. Add encryption method at the front of the byte array obtained 181 from the previous step. 183 6. If generated BID is that of the main chain, skip to the next 184 step. Otherwise, add corresponding AC code and ":" at the front of 185 the byte array obtained from the previous step. 187 7. Add "did:bid" at the front of the byte array obtained from the 188 previous step to obtain the complte BID. 190 3. BID Documentation 192 BID documentation follows from that of DID's, and makes some 193 extension. Specified keywords are: 195 - @context: A set of rules that explain JSON-LD documents for 196 interoperability between different DID documents. 198 - version: documentation version 199 - id: documentation BID 201 - publicKey: including 203 * id, publicKey's id 205 * type, encryption method 207 * controller, ownership of publicKey 209 * publicKeyHex, publicKey's hex encode 211 - authentication: BID of a publicKey, revealing the holder of the 212 BID, who retains the control of this BID document. 214 - alsoKnownAs: a set of ID related to BID, including 216 * type, related identifiers' types 218 * id, related identifiers. 220 - extension: optional fields, including 222 * recovery, id of publicKey used to recover control when 223 authentication privateKey is compromised or lost 225 * ttl, Time-To-Live, when resolution service requires usage of 226 buffer 228 * delegateSign, third party signature to publicKey, used for 229 trusted resolution, including 231 signer, id of publicKey 233 signatureValue, signature generated with publicKey's 234 corresponding privateKey 236 * type, property type of BID documentation 238 * attributes, a set of properties, varying according to 239 documentation's own properties 241 when type is of credential, property is verifiable credential 243 signature is generated based on credential's byte array 245 * acsns, optional field, side-chain AC code. BID documentation 246 is the sole type not belonging to credential type. On extra, only 247 BID documentation on main-chain can have this field, encapsulating 248 all of the AC codes. 250 - service: optional field comprising service addresses, including 251 * id, service address' id 253 * type, string representing service type 255 * serviceEndPoint, URI address 257 - created, mandatory field, time of creation 259 - updated, mandatory field, time of last update 261 - proof, optional field, documentation owner's signature on 262 documentation's content, including 264 * creator, creator of proof, id of publicKey 266 * signatureValue, signature on the entire documentation except 267 proof field 269 BID documentation example: 271 { 273 "@context": ["https://www.w3.org/ns/did/v1"], 275 "version": "1.0.0", 277 "id": "did:bid:efnVUgqQFfYeu97ABf6sGm3WFtVXHZB2", 279 "publicKey": [{ 281 "id": "did:bid:efnVUgqQFfYeu97ABf6sGm3WFtVXHZB2#key-1", 283 "type": "Ed25519", 285 "controller": "did:bid:efnVUgqQFfYeu97ABf6sGm3WFtVXHZB2", 287 "publicKeyHex": 288 "b9906e1b50e81501369cc777979f8bcf27bd1917d794fa6d5e320b1ccc4f48bb" 290 }, { 292 "id": "did:bid:efnVUgqQFfYeu97ABf6sGm3WFtVXHZB2#key-2", 294 "type": "Ed25519", 296 "controller": "did:bid:efnVUgqQFfYeu97ABf6sGm3WFtVXHZB2", 298 "publicKeyHex": 299 "31c7fc771eba5b511b7231e9b291835dd4ebde51cc0e757a84464e7582aba652" 301 }], 302 "authentication": ["did:bid:efnVUgqQFfYeu97ABf6sGm3WFtVXHZB2#key- 303 1"], 305 "extension": { 307 "recovery": ["did:bid:efnVUgqQFfYeu97ABf6sGm3WFtVXHZB2#key- 308 2"], 310 "ttl": 86400, 312 "delegateSign ": { 314 "signer": "did:bid:efJgt44mNDewKK1VEN454R17cjso3mSG#key-1", 316 "signatureValue": 317 "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19" 319 }, 321 "type": 206 323 }, 325 "service": [{ 327 "id": "did:bid:ef24NBA7au48UTZrUNRHj2p3bnRzF3YCH#subResolve", 329 "type": "DIDSubResolve", 331 "version": "1.0.0", 333 "serverType": 1, 335 "protocol": 3, 337 "serviceEndpoint": "192.168.1.23", 339 "port": 8080 341 }], 343 "created": "2021-05-10T06:23:38Z", 345 "updated": "2021-05-10T06:23:38Z", 347 "proof": { 349 "creator": "did:bid:efJgt44mNDewKK1VEN454R17cjso3mSG#key-1", 351 "signatureValue": 352 "9E07CD62FE6CE0A843497EBD045C0AE9FD6E1845414D0ED251622C66D9CC927CC21 353 DB9C09DFF628DC042FCBB7D8B2B4901E7DA9774C20065202B76D4B1C15900" 354 } 356 } 358 4. BID Method 360 4.1. Create 362 By creating a socket, a BID documentation creation is achieved, 363 while supporting http POST method. When creating BID documentation, 364 signer inside proof field must be same as authentication field's 365 public key for creation to be considered successful. 367 4.2. Update 369 By updating a socket, a BID documentation update is achieved, while 370 supporting http POST method. update is not authenticated to update 371 authenticate field. When updating BID documentation, signer inside 372 proof field must be same as authentication field's public key for 373 update to be considered successful. 375 4.3. Read 377 Inquire BID documentation according to BID, while supporting http 378 POST method. Return value is JSON string from BID documentation. 380 4.4. Deactivate 382 Deactivate revokes BID documentation, while supporting http POST 383 method. Revoked BID documentation is empty, not deleted. deactivated 384 BID documentation's proof field's signer has to be recovery field's 385 public key. 387 4.5. Recovery 389 Recovery modifies authentication and public key fields in BID 390 documentation, while supporting http POST. Proof field's signer must 391 be recovery field's public key for recovery to be effective. 393 5. Security Considerations 395 5.1. Security Consideration 397 DDOS: BID is based on blockchain, which is difficult for DDOS attack 398 at the first place. 400 Privacy data: in a BID framework, all user-related privacy data is 401 stored locally. Only encrypted hash or string is on the chain, so it 402 can be assumed that de-decryption is not possible. 404 Consensus: two layers of consensus consisting of DPOS and PBFT are 405 used to ensure each replica's stability. 407 5.2. Privacy Consideration 409 All privacy data is stored locally, went through sorting, 410 compression, encoding to ensure privacy. Under preceding measures, 411 privacy data is guranteed not to be compromised. 413 6. IANA Considerations 415 7. References 417 7.1. Normative References 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, DOI 421 10.17487/RFC2119, March 1997, 422 . 424 [W3C-DID] W3C, W3C., "Decentralized Identifiers (DIDs) 425 v1.0",February 2020, . 427 7.2. Informative References 429 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 430 Resource Identifier (URI): Generic Syntax", STD 66, RFC 431 3986, DOI 10.17487/RFC3986, January 2005, 432 . 434 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 435 Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 436 10.17487/RFC5234, January 2008, 437 . 439 8. Acknowledgments 441 This document is based on an identifier application of DIDs, the 442 author would like to thank J. Xie who suggested improvements and 443 provided many invaluable comments. This document are individual 444 submissions, based on the work done in RFC 7553. 445 This document was prepared using 2-Word-v2.0.template.dot. 447 Authors' Addresses 449 Yuanchao Liu 450 CAICT 451 No.52 Huayuan North Road, Haidian District 453 Phone: +86 188 0011 6727 454 Email: liuyuanchao@caict.ac.cn 456 Zhiping Li 457 CAICT 458 No.52 Huayuan North Road, Haidian District 460 Phone: +86 185 1107 1386 461 Email: lizhiping@caict.ac.cn 463 Bo Zhang 464 CAICT 465 No.52 Huayuan North Road, Haidian District 467 Phone: +86 153 8346 0204 468 Email: zhangbo3@caict.ac.cn 470 Jian Guo 471 CAICT 472 No.52 Huayuan North Road, Haidian District 474 Phone: +86 189 4004 7983 475 Email: guojian@caict.ac.cn 477 Weijun Shi 478 CAICT 479 No.52 Huayuan North Road, Haidian District 481 Phone: +86 131 1607 3615 482 Email: 1525109982@qq.com 484 Jiagui Xie 485 CAICT 486 No.52 Huayuan North Road, Haidian District 488 Phone: +86 150 0138 5070 489 Email: xiejiagui@caict.ac.cn