Capability profiles

bnw.capability-profile/1 is the first portable application-layer descriptor for a BNW capability. It is a UTF-8 JSON blob addressed by its BLAKE3 content ID and referenced by a signed CapabilityManifest.

The BNW networking core treats descriptor bytes as opaque. The bnw-profile crate and CLI provide strict parsing and validation for applications that choose this profile. Endpoint location and current availability remain in expiring provider offers; authorization remains in delegation and provider-local policy.

Shape

{
  "profile": "bnw.capability-profile/1",
  "name": "Finance lookup",
  "description": "Looks up one public market symbol.",
  "operation": {
    "name": "tools/call",
    "input": {
      "media_types": ["application/json"],
      "schema": null,
      "max_bytes": 1048576,
      "privacy": "participant-encrypted"
    },
    "output": {
      "media_types": ["application/json"],
      "schema": null,
      "max_bytes": 1048576,
      "privacy": "participant-encrypted"
    }
  }
}

schema, when present, is the hexadecimal content ID of an immutable application schema. It does not make that schema authoritative. Implementations must independently retrieve and validate the referenced bytes. A BNW node asks peers for the input and output schema blobs along with the descriptor, like any other content-addressed blob. It serves the schemas of capabilities it publishes or follows, so they stay available while the publisher is offline. From an input’s JSON Schema it derives a local, unsigned starter document (input_template in catalog-inspect) with the schema’s required properties, so clients can offer a correctly shaped request. Neither the schema nor the template is enforced on the requester side; the provider checks every input.

Invariants

• The profile identifier is exactly bnw.capability-profile/1.
• One capability describes exactly one operation in v1. The signed invocation therefore cannot be reinterpreted as a different operation.
• Operation names use the same lowercase machine-safe alphabet as invocation progress stages.
• Each input and output accepts 1–16 explicit media types and at most 1 GiB.
• Privacy is public, participant-encrypted, or either.
• Unknown JSON fields are rejected so misspelled security-relevant fields do not silently disappear.
• The descriptor carries no endpoint, secret, credential, price, load, or current-availability data.

Participant-encrypted payloads are existing BNW encrypted-blob manifests whose recipient set is exactly the invocation requester and provider. The manifest and ciphertext synchronize through their inbox scopes; filenames, media types, plaintext hashes, and sizes remain inside the sealed access record.

Compatibility

Capability manifests may continue to reference other descriptor formats. A new descriptor profile version must use a new profile identifier and may coexist with v1. Supporting this profile never changes the validation or replication semantics of the signed BNW core objects.