CBOR
Also called Concise Binary Object Representation, RFC 8949
CBOR is a binary data format built to do roughly what JSON does, represent structured data like numbers, strings, arrays, and maps, but more compactly, and faster to parse, at the cost of no longer being human-readable in a text editor. Where JSON is text ({"name":"Alice","age":30}), CBOR encodes the same structure as raw bytes with a compact, self-describing type-and-length prefix system, so a parser knows how many bytes a value occupies without scanning for a closing quote or brace.
The design goal is specifically constrained environments: embedded devices, smart cards, offline transfers over Bluetooth Low Energy or NFC, anywhere the extra bytes and parsing overhead of JSON's text encoding are a real cost, not a rounding error. It's a deliberate, minimal design, CBOR's own spec describes itself as aiming for "small code size, small message size, and extensibility without version negotiation."
CBOR shows up in the identity world as the foundation two related things build on: COSE (see that entry) is CBOR's answer to JWS, a signature envelope format assuming CBOR encoding throughout, and ISO/IEC 18013-5's mdoc format (see that entry) encodes an entire mobile driving licence's data, from individual claims to the issuer's signature, in CBOR. Anywhere a phone taps to present an mDL at a gate, CBOR is the byte-level format everything is actually written in.
Where it comes from
RFC 8949 (which obsoletes the earlier RFC 7049), authored by Carsten Bormann and Paul Hoffman, standardized through the IETF. Solidus has no editorial role in it.
Solidus status
Not built, for credentials. Every credential format Solidus ships today, SD-JWT VC, and the documented-but-not-live Data Integrity/Linked Data Signature shape, is JSON-encoded, not CBOR-encoded. No code anywhere in the credential-issuance, presentation, or verification path constructs or parses CBOR.
One exception worth naming directly, so this entry isn't technically wrong by omission: the Rust consensus layer's libp2p networking crate (solidus-p2p2/src/behaviour.rs) references CBOR as part of libp2p's own transport-protocol machinery. That's a dependency of the peer-to-peer networking stack itself, code Solidus didn't write to encode CBOR, using a format libp2p chose for its own reasons, and it has nothing to do with credentials. The "not built" answer for credential-format CBOR stands regardless; naming the one adjacent reference is more honest than pretending the grep came back completely empty.
Check it yourself: there's no credential-path demo to run, so this entry doesn't invent one. Pull any published @solidus-network package (sdk, types, auth, bbs) and grep its source for cbor, nothing appears anywhere near credential handling.
Where it comes from
Someone else specified this. Solidus assembles it.
RFC 8949 (obsoleting the earlier RFC 7049), authored by Carsten Bormann and Paul Hoffman, standardized through the IETF. It's the binary encoding underneath both COSE and ISO/IEC 18013-5's mdoc format (see those entries), CBOR is to mdoc/COSE roughly what JSON is to JWS/SD-JWT: the underlying data-serialization layer everything else builds on. Solidus has no editorial role in the spec.
How to check this
Solidus has not built this. The entry explains the concept.
None for credential-format CBOR. There is nothing to run. A stranger can grep any published @solidus-network package (sdk, types, auth, bbs) for "cbor" and find nothing in the credential-issuance path; the one CBOR reference in the whole monorepo is inside the Rust P2P networking crate, unrelated to credentials, named above rather than concealed.