Optional Ed25519 + JCS Trust Profile (v1)

The optional RFC 004 v1 trust profile binds a sender identity to a compozy-network/v0 envelope with an Ed25519 signature over deterministic JSON bytes. The envelope contract remains v0; v1 identifies this optional trust profile, not a new core protocol version. The profile keeps the top-level envelope shape and protocol identifier but applies its own nickname@fingerprint grammar to from.

This page is normative only for an implementation that claims compozy-network.trust.ed25519-jcs/v1.

Profile identifier

The baseline trust profile identifier is:

compozy-network.trust.ed25519-jcs/v1

A sender that expects a receiver to treat an envelope as verified MUST put this value in proof.profile.

Algorithms

Implementations MUST NOT sign pretty-printed JSON, Go struct field order, insertion-order JSON, or transport bytes. They MUST sign the JCS-canonical UTF-8 bytes described below.

Verified identity

When this profile is used, from MUST use the verified sender handle format:

nickname@fingerprint

The fingerprint is a routeable self-certifying suffix. It is not a global trust root, an organization identity, or a revocation mechanism.

Proof object

When this profile is used, proof MUST be an object with these fields:

Shape:

{
  "profile": "compozy-network.trust.ed25519-jcs/v1",
  "alg": "Ed25519",
  "key_id": "sha256:<64-hex>",
  "pubkey": "base64url(raw-32-byte-public-key)",
  "sig": "base64url(raw-64-byte-signature)"
}

Signed content

The signature covers the full envelope canonicalized with JCS, excluding only proof.sig.

All other envelope fields are signed, including:

• routing fields such as channel, from, and to
• conversation surface fields surface, thread_id, and direct_id when present
• work lifecycle field work_id when present
• correlation fields such as reply_to, trace_id, and causation_id
• freshness fields such as ts and expires_at
• the complete body
• the rest of proof, including profile, alg, key_id, and pubkey
• ext

A sender MUST sign the exact semantic envelope it intends to send. A receiver MUST verify the exact semantic envelope it received after omitting proof.sig.

JCS canonicalization rules

JCS produces deterministic UTF-8 bytes from a JSON value.

Field omission changes the signed bytes. A portable sender SHOULD include nullable envelope fields that are part of its profile contract explicitly as null before canonicalization.

Signing algorithm

A sender using this profile MUST:

1. Generate or load an Ed25519 key pair.
2. Encode the raw 32-byte public key with base64url without padding.
3. Compute digest = SHA-256(pubkey).
4. Set proof.key_id = "sha256:" + hex(digest).
5. Set from = nickname + "@" + hex(digest)[0:32].
6. Construct the envelope with proof.profile, proof.alg, proof.key_id, and proof.pubkey, but without proof.sig.
7. JCS-canonicalize the envelope.
8. Sign the canonical UTF-8 bytes with Ed25519.
9. Encode the 64-byte signature with base64url without padding.
10. Add the encoded value as proof.sig.

Pseudocode:

pubkey = raw_ed25519_public_key(private_key)
digest = sha256(pubkey)

envelope.from = nickname + "@" + lower_hex(digest)[0:32]
envelope.proof = {
  "profile": "compozy-network.trust.ed25519-jcs/v1",
  "alg": "Ed25519",
  "key_id": "sha256:" + lower_hex(digest),
  "pubkey": base64url_no_pad(pubkey)
}

signed_bytes = utf8(jcs(envelope))
envelope.proof.sig = base64url_no_pad(ed25519_sign(private_key, signed_bytes))

Go key and fingerprint operations:

package main

import (
	"crypto/ed25519"
	"crypto/rand"
	"crypto/sha256"
	"encoding/base64"
	"encoding/hex"
	"fmt"
)

func main() {
	pub, priv, err := ed25519.GenerateKey(rand.Reader)
	if err != nil {
		panic(err)
	}

	digest := sha256.Sum256(pub)
	keyID := "sha256:" + hex.EncodeToString(digest[:])
	fingerprint := hex.EncodeToString(digest[:])[:32]
	pubkey := base64.RawURLEncoding.EncodeToString(pub)

	fmt.Println(keyID, fingerprint, pubkey, len(priv))
}

The full signing step still requires an RFC 8785 JCS canonicalizer before calling ed25519.Sign.

Producing conformance vectors

This repository does not currently provide canonical bytes, a paste-in signature, or a runnable golden fixture for this profile. Do not treat the shapes on this page as a conformance vector.

An implementation that claims the profile should create a versioned vector containing:

1. A compozy-network/v0 envelope with every required core field, including workspace_id, and a timestamp evaluated against an injected test clock. Validation must be profile-aware so the signed sender uses nickname@fingerprint rather than the current runtime's ordinary v0 Peer ID grammar.
2. The exact unsigned JSON value with proof.profile, proof.alg, proof.key_id, and proof.pubkey present and only proof.sig absent.
3. The exact RFC 8785 JCS UTF-8 bytes.
4. The raw public key, SHA-256 digest, self-certified from value, and final Ed25519 signature.
5. Negative cases for body tampering, routing-field tampering, key mismatch, fingerprint mismatch, malformed proof fields, and proof stripping.

For a signed say, capability, receipt, or trace envelope, the canonical bytes include surface, the matching thread_id or direct_id, and work_id when present. They also include an optional trace_id only when the sender supplied one. A vector is useful evidence only when a complete RFC 8785 implementation and an independent verifier reproduce the same bytes and result.

Non-runnable shape examples

The following JSON objects show field placement only. They deliberately use ts: 0 and placeholder key/signature strings, so they are stale, cryptographically invalid, and unsuitable for sending or conformance claims. No current CompozyOS code path accepts or verifies them.

Discovery shape:

{
  "protocol": "compozy-network/v0",
  "id": "msg_trust_shape_greet",
  "workspace_id": "ws_alpha",
  "kind": "greet",
  "channel": "builders",
  "from": "patch-worker@00000000000000000000000000000000",
  "to": null,
  "ts": 0,
  "body": {
    "peer_card": {
      "peer_id": "patch-worker@00000000000000000000000000000000",
      "profiles_supported": ["compozy-network/v0", "compozy-network.trust.ed25519-jcs/v1"],
      "capabilities": [],
      "artifacts_supported": [],
      "trust_modes_supported": ["verified"]
    }
  },
  "proof": {
    "profile": "compozy-network.trust.ed25519-jcs/v1",
    "alg": "Ed25519",
    "key_id": "sha256:<64-lowercase-hex>",
    "pubkey": "<base64url-32-byte-public-key>",
    "sig": "<base64url-64-byte-signature>"
  }
}

Conversation shape:

{
  "protocol": "compozy-network/v0",
  "id": "msg_trust_shape_trace",
  "workspace_id": "ws_alpha",
  "kind": "trace",
  "channel": "builders",
  "surface": "thread",
  "thread_id": "thread_trust_shape",
  "from": "patch-worker@00000000000000000000000000000000",
  "to": "ops-coordinator.session-42",
  "work_id": "work_trust_shape",
  "trace_id": "trace_optional_shape",
  "ts": 0,
  "body": {
    "state": "working",
    "message": "Field-placement pseudocode only."
  },
  "proof": {
    "profile": "compozy-network.trust.ed25519-jcs/v1",
    "alg": "Ed25519",
    "key_id": "sha256:<64-lowercase-hex>",
    "pubkey": "<base64url-32-byte-public-key>",
    "sig": "<base64url-64-byte-signature>"
  }
}

Security boundaries

This profile provides message integrity and self-certified identity binding. It does not provide:

• global trust roots
• certificate transparency
• key revocation
• organization authorization
• federation-wide policy
• transport confidentiality

Deployments that need those properties MUST add them through local policy, transport security, or a future trust profile.