Operating Practices for Identity Certifiers

Abstract

This proposal defines operating practices for issuers of BRC-52 identity certificates. It requires an attributable, versioned statement of what an issuer certifies, how evidence is checked, how issuance is authorized, how keys and revocation are managed, and how errors and incidents are handled. It preserves the BRC-52 certificate format, BRC-100 wallet interface, and the relying user's choice of certifiers. Certificate-type specifications supply the meanings and evidence requirements of particular claims; these practices supply their common operational foundation.

Motivation

A valid certificate signature identifies a signing certifier. It does not establish that the issuer checked appropriate evidence, that an external attribute remains current, or that the verifier should trust that issuer. Two issuers can use the same certificate type while providing very different evidence handling and operational continuity. Subjects and relying parties need enough information to distinguish those practices.

The CA/Browser Forum's TLS Baseline Requirements provide useful examples of published certification policies, validation procedures, revocation processes, records, and security controls. RFC 3647 provides a policy/practice framework. Those sources concern X.509 public-key infrastructure. This proposal adapts their operational purpose to BRC certificates; it does not import browser root programs, TLS validation methods, X.509 formats, their deadlines, or accreditation claims. [1][2]

1. Scope and terminology

This is a proposed operational profile. The words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are interpreted as described in RFC 2119 and RFC 8174. A conforming certifier is an operator claiming conformance for identified certificate types and issuer keys. The requirements apply to that operator, including any evidence verification or signing service it delegates. Verifier guidance and implementation observations are identified separately.

• Subject: the identity key named in the certificate, and, where the context requires, its controller.
• Certifier or issuer: the key signing the BRC-52 certificate; the operator is the person or organization responsible for its use.
• Relying party or verifier: a party deciding whether and for what purpose to rely on an assertion.
• Type specification: the exact certificate type identifier, field schema, claim meanings, and any type-specific issuance rules.
• Operating statement: the operator's published certification policy and description of how it carries out that policy.
• Evidence: information used to establish a claim or authority to request issuance; it is separate from the certificate's encrypted fields.
• Issuance decision: the recorded decision to sign an exact certificate core under a particular operating-statement version.
• Revocation authority: the parties and keys able to spend a certificate's revocation output under its locking conditions.

BRC-52 remains authoritative for signed certificate content, encryption, keyrings, and revocation semantics. BRC-100 remains authoritative for wallet methods. BRC-103 and BRC-104 govern their respective authenticated exchange and HTTP transport. This proposal defines no new certificate field, endpoint, status token, signature preimage, or cryptographic proof.

The serialization guidance here relies on the unmerged BRC-52 clarification in PR 290, which describes historical locale-dependent ordering and exact signed-byte preservation. That revision is under draft review; this proposal does not claim that its clarified text has already been adopted.

These practices do not select universally trusted issuers, authorize application access to a wallet, establish one-person-one-key uniqueness, certify legal identity by default, or define government identity compliance. A registry listing describes a type; it does not appoint its issuers. A subject may use different wallets, issuers, or identity keys in different contexts.

2. Published operating statement

Before issuing certificates while claiming conformance, an operator MUST publish an operating statement retrievable without supplying a user's certificate, identity key, or account credentials. It MUST identify:

The operator MUST distinguish required type semantics from its own evidence methods, service choices, and implementation limitations. It MUST NOT use an operating-statement update to silently change the meaning of an established type. An incompatible type or wire-format change requires an explicitly distinguishable specification and migration plan. A policy document cannot add an unsigned expiry or assurance level to a signed certificate.

The operator MUST state which policy version governs an issuance, retain that association in its protected issuance records, and publish the rules needed to interpret historical versions. BRC-52 has no universal signed policy-version member or issuance timestamp. An external mapping or operator log is consequently an operator assertion, not an additional claim cryptographically bound into the certificate. Where independently verifiable policy/time binding is required, a type-specific specification MUST define it explicitly. Operators SHOULD preserve public document revisions in independently retrievable archives.

An operator publishing a BRC-68 domain manifest MUST keep its issuer-key information consistent with its operating statement. Discovering a key at a domain is evidence about that domain's publication; the relying user still decides whether to trust it. Changing the manifest does not rewrite the issuer key on existing certificates or transfer trust to a replacement key.

3. Evidence, authorization, and issuance

3.1 Evidence handling

A certifier MUST issue only claims supported by the applicable type specification and its published evidence policy. It MUST bind the evidence, the exact claimed values, the subject key, the requested type, and the issuance decision together. It MUST check the exact values that will be encrypted and signed, including schema-defined normalization. It MUST NOT sign arbitrary encrypted values merely because their encryption or a request signature is valid.

For a claim of account, mailbox, device, or other resource control, evidence of that control and authentication of the subject key are distinct checks. The certifier MUST bind both to the same authorized issuance. It MUST NOT infer a legal name, exclusive ownership, uniqueness of a person, or indefinite control from resource access unless the type explicitly defines that assertion and the evidence establishes it.

Evidence freshness and reuse rules MUST be documented and enforced. The rules MUST identify the relevant observation time, expiry or maximum age where applicable, and changes that require fresh verification. Unavailable, expired, mismatched, or incomplete evidence MUST result in rejection or a documented pending request; it MUST NOT be recorded as a successful check. A certifier MAY use approved automation, but remains responsible for its decision and for preventing a retry or duplicated request from substituting unchecked claims.

3.2 Subject authorization and user control

The certifier MUST authenticate the subject's authorization to issue the particular type and claims to the particular subject key. This MAY be a fresh authenticated request or a previously authorized process whose scope and validity the operator documents and checks. A delegated representative requires separately checked authority appropriate to the type. Proof that a service can sign a request is not, by itself, evidence that a human understood the request.

Before obtaining authorization, the certifier MUST explain the claims, evidence use, relevant retention, revocation limitations, and any fees or conditions. It MUST identify whether evidence or plaintext fields are accessible to the operator or delegated services. BRC-52 encryption permits selective revelation to verifiers; it does not promise that an issuing certifier cannot read the certified attributes.

Issuance authorization MUST NOT be treated as authorization to publish attributes publicly, to disclose additional fields to other verifiers, to grant wallet permissions, or to install a trust anchor. A certifier providing a publication service MUST obtain a distinct authorization identifying the fields and the public audience. It MUST explain that public revelation permits indefinite copying and correlation and that withdrawal or revocation cannot erase disclosed data. The certifier MUST NOT request the subject's root private key, recovery material, or an unrestricted master keyring for unrelated certificates as a condition of issuance.

3.3 Signing and delivery

Before signing, the certifier MUST validate the exact type, subject, issuer, unique serial, fields, evidence decision, and revocation arrangement. Serial numbers MUST be unique for distinct certificates issued under the same certifier identity key; retries MAY return the same exact previously issued core. Changing an assertion requires a new certificate and serial, not a conflicting certificate with the old identity.

For issuance acquisition, encrypted fields and a master keyring MUST be handled according to BRC-52 and the applicable issuance protocol. The certifier MUST establish that the plaintext it checks corresponds to the ciphertext it signs. It MUST prevent unauthorized substitutions of subject, type, certified values, or revocation ,[object Object] between verification and signing. Supporting a wallet method signature alone does not establish successful protocol interoperation; the chosen flow MUST be tested with the receiving wallet.

For certifier-created direct delivery, the certifier MUST provide the complete subject master keyring corresponding to the exact signed fields. It MUST protect master keyrings and evidence in transit and at rest, limit access to the intended participants, and never send a master keyring to an ordinary verifier. Delivery MUST let the subject verify the issuer signature, its own subject binding, and successful field decryption through the applicable wallet flow. If delivery fails after signing, the operator MUST record that distinction and apply its retry, abandonment, or revocation policy; a successful signature is not proof of subject receipt.

4. Key protection and operational records

The operator MUST restrict signing and revocation authority to documented authorized roles and services, authenticate administrative access, and record security-relevant changes. It MUST document protection, backup, restoration, rotation, and retirement procedures for issuer keys, revocation keys, and retained field keys. Production signing authority MUST be separated from development fixtures and test keys. Controls MUST cover delegated services as well as the operator's own systems.

The operator SHOULD separate evidence approval, signing administration, and recovery roles where practicable. A small operator MAY combine roles, but MUST disclose that limitation and document compensating controls and review. This proposal does not mandate a particular hardware product or assert equivalence to a named security certification.

The certifier MUST keep records sufficient to trace each issuance, rejection, reissuance, revocation, and incident to the governing policy, checked evidence outcome, exact certificate core, responsible process or role, and relevant times. It MUST protect records against unauthorized reading and alteration and test restoration of essential records and revocation capability. Retention MUST follow a documented purpose and duration; it MUST NOT become indefinite collection by default.

Records SHOULD use references or minimal verification outcomes instead of retaining raw evidence where that suffices. Access tokens, one-time challenge secrets, session credentials, private keys, and plaintext master keyrings MUST NOT be placed in public logs or public incident reports. Sensitive evidence retained for a justified period MUST have access controls and a deletion process. Backup retention and legal retention exceptions MUST be disclosed in the operating statement; deleting a live database record does not imply that all copies disappeared.

5. Revocation, correction, and continuity

5.1 Revocation arrangements

For a non-sentinel revocation outpoint, the certifier MUST establish that the specified output exists under its stated issuance confidence policy, that its locking conditions implement the declared revocation authority, and that the required spending capability is available before issuing. A syntactically valid outpoint is not evidence of any of those facts. The operator MUST preserve the information and authority necessary to carry out its policy and MUST protect the output from accidental spending as ordinary wallet funds.

The operator MUST disclose when multiple certificates share one revocation output, which parties can spend it, and the collateral effects of spending. It SHOULD use independently revocable outputs unless the type's published policy intentionally defines a group lifecycle. A spent revocation outpoint revokes every certificate relying on that outpoint under BRC-52; an operator's database flag cannot reverse that spend.

If the BRC-52 disabled sentinel is used, the certifier MUST explicitly state that UTXO-based revocation is unavailable, which validity mechanisms remain, and what errors or compromise cannot be remedied for already issued certificates. It MUST NOT advertise such a certificate as revocable through a nonexistent output. If the applicable type requires revocation, sentinel issuance MUST be rejected. Type-defined expiration is not a universal replacement for revocation and MUST NOT be invented for legacy schemas.

5.2 Requests and status

The certifier MUST provide documented subject revocation and correction channels and a channel for certificate problem reports from relying parties and other reporters. It MUST authenticate authority to request a particular action and assess a report's evidence; a third-party report alone MUST NOT confer revocation authority. Loss of subject keys MUST have a documented alternative evidence process or a disclosed inability to authenticate the request. The operator MUST record the outcome and explain it to the requester without disclosing another person's private evidence.

The operating statement MUST identify grounds for action, including misissuance, demonstrated compromise of relevant keys, incorrect claims, and loss of required ongoing qualification. It MUST describe investigation, action, and escalation targets proportionate to those cases. Missing a published target MUST trigger a recorded explanation and escalation. This proposal does not assign one deadline to every certificate type or risk level.

When revoking, the operator MUST distinguish intent to spend, transaction submission, and the evidence of spending accepted under its policy. A failed or delayed submission MUST NOT be reported as completed revocation. It MUST track failures and continue the documented response process.

Verifier guidance: check the signature, issuer suitability, relevant revealed claims, type validity conditions, and revocation evidence separately. Distinguish revoked, not observed revoked under the stated check, disabled revocation, and unavailable status. A Merkle inclusion proof proves transaction inclusion, not the continuing absence of a spend. Signature verification alone does not determine current validity. An operator-provided status answer MUST state its observation source/time and uncertainty; this document does not standardize a new status-response format.

5.3 Reissuance and changes

Correction or renewal MUST produce a new signed certificate after the necessary evidence and authorization checks. The certifier MUST explain the old certificate's remaining validity or revoke it as required by the type policy. Reissuance MUST NOT imply that already disclosed values have been erased. Subject key changes require checked authorization binding claims to the new key; equal names or account handles are not a cryptographic key-continuity proof.

For issuer rotation, the operator MUST publish the replacement key and applicability, retain attribution of certificates signed by previous keys, and arrange continued revocation handling or disclose its absence. A signature by an old uncompromised key MAY support continuity, but neither that signature nor a domain-manifest update forces a user to trust the new key. A compromised old key is an unsuitable sole basis for establishing replacement authority.

6. Incidents, assessment, and termination

The certifier MUST maintain and exercise a response procedure for suspected misissuance, issuer-key compromise, revocation-authority failure, evidence disclosure, and inability to enforce its published policy. It MUST record the incident, determine affected issuance scope, preserve necessary investigation evidence with restricted access, and stop affected issuance when trustworthy evidence approval or signing cannot be maintained. Unaffected issuance MAY continue only with a recorded justification.

The procedure MUST cover containment, policy-required revocation, recovery or reissuance, and communication through authenticated established channels. A public incident notice MUST describe the affected issuer keys/types, known impact, current uncertainty, recommended relying-party action, and remediation progress without publishing individual private certificates or identifying evidence unnecessarily. The operator MUST record why notice is delayed or limited where immediate publication would disclose sensitive information or obstruct containment. It MUST revise inaccurate notices and disclose material unresolved limitations.

The certifier MUST periodically assess its implementation against its statement and this proposal, and reassess after material policy, code, evidence-provider, or key-control changes. The statement MUST specify assessment scope and frequency. Assessment evidence MUST identify tested revisions, findings, unresolved gaps, and remediation decisions. Independent review is RECOMMENDED where practicable; self-assessment MUST be identified as such. A conformance claim MUST NOT be represented as CA/Browser Forum, browser-root-program, W3C, or government approval.

Before planned termination, the operator MUST publish the cessation date, affected keys/types, and arrangements or limitations for evidence requests, revocation, and historical policy retrieval. It MUST determine whether outstanding certificates require revocation under their policies. Transferring a public archive does not transfer signing authority or personal trust. If another operator takes over a service, it MUST explain the authority and data-handling changes and obtain fresh authorization wherever the prior authorization does not cover them.

7. Worked example and conformance cases

An email-control type says only that the subject demonstrated mailbox access at verification time. The certifier receives an authenticated issuance request, binds a time-limited mailbox challenge to that request and subject, checks its result, and validates the exact email value before signing the encrypted field. Its operating statement discloses evidence reuse rules and whether a usable revocation output is supplied. The subject receives the certificate and corresponding master keyring. No step automatically publishes the email or causes a verifier to trust the issuer.

If the email value is later corrected, the issuer checks the new evidence and issues a new serial. If the old output is spent, the old certificate is revoked; its previous public disclosure remains readable. If a verifier checks only the signature, it has checked attribution but has not obtained a current revocation determination or proven continuing mailbox control. This example is informative and does not define a new email schema.

A conformance assessment MUST include the following cases for the operator's supported flows. It MUST record the policy version, source revision/configuration, expected result, observed result, and gaps. Use synthetic keys and evidence; a production credential is not a required test input.

An operator claiming conformance MUST satisfy the MUST requirements applicable to its declared types and flows. Unsupported optional flows MUST be stated. Documentary assessment and test cases can reveal failures; they do not establish universal claim accuracy or future reliability. Operators MUST identify unresolved failures before claiming full conformance for the affected scope.

8. Compatibility and implementation evidence

Existing BRC-52 certificates and BRC-100 APIs retain their encodings. Operators can adopt this profile by publishing their existing practices, identifying gaps, and introducing the necessary operational controls. Adoption does not retroactively establish evidence checks for legacy issuance. A statement MUST distinguish certificates issued under these practices from earlier or otherwise unsupported issuance. If a new type needs certified time, assurance, or policy binding, define its schema explicitly and preserve the interpretation of existing types.

The following public sources were inspected at their linked pinned TS Stack revisions:

• Certificate.ts implements core serialization and signature verification. Its verify() checks the signature; it does not check that the revocation output is appropriate or unspent. Its field serialization uses host-dependent localeCompare, and verification reconstructs the preimage through that serializer. Operators MUST identify their compatible serialization environment and test actual signed preimages; this profile does not require replacing historical field ordering or existing signatures.
• MasterCertificate.ts provides encrypted fields, master/verifier keyrings, and direct issuance. Its default revocation callback returns a 64-zero txid without an output index. That placeholder is not a usable BRC-52 revocation outpoint; callers must supply a valid disabled sentinel or a functioning output according to their type policy.
• Wallet.ts implements direct acquisition with signature and field-decryption checks. Its issuance acquisition uses authenticated signCertificate, nonce/HMAC serial binding, response-issuer checks, exact field checks, signature verification, and decryption before storage. These checks do not assess the certifier's external evidence policy or perform a current revocation check in that path.
• IdentityClient.ts separately constructs public revelations of selected certificate fields. That separation supports the distinction between issuance and publication; application UI and operator procedures still need to establish informed authorization.

These are implementation observations, not claims that any operator already conforms to this operational profile. Evidence policies, administration, retention, incident exercises, and continuity require separate operational evidence. No implementation change is specified by this proposal.

The proposed identity/discovery integration work in BRCs pull request 282 explains related personal trust and public-revelation concepts. It remains a separate draft; this proposal's operational requirements do not depend on its acceptance. BRC-184 and the registry submission guide separate descriptive metadata from issuer trust and permissions.

9. Privacy and security considerations

Encrypted certified values can still expose field names, issuer/type relationships, stable subject identifiers, serials, sizes, and presentation correlation. A certifier normally sees the evidence and values it certifies. Selective revelation does not prevent a recipient from retaining plaintext or requesting additional attributes through another workflow. Operators MUST communicate these limits accurately and minimize evidence and disclosure consistent with the actual claim.

Key compromise can permit false issuance and undermine continuity statements. Revocation-key loss can prevent promised revocation; accidental output spending can revoke unrelated certificates when outputs are shared. Chain-source delay, stale caches, and unavailable services can make current status uncertain. A usable revocation design therefore requires tested controls and explicit relying-party freshness expectations, not only an outpoint-shaped string.

Resource ownership and handles can change independently of certificate cryptography. A valid signature or unspent revocation output cannot establish that an issuance-time external observation remains true. Subjects retain control of their own keys and public-revelation outputs; revoking an issuer assertion does not delete contacts, move identity keys, erase history, or revoke wallet permissions.

References

1. CA/Browser Forum, TLS Baseline Requirements 2.3.0, especially sections 2, 3, 4.9, 5.4, 5.7, and 6; operational analogy only. Official version index.
2. RFC 3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, informational framework; not a BRC wire format or mandatory accreditation scheme.
3. RFC 2119 and RFC 8174, normative terminology.
4. BRC-52, BRC-68, BRC-100, BRC-103, and BRC-104.
5. BRC-184 and registry submission guide.
6. Pinned TS Stack certificate, wallet, and public-revelation sources linked in section 8.