| Internet-Draft | The GNS DID Method | August 2022 |
| Schanzenbach, et al. | Expires 23 February 2023 | [Page] |
This document contains the GNU Name System (GNS) Decentralized Identifier(DID) technical specification.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 February 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
GNS is a decentralized, censorship-resistant name system [I-D.draft-schanzen-gns]. It allows users to register zones and resolve the names of other users in a petname-like manner. GNS is a suitable mechanism for a DID Document registry and DID method identifier due to it's inherent suitability as a public-key infrastructure.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The namestring that shall identify this DID method is "gns". A DID that uses this method MUST begin with the prefix "did:gns:". Per [W3C.did-core], this string MUST be in lowercase. The remainder of the DID, after the prefix, is specified below.¶
Each identity in GNS has a single public-private zone key pair. An ego should not be confused with a user. A user can have multiple egos. The GNS DID method utilizes the GNU Name System (GNS) and its zone key. It allows us to store a DID document in a GNS zone.¶
The method-specific identifier is the public zone key zk of an
identity, Base32GNS-encoded as defined in Appendix C of
[I-D.draft-schanzen-gns]. GNS DIDs are considered equal
if their method-specific identifiers decode to the same symbols.¶
gns-did = "did:gns:" ego-pubkey ego-pubkey = Base32GNS(zk)
For example:¶
did:gns:000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884 did:gns:000G057G3NM5FCGEDF35DBE6Y1R7QEFF7GJA9KXVK9KMT336XWKBY1M2XC
In order to create and register a new GNS DID, a new GNS zone key
must be created as defined in Section 4 of [I-D.draft-schanzen-gns].
The zone can then be populated with an DID Document.
DID Documents are stored as records of type DID_DOCUMENT.
DID Document records are published under the Apex Label.
Record expiration must be chosen carefully in order to facilitate
deletion (revocation) and updates of the DID Document and depends on
the use case and user preference.¶
In order to resolve a GNS DID, the public zone key is extracted
from the the DID as the Base32GNS-decoded value of the method-specific
identifier. Note that the decoding procedure of Base32GNS decodes
several characters to the same symbol, thereby implicitly adding
normalization to GNS DIDs.
The zone key is used in combination with the Apex Label in order to
resolve a resource record of type DID_DOCUMENT as defined in
Section 7 of [I-D.draft-schanzen-gns].¶
In order to update the DID Document of a GNS DID, the resource record data of the DID is updated. The updated DID Document will be available through GNS as soonn as the old records expire in GNS or the updated records are disseminated through the network.¶
In order to revoke a DID, the registered DID Document resource record is removed from the zone and no longer published. It will cease to be available as soon as it reaches its expiration date. In this case, the DID may be "revived" at a later point in time should the zone owner choose to do so.¶
Alternatively, the zone itself may be revoked according to Section 4.2 of [I-D.draft-schanzen-gns]. However, this also prevents any future use of the zone keys.¶
For temporary deletion of a DID, the depublication of the resource record is recommended. For revocation of a DID, the zone revocation mechanism in GNS is recommended.¶
Record data in GNS is encrypted and signed using the private key which corresponds to the public key in the DID. This ensures that no message insertion or modification is possible and authenticity of the DID Documents is ensured. Only compromised private key material is a threat to the integrity and authenticity of the DID. Denial of service attacks are difficult due to the common use of distributed hash tables as part of GNS implementations.¶
An incorrect implementation of the digital signature validation algorithm in GNS could make it possible for an attacker to impersonate any other ego. Leakage of the private zone key allows anyone to create or delete DID Documents. GNS itself provides crypto-agility and the possibility of extending the protocol with new cryptographic schemes should the need arise. In such cases, existing identities will need to be revoked and new DIDs created.¶
The DIDs are statistically unique because they consist of a public key corresponding to a GNS zone. The chance for two users to generate the same private key and derive the same public key is negligible.¶
The GNS DID method uses digital signatures. The security of the DID method depends on the assumption that a user can keep the private zone key secret. Any records containing DID Documents published in GNS are encrypted using a derived symmetric key as defined in Section 5.1 of [I-D.draft-schanzen-gns] and signed using a private key derived from the zone private key.¶
The GND DID method never exposes the private zone key. The user can however use and display the DIDs private key locally.¶
DID documents are not signed directly but instead stored in the apex of GNS zones. Every record in a GNS zone is signed by the zone owner's private key.¶
The underlying storage layer used by the DID method is the GNS. A Distributed Ledger Technology is not used. GNS does need resources such as for relaying messages and storing records. However, a given peer is not required to provide these resources. A peer may use more resources than it provides.¶
Any given set of two GNS DIDs cannot be correlated. Every DID uses a distinct private-public key pair. The identity's privacy may be compromised if the user decides to use a custom unique DID Document which contains compromising metadata. The user can not be identified through a DID as the DID doesn't contain any identifying information. The user cannot prevent others to share a DID and DID Document as they are essentialy public records. The GNS DID method does not reveal any information that could harm the users reputation. Users only reveal their DID document. However, the user has no control over how others handle that data.¶
GANA [GANA] manages the "GNU Name System Record Types" registry.¶
GANA is asked to register the record types defined in this specification in the "GNU Name System Record Types" registry as listed in Figure 3.¶
Number | Name | Contact | References | Comment -------+---------------+---------+------------+------------- 65566 | DID_DOCUMENT | N/A | [This.I-D] | DID Document
The DID_DOCUMENT resource record payload wire format consists
of a single string representing a DID Document.¶