> For the complete documentation index, see [llms.txt](https://bsv.brc.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bsv.brc.dev/peer-to-peer/0203.md). # BRC-52 Encrypted Certificate Profile for Verifiable Credential Interoperability Ty Everett () ## Abstract This specification 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 specification 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 specification instead defines a closed projection of the signed certificate and verifies that projection through the original binary signature. ## Status and scope 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](https://www.w3.org/TR/2025/REC-vc-data-model-2.0-20250515/), a Recommendation. This specification 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 specified here 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](/peer-to-peer/0052.md) remains authoritative for certificate primitives; [BRC-100](/wallet/0100.md), [BRC-103](/peer-to-peer/0103.md), and [BRC-104](/peer-to-peer/0104.md) retain wallet and authenticated transport authority. [BRC-202](/peer-to-peer/0202.md) specifies the exact identity-key DID conversion required here. No implementation refactor or deployment is included. This profile follows [BRC-52](/peer-to-peer/0052.md) and [BRC-2](/wallet/0002.md) for historical field serialization, UTF-8 byte lengths and encryption framing. It requires exact authenticated source bytes and does not designate a replacement comparator for historical certificates. ## Terminology and authority | BRC role or object | Credential interpretation | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | `certifier` identity key | Issuer identifier after identity-key DID conversion. | | `subject` identity key | The credential subject identifier; not a unique legal-person claim. | | Certificate holder | Party storing the certificate and applicable keyring; possession alone is not current subject control. | | Core certificate | Issuer-secured source material: type, serial, subject, certifier, revocation outpoint, encrypted fields, and signature. | | Verifier keyring | Unsigned transport of selected field revelation keys encrypted for a verifier. | | Credential graph | The exact deterministic encrypted projection defined below. | | Disclosure result | Values decrypted for a verifier, reported separately with their source and verification evidence. | | Verification | Checking the original signature and exact projection. | | Validation | Assessing issuer authority, schema meaning, current status, freshness, purpose, and authorization. | 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 specification. The fixed context below defines their machine-readable mappings inline; consumers do not fetch `N` to interpret the terms. These are BRC-defined 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: | Member | Requirement | | ------------------- | ----------------------------------------------------------------------------------------------------------- | | `profile` | Exactly `P`. | | `certificateBinary` | Canonical Base64 of the complete original BRC-52 `CertificateBinary`, including the original DER signature. | | `credential` | The exact graph produced by Section 3. | | `disclosure` | Optional unsigned verifier-keyring object specified in Section 5. | 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: ```json { "@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. 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: | Operation | Protocol | Key ID | Counterparty | | ------------------------------ | ------------------------------------- | -------------------------------- | ------------------------------------------------------------- | | Recover a master field key | `[2, "certificate field encryption"]` | Exact field name | Certifier or supported authenticated master-keyring revealer. | | Encrypt field key for verifier | `[2, "certificate field encryption"]` | `serialNumber + " " + fieldName` | Receiving verifier identity key. | | Verifier decrypts field key | Same protocol | Same serial/field key ID | Certificate subject identity key. | 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: | Result | Meaning | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | `revoked` | Accepted evidence under the verifier's chain policy establishes a spend of the signed outpoint. | | `notRevokedAsOf` | The verifier's accepted current-state evidence supports that the real outpoint exists and remains unspent as of the stated observation. | | `unknown` | Existence, current spend state, freshness, chain applicability, or evidence is insufficient. | | `disabled` | The signed outpoint is the BRC-52 all-zero transaction ID with output index zero; this certificate does not use UTXO revocation. | 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](/wallet/0184.md) 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](/peer-to-peer/0068.md) domain manifests and BRC-100 personal trust choices can establish configured trust anchors under their own policies. The W3C [Verifiable Credential Extensions](https://w3c.github.io/vc-extensions/) catalog is the relevant venue for candidate 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](https://github.com/bsv-blockchain/BRCs/tree/master/media/0203-envelope.json). 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: | Test | Required result | | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Export an existing authentic certificate | Signature and unsigned preimage byte-for-byte preserved; no signing operation. | | Verify the envelope | Only the computed ciphertext graph is returned as `verifiedDocument`. | | Change issuer, subject, type, serial, ciphertext, or outpoint | Signature failure or deterministic projection mismatch. | | Add plaintext, date, network, arbitrary context, or nested claim to the graph | Rejection even if the source signature remains valid. | | Verify against the root identity key rather than the BRC-derived signing key | Does not satisfy this mechanism. | | Change only a valid recipient-specific keyring | Issuer graph stays the same; disclosure assessed separately. | | Include an unknown field, malformed field key, bad GCM tag, or master keyring | Disclosure rejected; no plaintext accepted. | | Use a disclosure envelope from an unauthenticated or wrong-subject session | Insufficient for live-control authorization. | | Supply a spent outpoint | `revoked` under the accepted chain evidence policy. | | Supply unavailable, nonexistent, stale, or wrong-network outpoint data | `unknown`, not `notRevokedAsOf`. | | Supply the disabled sentinel | `disabled`; no chain query. | | Require a presentation-specific issuer status lookup | Reject that mode as nonconforming status privacy; use the local/private retrieval policy. | | Replace the W3C v2 context through runtime network retrieval | Do not reinterpret the graph; reject the substituted context. | | Trust no suitable issuer despite a valid signature | Cryptographic verification can succeed; application reliance fails. | | Supply an unrecognized suite to a generic W3C verifier | Explicit unsupported mechanism, no automatic compatibility claim. | 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](https://github.com/bsv-blockchain/ts-stack/tree/8ce780e1c740490f8bf2910f7f37775bf14c713f/packages/sdk/src/auth/certificates) provide existing BRC operations. The current [`@bsv/did` helper](https://github.com/bsv-blockchain/ts-stack/tree/8ce780e1c740490f8bf2910f7f37775bf14c713f/packages/helpers/did) 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 W3C bridge exists. The pinned helper cites SD-JWT VC revision 16; the public IETF document reviewed during this specification is revision 19, while SD-JWT itself is [RFC 9901](https://www.rfc-editor.org/rfc/rfc9901.html). 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](https://www.usenix.org/conference/usenixsecurity22/presentation/albertini). This specification 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](https://www.w3.org/TR/2025/REC-vc-data-model-2.0-20250515/), especially status, trust, securing mechanisms, privacy, and validation. * [Verifiable Credential Data Integrity 1.0](https://www.w3.org/TR/2025/REC-vc-data-integrity-20250515/) and [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/2025/REC-vc-jose-cose-20250515/), alternative mechanisms that this profile does not impersonate. * [Data Integrity ECDSA Cryptosuites v1.0](https://www.w3.org/TR/2025/REC-vc-di-ecdsa-20250515/), whose P-256/P-384 suites are distinct from BRC secp256k1 certificate derivation. * [JSON-LD 1.1](https://www.w3.org/TR/json-ld11/), including protected terms and JSON literals. * [Verifiable Credential Extensions](https://w3c.github.io/vc-extensions/), candidate mechanism/status registration venue. * [BRC-2](/wallet/0002.md), [BRC-42](/key-derivation/0042.md), [BRC-52](/peer-to-peer/0052.md), [BRC-68](/peer-to-peer/0068.md), [BRC-100](/wallet/0100.md), [BRC-103](/peer-to-peer/0103.md), [BRC-104](/peer-to-peer/0104.md), and [BRC-184](/wallet/0184.md). * [BRC-202](/peer-to-peer/0202.md), identity-key DID profile, and [BRC-189](/wallet/0189.md), related identity/discovery/personal-trust integration. * [Albertini et al., How to Abuse and Fix Authenticated Encryption Without Key Commitment](https://www.usenix.org/conference/usenixsecurity22/presentation/albertini), USENIX Security 2022. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://bsv.brc.dev/peer-to-peer/0203.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.