Which principal is this credential? Answered from what require_token already verified.
More
NOT gated on the read scope: "which principal am I" must be answerable by ANY authenticated
caller, including one that may not read workspace data. A credential that cannot discover what
it is cannot be used correctly.
THAT NOW INCLUDES MACHINE CREDENTIALS. This route used to 403 every non-human caller, which
contradicted the paragraph immediately above it: an api key could not find out what it was. The
dashboard's api-key mode therefore had to GUESS its scope, and guessed optimistically — showing
admin affordances the server then refused. Nothing answered here is a disclosure: every field is
a property of the very credential the caller is already holding.
id is the PRINCIPAL's identity, and its shape follows the kind: Identity's user id for a
human (not a webhookd row id — webhookd stores no users), and the credential label otherwise
(key:<prefix>, a service JWT's sub, or bootstrap). The label is a DISPLAY string, so
treat it as one — it tells the caller what it is; it is not a handle to look anything up by.
role is the human tier and is empty for a machine credential, which has none.
email and created_at are null because they are not token claims, so webhookd genuinely
never sees them; Identity's own /api/v1/account/me is the source for those. scope is the
field the dashboard needs here to gate admin affordances proactively, and it is exactly the
scope require_token enforced.