Identity primitives for digital credentials, presentations, trust, and selective disclosure
Identity · SSI · OpenID4VCI · OpenID4VP · Wallet · ZK
ReallyMe SSI is the protocol-neutral identity and credential semantics layer of the ReallyMe stack. It defines shared models and policy for credentials, presentations, claims, canonical claim paths and commitments, selective disclosure, DIDs, trust, status and revocation evidence, credential formats, identity-oriented OAuth primitives, EUDI profiles, and stable protobuf/domain integration contracts.
Credential and presentation envelopes such as SD-JWT and mdoc are implemented independently of issuance and presentation sequencing. ReallyMe OpenID4VCI and OpenID4VP build on these capabilities without duplicating credential, trust, status, or disclosure logic.
SSI does not own HTTP orchestration, persistence, wallet lifecycle, key management, generic cryptography, concrete ZK circuits, or platform SDK packaging. External evidence and capabilities enter through explicit interfaces, keeping the semantic core portable across server, native, and WebAssembly environments.
Looking for the ReallyMe SDK? Start with ReallyMe Identity, the application-facing SDK for building issuers, verifiers, wallets, and identity-enabled applications. This repository supplies the shared identity and credential foundation beneath those SDKs.
| Area | Responsibility |
|---|---|
| Identity data | Typed credentials, presentations, normalized claims, canonical paths, and DID documents |
| Credential and presentation envelopes | RFC 9901 SD-JWT, construction and verification of issuer-signed mdoc documents, DeviceResponse processing, the ReallyMe canonical-envelope JWT profile, and the did:me proof profile |
| Presentations | Protocol-neutral construction, validation, requested paths, and disclosure requirements |
| Claims and commitments | Claim registries, canonical commitments, matching, disclosure planning, and derivation requirements |
| Trust | X.509 policy, trusted-list processing, registration evidence, and native/Wasm trust boundaries |
| Status and revocation | Status-list validation and composition of supplied OCSP, CRL, and StatusList evidence |
| DIDs | Method-neutral DID models, validation, resolution boundaries, and pluggable method implementations |
| OAuth | Shared, transport-injected OAuth primitives consumed by higher-level protocol implementations |
| EUDI | ETSI EAA policy, EU PID profiles, relying-party registration, and requirement evidence |
| Integration | Rust APIs, canonical protobuf schemas, ProtoJSON, bounded codecs, and typed errors |
| Assurance evidence | Standards vectors, negative cases, requirement mappings, fuzzing, and release gates |
This diagram describes conceptual ownership and composition, not Cargo dependency edges.
Applications
│
▼
ReallyMe Identity
application SDKs and composition
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
OpenID4VCI OpenID4VP Wallet
issuance presentation/session state · consent
│ / \ lifecycle · audit
│ / \
└─────────────▼ ▼
SSI ReallyMe ZK
identity and credential circuits and proof
semantics infrastructure
/ \ /
JOSE COSE /
\ │ /
└──────┴────────────┘
▼
reallyme/crypto
SSI defines what credentials, claims, commitments, trust evidence, status evidence, and disclosure requirements mean. SD-JWT and mdoc implement credential and presentation envelopes over those semantics. ReallyMe ZK is a sibling foundation: it defines circuits, proof contracts, artifacts, and proof providers for statements about SSI-owned semantics and commitments; it does not become the owner of credential semantics.
OpenID4VCI sequences issuance. OpenID4VP sequences presentation and composes credential and proof capabilities into verifier-bound sessions. Wallet owns durable inventory, lifecycle, consent, persistence policy, and audit state. ReallyMe Identity packages the complete stack for applications.
Generic cryptographic operations and JOSE and COSE mechanics remain in
reallyme/crypto,
reallyme/jose, and
reallyme/cose. SSI builds identity and
credential semantics on those foundations rather than reimplementing them.
| Layer | Responsibility |
|---|---|
| ReallyMe Identity | Application SDKs, platform facades, and final composition |
| ReallyMe OpenID4VCI | Issuance protocol mechanics and sequencing |
| ReallyMe OpenID4VP | Presentation protocol mechanics, session binding, and credential/proof composition |
| ReallyMe SSI | Credential and identity semantics, envelopes, commitments, trust, status, DIDs, and disclosure policy |
| ReallyMe Wallet | Inventory, lifecycle, consent, persistence policy, and audit state |
| ReallyMe ZK | Circuits, proof contracts, artifacts, and provider infrastructure |
| crypto / JOSE / COSE | Lower-level cryptographic, signing, encryption, and encoding mechanics |
The table describes the implemented SSI surface. It does not claim complete implementation of every feature in a cited specification or external certification.
| Standard or profile | Implemented SSI responsibility |
|---|---|
| RFC 9901 — Selective Disclosure for JWTs | SD-JWT issuance, disclosures, parsing, key binding, presentation, and validation policy |
| ISO/IEC 18013-5:2021 mdoc and mDL | Issuer-signed documents, DeviceResponse construction, issuer authentication, and DeviceAuth verification |
| W3C Verifiable Credentials Data Model 2.0 | Protocol-neutral credential and presentation models used by the supported envelope profiles |
ReallyMe did:me proof |
Dispatch and validation for the ReallyMe-defined es256-jws-cid-2025 suite; this is not a general W3C Data Integrity cryptosuite implementation |
| W3C Decentralized Identifiers 1.0 | Method-neutral DID document types, validation and resolution boundaries, and pluggable DID methods |
| IETF Token Status List draft-21 | Bounded JWT and CWT status-evidence parsing and validation |
| ETSI EAA and EU PID profiles | Typed metadata and policy checks plus executable requirement evidence for the supported eIDAS-aligned surface |
Generic JWS, JWT, JWE, COSE Sign1, and COSE Key mechanics remain in their foundational repositories rather than being reimplemented here.
| Goal | Start here |
|---|---|
| Build an issuer, verifier, wallet, or identity-enabled application | Use ReallyMe Identity |
| Implement issuance or presentation protocol behavior | Use ReallyMe OpenID4VCI or ReallyMe OpenID4VP |
| Integrate protocol-neutral credential, trust, status, DID, or disclosure behavior | Compose the reallyme-ssi facade in the ReallyMe source workspace |
| Use one independently published primitive | Select the corresponding component crate from its manifest and documentation |
| Develop or audit SSI | Use this repository and the complete gate described under Development |
| Path | Purpose |
|---|---|
crates/ssi |
Source-composition facade consumed by ReallyMe protocols and services |
crates/proto, crates/proto-codec |
Canonical SSI protobuf schemas, generated messages, bounded codecs, and validated mappings |
crates/credential, crates/claims |
Credential semantics, issuance APIs, normalized claims, commitments, and disclosure validation |
crates/envelopes/* |
SD-JWT, mdoc, canonical-envelope JWT, supported Data Integrity proof, and envelope-profile implementations |
crates/did/* |
DID primitives, validation and resolution engines, APIs, and method implementations |
crates/presentation/* |
Protocol-neutral presentation models, policy, validation, and SD-JWT support |
crates/trust/* |
Trust policy, X.509, trusted lists, JAdES, and Wasm trust boundaries |
crates/status, crates/revocation |
Local status validation and supplied revocation-evidence composition |
crates/delivery/*, crates/oauth |
Delivery artifacts and shared, transport-injected OAuth primitives |
crates/eudi/*, crates/audit |
EUDI registration, ETSI EAA, QEAA metadata, and audit-evidence policy |
conformance, vectors, fuzz |
Requirement inventory, standards vectors, negative cases, and adversarial testing |
The facade exposes identity-owned capabilities through stable paths including
reallyme_ssi::credential::api, reallyme_ssi::delivery,
reallyme_ssi::trust, reallyme_ssi::claims, reallyme_ssi::did,
reallyme_ssi::presentation, reallyme_ssi::oauth, and
reallyme_ssi::single_use.
Credential models own credential kind, profile, assurance, issuer, validity, status, subject binding, claim commitments, optional compliance evidence, and issuer signatures. OpenID exchange state, wallet persistence, and envelope-specific parsing remain outside those generic models.
Status components validate supplied evidence. Hosts are responsible for fetching, caching, and native OCSP or CRL provider selection. Trust components evaluate supplied evidence without acquiring ambient network authority.
Disclosure policy determines which claims may be disclosed and which verifier requirements need derivation. Concrete ZK circuit selection, witness building, proving, verification, and protocol-specific proof formats remain outside SSI and are composed by OpenID4VP.
The DID framework is method-neutral. Individual DID methods integrate through explicit method interfaces rather than coupling credential or protocol models to a specific DID implementation.
Generated protobuf types and bounded codecs form the durable integration contract. JSON is used where standards require interoperability; it is not a second in-process operation protocol.
Platform packaging is provided by ReallyMe Identity. Swift, Kotlin, TypeScript, native, and WebAssembly artifacts are composed there rather than shipped as independent SSI runtimes.
SSI is developed alongside the JOSE, COSE, and shared protobuf repositories. Use the checkout layout required by CI:
<workspace>/reallyme/ssi
<workspace>/reallyme/jose
<workspace>/reallyme/cose
<workspace>/me-id/protos
me-id/protos supplies imported protobuf contracts for linting, generation,
freshness, and wire-compatibility checks. The JOSE and COSE checkouts supply the
pinned upstream conformance suites exercised by the complete repository gate.
Published foundational crates—reallyme-crypto, reallyme-codec,
reallyme-jose, and reallyme-cose—remain version-pinned dependencies.
Check out the reallyme/release-readiness package at the SHA pinned by
rust-ci.yml into .release-readiness, then run the repository gate and core
workspace checks before submitting changes:
cargo fmt --check
scripts/lint-protos.sh
node .release-readiness/scripts/run-consumer-check.mjs
cargo clippy --workspace --all-targets --all-features -- -D warnings
node scripts/run_bounded_nextest.mjs native
cargo check --workspace --no-default-features --features wasm --target wasm32-unknown-unknown
cargo deny checkContributor-facing crate boundaries are documented in Architecture. Standards requirements and generated evidence are documented in the executable conformance inventory. Cargo metadata and release preflight are the authoritative package inventory.
SSI processes credentials, identity attributes, trust evidence, and cryptographic bindings. Parsers and codecs apply explicit input bounds; verification receives trust, status, time, and network-derived evidence through typed boundaries rather than ambient access. Production paths use typed errors, reject malformed or invalid credential signatures and SSI-owned proofs, and keep secret-bearing material behind explicit ownership and redacted diagnostic boundaries.
Report vulnerabilities through the security policy. Do not include credentials, identity attributes, private keys, trust evidence, access tokens, or production identity data in reports.
SSI is in active pre-1.0 development. Workspace crates advance in lockstep, but
only component crates whose manifests opt into publication are released to
crates.io; the reallyme-ssi facade remains a source-workspace composition
crate. Public Rust API changes follow Cargo's pre-1.0 compatibility rules.
Protobuf schemas additionally pass freshness and wire-compatibility gates
because they form cross-language integration contracts. Public crates declare
Rust 1.99 as their minimum supported Rust version.
Licensed under either the MIT License or the Apache License, Version 2.0, at your option.
Third-party components retain their own licenses and notices.
Copyright © 2026 by ReallyMe LLC.
ReallyMe® is a registered trademark of ReallyMe LLC.