Files
zeekayandHanzo Dev e4fc5ab433 Read IAM at the addresses IAM serves
The three binaries that resolve identity from IAM each spelled its addresses in
their own string literals, and every one of those literals named a verb-noun
address IAM no longer serves. A guard reads the 410 as "not this person", so the
SSO and waitlist paths denied everyone they could not resolve any other way.

The address is now a value with one home (package iam) that all three read:

  account       -> /v1/iam/account          envelope, reader unchanged
  one person    -> /v1/iam/users/{owner}/{name}
  people        -> /v1/iam/users?owner=     owner-scoped, no ownerless listing
  organizations -> /v1/iam/organizations    cursor-paged, 100 to a page
  applications  -> /v1/iam/applications?owner=
  roles         -> /v1/iam/roles?owner=
  audit trail   -> /v1/iam/audit-logs?owner=

The resource collections answer the list itself under a key named for the
resource, so the admin API reads that key rather than unwrapping `data`, and
pageSize/p/field/value/sortField are gone -- the collections take limit/offset
or a cursor, and an unknown key binds nothing at all. audit-logs, roles and
applications answer an owner whole, so the caller's page is applied where the
page now is.

iam.User refuses anything that is not two non-empty segments: half an identifier
would otherwise address the collection, which answers 200 with a list that every
reader here would take for one person.

Tests assert the address each guard asks for and that a 410, a 401, a 200
carrying {"status":"error"} and a half identifier all deny. The account read
answers its refusal at HTTP 200, so the status code alone never decides there.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-23 21:49:26 -07:00
..
2026-08-23 21:49:26 -07:00