Internet-Draft The GNS DID Method August 2022
Schanzenbach, et al. Expires 23 February 2023 [Page]
GNUnet Living Standards
Intended Status:
M. Schanzenbach
Fraunhofer AISEC
T. Schwieren
Technische Universität München
T. Bellebaum
Fraunhofer AISEC

The GNU Name System DID Method


This document contains the GNU Name System (GNS) Decentralized Identifier(DID) technical specification.

Status of This Memo

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

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.

Table of Contents

1. Introduction

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.

1.1. Requirements Notation

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.

2. Method name

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.

3. Method-specific identifier

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)
Figure 1: The GNS DID format

For example:

Figure 2: Non-normative examples of GNS-DIDs

4. Method operations

4.1. Create (Register)

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.

4.2. Read (Resolve)

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].

4.3. Update

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.

4.4. Delete (Revoke)

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.

5. Security and Privacy Considerations

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.

6. GANA Considerations

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
Figure 3: The GANA Resource Record Registry Modification.

The DID_DOCUMENT resource record payload wire format consists of a single string representing a DID Document.

7. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Schanzenbach, M., Grothoff, C., and B. Fix, "The GNU Name System", , <>.
Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O., and C. Allen, "Decentralized Identifiers (DIDs)", , <>.
GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)", , <>.

8. Informative References

Authors' Addresses

Martin Schanzenbach
Fraunhofer AISEC
Lichtenbergstrasse 11
85748 Garching
Tristan Schwieren
Technische Universität München
Boltzmannstraße 15
85748 Garching
Thomas Bellebaum
Fraunhofer AISEC
Lichtenbergstrasse 11
85748 Garching