draft-schanzen-didgns.xml (15761B)
1 <?xml version='1.0' encoding='utf-8'?> 2 <!DOCTYPE rfc [ 3 <!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> 4 <!ENTITY RFC8174 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> 5 <!ENTITY RFC9106 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9106.xml"> 6 ]> 7 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 8 <?rfc strict="yes" ?> 9 <?rfc toc="yes" ?> 10 <?rfc symrefs="yes"?> 11 <?rfc sortrefs="yes" ?> 12 <?rfc compact="yes" ?> 13 <?rfc subcompact="no" ?> 14 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-21" ipr="*trust200902" obsoletes="" updates="" submissionType="independent" xml:lang="en" version="3"> 15 <!-- xml2rfc v2v3 conversion 2.26.0 --> 16 <front> 17 <title abbrev="The GNS DID Method"> 18 The GNU Name System DID Method 19 </title> 20 <seriesInfo name="Internet-Draft" value="draft-schanzen-didgns-00"/> 21 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> 22 <organization>Fraunhofer AISEC</organization> 23 <address> 24 <postal> 25 <street>Lichtenbergstrasse 11</street> 26 <city>Garching</city> 27 <code>85748</code> 28 <country>DE</country> 29 </postal> 30 <email>martin.schanzenbach@aisec.fraunhofer.de</email> 31 </address> 32 </author> 33 <author fullname="Tristan Schwieren" initials="T." surname="Schwieren"> 34 <organization>Technische Universität München</organization> 35 <address> 36 <postal> 37 <street>Boltzmannstraße 15</street> 38 <city>Garching</city> 39 <code>85748</code> 40 <country>DE</country> 41 </postal> 42 <email>tristan.schwieren@tum.de</email> 43 </address> 44 </author> 45 <author fullname="Thomas Bellebaum" initials="T." surname="Bellebaum"> 46 <organization>Fraunhofer AISEC</organization> 47 <address> 48 <postal> 49 <street>Lichtenbergstrasse 11</street> 50 <city>Garching</city> 51 <code>85748</code> 52 <country>DE</country> 53 </postal> 54 <email>thomas.bellebaum@aisec.fraunhofer.de</email> 55 </address> 56 </author> 57 58 <!-- Meta-data Declarations --> 59 <area>General</area> 60 <workgroup>GNUnet Living Standards</workgroup> 61 <keyword>name systems</keyword> 62 <abstract> 63 <t> 64 This document contains the GNU Name System (GNS) Decentralized Identifier(DID) 65 technical specification. 66 </t> 67 </abstract> 68 </front> 69 <middle> 70 <section> 71 <name>Introduction</name> 72 <t> 73 GNS is a decentralized, censorship-resistant name system <xref target="I-D.draft-schanzen-gns"/>. 74 It allows users to register zones and resolve the names of other users 75 in a petname-like manner. 76 GNS is a suitable mechanism for a DID Document registry and DID method 77 identifier due to it's inherent suitability as a public-key infrastructure. 78 </t> 79 <section numbered="true" toc="default"> 80 <name>Requirements Notation</name> 81 <t> 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in 85 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only 86 when, they appear in all capitals, as shown here. 87 </t> 88 </section> 89 </section> 90 <section> 91 <name>Method name</name> 92 <t> 93 The namestring that shall identify this DID method is "gns". 94 A DID that uses this method MUST begin with the prefix "did:gns:". 95 Per <xref target="W3C.did-core"/>, this string MUST be in lowercase. 96 The remainder of the DID, after the prefix, is specified below. 97 </t> 98 </section> 99 <section> 100 <name>Method-specific identifier</name> 101 <t> 102 Each identity in GNS has a single public-private zone key pair. 103 An ego should not be confused with a user. A user can have multiple egos. 104 The GNS DID method utilizes the GNU Name System (GNS) and its zone key. 105 It allows us to store a DID document in a GNS zone. 106 </t> 107 <t> 108 The method-specific identifier is the public zone key <tt>zk</tt> of an 109 identity, Base32GNS-encoded as defined in Appendix C of 110 <xref target="I-D.draft-schanzen-gns"/>. GNS DIDs are considered equal 111 if their method-specific identifiers decode to the same symbols. 112 </t> 113 <figure anchor="figure_did" title="The GNS DID format"> 114 <artwork name="" type="" align="left" alt=""><![CDATA[ 115 gns-did = "did:gns:" ego-pubkey 116 ego-pubkey = Base32GNS(zk) 117 ]]></artwork> 118 </figure> 119 <t> 120 For example: 121 </t> 122 <figure anchor="figure_did_ex" title="Non-normative examples of GNS-DIDs"> 123 <artwork name="" type="" align="left" alt=""><![CDATA[ 124 did:gns:000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884 125 did:gns:000G057G3NM5FCGEDF35DBE6Y1R7QEFF7GJA9KXVK9KMT336XWKBY1M2XC 126 ]]></artwork> 127 </figure> 128 </section> 129 <section> 130 <name>Method operations</name> 131 <section> 132 <name>Create (Register)</name> 133 <t> 134 In order to create and register a new GNS DID, a new GNS zone key 135 must be created as defined in Section 4 of <xref target="I-D.draft-schanzen-gns"/>. 136 The zone can then be populated with an DID Document. 137 DID Documents are stored as records of type <tt>DID_DOCUMENT</tt>. 138 DID Document records are published under the Apex Label. 139 Record expiration must be chosen carefully in order to facilitate 140 deletion (revocation) and updates of the DID Document and depends on 141 the use case and user preference. 142 </t> 143 </section> 144 <section> 145 <name>Read (Resolve)</name> 146 <t> 147 In order to resolve a GNS DID, the public zone key is extracted 148 from the the DID as the Base32GNS-decoded value of the method-specific 149 identifier. Note that the decoding procedure of Base32GNS decodes 150 several characters to the same symbol, thereby implicitly adding 151 normalization to GNS DIDs. 152 The zone key is used in combination with the Apex Label in order to 153 resolve a resource record of type <tt>DID_DOCUMENT</tt> as defined in 154 Section 7 of <xref target="I-D.draft-schanzen-gns"/>. 155 </t> 156 </section> 157 <section> 158 <name>Update</name> 159 <t> 160 In order to update the DID Document of a GNS DID, the resource record 161 data of the DID is updated. 162 The updated DID Document will be available through GNS as soonn as 163 the old records expire in GNS or the updated records are disseminated 164 through the network. 165 </t> 166 </section> 167 <section> 168 <name>Delete (Revoke)</name> 169 <t> 170 In order to revoke a DID, the registered DID Document resource record 171 is removed from the zone and no longer published. 172 It will cease to be available as soon as it reaches its expiration 173 date. 174 In this case, the DID may be "revived" at a later point in time 175 should the zone owner choose to do so. 176 </t> 177 <t> 178 Alternatively, the zone itself may be revoked according to Section 4.2 179 of <xref target="I-D.draft-schanzen-gns"/>. 180 However, this also prevents any future use of the zone keys. 181 </t> 182 <t> 183 For temporary deletion of a DID, the depublication of the resource 184 record is recommended. 185 For revocation of a DID, the zone revocation mechanism in GNS 186 is recommended. 187 </t> 188 </section> 189 </section> 190 <section anchor="security"> 191 <name>Security and Privacy Considerations</name> 192 <!-- The Security Considerations section MUST document the following forms of attack for the DID 193 operations defined in the DID method specification: eavesdropping, replay, message insertion, 194 deletion, modification, denial of service, amplification, and man-in-the-middle. Other known 195 forms of attack SHOULD also be documented.--> 196 <t> 197 Record data in GNS is encrypted and signed using the private key which 198 corresponds to the public key in the DID. 199 This ensures that no message insertion or modification is possible and 200 authenticity of the DID Documents is ensured. 201 Only compromised private key material is a threat to the integrity 202 and authenticity of the DID. 203 Denial of service attacks are difficult due to the common use of 204 distributed hash tables as part of GNS implementations. 205 </t> 206 <!-- The Security Considerations section MUST discuss residual risks, such as the risks from compromise 207 in a related protocol, incorrect implementation, or cipher after threat mitigation was deployed. --> 208 <t> 209 An incorrect implementation of the digital signature validation algorithm 210 in GNS could make it possible for an attacker to impersonate any other ego. 211 Leakage of the private zone key allows anyone to create or delete DID 212 Documents. 213 GNS itself provides crypto-agility and the possibility of extending the 214 protocol with new cryptographic schemes should the need arise. 215 In such cases, existing identities will need to be revoked and new DIDs 216 created. 217 </t> 218 <!--The Security Considerations section MUST discuss the policy mechanism by which DIDs are proven to 219 be uniquely assigned. --> 220 <t> 221 The DIDs are statistically unique because they consist of a public key 222 corresponding to a GNS zone. 223 The chance for two users to generate the same private key and derive the 224 same public key is negligible. 225 </t> 226 <!--If a protocol incorporates cryptographic protection mechanisms, the DID method specification MUST 227 clearly indicate which portions of the data are protected and by what protections, and it SHOULD 228 give an indication of the sorts of attacks to which the cryptographic protection is susceptible. 229 Some examples are integrity only, and endpoint authentication.--> 230 <t> 231 The GNS DID method uses digital signatures. 232 The security of the DID method depends on the assumption that a user can 233 keep the private zone key secret. 234 Any records containing DID Documents published in GNS are encrypted using 235 a derived symmetric key as defined in Section 5.1 of 236 <xref target="I-D.draft-schanzen-gns"/> and signed using a private key 237 derived from the zone private key. 238 </t> 239 <!-- Data which is to be held secret (keying material, random seeds, and so on) should be clearly labeled.--> 240 <t> 241 The GND DID method never exposes the private zone key. 242 The user can however use and display the DIDs private key locally. 243 </t> 244 <!-- DID method specifications should explain and specify the implementation of signatures on DID documents, 245 if applicable. --> 246 <t> 247 DID documents are not signed directly but instead stored in the apex of 248 GNS zones. 249 Every record in a GNS zone is signed by the zone owner's private key. 250 </t> 251 <!-- Where DID methods use peer-to-peer computing resources, such as with all known DLTs, the expected 252 burdens of those resources SHOULD be discussed in relation to denial of service. --> 253 <t> 254 The underlying storage layer used by the DID method is the GNS. 255 A Distributed Ledger Technology is not used. 256 GNS does need resources such as for relaying messages and storing records. 257 However, a given peer is not required to provide these resources. 258 A peer may use more resources than it provides. 259 </t> 260 <!-- Privacy--> 261 <t> 262 Any given set of two GNS DIDs cannot be correlated. 263 Every DID uses a distinct private-public key pair. 264 The identity's privacy may be compromised if the user decides to use a 265 custom unique DID Document which contains compromising metadata. 266 The user can not be identified through a DID as the DID doesn't contain 267 any identifying information. 268 The user cannot prevent others to share a DID and DID Document as they 269 are essentialy public records. 270 The GNS DID method does not reveal any information that could harm the 271 users reputation. 272 Users only reveal their DID document. However, the user has no control 273 over how others handle that data. 274 </t> 275 </section> 276 <section anchor="gana" numbered="true" toc="default"> 277 <name>GANA Considerations</name> 278 <t> 279 GANA <xref target="GANA" /> 280 manages the "GNU Name System Record Types" registry. 281 </t> 282 <t> 283 GANA is asked to register the record types defined in this 284 specification in the "GNU Name System Record Types" registry 285 as listed in <xref target="figure_rrtypenums"/>. 286 </t> 287 <figure anchor="figure_rrtypenums" title="The GANA Resource Record Registry Modification."> 288 <artwork name="" type="" align="left" alt=""><![CDATA[ 289 Number | Name | Contact | References | Comment 290 -------+---------------+---------+------------+------------- 291 65566 | DID_DOCUMENT | N/A | [This.I-D] | DID Document 292 ]]></artwork> 293 </figure> 294 <t> 295 The <tt>DID_DOCUMENT</tt> resource record payload wire format consists 296 of a single string representing a DID Document. 297 </t> 298 </section> 299 </middle> 300 <back> 301 <references> 302 <name>Normative References</name> 303 304 &RFC2119; 305 &RFC8174; 306 <reference anchor="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/"> 307 <front> 308 <title>The GNU Name System</title> 309 <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach"> 310 <organization>GNUnet e.V.</organization> 311 </author> 312 <author initials="C." surname="Grothoff" fullname="Christian Grothoff"> 313 <organization>GNUnet e.V.</organization> 314 </author> 315 <author initials="B." surname="Fix" fullname="Bernd Fix"> 316 <organization>GNUnet e.V.</organization> 317 </author> 318 <date year="2021"/> 319 </front> 320 </reference> 321 <reference anchor="W3C.did-core" target="https://www.w3.org/TR/did-core/"> 322 <front> 323 <title>Decentralized Identifiers (DIDs)</title> 324 <author initials="M." surname="Sporny" fullname="Manu Sporny"> 325 <organization>Digital Bazaar</organization> 326 </author> 327 <author initials="D." surname="Longley" fullname="Dave Longley"> 328 <organization>Digital Bazaar</organization> 329 </author> 330 <author initials="M." surname="Sabadello" fullname="Markus Sabadello"> 331 <organization>Danube Tech</organization> 332 </author> 333 <author initials="D." surname="Reed" fullname="Drummond Reed"> 334 <organization>Evernym/Avast</organization> 335 </author> 336 <author initials="O." surname="Steele" fullname="Orie Steele"> 337 <organization>Transmute</organization> 338 </author> 339 <author initials="C." surname="Allen" fullname="Christopher Allen"> 340 <organization>Blockchain Commons</organization> 341 </author> 342 <date year="2022"/> 343 </front> 344 </reference> 345 <reference anchor="GANA" target="https://gana.gnunet.org/"> 346 <front> 347 <title>GNUnet Assigned Numbers Authority (GANA)</title> 348 <author><organization>GNUnet e.V.</organization> 349 </author> 350 <date month="April" year="2020" /> 351 </front> 352 </reference> 353 354 355 </references> 356 <references> 357 <name>Informative References</name> 358 </references> 359 </back> 360 </rfc>