didbot_claim_check/
lib.rs

1//! The consistency checks a `bot.did.operator` claim rests on, and the
2//! record it writes.
3//!
4//! `didbot-claim` runs these on the operator's own machine over a real
5//! network; the policy page runs the same ones in a browser, over `fetch`.
6//! Both call this crate rather than each writing the record their own way,
7//! so a claim written from a page and a claim written from the command line
8//! are the same record, field for field and key for key.
9//!
10//! # What these checks rest on
11//!
12//! The root of trust is the hostname itself: the operator delegated that
13//! zone, the server proved control of it by passing ACME DNS-01, and the
14//! certificate that produced is what TLS proves belongs to whoever answers
15//! the connection. Resolving the `did:web` document ([`document`]) and
16//! cross-checking `describeServer` ([`agree`]) are consistency tests layered
17//! on top of that connection, not a second proof — a reader who takes the
18//! DID match as the security boundary has it backwards.
19//!
20//! # What is not here
21//!
22//! The waiting and the probing are `didbot-claim`'s: whether TLS answers at
23//! all, how long to wait for a certificate, and what the operator's own
24//! machine can reason about zone delegation. A browser is handed a
25//! connection the fetch already made and never sees the certificate behind
26//! it, so a caller in one shows what it checked and says what it did not.
27
28#![forbid(unsafe_code)]
29
30pub mod agree;
31pub mod document;
32pub mod record;
33
34pub use agree::{describes_same_server, DescribeMismatch};
35pub use document::{did_json_url, parse_document, signing_key, SigningKeyError};
36pub use record::{
37    credential_record, key_fingerprint, operator_record, record_key, Allowance, Credential,
38    OperatorClaim, Scope, COLLECTION, CREDENTIAL_COLLECTION, OIDC_IDENTITY_TYPE, PUBLIC_KEY_TYPE,
39};
didbot_claim_check/lib.rs

didbot_claim_check/
lib.rs
