Making DAPs more Decentralized

[decentralgabe]

I want to start by saying I'm a supporter of DAPs. Naming has been a problem in the payments, crypto, and decentralized identity community for a while. For DAPs to succeed, and differentiate themselves from prior solutions, they need to be decentralized--this isn't controversial since it's in the name. I believe that DAPs don't live up to their name today. This is OK, it's early days 😄.

That said -- with this issue I aim to outline a number of issues and corresponding recommendations to align the DAP spec more closely with principles of decentralization, making it more resilient, and secure. This list is not exhaustive, but it should be a good starting place for analyzing the decentralizedness of DAPs.

In no particular order of importance...

1. Multi-Registry Redundancy

The current single-registry model introduces a central point of failure, and centralization risk--decentralization is a measure of how many people can tell you "no." With the current design that answer is "one organization."

Recommendation:
Register DAPs across multiple redundant registries from different providers. For example, @name/test.app could be replicated across @name/terst.app, @name/toost.app with consistent values.

Considerations:

• Develop mechanisms for cross-checking consistency and error detection across registries
• Implement a key transparency-like approach for synchronization across registries
• Use cryptographic proofs (such as Merkle trees) to ensure DAP records are authentic, consistent, and in sync

Multi-registry redundancy provides resilience against failures or censorship risk, reduces lock-in, and improves portability. DAPs without redundancy cannot be considered decentralized.

2. Decentralized Root Registry

There's a need for a robust, decentralized registry mechanism that doesn't rely solely on centralized systems like businesses (Cash App) or domain registrars (DNS).

Recommendation:
Implement a decentralized "root" registry using one of the following approaches:

1. Distributed Hash Table (DHT) with a reputation system based on verifiable hashes (similar to this)
2. Blockchain-based solution (i.e. integration with ENS, Handshake, or other similar naming initiatives)

The root registry would serve as the authoritative source for a user's identity, with other registries acting as pointers or replicas. A decentralized root registry = an authoritative source of truth without relying solely on centralized providers.

3. Single DAP as the Default Model

The current design may lead to users having multiple DAPs when interacting with different providers, potentially causing fragmentation and undermine the purpose of a unified, self-sovereign identity that's human-friendly (see #39).

Recommendation:
Promote a model where users maintain a single primary DAP that points to multiple payment addresses. While supporting multiple DAPs for specific use cases (privacy, personas), the default should be "one true identity" for payments.

A single, primary DAP per user simplifies the user experience, strengthens the concept of a unified digital identity for payments, and aligns with SSI principles. Users can maintain a consistent identity across multiple services without the need for multiple DAPs == a selling point.

4. DNS Agnosticism

The @local-handle/domain structure implies a reliance on traditional DNS, introducing centralization risks. DNS-based systems are vulnerable to control and censorship issues.

Recommendation:
Make the DAP system completely agnostic to DNS, capable of accommodating multiple name resolution systems such as GNS, ENS, Handshake, or others. Providing a base level of decentralization is important.

The 'default' can still be DNS based, and coupled with the other aforementioned proposals, is less of an issue. For those wishing to avoid replication, they can go direct to an avenue they already view as sufficient for their needs (like existing ENS or UMA).

5. Integrity Protection for DAP Records

Relying on any single provider for hosting the DAP introduces risks of tampering or malicious redirection. Current DID signatures alone are not sufficient to guarantee that the DAP has not been tampered with.

Recommendation:
Implement robust integrity protection mechanisms:

• A KT approach to guarantee that records haven’t been modified
• Cryptographic consistency checks using Merkle trees/other verifiable data structures
• Optionally, a blockchain-based timestamping / audit system for additional security
• Tie in trusted Verifiable Credentials/Presentations that go along with DAPs/DIDs. More proofs of DAP = higher trust. Consider DAP assurance levels.

Strong integrity protection ensures that DAP records remain tamper-evident and verifiable, crucial for maintaining trust in the system.

6. Decentralized DID Methods

The use of did:web introduces unnecessary centralization and vulnerability to domain control or censorship (there are a ton of articles and real-world examples about the risks of relying solely on domain names, if you need sources let me know).

Recommendation:
Prioritize more decentralized DID methods such as did:dht, did:jwk, or even an enhanced did:web-type method like did:tdw. Add explicit language about choice/tradeoffs in DID method.

Using decentralized DID methods reduces dependencies on centralized infrastructure and aligns better with the overall goals of a decentralized system. Having multiple centralization points introduces signifacntly more room for failure (a central registry on top of a did:web, for example).

7. Data Authentication in Services

Data pointed to by a DAP must be authenticated to prevent tampering and malicious modifications.

Recommendation:
Implement auth and verification mechanisms for all data within the DAP ecosystem:

• Use signatures for all data interactions
• Implement privacy-preserving proofs (like SD-JWT or limited-disclosure presentations) where possible

Verifiability as a base construct can ensure that data stored in services remains tamper-evident and trusted.

8. Simplify Data Representation

The use of JSON Canonicalization Scheme (JCS) adds unnecessary complexity and can lead to security issues.

Canonicalization introduces unnecessary complexity, risks, and performance hits. Deterministic encoding methods like CBOR offer simpler, more secure/efficient solutions for ensuring data consistency without transformations.

When we don't require full serialization, simpler approaches like predefined sorting rules or hash-then-sign methods can achieve necessary consistency without canonicalization's drawbacks.

Replace JCS with simpler and more efficient solutions:

• Use plain JWTs without canonicalization (widely adopted without issue)
• Use CBOR / a custom CBOR scheme if necessary
• If determinism is required, use something like Common Deterministic Encoding (CDE) with CBOR, but determinism should only be applied when necessary to avoid introducing complexity.

Final Thoughts

Looking forward to discussing and hearing what you think 😄 .