POST /api/principals/xauth

Create an externally-authenticated (XAuth) principal. Idempotent by exact id.

Creates an XAuth principal, or reports the existing one unchanged.

This route resolves by exact id first and writes nothing when one exists. The principal-management module performs no lookup of its own, but the store enforces one id per XAuth principal, so a second creation would be refused as a generic failure (a 500) rather than minting a duplicate; the lookup-first shape is what makes a repeated provisioning call a read instead.

The id is stored VERBATIM and nothing maps it. There is no cross-reference table in this Gateway and none in the key server -- that is the point: the identity must be reproducible from the consuming application alone. namespaced reports whether it carries the recommended <application>:<user id> shape. That shape is not enforced, because enforcing it would be a scoping policy and scoping has not been ruled.

An empty id is refused rather than ignored: the underlying setter ACCEPTS the empty string and CLEARS the stored id with it, so an empty value would blank a column rather than doing nothing.

WARNING: with no roles, the principal holds no operations -- it can be impersonated and can do nothing, not even own a key. Roles are applied here as a genuine second call because the key server clears them on creation whatever is sent.

Authentication

Send the session id as Authorization: Bearer <session id>, and an RFC 9449 DPoP proof in the DPoP header if your session is bound to a key. The two are required together, not as alternatives — see Authenticating and Proving you hold your key.

This surface sets no cookie

There is no session cookie on any response and none is read on any request. Do not set credentials: "include" on a browser fetch.

Request

Field	Type	Required	Description
id	string	yes	The deterministic, namespaced identity, derived from your own user id. No leading or trailing whitespace and no control characters: it is stored verbatim and it is what an audit row names.
metaInfo	string	no	A string when present. Omit it to leave the field unset -- the empty string CLEARS it rather than leaving it alone.
roles	array of string	no	16-hex-digit role ids, from GET /api/roles.

Example

{
  "id": "...",
  "metaInfo": "...",
  "roles": [
    "..."
  ]
}

Responses

200

The principal exists, either created now or already present.

Field	Type	Required	Description
created	boolean	yes	False means it already existed and NOTHING was written.
namespaced	boolean	yes
requestedRoles	array of string	no
rolesApplied	boolean	no
principal	object	yes
detail	string	no

principal object

Field	Type	Required	Description
id	string	no	The XAuth id -- a string
principalId	string	no	Decimal string.
systemId	integer	no
metaInfo	string	no
flags	integer or null	no
disabled	boolean or null	no
roleIds	array of string	no

Example

{
  "created": true,
  "namespaced": true,
  "requestedRoles": [
    "..."
  ],
  "rolesApplied": true,
  "principal": {
    "id": "...",
    "principalId": "...",
    "systemId": 0,
    "metaInfo": "...",
    "flags": 0,
    "disabled": true,
    "roleIds": [
      "..."
    ]
  },
  "detail": "..."
}

400

The request was refused before anything was sent to the key server.

Most 400s on this surface carry code: BAD_REQUEST and a detail naming the field and saying what the key server would otherwise have done with it. A large share of them exist because the value would have been ACCEPTED downstream and quietly meant something else -- an empty string that reaches the wire as "mint a new key", a zero-length identifier that names no object, a numeric flag word that clears bits the caller did not name.

INVALID_ARGUMENT is the one 400 that DID reach the key server: the key server itself refused the argument (ERR_INVALID_ARGUMENT), and detail is its own sentence. On POST /api/certificates/enroll that is a certificate that cannot authenticate -- certificate not permitted for authentication: keyUsage is present without digitalSignature (...), ... extendedKeyUsage is present without clientAuth (...), or certificate expired at enrolment: notAfter <UTC> ... -- and a multi-certificate body that carries one such leaf persists nothing.

401

No live session, a DPoP proof that did not verify, or a certificate session whose certificate the key server now refuses.

SESSION_NOT_FOUND -- the credential names no session this Gateway holds. SESSION_EXPIRED -- it aged out. Both carry reauth: true; obtain a new credential rather than retrying.

PROOF_* -- the sender constraint refused. See the DPoP section of this document for the full table; PROOF_MALFORMED is a 400 and PROOF_REPLAY_CACHE_FULL a 503, and the rest are here.

SCOPED_CREDENTIAL_EXPIRED -- a scoped browser credential passed its fixed lifetime. Use does not extend it: an idle timeout would be refreshed by exactly the traffic a stolen handle produces.

CERTIFICATE_REVOKED -- on a session established by certificate login, the key server re-checks the certificate that session was established with on its operations, and it is now named by revocation evidence (ADR 0115). detail is the key server's sentence. Every later operation of the session is refused the same way; log in with a different certificate.

403

Authenticated, and refused. The codes differ in what they say about where the refusal came from: ACCESS_DENIED, PRINCIPAL_DISABLED and DELEGATOR_REFUSED are the key server's -- the last one on a DELEGATED session whose delegator has since been disabled, lost its DELEGATION flag, been unenrolled or had its certificate revoked (ADR-0123); its detail is the key server's sentence naming the delegator, and no new login helps until an administrator restores it. REVOCATION_STATUS_UNAVAILABLE and REVOCATION_EVIDENCE_STALE are the key server's too, on a session established by certificate login: the same re-check found no current revocation evidence for that certificate's issuer under a policy that requires it (ADR 0115) -- the credential is not what was refused, and an operator importing a current CRL for the issuer is what helps -- while NOT_WRITABLE, BUILT_IN_PRINCIPAL, OWN_ACCOUNT and OBJECT_NOT_IN_CREDENTIAL_SCOPE are decided by the Gateway before anything is sent.

409

ROLES_NOT_VERIFIED -- the principal is there and the roles were sent and not refused, and the read-back does not show them.

500

A fault rather than a refusal.

OP_FAILED is the catch-all: the key server refused in words that match no classified pattern, so the Gateway cannot say more than that the operation did not happen. Some key server refusals that are conceptually a caller error arrive here rather than as a 4xx, because the wire carries no distinguishing code -- where a route can recognise one from its message it maps it, and each such mapping is documented on the operation.

502

READBACK_FAILED -- creation was sent and not refused, and the principal was not present when read back by exact id. Do not simply retry: the store enforces one id per XAuth principal, so a retry meets the existing row or the same failure; read GET /api/principals?type=xauth first.

503

A capacity ceiling or a missing deployment prerequisite. retryable says which.

A scope of session or process names the ceiling that was hit, and the response carries Retry-After.

BUILD_NOT_ADMITTED (scope: process, retryable: true, Retry-After): the key server does not admit this Gateway's client build. Every key-server connection the Gateway opens attests the signed release it runs (TE_RELEASE_MANIFEST) right after it authenticates; while that attestation is refused -- the release is not registered at the key server's code-signing level, the level was raised under it, or the installed files no longer match the signed manifest -- every route but GET /api/health and GET /api/ready answers this, and detail names the cause. It is never a 401 or a 403: no credential or role of the caller's is at fault. The Gateway re-attempts on a timer and recovers without a restart once the key server admits it; GET /api/ready says when.

Error handling

Every failure answers JSON carrying at least code and detail. Match on code — detail is written for a human debugging the call and its wording is not part of the contract. See the error model.

Status	Meaning
400	The request was refused before anything was sent to the key server. Most 400s on this surface carry code: BAD_REQUEST and a detail naming the field and saying what the key server would otherwise have done with it. A large share of them exist because the value would have been ACCEPTED downstream and quietly meant something else -- an empty string that reaches the wire as "mint a new key", a zero-length identifier that names no object, a numeric flag word that clears bits the caller did not name. INVALID_ARGUMENT is the one 400 that DID reach the key server: the key server itself refused the argument (ERR_INVALID_ARGUMENT), and detail is its own sentence. On POST /api/certificates/enroll that is a certificate that cannot authenticate -- certificate not permitted for authentication: keyUsage is present without digitalSignature (...), ... extendedKeyUsage is present without clientAuth (...), or certificate expired at enrolment: notAfter <UTC> ... -- and a multi-certificate body that carries one such leaf persists nothing.
401	No live session, a DPoP proof that did not verify, or a certificate session whose certificate the key server now refuses. SESSION_NOT_FOUND -- the credential names no session this Gateway holds. SESSION_EXPIRED -- it aged out. Both carry reauth: true; obtain a new credential rather than retrying. PROOF_* -- the sender constraint refused. See the DPoP section of this document for the full table; PROOF_MALFORMED is a 400 and PROOF_REPLAY_CACHE_FULL a 503, and the rest are here. SCOPED_CREDENTIAL_EXPIRED -- a scoped browser credential passed its fixed lifetime. Use does not extend it: an idle timeout would be refreshed by exactly the traffic a stolen handle produces. CERTIFICATE_REVOKED -- on a session established by certificate login, the key server re-checks the certificate that session was established with on its operations, and it is now named by revocation evidence (ADR 0115). detail is the key server's sentence. Every later operation of the session is refused the same way; log in with a different certificate.
403	Authenticated, and refused. The codes differ in what they say about where the refusal came from: ACCESS_DENIED, PRINCIPAL_DISABLED and DELEGATOR_REFUSED are the key server's -- the last one on a DELEGATED session whose delegator has since been disabled, lost its DELEGATION flag, been unenrolled or had its certificate revoked (ADR-0123); its detail is the key server's sentence naming the delegator, and no new login helps until an administrator restores it. REVOCATION_STATUS_UNAVAILABLE and REVOCATION_EVIDENCE_STALE are the key server's too, on a session established by certificate login: the same re-check found no current revocation evidence for that certificate's issuer under a policy that requires it (ADR 0115) -- the credential is not what was refused, and an operator importing a current CRL for the issuer is what helps -- while NOT_WRITABLE, BUILT_IN_PRINCIPAL, OWN_ACCOUNT and OBJECT_NOT_IN_CREDENTIAL_SCOPE are decided by the Gateway before anything is sent.
409	ROLES_NOT_VERIFIED -- the principal is there and the roles were sent and not refused, and the read-back does not show them.
500	A fault rather than a refusal. OP_FAILED is the catch-all: the key server refused in words that match no classified pattern, so the Gateway cannot say more than that the operation did not happen. Some key server refusals that are conceptually a caller error arrive here rather than as a 4xx, because the wire carries no distinguishing code -- where a route can recognise one from its message it maps it, and each such mapping is documented on the operation.
502	READBACK_FAILED -- creation was sent and not refused, and the principal was not present when read back by exact id. Do not simply retry: the store enforces one id per XAuth principal, so a retry meets the existing row or the same failure; read GET /api/principals?type=xauth first.
503	A capacity ceiling or a missing deployment prerequisite. retryable says which. A scope of session or process names the ceiling that was hit, and the response carries Retry-After. BUILD_NOT_ADMITTED (scope: process, retryable: true, Retry-After): the key server does not admit this Gateway's client build. Every key-server connection the Gateway opens attests the signed release it runs (TE_RELEASE_MANIFEST) right after it authenticates; while that attestation is refused -- the release is not registered at the key server's code-signing level, the level was raised under it, or the installed files no longer match the signed manifest -- every route but GET /api/health and GET /api/ready answers this, and detail names the cause. It is never a 401 or a 403: no credential or role of the caller's is at fault. The Gateway re-attempts on a timer and recovers without a restart once the key server admits it; GET /api/ready says when.