BRC-52 Encrypted Certificate Profile for Verifiable Credential Interoperability

Abstract

This proposal defines a deterministic credential view and an explicit verification envelope for existing BRC-52 certificates. The original certifier signature and encrypted fields remain unchanged. Issuer, subject, credential type, selective disclosure, and status are expressed using W3C Verifiable Credential concepts, while certificate signature verification, field encryption, verifier keyrings, and outpoint revocation retain their BRC semantics.

The issuer-secured credential graph contains encrypted fields. Decrypted values are separate disclosure results. This proposal specifies a custom securing mechanism and status type; it does not rename an existing BRC signature as a Data Integrity or JOSE proof.

Motivation

A certificate holder should not need a second issuer signature merely to describe an existing certificate to a credential-aware application. A safe bridge must protect every claim it labels issuer-secured, preserve encrypted fields and their exact preimage, and distinguish credential integrity from disclosure authorization, current revocation, and issuer trust.

A wrapper that copies plaintext into a W3C-shaped JSON object and attaches the old signature does not provide those properties. This proposal instead defines a closed projection of the signed certificate and verifies that projection through the original binary signature.

Status and scope

Status: Draft. MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY have the meanings in RFC 2119 and RFC 8174. Specification and conformance requirements are normative; examples, rationale, observations, and migration planning are informative.

The W3C baseline is Verifiable Credentials Data Model v2.0, a Recommendation. This proposal follows its securing-mechanism interface and extension model, with BRC-52 cryptography as a newly specified custom mechanism. The mechanism, vocabulary, and status type are proposed and unregistered. Generic W3C, Data Integrity, JOSE, COSE, SD-JWT, and status-list implementations MUST NOT be assumed to support them.

No W3C endorsement, certification, deployed interoperability, or complete external conformance-test result is claimed. Full W3C conformance review, extension registration, and interoperable implementations remain work to perform. In particular, this profile provides no zero-knowledge or unlinkable disclosure; interpretation of the anti-correlation requirements in the data model's zero-knowledge section requires external review before an unqualified conformance claim.

BRC-52 remains authoritative for certificate primitives; BRC-100, BRC-103, and BRC-104 retain wallet and authenticated transport authority. The BRC-202 proposal specifies the exact identity-key DID conversion required here and is an unmerged companion proposal. No implementation refactor or deployment is included.

This draft relies on the unmerged BRC-52 and BRC-2 clarifications in PR 290 for historical field serialization, UTF-8 byte lengths and encryption framing. That revision remains under draft review. This profile requires exact authenticated source bytes and does not designate a replacement comparator for historical certificates or claim that the clarified specifications are already adopted.

Terminology and authority

An issuer DID does not transfer trust from a user's selected certifier to a translator, registry, wallet vendor, overlay, or resolver. Registry metadata can describe a type but cannot certify its claims. A holder, subject, issuer, DID controller, and verifier MAY coincide, but their authorities MUST remain distinguishable.

Specification

1. Profile identifier and transport envelope

Define the vocabulary namespace N and mechanism identifier P as:

N = https://github.com/bsv-blockchain/BRCs/blob/master/peer-to-peer/0203.md#
P = N || BRC52EnvelopeV1

N identifies terms defined by this draft. The fixed context below defines their machine-readable mappings inline; consumers do not fetch N to interpret the terms. These are proposed BRC terms, not entries already accepted into a W3C registry. An incompatible revision MUST use a distinct profile identifier and distinguishable term definitions.

The envelope is UTF-8 JSON transmitted as application/json. It has exactly these members:

Duplicate JSON member names, invalid UTF-8, noncanonical Base64, unknown members, and values outside the stated types MUST be rejected. Receivers MUST impose and document finite certificate, JSON, field-count, and keyring size limits. They MUST reject oversized input rather than truncate it. The generic JSON media type is not an IANA registration of a BRC-specific credential media type.

certificateBinary MUST be the original signed core; master or verifier keyrings MUST NOT be appended inside it. Exporters MUST preserve its bytes and signature. They MUST NOT sign again, reorder fields while rebuilding the preimage, or use stable JSON as the certificate preimage. A wallet that stores only structured certificate data may export a compatible BRC-52 serialization only after verifying that the resulting bytes authenticate under the existing signature. Field enumeration order can matter when historical locale comparisons treat distinct names as equal; an exporter MUST NOT assume that reordering JSON field members always preserves the signed bytes.

2. Parse the signed source without changing it

The parser MUST read the BRC-52 binary fields in order: 32-byte type, 32-byte serial, 33-byte subject, 33-byte certifier, 32-byte revocation transaction ID, CompactSize output index, CompactSize field count, and the length-prefixed field names and values. The remaining bytes MUST be exactly one complete BRC-52 DER signature. The parser MUST retain the original unsigned prefix B and the signature bytes S; verification MUST operate on B, not a reserialization of a parsed object.

The transaction-ID bytes are displayed in their signed hexadecimal order, without Bitcoin transaction-input byte reversal. Signed field values are UTF-8 bytes of Base64 ciphertext strings, not decoded ciphertext bytes. Type and serial are rendered as canonical Base64. Public keys are rendered as compressed lowercase hexadecimal.

Every signed field value MUST be the canonical Base64 encoding of a BRC-52 AES-GCM envelope of at least 48 bytes (32-byte IV plus 16-byte tag, including when plaintext is empty). The parser MUST validate that encoding without rewriting the signed Base64 text. The parser MUST enforce BRC-52's field-name bounds, unique field names, canonical length encodings, and key validity. It MUST reject malformed CompactSize values, invalid lengths, duplicate fields, unconsumed bytes, and malformed signatures. Field-name and value lengths count UTF-8 bytes. The parser MUST preserve the signed field order and text, without imposing another comparator, Unicode normalization, or case folding. Parsed values used by the graph MUST come from the exact authenticated prefix. This permits signature-preserving verification across historical serialization environments without claiming that those environments produce identical preimages from JSON alone.

3. Deterministic credential graph

Let C be the parsed source, D(k) the identity-key DID conversion in BRC-202, and X the following fixed context object:

{
  "@protected": true,
  "brc": {
    "@id": "https://github.com/bsv-blockchain/BRCs/blob/master/peer-to-peer/0203.md#",
    "@prefix": true
  },
  "certificateType": "brc:certificateType",
  "serialNumber": "brc:serialNumber",
  "revocationOutpoint": "brc:revocationOutpoint",
  "encryptedFields": { "@id": "brc:encryptedFields", "@type": "@json" }
}

The graph MUST contain exactly:

@context = ["https://www.w3.org/ns/credentials/v2", X]
type = ["VerifiableCredential", "brc:BRC52EncryptedCertificate"]
issuer = D(C.certifier)
credentialSubject = {
  id: D(C.subject),
  encryptedFields: exact map C.fields
}
certificateType = C.type
serialNumber = C.serialNumber
revocationOutpoint = C.revocationOutpoint

For a non-sentinel outpoint, it MUST also contain:

credentialStatus = {
  type: "brc:BRC52OutpointStatus",
  revocationOutpoint: C.revocationOutpoint
}

For the BRC-52 disabled sentinel, credentialStatus MUST be absent; the sentinel remains in revocationOutpoint. No id, validFrom, validUntil, name, description, plaintext claim, holder assertion, network name, provider URL, or metadata registry result is added. This prevents unsigned information from becoming an issuer-secured claim. A future profile defining additional signed facts must use authenticated source evidence and a separately specified mapping.

The context constants define format semantics, not new issuer-supplied facts. A verifier MUST use exactly these constants and a locally trusted fixed definition of the W3C credentials v2 context. It MUST NOT reinterpret a verified graph using a network-fetched replacement context; the context definition is part of the selected versioned profile. Context identifiers are semantic identifiers, not permission for arbitrary runtime network fetches. It MUST compare the received graph to its independently computed graph before JSON-LD expansion or any downstream credential processing. JSON object member order is immaterial; arrays, string values, exact members, and field names MUST match. It MUST reject added graphs, alternative contexts, aliases, rewritten types, and alternate ciphertext encodings even when a general JSON-LD processor might consider them equivalent.

encryptedFields is one JSON literal containing the original field-name-to-ciphertext map. It is not a set of plaintext vocabulary claims. certificateType is the original 32-byte certificate schema identifier; it is not a DID, VC class, registry authority, or assurance level. serialNumber preserves issuer/type certificate selection and is not a globally unique identity identifier.

<a id="BRC52EnvelopeV1"></a> <a id="BRC52EncryptedCertificate"></a> <a id="BRC52OutpointStatus"></a> <a id="certificateType"></a> <a id="serialNumber"></a> <a id="revocationOutpoint"></a> <a id="encryptedFields"></a>

The named terms have the exact meanings and types above. The first identifies the envelope mechanism, the second the encrypted certificate class, and the third the UTXO-spend status method. The remaining terms are literal copies of the corresponding signed source facts. They do not inherit external meanings from similarly named terms.

4. Verify the custom securing mechanism

The interface is verifyBRC52Envelope(inputMediaType, inputData). Implementations MUST return at least verified, verifiedDocument, mediaType, and errors. On success, mediaType is application/vc and verifiedDocument is the computed graph, without source signature, envelope, keyrings, or disclosure results. On failure, verified is false, verifiedDocument is null, and errors identifies the failed condition.

The verifier MUST:

1. Require inputMediaType = application/json, parse the strict envelope, and require the exact profile identifier. Unsupported profiles fail without signature-suite guessing.
2. Decode and parse certificateBinary under Section 2, retaining B and S.
3. Compute G(C) under Section 3 and reject any mismatch with credential.
4. Verify S through the BRC-100/BRC-52 signature operation with protocolID = [2, "certificate signature"], keyID = C.type + " " + C.serialNumber, counterparty = C.certifier, and data = B. The signature operation hashes the data with SHA-256; supplying an already hashed value to an operation that hashes again is incorrect. Publicly verifiable BRC derivation uses the anyone relationship.
5. Return only G(C) as the issuer-secured document after successful signature verification. Any returned diagnostic source bytes or signature MUST be explicitly separate from verifiedDocument.

A non-wallet implementation MUST derive and verify the same BRC-42 certificate signing public key using BRC-52's publicly verifiable counterparty semantics. It MUST NOT use the issuer's root public key directly as the ECDSA certificate verification key. It MUST NOT convert S into a DataIntegrityProof, ES256, ES256K, COSE signature, or SD-JWT without a separately specified securing transformation. No new signature is created by this profile.

This mechanism protects the entire closed credential graph because each variable graph value comes from the authenticated binary source and each remaining value is a fixed profile constant. A source signature that verifies independently is insufficient when the received graph differs. A display component MUST consume verifiedDocument, not the unverified incoming graph.

The detached envelope is not an embedded proof graph. The mechanism's shape follows VCDM's custom securing-mechanism model; dispatching to it requires explicit implementation support. A structurally similar application/vc object without this verified envelope is not secured by this mechanism.

5. Selective field revelation

The optional disclosure object has exactly subject, verifier, and keyring members. The first two are compressed hexadecimal identity keys; subject MUST equal C.subject, and verifier MUST equal the intended receiving identity key. keyring maps a subset of C.fields names to canonical Base64 BRC verifier-keyring ciphertexts. Unknown names, empty entries, duplicates, and master-keyring objects MUST be rejected. This object is unsigned by the certifier and MUST NOT appear in verifiedDocument.

The holder MUST obtain user authorization for the recipient, purpose, and selected fields under the wallet's permission model. It MUST verify the stored certificate and its applicable master keyring, recover only the requested field revelation keys, and produce verifier keyrings through BRC-100 proveCertificate or equivalent BRC-52 operations:

Each keyring plaintext is the raw 32-byte field revelation key. Verifier keyrings use BRC-2/BRC-100 AES-GCM envelopes: Base64 of a 32-byte IV, ciphertext, and 16-byte tag. Field ciphertexts use the same layout with an independently random 32-byte field key and no additional authenticated data. Producers MUST generate fresh cryptographically random keys and IVs as required by BRC-52; they MUST NOT shorten the IV to another ecosystem's default length.

For an interaction requiring current subject control or disclosure authorization, the holder MUST deliver the complete exact envelope as application payload within a fresh authenticated BRC-103 session with the receiving verifier, using BRC-104 where HTTP is used. The complete envelope MUST be inside the signature-covered application payload. The verifier MUST establish that the authenticated peer key equals C.subject, reject repeated request nonces, enforce a documented bounded session/request age, and bind reliance to that authenticated request and intended operation. The operation and routing context themselves MUST be authenticated: for HTTP this includes the applicable BRC-104 signed method/path, and a different application transport must define the equivalent signature-covered operation data. Unsigned transport metadata is insufficient. Certificates discovered publicly or copied from storage do not satisfy this live-control requirement. This profile adds no alternate BRC-103 wire encoding or generic verifiable-presentation proof.

After Section 4 succeeds, the verifier MAY decrypt only authorized keyring entries. It MUST require each recovered field key to be exactly 32 bytes, validate each field's AES-GCM authentication tag, reject decryption failure, and interpret the UTF-8 plaintext under the identified certificate type's documented schema. It MUST NOT return unauthenticated partial plaintext.

The result of decryption MUST be reported separately as disclosedFields, associated with the verified source certificate, recipient, authenticated session where used, and status assessment. It MUST NOT be inserted into verifiedDocument or labeled a new plaintext signature by the certifier. Successful decryption retains BRC-52's underlying encryption and issuance assumptions. AES-GCM does not provide a general key-commitment guarantee, and field keys are not part of the issuer signature. This bridge therefore does not claim a stronger proof that a holder-supplied key reveals uniquely the same plaintext the issuer inspected. Stronger authenticated plaintext commitments require separate authenticated evidence and cannot be added retroactively to the old signature.

An empty keyring reveals no fields and can still accompany a successfully verified encrypted graph. Field names, ciphertext lengths, issuer, subject, type, serial, signature, and outpoint remain visible. This is selective revelation, not a predicate proof or unlinkable presentation.

6. Outpoint-based credential status

brc:BRC52OutpointStatus refers to the exact signed non-sentinel BRC-52 revocation outpoint. An accepted spend revokes the certificate under the verifier's chain policy. No suspension or unrevocation operation is defined by this status type; handling temporary observations and reorganizations remains part of the explicit chain policy below. It is not a Bitstring Status List entry.

A status evaluator MUST receive a locally selected network and evidence/freshness policy. Network selection is not encoded in the BRC-52 signed core and MUST NOT be presented as an issuer-secured wrapper claim. A certificate-type policy MAY constrain the applicable network; the verifier must establish that policy independently. The evaluator MUST bind observations to the exact transaction ID, output index, network, evidence source, and observation time.

Its result MUST distinguish:

Status retrieval MUST NOT enable an issuer, directly or through a provider, to learn a verifier’s interest in a particular holder or subject. A per-presentation issuer lookup that reveals that interest is prohibited. Implementations MUST support a verifier-local chain view or a retrieval approach with batching, caching, or equivalent privacy protections that prevents such issuer tracking. A remote query MUST disclose only the minimum outpoint and network information required by the selected service; it MUST NOT attach subject/issuer DIDs, certificate fields, the complete credential, verifier identity, presentation nonce, or the relying operation. If an external provider can correlate a query to a certificate or presentation despite these measures, the result MUST identify that privacy limitation. A retrieval mode that directly or indirectly reveals this interest to the issuer MUST NOT be treated as conforming; the evaluator MUST use a compliant alternative or return unknown rather than waive this requirement through an application acceptance policy. Other third-party exposure remains a separately disclosed privacy consideration. An implementation MUST NOT advertise compliance with this profile's status privacy requirement when its only supported mode phones home to the issuer for each use.

The evaluator MUST NOT infer notRevokedAsOf from a provider error, missing database entry, nonexistent transaction, successful certificate signature, old Merkle proof alone, or presence in an identity overlay. The all-zero sentinel MUST NOT be looked up as a real outpoint. disabled is not evidence that the underlying assertion is current or irrevocable under every application policy.

Providers may supply assertions, authenticated views, or independently validated chain evidence. A result MUST state which was used; a remote JSON response is not automatically independent cryptographic proof. Implementations MUST follow their documented handling of unconfirmed spends, confirmation depth, competing observations, reorganizations, and maximum accepted age. Unknown or stale status MUST NOT authorize an operation whose policy requires a current non-revoked certificate. A holder's own withdrawal of a public discovery token is a separate operation and is not necessarily issuer certificate revocation.

7. Relying-party validation and registries

After cryptographic verification, the verifier MUST apply its issuer trust and certificate-type policy before relying on claims. It MUST assess field meaning, the source's subject, required live control, status, currentness, and permitted purpose. A certificate type can define signed date or qualification fields, but this core has no universal issuance date, expiry, assurance level, or government-ID status. Omission of VC validity properties MUST NOT be used as evidence that a real-world fact remains true indefinitely.

BRC-184 CertMap metadata MAY assist schema discovery and display. The original Base64 certificate-type identifier remains authoritative for selecting the applicable schema; metadata MUST NOT alter signed field spelling, encrypted values, issuer trust, or the projection algorithm. BRC-68 domain manifests and BRC-100 personal trust choices can establish configured trust anchors under their own policies.

The W3C Verifiable Credential Extensions catalog is the relevant venue for proposed securing-mechanism and status-type discoverability. A registration request should include this versioned mechanism, its verification interface, the exact vocabulary/context, status evaluation rules, test vectors, privacy limitations, and implementation reports. Registration is future work and does not itself establish trust in certifiers. No existing registration is asserted here.

Examples and conformance criteria

For a certificate whose subject is 02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5 and whose certifier is 02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9, projection uses:

credentialSubject.id = did:key:zQ3shajmTb29MxR6htjD79Hdo6vneJLvyKCzZSRcawNWks9JC
issuer = did:key:zQ3sheBXCeZNNKcYTSbn3U6mTZD228vEFA753n76azCDQq16g

These are public test keys with known private scalars and MUST NOT be used in production. If the signed certificate has an email field, its entire original ciphertext string goes into credentialSubject.encryptedFields.email. An email revelation key can go into disclosure.keyring.email; the decrypted email goes only into the receiver's separate disclosure result. The graph and signature stay unchanged across verifier-specific keyrings.

A complete synthetic envelope is provided in the BRC-203 test artifact. It uses only public test values. Its unsigned signature-preimage length is 353 bytes and its SHA-256 digest is 296e5e07d39301a5530b9ae2b0b14624ea4089ab20eaa860fe4a81fb22e5a624. The complete original signed binary is 424 bytes. The derived signing public key is 02818a006c82d870268dcd8539ff05323a20dcc164762b120e265d52882b616234. The example outpoint is synthetic; this artifact does not assert its existence or live status. No master keyring, private key, or plaintext claim is included.

An implementation MUST declare its roles: exporter, custom-mechanism verifier, holder disclosure producer, disclosure receiver, status evaluator, or relying party. Each claimed role MUST pass the applicable tests:

An implementation report MUST identify revisions, supported profiles, signed-byte preservation and any structured-data serialization environment, disclosed schema types, status evidence/freshness policies, and negative-test outcomes. W3C data-model and JSON-LD test suites are additional external checks; these BRC tests do not replace them.

Compatibility, implementation gaps, and migration

This profile preserves the existing certificate signature and revelation cryptography. Existing BRC applications can continue using core certificates and BRC-100 APIs; the adapter supplies the new envelope and verifies the projection. The envelope is not an added member of the signed BRC core and does not change wallet-wire formats.

Published TS Stack certificate primitives provide existing BRC operations. The current @bsv/did helper has a different purpose: it issues JOSE ES256K IETF SD-JWT credentials with iss, vct, and cnf.jwk, using a fresh issuer signing operation. Its source does not implement this signature-preserving BRC-52 projection. Its README also states that status-list and type-metadata retrieval/evaluation are absent. Its SD-JWT support is not evidence that this proposed W3C bridge exists.

The pinned helper cites SD-JWT VC draft 16; the public IETF document reviewed during this proposal is draft 19, while SD-JWT itself is RFC 9901. Those are separate IETF formats and revision work, not normative sources for this BRC's encrypted certificate format.

Future implementation work should follow this specification: strict raw-binary export/parsing, the identity-key DID conversion, deterministic graph generation and comparison, custom-mechanism dispatch, recipient-scoped revelation transport, separate verification/validation outputs, status evidence adapters, and conformance vectors. Existing SD-JWT and legacy DID components may remain separately supported formats; they MUST NOT be silently relabeled as this profile. A future adapter must expose unsupported cases rather than change old certificate signatures or infer unsigned validity properties.

The main external limitations remain unregistered mechanism/status terms, absence of interoperable implementation reports, full W3C conformance review including anti-correlation wording, and the inherited non-key-committing encryption limit. A future requirement for cryptographically unique issuer-intended plaintext binding needs additional authenticated evidence or another certificate format and independent review. It is not satisfied by this signature-preserving bridge.

Privacy and security considerations

Issuer and subject DIDs, signatures, serials, outpoints, field names, and ciphertext lengths support correlation. This profile neither conceals them nor provides unlinkable presentations. Publicly publishing the graph has a different privacy effect from private verifier revelation and requires an explicit user decision. Wallets MUST NOT publish master keyrings or automatically reveal every field to make a W3C-shaped result look complete.

A recipient can retain decrypted values and keys. Revocation, wallet permission withdrawal, or discovery withdrawal cannot erase what a recipient already learned. Decrypted values and evidence SHOULD be retained only as needed for the stated purpose. Status queries and remote schema/image fetches can themselves reveal activity; local caching with explicit freshness and privacy-aware provider selection can reduce disclosure.

Strict graph matching prevents unsigned wrapper claims from inheriting the certifier signature. Valid issuer signatures do not establish truth or issuer authority. Authenticated subject sessions do not establish informed human consent by themselves. Status, user permissions, schema trust, and display provenance must remain explicit.

AES-GCM authentication is required but does not establish general key commitment. This limitation is explained in Albertini et al., USENIX Security 2022. This proposal preserves the original BRC security model and does not add an undocumented security property. Plaintext disclosure results must retain that distinction.

References

• Verifiable Credentials Data Model v2.0, Recommendation, 15 May 2025, especially status, trust, securing mechanisms, privacy, and validation.
• Verifiable Credential Data Integrity 1.0 and Securing Verifiable Credentials using JOSE and COSE, alternative mechanisms that this profile does not impersonate.
• Data Integrity ECDSA Cryptosuites v1.0, whose P-256/P-384 suites are distinct from BRC secp256k1 certificate derivation.
• JSON-LD 1.1, including protected terms and JSON literals.
• Verifiable Credential Extensions, proposed mechanism/status registration venue.
• BRC-2, BRC-42, BRC-52, BRC-68, BRC-100, BRC-103, BRC-104, and BRC-184.
• BRC-202 proposal, identity-key DID profile, and BRC-189 proposal, related identity/discovery/personal-trust integration.
• Albertini et al., How to Abuse and Fix Authenticated Encryption Without Key Commitment, USENIX Security 2022.