RA Decentralized IDentification (DID) Service - Java

Implementing Web Of Trust with Self Sovereign Identity.

W3C DID interoperability is kept as a guideline. RA will not register its own DID method — see ../DESIGN.md §5, which produces a did:nostr view of the key instead.

Uses Key Ring Service to Manage the Physical Persistence, Generation, Encryption, Decryption, Revocation, and Destruction of Keys

Status

The identity layer is Nostr-compatible secp256k1 / BIP-340 (ra.did.nostr): 32-byte secret, x-only public key, hex / npub / nsec / did:nostr encodings, canonical Nostr-event signing, attestations (vouch), guardian-based recovery and rotation, NIP-44 v2 encrypted payloads (Nip44: ECDH → HKDF-SHA256 → per-message ChaCha20 + HMAC-SHA256, verified against the spec's own official test vectors — see Nip44VectorsTest), and secrets sealed at rest (Argon2id + AES-256-GCM). It passes the shared did-vectors conformance suite. 1m5-core-java's IdentityService derives the node identity through this module.

The legacy OpenPGP keyring (ra.did.openpgp) is kept as a self-contained encrypt / decrypt / sign / verify subsystem for any stray OpenPGP material, but it is no longer an identity path.

The rationale and the spec are one level up:

• ../STRATEGY.md — why identity adoption keeps failing and the plan: ride Nostr rather than bootstrap a network, own the gap it still has (key recovery and attestation), ship a specification and a small library before a product.
• ../DESIGN.md — the technical specification: secp256k1 / BIP-340 Schnorr identities, Nostr-compatible signed records, attestations as a decentralized replacement for NIP-05, guardian-based recovery and rotation, and a did:nostr compatibility view. §7.3 covers this module specifically.

RA does not register its own DID method (a did:nostr community draft already exists), and relays are an opt-in distribution option, not the architecture — signed records are transport-agnostic.

The sections below still describe the OpenPGP keyring mechanics.

Abstract (from W3C)

Decentralized identifiers (DIDs) are a new type of identifier to provide verifiable, decentralized digital identity. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to a DID document allowing trustable interactions with that subject. DID documents are simple documents describing how to use that specific DID. Each DID document can express cryptographic material, verification methods, or service endpoints, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Service endpoints enable trusted interactions with the DID subject.

Bill of Rights

From https://github.com/WebOfTrustInfo/self-sovereign-identity/blob/master/self-sovereign-identity-bill-of-rights.md and how we plan on supporting them.

Individuals must be able to establish their existence as a unified identity online and in the physical world

A unified identity requires that people not only have an online presence, but that presence must function seamlessly across both online and real-world environments. One unified identity for all spheres of life.

One unified identity can come about through individual projects by supporting common standards. RA DID will only use standard algorithms well supported globally and any standard interfaces that become widely adopted so long as those interfaces come from open source and free efforts.

• AES symmetric keys for encrypting identity keys and as session keys
• SHA256 hashing for signatures and other integrity verifications
• ElGamal for asymmetric keys
• Multiple identities per person are supported to take into consideration different aspects of life

Individuals must have the tools to access and control their identities

Self-sovereign identity holders must be able to easily retrieve identity attributes and verified claims as well as any metadata that has been generated in the process of transactions. There can be no personally identifiable information (PII) data that is hidden from the identity holder. This includes management, updating or changing identity attributes, and keeping private what they choose.

• Service interfaces for managing identities that can be called by user interface based applications.
• Identity Keys lost can be recovered through verification with an established reputation via friends and family.

The platforms and protocols on which self-sovereign identities are built, must be open and transparent

This refers to how the platforms and protocols are governed, including how they are managed and updated. They should be open-source, well-known, and as independent as possible of any particular architecture; anyone should be able to examine how they work.

• All code in this project is open source, dedicated to the public domain (CC0 1.0).

Users must have the right to participate in the governance of their identity infrastructure

The platform, protocols on which self-sovereign identities are built, must be governed by identity holders. By definition, if the platform is governed by a private entity or limited set of participants, the Identity holder is not in control of the future of their identity.

Identities must exist for the life of the identity holder

While the platform and protocols evolve, each singular identity must remain intact. This must not contradict a "right to be forgotten"; a user should be able to dispose of an identity if he or she wishes and claims should be modified or removed as appropriate over time. To do this requires a firm separation between an identity and its claims: they can't be tied forever.

• All keys and the data they have access to can be deleted from the system at any time.
• Any recurring data access to another party can be immediately canceled at any time.

Identities must be portable

Identity attributes and verified claims must be controlled personally and be transportable and interoperable as desired. Government entities, companies and other individuals can come and go. So it is essential that identity holders can move their identity data to other platforms to ensure that they alone control their identity.

• Using common standards today and as the industry evolves while ensuring keys can be imported, exported, and mapped to new technologies as they evolve.

Identities must be interoperable

Identity holders must be able to use their identities in all facets of their lives. So any identity platform or protocol must function across geographical, political and commercial jurisdictions. Identities should be as widely usable as possible. Ultimately, identities are of little value if they only work in niches.

• Common interfaces will be supported so long as they do not violate free and open source systems.

Individuals must consent to the use of their identity

The point of having an identity is that you can use it to participate in mutually beneficial transactions — whether personal or commercial. This requires that some amount of personal information needs to be shared. However, any sharing of personal data must require the absolute consent of the user — even if third parties have a record of previously verified claims. For every transaction associate with a claim, the identity holder must deliberately consent to its use.

• Only public keys can be given out.
• If a 'power of attorney' type action is desired (such as for the elderly), it can be set up to support that without giving away private keys. (Expected in future development).

Disclosure of verified claims must be minimized

For every transaction, only the minimum amount of personally identifiable information should be required and shared. If an identity holder wants to enable an age-related commercial transaction, e.g. buy alcohol, the only verified claim that needs to be share is whether they are over 21. There is not need to share actual age, street address, height, weight, etc.

The rights of identity holders must supersede any other platform or ecosystem entities

If a conflict arises between the needs of the platform or entities engaging with identity holders, the governance must be designed to err on the side of preserving these rights for identity holder over the needs of the protocols, platform or network. To ensure this, identity authentication must be decentralized, independent, and free of censorship.

Design Goals

We share design goals from the W3C spec:

Goal	Description
Decentralization	DID architecture should eliminate the requirement for centralized authorities or single points of failure in identifier management, including the registration of globally unique identifiers, public verification keys, service endpoints, and other metadata.
Self‑Sovereignty	DID architecture should give entities, both human and non-human, the power to directly own and control their digital identifiers without the need to rely on external authorities.
Privacy	DID architecture should enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data.
Security	DID architecture should enable sufficient security for relying parties to depend on DID Documents for their required level of assurance.
Proof-based	DID architecture should enable the DID subject to provide cryptographic proof of authentication and proof of authorization rights.
Discoverability	DID architecture should make it possible for entities to discover DIDs for other entities to learn more about or interact with those entities.
Interoperability	DID architecture should use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability.
Portability	DID architecture should be system and network-independent and enable entities to use their digital identifiers with any system that supports DIDs and DID Methods.
Simplicity	To meet these design goals, DID architecture should be (to paraphrase Albert Einstein) "as simple as possible but no simpler".
Extensibility	When possible, DID architecture should enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity.

Features and Roadmap

The DID Service is being implemented as individual projects needs arise.

SHA-1 is used throughout while still in testing mode. Will move to SHA-256 prior to production release.

TBD

• Moving key handling off OpenPGP key rings onto secp256k1 / BIP-340 Schnorr keys and signed attestations — specified in ../DESIGN.md; §7.3 lists the changes landing in this module.
• Adding Reputation support for signers signing attributes of signees. Note ../DESIGN.md §3.5 treats trust scoring as a client concern, so this may become an attestation query rather than a Reputation class.

1.2

• Converging with KeyRingService.
• Beginning of YubiKey integration.

1.1

• Symmetric Encryption/Decryption

1.0

• OpenPGP Key Rings Collections Generation, Key Rings Creation/Deletion, Encryption, Decryption, Signing, Verify Signatures.
• Keys persisted locally.

License

Public domain, via CC0 1.0 Universal — see LICENSE. (Formerly GPLv3, then MIT; now public domain along with the rest of the DID work.)