@wellknown-id/wallet/service
The wallet service: everything a wallet does, made once from the platform's ports. An app builds it with createWalletService(ports), calls its commands, listens for what changed (on), opens and closes it as the app comes to the front and goes, and puts to the holder what only they can answer (open's asks). The app itself keeps no state and makes no decisions: kivi is such an app, over its platform adapters.
@wellknown-id/wallet/view
What a wallet's screens may use besides the service: pure functions over values, with no storage, keys or network. Everything that acts goes through the service (@wellknown-id/wallet/service).
@wellknown-id/wallet/self-issued
Self-issued proofs (prd.md §4.11): the token a holder's page signs with their key for your site, in SIOPv2's self-issued ID token shape. The IdP checks it and issues an ordinary ID token; a site whose config says self_issued: "allow" may take it straight from the page and check it here with verifySelfIssued. WebCrypto only: it runs in Node, browsers, Deno and Workers alike.
@wellknown-id/wallet/grants
Delegation for sites (prd.md §7.13): checking a grant that lets one holder act for another at your site, and whether it still stands. A grant is a JWS the granter signs with their key for your site, sealed to your site's HPKE key and posted to the mailbox your config names; look it up at every use (grantStands): gone means taken back.
@wellknown-id/mailbox
A mailbox that keeps ciphertext under ids its writers choose, and answers anyone who knows an id: wellknown.id's relay runs one, and a site that accepts delegation may run its own. It can't read what it holds, tell whose it is or link one id to another, logs nothing, and throws away what's extinct. Mount mailboxHandler in a server of your own, or run createMailboxServer (or the wellknown-mailbox command).
@wellknown-id/emrtd
Reads and checks passports and ID cards (ICAO 9303 eMRTDs) over any card transport: BAC or PACE, the data groups, passive authentication against country signing certificates, and Chip or Active Authentication. Nothing here knows the hardware: native NFC, a USB reader or the virtual passport in testing implement CardTransport.
Web SDK (web.js)
The web SDK as a page sees it: <script src="https://wellknown.id/sdk/web.js"> defines the <wellknown-id-button> element, tells the page how each sign-in ended with two window events, and adds window.WellknownId. Types only: the script is served by wellknown.id, not installed.
The /.well-known/id config
The /.well-known/id config a site publishes (prd.md §5), as wellknown.id's IdP reads it: its shape, and how it's found (DNS first, then HTTPS) and checked. A site's client_id is its domain; the config there says where sign-ins may return, how codes are redeemed, what the site declares about the data it keeps, and whether it accepts delegation.