Resolve Gate reference

ECZ-ID supplies evidence; your policy decides

1. You observe a native identity: an MCP server endpoint, an AWS role ARN, an Entra Agent ID, a SPIFFE ID.
2. Reverse-resolve it: Core answers which ECZ-ID holds it through a proven binding, and what is true of that binding now.
3. Direct-resolve the ECZ-ID it names for the current public record.
4. Your own policy reads the evidence and decides. The gate has no default decision.
5. Act, record your reliance as a receipt if you want one, and re-resolve before relying again.

Native resolution

POST https://api.ecocitizenz.com/api/v1/resolve/native with namespace, resource_type, identifier in a JSON body. A provider identifier (an ARN carries an account id) never sits in a URL or an access log. The answer is a ecz.native_resolution.v1 document.

BOUND is reached only through a proof Core itself observed on the exact identifier, by a route listed for its namespace; Core records that route as native.proof_method. No claimant, console or provider adapter can state it. Reverse resolution names an ECZ-ID only for a binding whose projection policy publishes the link at that moment (PUBLIC_WHEN_BOUND, PUBLIC_SETUP_INCOMPLETE and HASH_ONLY while the binding holds the identifier; PRIVATE_UNTIL_BOUND only while it is BOUND, never while DEGRADED or SUSPENDED) and whose owner has not withdrawn publication (A-45). NEVER_PUBLIC and CUSTOMER_OPT_IN bindings are withheld until an explicit reverse-resolution publication/consent primitive exists; consent is never inferred from target_public_value or any other field. A withheld binding is never named or confirmed and changes no answer: there is no existence or liveness signal. Historical ownership is not part of anonymous resolution; it stays in the owner's authenticated records.

There is no search by native identifier: a caller resolves one exact identifier it already holds. The public Resolver offers no native-identifier search in this release.

URL identifiers (mcp/server_endpoint, web/api_origin) are https on the default port: http://, any other port, userinfo, a backslash, an IDNA deviation character, and a host, path or query that a client would read differently (compatibility, invisible or white-space characters) are refused as INVALID_IDENTIFIER, never repaired. A path and query have exactly one accepted spelling, the request target Core's own fetcher sends for them; any other spelling is refused as INVALID_IDENTIFIER with error_code NATIVE_IDENTIFIER_URL_PATH_NOT_CANONICAL: a '.' or '..' path segment or an empty one ('//'), a ';' or an escaped '/' or ';' in the path, a lower-case or malformed percent-escape or one of an unreserved character, a bare '?', a raw "'" in the query, or a character the fetcher percent-encodes left raw (non-ASCII, or one of '"', '<', '>', '[', ']', '^', '`', '{', '|', '}'). The normaliser's work bounds (see INVALID_IDENTIFIER) are checked before this rule, so a spelling beyond them has their error_code (NATIVE_IDENTIFIER_TOO_LONG or NATIVE_IDENTIFIER_INVALID) instead. Resolve exactly the identifier your client connects to, spelled as your client requests it.

While the route is switched on, every answer it gives after admitting a request, a resolution or a refusal, comes no sooner than 0.5 seconds after the request started. At capacity it answers at once with HTTP 503 {"ok": false, "error": "unavailable"} and Retry-After: 1, whatever was asked; an unexpected fault is the same 503 body, without Retry-After. A request body over 8192 bytes (8 KiB) is refused with HTTP 413 {"ok": false, "error": "body_too_large", "limit": 8192}. While the route is switched off it does not exist: an empty HTTP 404. None of these is a resolution document: the gate reads each as RESOLUTION_FAILED with resolution null, and it never retries. Whether, when and how often to retry is the relying party's choice, bounded and explicit in its own code.

A RESOLVED answer carries the binding block exactly as the Resolver projects it, current (BOUND and inside its expiry), and freshness times. Then read https://api.ecocitizenz.com/api/p/{ecz_id}.json. The anonymous machine record of the ECZ-ID a RESOLVED answer names (direct_resolve.machine_json). It is the one follow-up read a public resolution points to, and it needs no key.

Supported native identifiers

Evidence status

The gate loop

import { createResolveGate } from './resolve-gate.mjs';

const gate = createResolveGate({
  // Your policy. ECZ-ID never decides for you.
  policy: (evidence) =>
    evidence.evidenceStatus === 'EVIDENCE_AVAILABLE' ? 'PROCEED' : 'HOLD',
});

const result = await gate.check({
  namespace: 'mcp',
  resourceType: 'server_endpoint',
  identifier: 'https://mcp.example.com/mcp',
});
// result.decision is your policy's answer; result.decidedBy is 'RELYING_PARTY'.

const later = await gate.recheck(result);
// later.materialChanges lists what changed since the evidence you relied on.

• The relying party supplies the policy. The gate has no default decision and returns whatever the policy returns.
• The policy is called for every evidence status, including RESOLUTION_FAILED: failing open or closed is the relying party's choice.
• Re-resolve before each consequential reliance, and on a schedule; a material change is a reason to re-decide.
• Reverse resolution is followed by direct resolution of the ECZ-ID it names.
• For a URL identifier (mcp/server_endpoint, web/api_origin) the gate sends the identifier exactly as a WHATWG fetch client requests it: the scheme and the host canonicalised by the WHATWG URL parser, so that ECZ-ID resolves the host your client connects to, and the path and query as that parser serialises them (dot segments removed, characters percent-encoded as it encodes them), without the fragment. Core accepts one spelling of a path and query, the request target its own fetcher sends, and refuses any other as INVALID_IDENTIFIER with error_code NATIVE_IDENTIFIER_URL_PATH_NOT_CANONICAL; the gate never repairs such an identifier or tries another spelling, so it is RESOLUTION_FAILED. It refuses, without sending a request, an identifier that is not https, that carries userinfo or a backslash, or whose path or query holds a character Core would fold or drop (an NFKC compatibility form, a control or format character, or trailing white space). It compares the resolved binding's target host with the host your client connects to.

Recording reliance

A DCI_RELIANCE receipt (ecz.receipt.v1) records that your organisation relied on resolved evidence. An OWNER or ADMIN of the relying organisation, through its signed-in TrustOps account. For a native resolution (resolution), Core recomputes the resolution digest from its contents, checks core_attestation when it holds the attestation key (refusing evidence it did not issue), and requires the binding it names to be one Core may confirm. For evidence Core attested, the binding must still exist for that same identifier, proven BOUND through a Core-observed route, under a projection policy that publishes the link, and not withdrawn; it need not still be current, and the facts recorded are Core's as of checked_at. For unattested evidence, public reverse resolution must name exactly that binding now (a current public holder), and the facts recorded are Core's at recording. Its checked_at must be no more than 24 hours old when Core records the reliance and no later than that recording time plus a 60-second clock leeway (else check CHECKED_AT_INVALID), and decided_at no earlier than checked_at less the same leeway; a decided_at in the future (a later second than the recording) is refused. For direct-resolution evidence (direct_resolution: an ecz_id and a digest), Core checks the format, and when the relying party states checked_at, it must be an RFC 3339 UTC timestamp held to the same three time rules. Core records that evidence as the relying party reported it (REPORTED_ONLY) and checks neither the digest nor a binding. Core never makes or endorses the decision. relying_party_decision is the relying party's own label, an upper-case token of 2 to 40 characters (A-Z, 0-9 or _, starting with a letter), and Core refuses one that is, or holds as a token in any case, a word in never_returned_by_ecz_id (check RESERVED_VERDICT_WORD).

• It carries the ECZ-ID relied on.
• It carries the resolution_digest relied on.
• It carries the relying party's own decision label and local policy reference.
• It carries the relying party's action reference.

Re-resolve and material change

A change to any of outcome, ecz_id, binding_state, current, binding_id between two resolutions is material. A re-check that only renews freshness is not.