Social Account Certificate Types and Issuance Profile

Abstract

This proposal documents the existing Email, X, and Discord certificate types used by SocialCert and recognized by BSV identity clients. It specifies their exact identifiers, case-sensitive field names, plaintext meanings, issuer evidence requirements, and limits on reliance. These types use the encrypted certificate primitives of BRC-52 and the acquisition and selective disclosure methods of BRC-100. Issuance establishes an issuer's observation of an external account association with a subject key; public discovery remains a separate choice made by the subject.

The schemas and source observations are grounded in pinned public implementations. The proposed issuer and application requirements are a conformance profile, not a claim that those implementations already satisfy every requirement.

Motivation

An application can show an email address or social account name associated with an identity key without creating its own global username system. Independent issuers and wallets need to agree on what the certificate means, which fields to validate, and what remains uncertain. A recognizable badge or valid signature must not turn a historical observation into a claim of permanent ownership, legal identity, or present account control.

The existing type identifiers already have meaning in client software. Recording that meaning, while specifying careful issuance and disclosure behavior, avoids incompatible repurposing and permits users to choose certifiers and trust policies independently.

1. Status, scope, and terminology

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are interpreted as described in RFC 2119 and RFC 8174 when they appear in uppercase.

This is a proposed profile for three existing certificate types. Normative requirements apply to parties claiming conformance to the applicable role: issuer, acquisition application, or verifier. An implementation MUST identify its supported types and roles. Implementation observations and examples are informative. No live service conformance or deployment audit is asserted here.

BRC-52 remains authoritative for core certificate serialization, signing, field encryption, keyrings, and revocation. BRC-100 remains authoritative for wallet interfaces. BRC-103 and BRC-104 provide authenticated exchange. BRC-200 supplies general certifier operating procedures; this document adds the type-specific claim and evidence rules. The proposed BRC-189 identity integration profile provides broader discovery and personal-trust context; it is a separate proposal and is not required to understand these schemas.

• Subject: the BRC-52 subject key named in the certificate.
• Issuer: the BRC-52 certifier key signing the certificate.
• External account: the mailbox, X account, or Discord account checked during issuance.
• Verification event: the issuer's successful evidence check, bound to the intended subject and certificate type.
• Account association: the issuer's assertion that the requesting subject demonstrated the specified account access at a verification event.
• Public revelation: the subject's separately authorized disclosure of selected certificate fields for anyone to read, potentially through on-chain identity publication and public discovery.

The profile does not define government identification, legal-person status, KYC or AML compliance, eligibility for a regulated service, a unique-human registry, an OAuth protocol, or a W3C Verifiable Credential representation. A provider's use of those terms in old comments does not add those assertions to a signed Social certificate.

2. Existing type identifiers and schemas

The following identifiers are canonical Base64 encodings of 32-byte type IDs. A conforming issuer MUST use the exact identifier for the corresponding type. These identifiers describe field semantics; they do not grant one operator exclusive authority to issue certificates or compel a user to trust that operator.

These match the issuer definitions and SDK known types. Field names are case-sensitive: userName is not username. Plaintext values are strings encoded as UTF-8 and encrypted independently under BRC-52. The signed fields map contains ciphertext Base64 strings, not the following plaintext examples.

The image URL requirement is a proposed validation rule; the existing definitions supply example URLs and do not fully enforce this rule. If the provider has no usable image, the issuer MUST NOT invent an account-specific image assertion. It may decline issuance of this existing two-field profile, explain the limitation, or propose a distinguishable future schema. A placeholder that purports to be an observed account image is not an equivalent assertion.

A conforming issuer MUST sign exactly the field set above, with no additional fields. A certificate with extra fields can still have a valid BRC-52 signature, but it is outside this profile. Applications MUST NOT infer undocumented semantics from those fields or alter the signed field map while checking the signature. New certified facts, such as a stable provider account ID, observation time, expiration, or assurance class, require a separately specified distinguishable type and migration. They MUST NOT be silently appended to these identifiers as if every existing client understood them.

Values MUST be preserved exactly between evidence validation, encryption, and signature. An issuer MUST NOT lower-case an email local part or replace a username with a display name after verification. Any provider-specific normalization needed before a challenge MUST be documented and performed before defining the verified string. Verifiers MAY normalize a copy for a clearly described search or display purpose, but MUST retain the certified value and MUST NOT treat a fuzzy match as exact account equality.

3. Claim semantics and limitations

Under this profile, a certificate means: the named issuer checked account-access evidence for the intended subject and certified these observed attributes. The evidence method and its limits come from the issuer's published policy. The certificate does not carry the original authorization token, verification code, provider account identifier, or private evidence.

The three schemas have no certified observation time, expiry, or stable provider account ID. A serial number is not a timestamp. A blockchain publication time, discovery cache time, or issuer's unsigned response MUST NOT be presented as a certified account observation time. A verifier needing evidence of recent control MUST obtain a new verification event or other suitable authenticated evidence under its acceptance policy; the old certificate alone cannot supply that fact.

Names, image URLs, and mailbox access can change, and identifiers can be reassigned. Two subjects can legitimately obtain certificates associated with the same external account. An external account can be shared by several authorized people. A conforming issuer or verifier MUST NOT treat these types as a proof of one-human-one-key uniqueness or exclusive ownership of a name.

The subject key proves a binding within the certificate. A verifier requiring the presenter to control that key MUST also establish current key control through an authenticated exchange or an equivalent suitable challenge. Merely copying a valid certificate or encountering it in public discovery does not authenticate its presenter.

4. Type-specific issuer requirements

4.1 Issuer eligibility and evidence

Any issuer can implement this profile if it fulfills the applicable requirements and accurately publishes its methods and limitations. Each verifier independently selects acceptable certifier keys and policies. A CertMap description, type recognition in software, or friendly issuer name MUST NOT be represented as issuer accreditation or a universal trust decision.

Before issuance, the issuer MUST authenticate the requesting subject key, obtain the subject's authorization for the verification and intended certificate, and bind the verification event to that key and type. The issuer MUST obtain fresh evidence for the issuance operation within a documented bounded validity window. Its policy MUST state that window, how retries are handled, and when verification must be repeated. No universal duration is invented by this profile.

For Email, the evidence MUST demonstrate receipt of a challenge delivered to the claimed mailbox, or an explicitly documented method establishing equivalent mailbox access. A mere client-supplied email address, screenshot, or unverified request is insufficient. For X and Discord, the evidence MUST come from an authenticated account-access flow and an authenticated provider response identifying the account and its attributes, or a documented equivalent method. An unauthenticated profile page or a client-supplied name and photograph is insufficient. The issuer MUST document methods that materially differ from the public implementation basis and MUST NOT describe an unsupported provider response as verified.

External authorization state and challenges MUST be bound to the intended verification transaction and subject, expire according to the published policy, and be protected against reuse outside that transaction. A successful challenge MUST NOT silently authorize certificates for a different subject, different type, or different external account. Idempotent recovery of the same authorized issuance operation MAY reuse its completed verification record under the documented bounded policy.

4.2 Validate every signed field

In BRC-52 encrypted issuance, the issuer MUST decrypt each submitted field using the supplied master keyring and validate its exact plaintext against the same completed verification event. It MUST reject missing fields, unexpected fields, incomplete or undecryptable keyrings, and mismatched values before signing. X and Discord userName and profilePhoto MUST describe the same authenticated account response; independently plausible values are not enough.

The issuer MUST NOT treat a generic verification-success flag, a record for another subject, an email-only check, or a client-provided plaintext cache as evidence for all three certificate types. Successful authentication of the subject key and successful authentication of an external account are separate checks; both bindings are required.

The issuer returns a BRC-52 core certificate naming the authenticated subject and its actual certifier key, with the agreed type and exact encrypted fields. It MUST use BRC-52 signature semantics and the supported acquisition protocol. Legacy validationKey members or old example JSON MUST NOT replace the current BRC-52 signature procedure.

4.3 Minimize collection and preserve choice

An issuer MUST limit mandatory evidence collection to what is necessary to verify the specified account association and operate the stated issuance policy. It MUST NOT require government identity documents, unrelated social accounts, a private address book, or disclosure of unrelated wallet activity solely to issue this profile. A separate service needing other evidence must clearly separate that service and its claims from this certificate issuance profile.

The issuer MUST offer issuance without requiring the subject to publish the certificate or attributes for public discovery. It MUST NOT publish the subject's certificate, field-revelation keys, or private evidence on the subject's behalf without a separate informed authorization specifying the fields and audience. The issuer already sees the fields it verifies; BRC-52 field encryption does not hide those fields from that issuer.

The issuer SHOULD request the smallest provider authorization scope sufficient to check these fields, promptly dispose of tokens and codes no longer needed, and retain only the evidence needed for its disclosed dispute, correction, renewal, and incident policy. Authorization tokens and verification codes MUST NOT become certificate fields, public logs, public standards examples, or on-chain evidence. Routine verification MUST NOT require the issuer to remain an online intermediary for every later selective disclosure.

5. Acquisition and disclosure application behavior

A conforming acquisition application MUST distinguish verification, certificate acquisition, and optional public revelation. Each can fail independently. It MUST identify the issuer, type, intended plaintext fields, and disclosure choice clearly enough for the subject to authorize them.

The application uses BRC-100 acquireCertificate with the intended issuer key, type, and fields. The wallet and application MUST validate the acquired certificate under BRC-52 and the supported acquisition protocol, including subject and issuer binding, signature, exact returned encrypted fields, complete master-keyring decryptability, and acceptable revocation policy. A successful HTTP response or provider verification alone is not successful certificate acquisition.

Public revelation MUST be a separate explicit choice naming the fields to reveal. Private holding and selective disclosure to a named verifier MUST remain usable without a public identity publication. If an application offers publication, it MUST explain that public fields and their association with the subject and issuer can be copied indefinitely. Withdrawing discovery publication, removing a local certificate, and revoking a certificate are different operations; none promises deletion of information already disclosed.

Illustrative private acquisition of a synthetic Email claim:

const certificate = await wallet.acquireCertificate({
  acquisitionProtocol: 'issuance',
  certifier: selectedCertifierKey,
  certifierUrl: selectedCertifierURL,
  type: 'exOl3KM0dIJ04EW5pZgbZmPag6MdJXd3/a1enmUU/BA=',
  fields: { email: 'alice@example.invalid' }
})

This call follows a separately completed mailbox verification event. selectedCertifierKey and selectedCertifierURL must come from the user's selected issuer configuration; an HTTPS hostname alone does not authenticate the certificate signer. The example does not perform a live request or certify the reserved example address.

After separate publication authorization, an identity client can publish ['email'], or ['userName'] without profilePhoto. Selective revelation does not remove unrevealed encrypted fields from the issuer's signed certificate. BRC-52 proof creation preserves the full signed core and releases only the selected field keys. This proposal does not define a new discovery output or change BRC-100 transport encodings.

6. Revocation, renewal, and verifier behavior

The issuer MUST publish whether it uses a functioning BRC-52 revocation outpoint or the disabled sentinel 0000000000000000000000000000000000000000000000000000000000000000.0. A functioning non-sentinel outpoint must follow BRC-52 and the issuer's published control and monitoring policy. A verifier MUST reject a certificate as current when it has authenticated evidence that this outpoint is spent. An unavailable status check MUST NOT be relabeled a successful current-validity check.

The sentinel disables UTXO revocation. It MUST NOT be described as an unspent revocation output or proof that a certificate remains current. For a sentinel certificate, the verifier MUST either accept the limited historical account-association assertion for its stated purpose or obtain additional evidence sufficient for the freshness and status it requires. The profile does not invent an online status endpoint or make an issuer's unsigned status page authoritative.

Renewal after an account-name or image change MUST validate the new attributes and issue a new certificate with a new serial number. A previously signed certificate cannot be edited into a new claim. Subject-key changes require new subject-bound issuance; matching names do not establish key continuity. A conforming issuer MUST explain the limits of correcting or retiring old sentinel certificates and MUST NOT promise that reissuance invalidates every old copy.

A conforming verifier MUST check the BRC-52 signature, expected type, disclosed field keys and plaintext, subject binding where needed, its selected issuer policy, and applicable revocation and freshness requirements before reliance. It MUST attribute the assertion to the actual certifier. It MUST NOT upgrade this claim to provider endorsement, legal identity, permanent access, immutable photograph contents, or authority to act for the subject.

External strings and URLs are untrusted content. Applications MUST render names without executing markup or code. Applications SHOULD avoid automatic image fetches unless consistent with the user's privacy choices; image hosts can observe requests and image contents can change. An image URL MUST NOT become a payment destination or a key-continuity proof.

7. Implementation basis and migration

The public source baseline is SocialCert backend 79de17aa35797b34abcc7587d83cf137a895fa25, SocialCert UI b662c8a777c2db2915b32062b4532fbbfaf85255, and SDK 9e3ede6b6302480005259ca36cbc73d9b6509d53. These are source observations, not operational test results.

• The backend configuration enables Email, X, and Discord. It retains a disabled telephone definition.
• The Email handler uses a provider verification check. The X and Discord handlers obtain account attributes through provider authorization flows. These paths demonstrate the intended evidence sources; they do not establish end-to-end conformance to the requirements above.
• The signing route decrypts submitted fields and signs a Certificate with the authenticated subject. The baseline does not demonstrate complete type-specific evidence matching and profile validation for every enabled type. Implementers must add or establish those checks before claiming issuer conformance; this proposal does not change the running implementation.
• That signing path uses the disabled revocation sentinel. The server route configuration does not register the revoke handler, and the retained handler reports that it is unsupported. No working per-certificate UTXO revocation service is claimed.
• The UI separates acquisition from publication through a user-controlled choice in its Email, X, and Discord flows. The SDK identity client recognizes these types for display and can publicly reveal selected fields. Recognition and a rendered badge are not evidence of issuer compliance or a complete current-status assessment.

An implementation adopting this profile MUST preserve existing signed certificates and their original meanings. It MUST NOT relabel certificates from an unaudited historical issuance path as having passed these new issuance controls. Where provenance or verification time is unavailable, it SHOULD offer fresh issuance with explicit limits. New issuer controls can be deployed without changing these type IDs when their field meanings remain the same; expanded or incompatible signed schemas require distinguishable types.

The disabled telephone example has type mffUklUzxbHr65xLohn0hRL0Tq2GjW1GYF/OPfzqJ6A= and field phoneNumber. SDK and UI recognition do not establish an enabled issuer flow. Telephone issuance and normalization are outside this profile; the identifier MUST NOT be repurposed for one of the three types above.

8. Conformance criteria and tests

Tests SHOULD use synthetic accounts, fixtures, or controlled provider responses and MUST NOT require disclosure of production tokens, verification codes, private certificates, or customer evidence. BRC-52 primitive tests are required by the underlying implementation; the following tests exercise this profile's additional boundaries.

A conformance statement MUST identify the implementation revision, role, type coverage, tested evidence method, and outstanding limitations. Passing parsing or display tests alone is not issuer conformance. No test results for a production provider or issuer are asserted by publication of this document.

9. Security and privacy considerations

These credentials create linkable relationships among a subject key, issuer, and external account. Field encryption limits disclosure to parties receiving the relevant keys; it does not hide the field names, type, subject, issuer, serial, or ciphertext lengths. Public revelation makes selected plaintext available to observers indefinitely. Reusing a subject key or certificate across applications can create further correlation.

The issuer and account provider can observe verification activity. Unnecessary provider scopes, retained codes, broad log contents, and automatic image fetching expand that exposure. Issuers should minimize these observations and communicate retention limits. A certificate signature proves attribution and integrity, while the account assertion still depends on issuer practice and the selected evidence method. Account compromise, mailbox forwarding, account sharing, renamed accounts, and provider reassignment limit what receipt of a challenge or an authorization grant proves.

Users retain control over issuer selection, private certificate holding, and scoped disclosure. An issuer cannot legitimately make itself a universal identity gate merely because its type is recognized. Wallet permissions, personal contacts, optional metadata registries, certificate status, and an application's acceptance policy remain distinct decisions. No single name, photograph, directory result, or certificate authorizes a transaction or an action on another person's behalf.

References

• BRC-52: Identity Certificates, BRC-100: Wallet-to-Application Interface, BRC-103, and BRC-104.
• BRC-200: Operating Practices for Identity Certifiers, companion proposed operating guidance; BRC-189 identity integration proposal, broader context.
• BRC-116: Wallet Permissions and Counterparty Trust, BRC-184: Optional Metadata Registries and Their Stewardship, and registry submission guidance.
• SocialCert backend pinned source: Email schema, X schema, Discord schema, and verification routes in src/routes.
• SocialCert UI pinned source, acquisition and publication flows in frontend/src/pages.
• SDK known identity types and identity client.
• RFC 2119 and RFC 8174, requirement terminology.