Skip to content

mid-types: the wire format as a no_std leaf; mid-verify no_std over it - #1

Open
Ttimmahlax wants to merge 1 commit into
mainfrom
no-std-types
Open

mid-types: the wire format as a no_std leaf; mid-verify no_std over it#1
Ttimmahlax wants to merge 1 commit into
mainfrom
no-std-types

Conversation

@Ttimmahlax

Copy link
Copy Markdown

What

  • mid-types (new): the mID wire-format types (MidJwtPayload, ClaimValue, AttestedBy, EmbeddedGenesisRoster, EmbeddedRosterChainEntry, VerificationMethod, EmbeddedVerificationMethod, the request types) and canonical::{genesis_canonical_bytes, chain_entry_canonical_bytes}, moved verbatim out of mid-issuer. no_std + alloc; std (default) only forwards to serde and serde_json. The unit tests moved with them.
  • mid-issuer depends on mid-types and re-exports everything from the same module paths (mid_issuer::types::*, mid_issuer::canonical::*, and the pub use in the root), so no consumer changes.
  • mid-verify depends on mid-types instead of mid-issuer, is #![no_std] with alloc, and gains a std default feature that forwards to its dependencies. thiserror moves to 2.x for the no_std derive.

Why

A device that signs its own genesis roster and self-issued token — the Janus ESP32 family (rusty_esp_mid) — was carrying a copy of these types. It now imports them from mid-types; its oracle tests, which compare its canonical bytes with mid-issuer's and verify its tokens with mid-verify, pass unchanged (28 unit + 7 oracle tests, including a byte-identical genesis-roster canonical form). A verifier that fits a chip is the second half of the same seam.

API changes (please read)

  • VerifyError::Base64Decode { segment, source }{ segment, cause }. base64 implements the error trait only with std, so the field cannot be an implicit source on the no_std arm; under std it is still marked #[source].
  • VerifyError::PayloadJson keeps From<serde_json::Error> (hand-written) and its #[source] under std.
  • Everything else is path-compatible.

Gates run here

gate result
cargo test -p mid-types -p mid-verify 10 + 26 green
cargo check -p mid-types -p mid-verify --no-default-features --target riscv32imac-unknown-none-elf clean
cargo check --workspace clean
cargo clippy -p mid-types -p mid-verify --all-targets -- -D warnings clean; kms-client already fails clippy on main (a generic-array deprecation in signer.rs:94), untouched here
downstream: rusty_esp_mid-core on this branch 28 unit + 7 oracle tests green, riscv32imac with and without alloc

🤖 Generated with Claude Code

mid-issuer's wire types (the JWT payload, embedded rosters and
verification methods) and the canonical signing bytes move to a new
`mid-types` crate that is `no_std` + `alloc` (`std` forwards to serde and
serde_json). mid-issuer re-exports them from the same module paths, so
nothing that named `mid_issuer::MidJwtPayload` or `mid_issuer::canonical`
changes. mid-verify depends on mid-types instead of mid-issuer, is
`#![no_std]` with `alloc`, and gains a `std` default feature that only
forwards to its dependencies; thiserror moves to 2.x for the no_std
derive. One API change: `VerifyError::Base64Decode`'s field is `cause`
(base64 implements the error trait only with std, so the field cannot be
an implicit `source` on the no_std arm; `#[source]` is kept under `std`),
and `PayloadJson` keeps its `From<serde_json::Error>` by hand.

Why: a device that signs its own genesis roster and self-issued token
(the Janus ESP32 family) should carry these types from here rather than
keep a copy; a verifier should fit a chip.

Gates: `cargo test -p mid-types -p mid-verify` (10 + 26 green),
`cargo check -p mid-types -p mid-verify --no-default-features --target
riscv32imac-unknown-none-elf`, `cargo check --workspace`. clippy on
kms-client already fails on a `generic-array` deprecation on main;
mid-types and mid-verify are clippy-clean.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants