Credentials, Presentations, and Selective Disclosure

A not.bot™ identity carries credentials. A credential is a signed statement by one entity (the issuer) about another (the subject). Credentials let a user prove facts about themselves without revealing more than they intend, without contacting the issuer at presentation time, and without granting the recipient the ability to re-present the underlying claim.

The credential model is the operational substrate of every interaction a not.bot user has with the outside world. Signatures carry credentials. Website verification exchanges carry credentials. The proof-of-human guarantee that distinguishes a not.bot signature from any other digital signature is itself a credential. This document covers the architecture: how credentials are structured, what Julia Social issues, how a user presents them, and the trust properties that follow.

Single-claim credentials

A W3C verifiable credential is a JSON-LD document containing some number of claims. Each claim is a statement about the subject. The entire credential, including all claims, is signed by the issuer.

Julia Social credentials constrain that model. A Julia Social credential carries one claim. Each claim is signed by the issuer on its own. Metadata about the credential lives in a separate document that the claim references by hash.

Multiple Julia Social claims will often share the same metadata file hash. When they do, the claims can be combined into a W3C JSON-LD verifiable credential document. The data the claims contain is extracted into the JSON-LD structure, and the individual claims, the metadata document, and the hash reveals that tie them together are placed in the document's proof segment. The result is a standard W3C verifiable credential. The Julia Social model remains interoperable with W3C tooling that consumes that format.

This design avoids zero-knowledge cryptography. Selective disclosure, in most W3C-style implementations, requires zero-knowledge proofs to present a subset of claims without invalidating the issuer's signature over the whole credential. Schemes built on BBS+ and similar primitives are complex in practice and computationally expensive. Single-claim credentials make selective disclosure a list operation: present the claims you want, omit the ones you don't. The signatures on the presented claims remain valid. The omitted claims never appear.

The design also lets credential claims be presented directly on the Chia blockchain. Each signed claim is self-contained and compact enough to fit inside an on-chain spend. Any smart contract on the Chia blockchain can examine any credential the holder chooses to present and condition its behavior on the result. No other blockchain identity model gives smart contracts this kind of direct access to verified user credentials.

The applications span any context where on-chain logic needs to know something verified about the entity initiating an action. On-chain KYC for regulatory-compliant DeFi is one notable case: a contract can enforce that participants hold the credentials a jurisdiction requires, with no off-chain gatekeeper sitting in front of the protocol. Pay-to-credential, where a coin is controlled by the right to present a specific credential, is another. The pay-to-credential section below covers that pattern.

Property names

Every claim names the property it carries. The verification-level credentials above show the form: notbot://./v1/notbot0. The age credentials, the Domain Name credential, the personal-information credentials each carry a name in the same shape. The name is a URI, and its structure is load-bearing. An issuer designing a credential schema works in this grammar.

A bare name like is_admin is the problem the grammar solves. Read it cold and the questions stack up. Administrator of what system? Administrative privileges, or the job title an office shortens to "admin"? Give the claim a value of 5 and the ambiguity compounds: level five, on what scale. A name with no issuer behind it and no statement of how its value is encoded tells a verifier nothing it can act on. A well-formed property name describes both the meaning of the claim and the encoding of its value, so a verifier reading it knows when, where, and why the claim applies and how to interpret what it holds.

The three components. A property name is a URI of the form encoding:authority/path.

• Encoding sits left of the :// and says how the claim value is encoded. cleartext://./.julia-payment carries an unencoded value. sha2-256|CBOR://./v1/domain_name carries a value that was CBOR-encoded and then SHA2-256-hashed.
• Authority names the DID whose namespace defines the property's semantics. A . means the issuing DID is the authority, so notbot://./v1/notbot0 reads as "a property defined by the issuer of this credential." A full DID in the authority position points the verifier at a different namespace, which is how one issuer can issue claims whose meaning a separate body defines.
• Path is the issuer's own taxonomy: /v1/pii/age_range_18_20, /v1/employee/badge/image. The issuer owns the path space under its authority and lays it out however its schema needs.

The hash round-trip. The on-chain claim does not store the cleartext property name. It stores sha2-256(property name). At presentation, the holder includes the cleartext name, the verifier hashes the name it expects to see and checks the result against the hash in the signed claim. A match confirms the claim carries the property the verifier is asking for.

The encoding pipeline. A claim value is reduced to a 32-byte commitment before it goes into the claim. The encoding segment of the property name describes that reduction. Encodings pipe with |, applied left to right: zip|sha2-256 compresses the value and then hashes it; rsa3072|zip|sha2-256 encrypts to a single verifier, compresses, then hashes. The current encodings are cleartext, sha2-256, argon2id, aes256gcm, rsa3072, zip, and CBOR. The hashing encodings produce a commitment a verifier confirms by re-hashing the value the holder supplies. The encrypting encodings let an issuer restrict which verifier can read a value, so an issuer can mint a credential only the intended recipient can decode. The raw parameters each encoding takes, salts, key fingerprints, nonce placement, live in the encoding registry in did:julia Technical Specification (Doc #15) and Chialisp Code Reference (Doc #19).

Reserved namespaces. The julia and notbot property namespaces belong to Julia Social. A third party cannot mint names under them. A property name in either namespace is a Julia Social-defined credential, and decoding its value uses Julia Social software.

did:julia Technical Specification (Doc #15) carries the formal grammar for property names and the full encoding registry.

Credentials Julia Social issues

Julia Social issues the credentials that ground a not.bot identity's interaction with the world. Most carry personal information sourced from the user's passport.

Personal information

During enrollment, the not.bot app reads the passport's NFC chip and verifies the issuing government's digital signature on the data. The static personal-information fields, FirstName, FamilyName, Gender, and Nationality, each become a separate single-claim credential. Julia Social produces each one through a multiparty computation and signs it without seeing the value, the same blindness that covers every credential Julia Social issues. These credentials state what the passport showed on the day the user enrolled and expire three years later. The birthdate and the claims derived from it follow a different lifecycle, covered under Age credentials below.

A user can enable or disable each credential type on each alias independently. The first alias has personal information enabled by default. New aliases have all personal information disabled by default.

The same value issued to two different aliases produces two cryptographically distinct credentials. A user's first name held by their journalist alias cannot be correlated with their first name held by their personal alias. The unlinkability property described in Identity Architecture (6A) applies to credentials by construction.

Age credentials

The birthdate, its components, exact-age claims, age thresholds (AgeOver13 through AgeOver25, plus AgeOver100), and five-year and ten-year age range brackets for ages 20-99 are all derived from the passport's date of birth through a three-party multiparty computation among the not.bot app, Julia Social, and the Escrow Server (operated by Praxis, the independent escrow agent). Neither Julia Social nor the Escrow Server learns the user's birthdate. The MPC produces correctly valued, Julia Social-signed credentials without exposing the underlying data to either participant.

These credentials carry a one-calendar-month validity window: Valid-From the first of the month, Valid-To the last day. They refresh together through the same MPC, and every threshold and bracket is issued each time, including the ones that do not apply to the user, so the set requested never reveals which ones apply. When a user crosses an age threshold, the refreshed credentials reflect the new threshold without either party learning when the crossing occurred, because each request re-encodes the full set.

The app requests fresh birthdate-derived credentials for an alias only when it does not already hold valid ones for the current month. This caching is a privacy measure, not an efficiency one: refetching on every presentation would give Julia Social and the Escrow Server a usage-frequency signal, and caching denies it. The user can also refresh by hand with a button in the app.

The not.bot credential

Every alias holds a not.bot credential. The credential proves the alias belongs to a passport-verified human. It carries a cryptographic value, the not.bot ID, computed through an MPC between Julia Social and the user's app. Neither party can derive the user's identity from the value alone. Julia Social uses the not.bot ID to construct and sign the credential, but does not store it. The value cannot be linked back to the user's passport data outside of one narrow circumstance.

That circumstance is law enforcement access. When a court order requires it, Julia Social can identify the holder of a specific not.bot ID through a process that requires Praxis's cooperation. Neither party can do it alone. The mechanics are covered in Law Enforcement (Doc #9). For the credential architecture, the relevant point is that the not.bot credential lets a verifier confirm "this signature came from a verified human" without learning who.

Verification levels

Three credentials describe the strength of identity proofing the user completed at enrollment. Each is a distinct verifiable credential with its own URI:

• notbot://./v1/notbot0: at-home enrollment via NFC passport scan (current state)
• notbot://./v1/notbot1: in-person enrollment at a contracted partner under NIST SP 800-63A IAL2 procedures (planned)
• notbot://./v1/notbot2: in-person enrollment at a Julia Social-operated facility (planned)

The levels are cumulative. A notbot1 holder also holds notbot0. A notbot2 holder holds all three.

Cross-issuer enforcement runs through the credential infrastructure. If Julia Social suspects a notbot1 partner of substantial fraudulent issuance, Julia Social can melt the partner's issuer key singleton. The melting operation invalidates every credential the singleton ever signed in one on-chain transaction. Affected users must re-enroll elsewhere.

The verifier requests the minimum level appropriate for the use case. The user presents only what the verifier requested. The verifier does not learn the user's maximum verification level unless the user volunteers it. A user holding notbot2 can present a notbot0 response to a notbot0 request without revealing the higher level.

Site Pass

A Site Pass is a pairwise identifier unique to a single human-site combination. The same human always produces the same Site Pass for a given site, regardless of which alias they used to interact. The same human produces different Site Passes for different sites. Sites cannot correlate Site Passes across sites.

The Site Pass is computed through a three-party MPC between the user's app, the site's Verify instance, and Julia Social. The protocol prevents Julia Social from learning which site generated the request and prevents the site from learning the user's identity.

Site Pass is the named exception to the general unlinkability property. A user opts into it for a specific site when the site needs sybil resistance. The site learns "this person, on my site" without learning who or correlating across sites.

Verified Signer

The Verified Signer credential links an alias to an online account, often a social media handle. The alias presents the credential alongside content the user signs, and the badge appears in addition to the alias's petname or reserved name. The credential carries the property AccountName on the verified alias, with the account identifier as the value, signed by Julia Social after the user completes the verification proof.

Domain Name

A Business DID holds a Domain Name credential that links the DID to a DNS domain. A user's app receiving a verification request from a Verify instance checks the request's Domain Name credential against the domain in the universal link or QR code, so the user sees a verified site identity before deciding whether to respond.

Selective disclosure

A user presents only the claims a verifier requested. Single-claim packaging makes selective disclosure a list operation: include the claims that match the request, omit the rest.

Property granularity. The verifier requests specific properties. AgeOver18 is a separate credential from AgeOver21, and both are separate from BirthDate. A site can request AgeOver18 and receive only that property's value. The site does not learn the user's age, age range, or birthdate.

Boolean values. Many claim values are boolean. AgeOver18 is true or false. Requesting the claim and receiving a value tells the verifier exactly what they asked, not more.

Volunteered claims. The user can present more than the verifier requested, but the default is to present only what was asked. The verification level credentials illustrate this: the holder of a higher-level credential can present a lower-level response to a lower-level request without revealing the higher level.

Declined claims. The user can decline to present one or more claims the verifier requested, even if they hold the requested claims. The user can also decline to provide a presentation at all.

Credential metadata

A claim references its credential metadata by hash. The metadata document contains the issuer's human-readable name and description, claim-specific names and descriptions, language translations, and the W3C-standard refresh-service, terms-of-use, and evidence fields.

A holder presenting one claim does not have to include the full metadata document. Parts of the metadata can be elided without invalidating the link between the document and the claims that reference it. If the metadata document describes three claims and the holder presents only one, the metadata for the other two can be omitted.

Issuer name, description, and icon fields in the metadata file are not trustworthy on their own. Any DID can create a credential and write anything it wants into the metadata. A verifier confirms the issuer's identity through a holder presentation of a credential that names the issuer's DID, issued by a trusted third party (Julia Social being the common case for business names).

External metadata and the tracking signal. Metadata can live outside the claim. An issuer can host a claim's name, description, and icons in its DID document instead of carrying them inline, which keeps presentations smaller and lets the issuer correct a typo or add a language translation without reissuing. Fetching that external metadata hands the issuer a usage signal. The party that retrieves it tells the issuer's server that this credential was used, and the request timing and origin say where and when. That is the phone-home pattern this document foregrounds, reappearing one layer down. not.bot defaults to inline metadata so a presentation reveals nothing to the issuer. A holder can elide external metadata links before presenting, and a verifier can ignore external metadata even when a presentation includes it. Privacy Architecture (Doc #7) carries the formal assertion that credential use does not contact the issuer.

Issuer design and validity timing. An issuer chooses a claim's validity window and its revocation index, and both choices can leak the subject's data if the issuer is careless. An issuer that sets Valid-From on an "over 18" credential to the subject's eighteenth birthday writes the birth date into the validity window, and any presentation of that credential exposes it. An issuer must not encode a sensitive attribute in validity timing. A revocation index assigned in issuance order leaks that order, and comparing two credentials' indices then reveals which was issued first and roughly how many an issuer has issued. An issuer assigns indices so issuance order stays hidden; Cryptographic Foundations (Doc #12) covers the index-randomization mechanism. not.bot ships these designs already. The rules become load-bearing for every issuer once third parties run their own issuer keys, which Roadmap (Doc #20) describes.

Antecedents

A claim can depend on other claims. The dependency is called an antecedent. A claim is valid in a presentation only when its antecedents are also presented and valid.

Antecedents express the relationships that real-world authority structures embed. An access-control claim depends on a role-membership claim, which depends on an employment claim. A claim about an event award depends on a claim about event participation. The antecedent links make these dependencies machine-verifiable.

Cascade revocation. When an antecedent claim is revoked, every claim that lists it becomes invalid in any future presentation. The verifier walks the antecedent chain at presentation time. One revocation can collapse a tree of derived authority.

Cross-issuer. Antecedents do not have to share an issuer with the dependent claim. A claim can list antecedents from any number of separate issuers. The dependent claim's issuer learns only that the antecedent claims exist and have not been revoked, not the values they carry.

Cross-subject. Antecedents can name subjects other than the subject of the dependent claim. Two-person-rule constructions become expressible: a pair of mutually-antecedent claims, each held by a different subject, can only be presented when both subjects merge their presentations.

Structural disclosure. Presenting a claim discloses the existence and property hashes of its antecedents, and the antecedent claims themselves must be presented for the verifier to accept the presentation. An issuer designing a credential schema should treat the antecedent structure itself as visible to verifiers.

Conditional delegations. A delegation is itself a credential claim, and a delegation claim can carry antecedents. A delegator uses antecedents to give the verifier context about the purpose of the delegation, and to ensure the delegation cascades correctly when an underlying credential is revoked.

Holder presentations respect antecedents. A holder presentation of a claim, presented as supporting context rather than as a subject claim, also requires the antecedents to be included. A holder cannot present a claim's existence without also presenting the basis for its validity.

Worked example: cross-issuer with cascade. A company grants administrator access to its Accounts Payable system through a credential claim. The Accounts Payable Admin claim depends on three antecedents: an In Department: Finance claim issued by the company's HR delegate, a Good or Excellent credit-rating claim from a credit bureau, and a No Felonies claim from a background-check provider. The company's HR delegate issues the access claim. It never sees the underlying credit score or the contents of the background-check report; it learns only that the external claims exist and remain valid.

The employee presents the Accounts Payable Admin claim with all three antecedents bundled into the same verifiable presentation. The verifier confirms the access claim, walks each antecedent to its issuer's revocation record, and authorizes the action.

When the background-check provider later revokes the No Felonies claim, the next attempted use of Accounts Payable Admin fails. The verifier walks the antecedent chain, finds the background-check claim revoked, and rejects the presentation. The company took no action; the change at the external issuer was sufficient. The same cascade applies to internal role changes: a transfer from Finance to Marketing requires only that the company revoke the In Department: Finance claim, and every access claim that depended on it becomes unpresentable in the same instant.

Worked example: cross-subject. A hospital pharmacy requires two licensed pharmacists, working together, to authorize any dispatch of a controlled substance. The pharmacy issues a pair of Authorized Dispatcher claims for each pairing of pharmacists, where each pharmacist's claim lists the other's parallel claim as an antecedent.

When Pharmacist A attempts to present their Authorized Dispatcher claim, the antecedent requirement pulls in Pharmacist B's parallel claim. Pharmacist A's claim cannot be presented on its own. To authorize a dispatch, the two pharmacists combine their presentations into one verifiable presentation that contains both claims.

If either pharmacist is unavailable or unwilling, the dispatch cannot proceed. No central system enforces the two-person rule; the antecedent structure enforces it cryptographically.

Delegation as a topic is covered in Delegation and Organizational Identity (6C).

Verifiable presentations

A verifiable presentation is the package a holder assembles to share identity information with a verifier. It can contain signed messages, credential claims, delegation proofs, a timestamp, and a nonce. The package is cryptographically self-contained: everything needed to verify it is bundled inside.

did:julia presentations operate in three modes. The same identity and the same credentials work in all three.

On-chain

A presentation submitted to the Chia blockchain creates a permanent public record. On-chain presentations support actions that need that record: voting in a decentralized organization, exercising on-chain rights, interacting with a smart contract. The blockchain transaction includes the credential presentation alongside any other operations the identity is performing in the same spend.

Online off-chain

Most uses of a not.bot identity are off-chain. The holder constructs a presentation and sends it directly to the verifier. The verifier checks it locally against the blockchain. No transaction is recorded. No third party participates.

Off-chain presentations carry an invalidator condition that prevents the spend bundle from being submitted to the blockchain. The condition is structural: the bundle asserts a constraint that can never be satisfied (a concurrent spend of a coin that does not exist). The verifier accepts the presentation because all the cryptographic proofs check out, but no one can take the same bundle and put it on-chain. The act of presenting a credential off-chain cannot be repurposed into a permanent on-chain record of the interaction.

Since off-chain presentations do not consume a blockchain transaction, the same identity can produce any number of them at once. Each is verified on its own.

Fully offline

A presentation can be verified without internet access. The verifier needs a snapshot of the issuers it cares about: the issuer DIDs, their active signing keys, and the current revocation records. The snapshot contains nothing about individual holders.

The holder provides a self-contained proof package: the original key the alias DID was created with, a log of any key changes since, and the credential presentation. The verifier can confirm the DID was created with that key, that the current key is the legitimate one, and that the credential was issued to this DID, without ever having seen the DID before.

A game warden in a remote area, a venue gate at an event, a vehicle inspection in a tunnel: each can carry a snapshot of the relevant issuer and verify credentials from holders the device has never seen.

Holder presentation

Subject presentation is the direct case: the subject of a credential presents it as a statement about themselves. Holder presentation is the second case: anyone who holds a copy of a credential can present it as supporting context, not as a statement about themselves.

A holder presentation lets a recipient see that a credential exists and is genuine, in support of a separate claim.

Holder presentation example: concert proof of attendance

A band and a ticketing company each hold Business DIDs. Three credential claims describe the chain of authority around a concert:

The ticketing company gives the fan a copy of all three claims when the fan attends the concert. To prove later that they were there, the fan assembles a verifiable presentation containing:

• A subject presentation of the attendance claim (the fan is the subject)
• A holder presentation of the authorized-seller claim (the ticketing company is the subject; the fan is not)
• A holder presentation of the domain claim (the band is the subject; the fan is not)

A verifier who trusts Julia Social's domain credentials can confirm the full chain: the band owns the concert's domain, the band authorized this ticketing company to sell tickets, and the ticketing company issued the fan an attendance credential. The fan never claims to be the band or the ticketing company; the holder presentations supply the chain that establishes who the attendance issuer was.

Antecedents can make this required. If the attendance claim lists both the authorized-seller claim and the domain claim as antecedents, presenting the attendance claim requires presenting both holder presentations. The verifier cannot accept the attendance claim on its own.

Receiving a holder presentation does not make the recipient a holder of the underlying claim. The signatures on the claims in a presentation are aggregated into a single BLS signature over the whole presentation envelope, and the envelope carries a nonce that binds the signature to this specific presentation. An aggregated BLS signature cannot be disaggregated into a signature over the claim alone, except through signature subtraction, which the nonce prevents. The recipient of a holder presentation cannot extract the underlying signed claim and re-present it elsewhere.

The architectural consequence is meaningful: collecting verifiable presentations does not let a verifier build a stockpile of presentable credentials. Each presentation stands on its own.

An issuer can mark a credential as non-delegatable when it is issued. A non-delegatable credential cannot be holder-presented at all; only the subject can ever present it.

Delegated presentation, the case where a subject explicitly authorizes another identity to present a credential on their behalf, is covered in Delegation and Organizational Identity (6C).

Pay-to-credential

A coin on the Chia blockchain can be controlled by a credential rather than by a cryptographic key. The coin's owner issues credentials, one per coin, granting the holder the right to spend the coin. The holder spends the coin by presenting the credential on-chain.

The model is useful because granting and expiring access are off-chain operations. Issuing a credential and letting that credential expire requires no on-chain transaction. The coin remains as it is until the moment the holder spends it.

A human can issue credentials for a hundred coins to an AI agent off-chain. The agent can delegate access to a subset of those coins to another agent, with a short expiration (one hour, for example). Coins the delegate does not spend in that hour become unavailable to it. Similarly, when the agent's coin credentials expire, the coins become unavailable to the agent. The human owner retains access at all times. To revoke access before expiration, the owner can update the issuer key singleton's revocation bitfield, which cancels up to 512 credentials in a single on-chain transaction.

Pay-to-credential demonstrates the expressive range of the credential model: an identity can grant and expire rights to economic resources at off-chain speed, and revoke rights in batches with a single on-chain operation, while the coins themselves only see on-chain activity at the moment a right is exercised.

The sibling pattern, a coin owned by a DID outright rather than controlled by a credential, is covered in the Asset ownership section of Identity Architecture (6A).

Self-attested credentials

An identity can issue credentials about itself. A user issues a credential giving the value of their chosen avatar, with themselves as both the issuer and the subject. Other identities can hold that credential and reference it when corresponding with the user.

Self-attested credentials let a user attach verifiable profile data to their identity without involving an external issuer. The mechanism (self-delegation, where the identity delegates issuance authority to its own key) is covered in Delegation and Organizational Identity (6C).

No phone home

A verifier checking a not.bot credential does not contact Julia Social. The check runs against the Chia blockchain. The revocation bitfield, the issuer key singleton, the alias DID's current state, and any antecedent credentials are all read from the chain.

The property is structural across all three presentation modes:

• On-chain presentations. The transaction itself executes on the chain. No off-chain server participates.
• Online off-chain presentations. The verifier's blockchain read can hit any of the thousands of public Chia nodes, the verifier's own node, or any other node they choose. Julia Social is not on the path.
• Fully offline presentations. The verifier checks against a local snapshot of issuer state. Julia Social is not contacted at all.

Creating a credential presentation and verifying one are the most common operations a not.bot user performs, and the most common interactions between a not.bot user and the outside world. Neither operation contacts Julia Social.

Julia Social is a signer to the No Phone Home movement (https://nophonehome.com/), which promotes verification architectures in which the identity issuer is not on the verification path. The not.bot credential architecture is designed to satisfy that principle by construction.

Privacy Architecture (Doc #7) carries the formal assertions. System Architecture (Doc #13) presents the no-phone-home property in the system view.

What lives where

Identity Architecture (6A) covers the structure of a not.bot identity: root and alias DIDs, the cryptographic basis of the identifier, ownership models, display names, and hidden aliases. Credentials are bound to alias DIDs; the unlinkability properties of credentials follow from the alias derivation structure described there.

Delegation and Organizational Identity (6C) covers the delegation infrastructure: issuer delegation (how Julia Social signs every credential through a singleton-bound delegate key), credential delegation (how a subject authorizes another identity to present their credentials), self-delegation as the mechanism behind self-attested credentials, the revocation operations on the issuer key singleton, Business DIDs and their governance models, and the custodian capability.

Recovery (6D) covers the recovery model.

The did:julia Technical Specification (Doc #15) is the implementer-facing reference for the on-chain protocol, complementary to the conceptual treatment here.

View this page as Markdown