GET /api/policy-parameters

Read the four XAuth/X.509 auto-provisioning policy parameters.

Reads exactly four parameters -- the two auto-create switches and the two role lists that form a single machine-to-machine mechanism. Each is read with its own request, so that one absent key does not fail the other three.

WARNING: present: false is INFERRED FROM A REJECTION, and the rejection does not distinguish an absent parameter from a transport failure: the key server's refusal for a missing key arrives with its code collapsed to a generic one, which is the same shape a dropped connection can produce. The raw error travels as readError so you can see what it actually was. No substring of it is matched to synthesise a status.

effective reports whether each role list is REACHED. A role list whose paired auto-create switch is off does nothing at all: the role assignment lives inside the auto-create branch and is never reached with auto-creation off, so the list is stored and ignored. Set both, or neither has an effect.

WARNING: there are TWO switches, and these parameters are the second one. The first is an enabled attribute in the key server's CONFIG DOCUMENT, which ships off and is reachable through POST /api/config/update -- and also requires a restart. With either switch off, a delegated login against an unseen target is refused with an unknown-principal error naming the target.

WARNING: the four keys DO NOT SHARE WRITERS. The two auto-create keys ship writable by one role and the two role lists by another, so on a key server with split duties one identity cannot write both. It appears to work on a stock fixture only because the default administrative principal holds both roles.

writers are role IDS as lowercase hex, which is the comparison key; writerNames is display-only and is never compared.

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

No request body.

Responses

200

The four parameters, and whether each role list is in force.

Field	Type	Required	Description
parameters	array of object	yes
effective	array of object	yes
detail	string	no

parameters[] object

Field	Type	Required	Description
key	string	no
label	string	no
grammar	string (boolean, role-list)	no
present	boolean	no
absenceMeans	string	no
absenceDetail	string	no
writers	array of string	no
writerNames	array of string	no
readError	string	no	Present only when the read was rejected.
raw	string	no	Present only when present is true.
decoded	boolean	no
decodedAs	string	no
roleIds	array of string	no
malformed	boolean	no
malformedDetail	string	no

effective[] object

Field	Type	Required	Description
key	string	no
requiresCreatePrincipal	string	no
createPrincipalOn	boolean	no
roleCount	integer	no
inForce	boolean	no
detail	string	no

Example

{
  "parameters": [
    {
      "key": "...",
      "label": "...",
      "grammar": "boolean",
      "present": true,
      "absenceMeans": "...",
      "absenceDetail": "...",
      "writers": [
        "..."
      ],
      "writerNames": [
        "..."
      ],
      "readError": "...",
      "raw": "...",
      "decoded": true,
      "decodedAs": "...",
      "roleIds": [
        "..."
      ],
      "malformed": true,
      "malformedDetail": "..."
    }
  ],
  "effective": [
    {
      "key": "...",
      "requiresCreatePrincipal": "...",
      "createPrincipalOn": true,
      "roleCount": 0,
      "inForce": true,
      "detail": "..."
    }
  ],
  "detail": "..."
}

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.

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.

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
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.
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.
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.