Glossary · every term, in plain English

Every KYE Protocol™ term, in plain English.

Defined once, used consistently. Where the term is a trademark of the KYE Protocol™ project, the ™ is shown; where it is a generic concept, it is not. Glossary anchors are stable URLs — link to glossary.html#authority-finality in your own docs.

architecture Core protocol bolt Runtime verified Evidence rule Compliance workspace_premium Programme extension External
Core protocol

Identity, authority, and the chain.

  • EntityAnything the protocol can name and reason about: a human, a service, an AI agent, a model, a tool, a workflow. Every entity has a URN.
  • URNThe canonical identifier format: kye:<class>:<trust-domain>:<subclass>:<local>. Stable, namespaced, human-readable. Defined in public/id-format/.
  • ActorThe entity actually performing an action. For an AI agent paying a merchant, the actor is the agent.
  • PrincipalThe entity on whose behalf the actor is acting. For the same payment, the principal is the customer or business that delegated authority.
  • on-behalf-ofThe relationship between actor and principal. A first-class object in the protocol — not a header, not a claim, an object with its own schema and endpoint.
  • DelegationA signed grant from one entity to another. Carries the authority being delegated, the scope it can be exercised under, and any constraints. Delegations form chains.
  • AuthorityThe protocol's noun for "what an entity is allowed to cause to happen." Authority binds a capability + scope + state to an actor + principal pair.
  • CapabilityThe named verb in the action vocabulary — e.g., payment.initiate, data.read. Capabilities are first-class with their own schemas.
  • ScopeThe constraint set bounding an authority — amount cap, currency, corridor, time window, beneficiary allowlist, etc. Children inherit parent scope (attenuation rule).
  • AttenuationThe rule that a child authority's scope must be a subset (⊇) of its parent's. The chain only narrows; it never broadens.
  • StateThe current lifecycle status of an entity / authority / payload — e.g., active, quarantined, suspended, revoked. The protocol enforces transitions.
  • Authority Graph™The protocol's view of entities + delegations + authorities + capabilities + scopes as a typed graph. Every relationship is a typed edge.
    • Runtime

    Decision, enforcement, cascade.

  • DecisionThe runtime's verdict on a single requested action: allow, allow_with_constraints, require_approval, deny — plus a reason code.
  • Decision codesThe standard set: allow_with_constraints, require_approval, deny. Stable across versions; mappable to your own code-set via the conformance pack.
  • Decision Map™The signed, replayable artefact emitted with every authorise call. Shows which inputs led to which decision; verifiable offline with public keys.
  • PEP — Policy Enforcement PointThe component that intercepts an action and asks the PDP for a decision. Lives in your application; ships as a reference Express middleware.
  • PDP — Policy Decision PointThe component that evaluates the request against authorities + state + scope and returns a decision. Ships as the reference Gateway.
  • ePDP — Edge PDPA locally-cached, offline-capable PDP for the bank/merchant edge. Walks the chain, verifies signatures, returns a decision in < 1 ms.
  • CascadeThe propagation pattern applied when an upstream authority is revoked or quarantined; downstream-derived authorities become unusable before the originating request returns. Mechanism is part of the patent track.
  • Authority Finality™The protocol-level guarantee that a request's authority chain is verified before the action takes effect — not after. The technical and evidentiary foundation behind the entire protocol.
    • Evidence

    Audit chain, packs, replay.

  • Audit chainThe append-only, hash-linked sequence of audit events the runtime emits. Every entity creation, delegation, authority grant, decision, and state transition lands here.
  • Evidence PackA signed bundle of audit-chain entries + Decision Maps™ + signatures + public-key set, replayable end-to-end with public keys alone. The artefact a regulator or auditor verifies.
  • Evidence Graph™The graph view across multiple evidence packs — how decisions, authorities, and audit events relate. Used for incident reconstruction and dispute resolution.
  • Blast Radius Map™The view of which downstream authorities and active sessions a single revocation or quarantine signal will reach. Pre-emit; helps operators choose the right action.
  • Proof bundleThe transport format for an evidence pack: signed JSON over JWS, or COSE-Sign for embedded contexts.
  • Payload stateThe lifecycle status of a single payload: signed, verified, replayed, tampered. Defined in public/vocabulary/payload-states.md.
  • CanonicalisationJCS (RFC 8785) canonical JSON form, used for hashing and signing. Ensures bit-exact reproducibility across implementations.
  • Ed25519The default signing primitive across credentials and proof bundles. Specified by the spec; alternatives are enumerated, not extensible.
    • Compliance

    Mapping rail, OSCAL, frameworks.

  • Control mappingThe named link from a protocol artefact to a regulatory control — e.g., evidence pack → SOC 2 CC7.2. 266 mappings across 13 frameworks.
  • KYE Compliance Mapping Rail™The runtime channel through which evidence becomes per-framework projection. One signed evidence pack → many framework views.
  • AI System Compliance Card™The public-key-verifiable nutrition label for any AI system: which controls are evidenced, against which framework, with which signing keys.
  • OSCALNIST Open Security Controls Assessment Language. The protocol projects to OSCAL component-definition / SSP / assessment-results / POA&M, so OSCAL-native auditors keep their workflow.
  • ProfileA scoped overlay of the spec for a specific sector or use case — kye-payments-1.0, kye-custody-1.0, etc. 36 v1.0 profiles, 5 v1.1 preview.
  • Non-goalsThings the protocol explicitly does NOT do — replace SCA, replace tokenisation, run fraud scoring, etc. Documented in the threat-model page.
    • Programme

    Conformance, certification, partner ladder.

  • Conformance packThe 38 black-box fixtures any implementation runs to demonstrate spec compliance. Reproducible on a laptop; deterministic outputs.
  • KYE Self-Tested™L1 of the conformance ladder. You run the fixtures locally and self-declare results.
  • KYE Self-Attested™L2. Signed self-attestation (Ed25519, JWS) bundled with fixture results.
  • KYE Conformant™L3. Programme-reviewed conformance report + badge + registry listing.
  • KYE Certified™L4. Third-party-audited certification by an approved firm. Annual revalidation.
  • KYE Cloud™The optional commercial layer: hosted Registry, Validator, Evidence Vault, Conformance Runner. The protocol works without it.
  • RFCThe four-stage process for landing changes: discussion → spec PR → conformance fixture → sign-off. Documented on the working groups page.
    • External standards we compose with

    For reference, not redefinition.

  • OAuth 2.0 / OIDCHuman-centric authorisation + identity federation. KYE Protocol™ composes; it does not replace.
  • SPIFFE / SPIREWorkload identity for services. Composes with KYE™ entity URNs at the trust-domain boundary.
  • MCP — Model Context ProtocolTool / agent communication protocol. KYE™ capability profiles map onto MCP tools.
  • KYA — Know Your AgentThe general industry term for agent attestation. KYE Protocol™ is the open contract layer that makes KYA, KYC, and KYB interoperable.
  • PSD3EU revised Payment Services Directive. KYE Protocol™ open-banking profile binds delegated payment-initiation authority to PSD3 SCA + reporting obligations.
  • DORAEU Digital Operational Resilience Act. The protocol's audit chain + evidence packs satisfy DORA's incident-reconstruction obligations.
  • EU AI ActThe Union's horizontal AI regulation. The protocol provides evidence for high-risk-AI obligations; conformance is a customer obligation, not a protocol claim.
    • Where to go next

    Adjacent reading.

    category The 6 primitives → menu_book Vocabulary architecture Protocol menu_book Whitepaper help FAQ