BSV TypeScript Stack Merges Identity Adapters Alongside BRC-200–203

Identity Infrastructure Watch / Developer Tools

In Brief

Four identity-related specifications—BRC-200 through BRC-203—were merged into the BSV Blockchain BRC repository on October 1.

The same day, the BSV TypeScript Stack merged a related implementation covering identity-key identifiers and a signature-preserving adapter for encrypted certificates.

Together, the changes address how applications identify keys, verify certificate evidence, and evaluate the practices of certificate issuers. The implementation milestone is a source-code merge; package publication, production deployment, and complete release qualification remain separate.

News Report

The four specifications, submitted by contributor ty-everett on September 30, have moved from open proposals into the BRC repository.

Their subjects are closely related but distinct: operating practices for identity certifiers, issuance rules for social-account certificates, decentralized identifiers derived from identity keys, and a credential profile that preserves existing certificate signatures.

Identity Keys Become Offline-Resolvable Identifiers

BRC-202 defines a way to represent an identity public key as a decentralized identifier using the did method.

The identifier represents the key itself. It can be resolved into a defined DID document without asking a hosted service to supply a mutable identity record.

The specification distinguishes that key identity from certificate serial numbers, names, and answers returned by hosted resolvers. It also describes verification relationships and limits around rotation and recovery.

The approach does not require exporting a root private key or changing wallet methods. Nor does it turn a certificate signed with a derived key into a signature made directly by the root key.

Preserving the Evidence Behind a Credential

BRC-203 addresses how encrypted BRC-52 certificates can be represented for credential interoperability while retaining their original cryptographic evidence.

An existing certificate signature authenticates particular encrypted bytes. Copying information into another credential structure does not automatically give that new structure the same authority.

The profile therefore preserves the original signed representation and defines how verifiers relate it to the credential they receive. It also specifies recipient-scoped disclosure and explicit handling of certificate status.

This remains a custom mechanism. Its merger into the BRC repository does not establish W3C registration, acceptance by generic credential verifiers, or complete interoperability with external systems.

The specification also identifies further work on independent implementations, status adapters, and conformance.

Issuer Practices and Social-Account Evidence

BRC-200 addresses the operational responsibilities surrounding certificate cryptography.

It covers evidence checks, authorization by the subject, protection of issuer keys, revocation, incident handling, and continuity. Versioned public policies and user-selected trust form part of the model.

These practices help distinguish a correctly signed certificate from a certificate issued through a process that a relying application considers trustworthy.

BRC-201 applies more specific rules to certificates associated with Email, X, and Discord accounts. It records the existing certificate types and defines checks connecting the evidence, certificate fields, and subject.

It also separates private issuance from consent to publish and makes freshness limitations explicit. Possessing an account certificate does not, by itself, establish that the holder still controls that account indefinitely.

Repository acceptance does not establish that existing certifier services already conform to these requirements.

Implementation and Migration

The related TypeScript Stack change, pull request #716, replaces older DID and credential-wrapper paths with offline identity-key resolution and an optional BRC-52 adapter.

It removes obsolete DID overlay/client components and supplies migration guidance. Existing serial-based identifiers must not simply be relabeled as identity-key DIDs. The change does not delete persisted or on-chain user data.

The pull request reports focused verification but also records inherited CI and dependency-check failures and incomplete full release qualification. Package publication, production deployment, and implementation of SocialCert features were outside its scope.

Developers should therefore distinguish the merged source from a fully qualified release.

BSV TIMES Read

Identity infrastructure needs clear answers to several separate questions: which key is being identified, what evidence was signed, which information may be disclosed, and why an application should trust the issuer.

The four specifications give those questions distinct technical and operational treatment. The accompanying implementation provides a concrete development step toward applying part of that model.

For applications, the potential value is more consistent handling of identity and certificate evidence across services. Real interoperability will depend on implementations following the same rules, completing qualification, and demonstrating that they work together under actual operating conditions.

Developer context

Ty Everett

His earlier BRC work includes:

BRC-26 — Universal Hash Resolution Protocol
BRC-29 — Simple Authenticated BSV P2PKH Payment Protocol
BRC-42 — BSV Key Derivation Scheme (BKDS)
BRC-73 — Group Permissions for App Access
BRC-100 — Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface, coauthored with Tone Engel and Brayden Langley

Source Links

Posted on October 2, 2026