SansID is an enforceable privacy boundary, not a promise that a verifier should collect less data while continuing to depend on document uploads. The core profile fixes the ciphersuite and message layout, uses blind issuance, hides the holder secret, binds every presentation to an origin and fresh nonce, rejects untrusted issuer keys, and rejects ambiguous or oversized encoded input.

Those properties are concrete and tested. A real deployment still has security-critical code outside this crate: issuer operations, holder application packaging, native hardware adapters, browser integration, server-side nonce consumption, trust registry management, and telemetry. An audit evaluates that complete deployment, not just the BBS+ arithmetic.

Do not represent an unreviewed integration as legal-age, identity, access-control, or compliance infrastructure. That is a claim about the whole system and its operation, not a limitation of the protocol's ability to minimize data disclosure.

The confidentiality and unlinkability properties depend on correct BBS+ implementation, fresh operating-system randomness, a protected holder secret, honest issuer issuance, verifier nonce handling, and the absence of identifying data outside the proof.

Do not disclose security vulnerabilities in a public issue. Contact the repository owner through GitHub and request an encrypted reporting channel. Include a minimal reproduction, affected revision, impact, and any mitigations already tested.

Avoid attaching real identity documents, credentials, secrets, or personal data to a report.

• Use a holder-secret provider that is gated by TPM 2.0, Secure Enclave, Android Keystore, or PKCS#11 hardware. Protect the credential envelope at rest with a non-exportable platform key, require user authorization for each presentation, and zeroize the released secret immediately after proof generation. The in-memory HolderSecret implementation is for local tests only.
• Keep issuer private keys in a hardened key-management boundary with access control, audit logs, backup recovery, and rotation procedures.
• Pin issuer public keys through a controlled trust registry. Never use a key solely because a holder sent it.
• Generate exactly 32 random bytes for every verifier request. Store request state server-side and atomically consume a nonce after success.
• Display the canonical origin and requested predicate in a user-controlled consent flow. Use a browser-native API or a reviewed native-messaging bridge where possible. A plain loopback HTTP service is not equivalent to a browser-native credential API.
• Serve websites over HTTPS and apply strict origin checks at the local integration boundary.
• Limit and protect logs. Do not retain raw presentations, browser identifiers, IP addresses, or timing data longer than operationally required.

This profile has no anonymous credential revocation mechanism. A verifier cannot learn that one individual credential has been revoked without a separately designed privacy-preserving revocation system.

The profile signs the boolean age_over_18. It does not prove a numeric birthdate range. Issuers must determine the predicate during issuance.

The proof does not prevent a person from obtaining several credentials. Issuers must enforce their own issuance policy.

An attacker who can authorize use of the holder secret on the device can produce valid proofs. Hardware-backed envelope protection prevents offline credential copying from becoming immediately reusable, but it cannot protect a fully compromised device or a compromised consent path. Commodity TPMs and Secure Enclaves protect authorization keys and envelope access. They do not generally execute SansID's BLS12-381 proof arithmetic internally.

The proof does not hide IP address, browser fingerprint, cookies, account identity, timing, or other application-level metadata. These can still correlate activity across verifiers.

The BBS+ dependency is a cryptographic building block, not a substitute for a complete application audit. BBS and related specifications remain active areas of standardization and research. Pin dependencies, review advisories, reproduce test vectors, and obtain independent review before production use.