Wallets & Identity

Two new BRC proposals are exploring how BSV identity keys and encrypted certificates could become easier to use across broader digital-identity systems without discarding the cryptographic structure they already rely on.

Proposed BRC-202 defines a standardized did:key representation for BSV identity keys.

Proposed BRC-203 builds on that idea by defining a way to present BRC-52 encrypted identity certificates through a verifiable-credential structure while preserving the original BRC-52 signature, selective-disclosure model and status semantics.

Both proposals were submitted on September 30 and remain open for review.

They do not yet establish deployed interoperability, production support or completed W3C conformance.

What they attempt to address is a quieter but increasingly important identity problem:

how can existing BSV identity material travel into wider standards-based systems without pretending it was created in a different format from the one that was actually signed?

Proposed by

Ty Everett

Other notable BRC work includes:

• BRC-26 — Universal Hash Resolution Protocol
• BRC-29 — Simple Authenticated BSV P2PKH Payment Protocol
• BRC-42 — BSV Key Derivation Scheme
• BRC-73 — Group Permissions for App Access
• BRC-100 — Unified Wallet-to-Application Interface, coauthored with Tone Engel and Brayden Langley

BRC-202 gives a BSV identity key a portable DID representation

BRC-202 focuses first on the identity key itself.

BSV wallet and certificate systems already use secp256k1 public keys as cryptographic identities.

The proposal defines a reversible way to represent one of those keys as a did:key identifier.

That means the DID does not point to a hosted profile or require a separate resolver service to discover the underlying key.

The identifier itself contains enough information to recover the public key.

A verifier can therefore resolve the DID offline and deterministically reconstruct the associated DID document.

That distinction is useful because identity systems often need a stable identifier that can move between applications without depending on one vendor’s database or web endpoint.

The proposed representation does not create a new BSV key.

It gives an existing identity key a standard external form.

The proposal is also careful about scope.

A did:key representing a BSV identity key does not automatically provide key rotation, account recovery or organizational authority.

It simply identifies the cryptographic key.

Other systems still need to determine what that key is authorized to represent and how lifecycle changes are handled.

The proposal separates key identity from certificate identity

That may sound obvious, but it addresses a real source of confusion.

A certificate serial number is not the same thing as the identity key of the certificate subject.

A human-readable name is not the identity key.

A hosted resolver response is not the identity key.

BRC-202 attempts to make the underlying key identity unambiguous.

The proposal defines how a compressed secp256k1 public key is encoded into the DID representation and how a conforming verifier reconstructs the expected verification relationships from it.

Because the transformation is deterministic, two independent implementations receiving the same BSV identity key should derive the same did:key representation.

That gives applications a potential bridge between native BSV identity architecture and software that already understands DID-style identifiers.

BRC-203 tackles the harder credential problem

Representing the key is only one part of interoperability.

Credentials are more complicated because they already have signatures, encryption rules, selective-disclosure behavior and status mechanisms.

BRC-52 certificates are designed around encrypted fields.

A certifier signs the encrypted certificate structure, while the holder can later reveal selected fields to a specific verifier through a verifier-specific keyring.

That allows the holder to prove particular certified information without disclosing every field in the certificate. GitHub

The obvious interoperability shortcut would be to decrypt selected fields, place them into a familiar verifiable-credential JSON structure and present that object externally.

BRC-203 explicitly rejects treating that wrapper as though it were what the original certifier signed.

The certifier signed the BRC-52 certificate bytes.

It did not sign an independently reconstructed credential document created later.

Preserve the original signature rather than inventing a new one

BRC-203 therefore attempts to preserve the original authenticated material inside the interoperability profile.

The proposal carries the original certificate signature and the exact signed representation into a deterministic credential structure.

A verifier can then check the original BRC-52 signature rather than relying on a newly created wrapper whose relationship to the issuer’s actual signature may be unclear.

This is an important integrity boundary.

Changing presentation format should not silently change the meaning of what was signed.

The credential representation becomes an adapter around the existing certificate rather than a replacement for the certificate’s cryptographic evidence.

Selective disclosure remains part of the model

The same principle applies to privacy.

BRC-52 certificates do not require every verifier to receive every certified field.

The holder can reveal selected fields by re-encrypting the appropriate field-revelation keys for the verifier.

BRC-203 attempts to preserve that behavior inside the verifiable-credential profile.

The holder can therefore present only the fields needed for a particular interaction while the unrevealed fields remain encrypted.

That is different from creating a new plaintext credential containing all certified attributes.

The original selective-disclosure structure remains part of the evidence being carried across the interoperability boundary.

BRC-202 links the credential parties to DID identifiers

BRC-203 uses proposed BRC-202 for the issuer and subject identifiers.

That gives the credential representation DID-style identities derived directly from the BSV identity keys already used by the certificate.

The resulting structure can therefore express the issuer and subject through identifiers that broader identity tooling may recognize while retaining the BSV certificate’s original cryptographic relationships underneath.

This dependency is also one reason the work remains provisional.

BRC-202 itself is still an open proposal.

If its identity-key representation changes during review, BRC-203 may need to change with it.

Status information also needs to preserve privacy

Credential portability involves more than the credential document itself.

A verifier may need to determine whether a certificate is still valid or has been revoked.

BRC-52 certificates use revocation outpoints as part of that model.

BRC-203 attempts to translate that status behavior without creating a new centralized status service that could monitor every time a holder presents a credential.

The proposal explicitly treats privacy around status checking as part of the interoperability problem.

A credential system that protects selective disclosure can still leak significant information if every verifier must contact the issuer through a trackable endpoint each time the credential is checked.

That is why the proposal pays attention not only to representation but also to how status is determined.

This is not yet a W3C credential implementation

The proposals are careful not to overstate their maturity.

BRC-202 distinguishes its proposed semantics from full DID conformance certification.

BRC-203 explicitly says that it is a custom interoperability mechanism, not an existing registered Data Integrity, JWS, COSE or SD-JWT verification suite.

It does not claim that generic W3C verifiable-credential software will automatically accept these credentials today.

It also does not claim completed external conformance testing or live production interoperability. GitHub

That distinction is important.

A document resembling a standard credential format is not the same thing as proven compatibility with independent identity software.

The value of the proposals is that they define the bridge precisely enough for that compatibility work to begin.

A bridge rather than a replacement

The broader significance of BRC-202 and BRC-203 is therefore not that BSV identity is being replaced by another identity system.

The proposals attempt the opposite.

They preserve the native identity keys, encrypted certificates, original signatures and selective-disclosure behavior while defining a way for those objects to be represented in forms that outside systems may understand.

That is a more conservative interoperability model.

The existing BSV identity architecture remains the source of the cryptographic evidence.

The proposed DID and verifiable-credential structures become translation layers around it.

If implemented successfully, that could make it easier for a BSV wallet or identity system to exchange verifiable identity information with software built around broader DID and credential standards without forcing either side to abandon its native model.

But significant work remains.

Both proposals are still open.

BRC-203 depends on BRC-202 and related certificate clarification work that is also under review.

Independent implementations, interoperability testing, privacy review and broader standards conformance would still be needed before the proposals could be treated as established bridges between identity ecosystems.

For now, they are worth watching because they address a problem that tends to appear only after an identity system begins maturing:

not how to create another identity format, but how to make existing identity evidence portable without losing the meaning of what was originally signed.

Source: Proposed BRC-202 — GitHub / Proposed BRC-203 — GitHub

BSV TIMES – Under the Surface

Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Update — October 1, 2026