Agent Admission — Issue

PROPOSED — not yet upstreamed. Built to the ToIP spec.meta.schema.json for the dtgwg-trust-tasks-tf registry; the slug below is proposed to that namespace, not registry-accepted. The PR is pending; the registry's decision governs.

Proposed slug: agent-admission/issue · version 0.1 · status draft

The gate authority offers the bilateral relationship credential that admits an agent — only when both gates passed and their evidence resolves into a verified audit ledger; the agent's counter-signature completes it.

Abstract

The Agent Admission — Issue Trust Task completes the ceremony: the gate
authority offers a bilateral relationship credential — a W3C Verifiable
Credential expressing the admission relationship, first-signed by the gate
authority — and the candidate agent's counter-signature in the #response
completes it. In ToIP terms the ceremony is a Trust Spanning Protocol
relationship formation between two VIDs: exactly two proofs, two roles, two
distinct parties. A self-signed credential is a named rejection
(notBilateral), not a degenerate case.

Issuance is where the ceremony's rules are enforced in order:

the audit ledger verifies, or the ceremony is void before any gate is weighed;
both gates — a passed supervisor approval AND a passed understanding
challenge, distinct kinds — or no credential (missingSupervisorGate /
missingUnderstandingGate);
the verdict comes from the closed lexicon: validated → deploy within
granted scope, failedHeldOut → sandbox, blocked → hold and no
credential at all (blockedNoIssuance);
every gate's evidence resolves into the verified ledger;
the tier is derived by the published scope function from the recorded
assessment, never negotiated — a flattering tier is refused
(tierScopeMismatch).

Status of this Document

This is a draft Trust Task specification per SPEC.md §5.3; the schema MAY change without notice. Feedback via the issue tracker.

Conformance

RFC2119(https://www.rfc-editor.org/rfc/rfc2119) and RFC8174(https://www.rfc-editor.org/rfc/rfc8174) key-word conventions apply.

A conforming producer (the gate authority) MUST:

Emit a Trust Task document whose type is https://trusttasks.org/spec/agent-admission/issue/0.1, with itself as issuer, the admitted agent as recipient, and a verifiable proof.
Enforce the five rules above, in order, before emitting the offer; the checks are the producer's because only the gate authority holds the ledger and the recorded gates.
Carry both gate results (with evidence digests), the verdict, the tier grant, and the ledger head in the payload, so the offer is auditable standing alone.
First-sign the embedded credential in the gate-authority relationship role.

A conforming consumer (the candidate agent) MUST:

Verify the proof, the embedded credential's first signature, and that the credential's subject is itself.
Re-check what it can from outside: both gates present and of distinct kinds, verdict in the closed lexicon, evidence digests present. An agent SHOULD refuse to counter-sign an offer whose gates it cannot see.
Counter-sign in the agent relationship role and return the completed credential in the #response. The credential is not in force until the counter-signature exists — admission is a relationship, and a relationship has two signatures.

Payload

payload.applicationId (REQUIRED) — the completed application.
payload.agent (REQUIRED) — VID of the admitted agent; MUST equal recipient.
payload.verdict (REQUIRED) — from the closed lexicon.
payload.tierGrant (REQUIRED) — the derived tier and its published scope function.
payload.gates (REQUIRED) — exactly two gate results, distinct kinds.
payload.ledgerHead (REQUIRED) — digest of the audit-ledger head at issuance.
payload.credential (REQUIRED) — the first-signed W3C Verifiable Credential.
payload.ext — extension slot per SPEC.md §4.5.1; an external anchor reference (evidence, never authority) belongs here under the anchoring vendor's namespace.

Request

{
  "id": "urn:uuid:7d3c8196-a0b4-4fc2-e4d5-6e7f80910213",
  "type": "https://trusttasks.org/spec/agent-admission/issue/0.1",
  "issuer": "did:key:z6MkGateAuthorityExample",
  "recipient": "did:key:z6MkCandidateAgentExample",
  "issuedAt": "2026-07-18T10:25:00Z",
  "payload": {
    "applicationId": "app-7c1b2a90",
    "agent": "did:key:z6MkCandidateAgentExample",
    "verdict": "validated",
    "tierGrant": {
      "tier": 6,
      "scopeFunction": "https://gate.example.com/policy/deployment-rules/3.1#scope-function"
    },
    "gates": [
      {
        "gate": "understandingChallenge",
        "passed": true,
        "at": "2026-07-18T10:12:05Z",
        "evidenceDigest": "1d2e3f4a5b6c7d8e9f001d2e3f4a5b6c7d8e9f001d2e3f4a5b6c7d8e9f001d2e"
      },
      {
        "gate": "supervisorApproval",
        "passed": true,
        "at": "2026-07-18T10:20:02Z",
        "evidenceDigest": "2e3f4a5b6c7d8e9f102e3f4a5b6c7d8e9f102e3f4a5b6c7d8e9f102e3f4a5b6c"
      }
    ],
    "ledgerHead": "3f4a5b6c7d8e9f20113f4a5b6c7d8e9f20113f4a5b6c7d8e9f20113f4a5b6c7d",
    "credential": {
      "@context": ["https://www.w3.org/ns/credentials/v2"],
      "type": ["VerifiableCredential", "RelationshipCredential"],
      "issuer": "did:key:z6MkGateAuthorityExample",
      "credentialSubject": {
        "id": "did:key:z6MkCandidateAgentExample",
        "relationship": "admitted-agent",
        "tier": 6,
        "applicationId": "app-7c1b2a90"
      },
      "proof": [
        {
          "type": "DataIntegrityProof",
          "cryptosuite": "eddsa-jcs-2022",
          "created": "2026-07-18T10:25:00Z",
          "verificationMethod": "did:key:z6MkGateAuthorityExample#z6MkGateAuthorityExample",
          "proofPurpose": "assertionMethod",
          "proofValue": "z3FXQmV6ExampleFirstSignatureGateAuthorityRole"
        }
      ]
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2026-07-18T10:25:00Z",
    "verificationMethod": "did:key:z6MkGateAuthorityExample#z6MkGateAuthorityExample",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3FXQmV6ExampleProofValueForAgentAdmissionIssue"
  }
}

Response

The agent returns the completed, counter-signed credential. The credential now
carries exactly two proofs — the gate authority's and the agent's — in the two
relationship roles.

{
  "id": "urn:uuid:8e4d92a7-b1c5-4ad3-f5e6-7f8091021324",
  "type": "https://trusttasks.org/spec/agent-admission/issue/0.1#response",
  "issuer": "did:key:z6MkCandidateAgentExample",
  "recipient": "did:key:z6MkGateAuthorityExample",
  "threadId": "urn:uuid:7d3c8196-a0b4-4fc2-e4d5-6e7f80910213",
  "issuedAt": "2026-07-18T10:25:04Z",
  "payload": {
    "applicationId": "app-7c1b2a90",
    "credentialDigest": "4a5b6c7d8e9f2021324a5b6c7d8e9f2021324a5b6c7d8e9f2021324a5b6c7d8e",
    "counterSigned": true
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2026-07-18T10:25:04Z",
    "verificationMethod": "did:key:z6MkCandidateAgentExample#z6MkCandidateAgentExample",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58aKqExampleCounterSignatureAgentRole"
  }
}

Security & Privacy

The offer discloses verdict, tier, gate outcomes, and evidence digests — audit
metadata, not challenge content; the submission and the answers never leave the
application record. The bilaterality requirement is load-bearing: a credential
one party can mint alone is an assertion, not a relationship, and everything
downstream (delegation policy, revocation, external anchoring) assumes the
relationship reading. Where the outcome is anchored on an external registry via
ext, the anchor MUST carry digests and tier only — anchors are evidence,
never authority, and revocation MUST mirror to the same registry (see
agent-admission/revoke).

Assets

Source: specs/agent-admission/issue/0.1/ — spec.md + payload.schema.json

📎 agent-admission-issuepayload.schema.json spec.md

upstream: ~/dtgwg-trust-tasks-tf-mage (untracked contribution lane; upstream registry: trustoverip/dtgwg-trust-tasks-tf) · author: Mitchell Travers · the git source wins on any disagreement · (⚔️⊥⿻⊥🧙)😊

← The Trust Tasks · Welcome Visitors