docs(otel): draft supporter acceptance for open-telemetry/community#2409

CHANGELOG.md

@@ -9,6 +9,7 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 ## [Unreleased]
 
 ### Added
+- **OTel Audit Logging initiative: supporter acceptance drafted — the standards footprint grows a second leg.** Hilmar Falkenberg (SAP) incorporated our two OCSF observations into the Audit Logging spec draft (apeirora/opentelemetry-specification@578b930: `audit.sequence.stream_id` chain scoping, `audit.integrity.signer` producer-vs-collector split) and invited us to join [open-telemetry/community#2409](https://github.com/open-telemetry/community/pull/2409) as a supporter. `docs/otel-2409-draft-comment.md` is the paste-ready acceptance, scoped deliberately to the OCSF↔OTel intersection: three production lessons verified absent from 578b930 (chain pointers need a resolvable record id, not only a hash; genesis omits the prev pointer — never a sentinel; signatures need a declared canonicalization or verification degrades to trusting the producer), the offer of a written OCSF↔OTel crosswalk (`stream_id`↔`chain_uid`, signer split↔`authority_uid`, chain pointer↔`prev_event`), and both public artifacts offered as test vectors (production reference bundle + stdlib-verifiable sample). Context recorded in the draft's header: SAP-led (sponsors SAP + Microsoft), developed in the `apeirora` org (SAP's IPCEI-CIS EU sovereign-cloud program) after the OTel GC declined formal SIG status Oct 2025 — supporter is the lightest-weight standards commitment available, and the crosswalk is the durable role. Docs only — no product impact.
 - **PR-shaped OCSF class draft for ocsf-schema#1724 — AI Agent Trust Inventory — ready to hand to Dave the moment the co-drafting offer is taken up.** `docs/ocsf-1724-class-draft/` lays the files out exactly as they would land in the ocsf-schema repo: a thin Discovery class (`events/discovery/ai_agent_trust_inventory.json`, uid 24 — first free above `cloud_resources_inventory_info`'s 23 — with a Log/Collect/Change activity enum whose `Change` caption carries the admission-control timing contract), five objects (`agent_config_declaration`, `agent_execution_params`, a single typed `agent_artifact` with a Model Weights/Adapter/Tool Schema/Policy Bundle/Charter enum instead of per-kind arrays, `ai_sampling_params`, `agent_credential` — references and scopes only, structurally incapable of carrying material), and a `dictionary-additions.json` fragment listing every new attribute, all collision-checked by name against ocsf-schema `main` 2026-08-11. Three verified conventions shaped the design: `record_integrity` is attached at `base_event`, so the per-emission chaining the issue asks for needs zero schema mechanics; `charter` already exists in the dictionary as a `file` object, so the charter digest rides `ai_agent.charter.hashes[]` natively; and `agent_artifact` introduces no new dictionary attributes at all. The worked sample (`docs/cosai-ws4-ocsf-mapping/trust-base-inventory-sample/`) is regenerated in the drafted shape — `declared_configuration`/`executed_parameters` with the typed `artifacts` array and credential `type_id`s — so the public sample Dave's issue thread links to and the class draft are one shape; `build_sample.py --verify` re-verifies the chain, digests, and event-3 divergence after the regen. The draft README carries the design rationale and six open questions for the WG (naming, enum-merge semantics, float attributes, the cross-object required-ness of loaded artifacts, TEE reference posture). Not metaschema-validated here — that needs the files inside a real ocsf-schema clone, which is step one when this graduates to an actual PR branch. Docs only — no product impact.
 - **Support package for ocsf-schema#1724 — Dave's (PayPal) agent trust-base inventory proposal, reviewed and backed with worked data.** The issue proposes a Discovery-category class snapshotting an agent's trust base (declared configuration as content digests + executed parameters in one event) with the `record_integrity` profile applied per emission — i.e., built directly on the #1661 shape we landed in OCSF 1.9 and run in production. Three artifacts: a review (`docs/ocsf-1724-trust-base-review.md`) assessing the proposal against our production experience and his two maintainer questions (Discovery: yes, with the `config_state`/`device_config_state_change` split as precedent for a Change *activity*; new class over extending device-shaped inventory classes); a paste-ready issue response (`docs/ocsf-1724-draft-issue-comment.md`) carrying the practitioner notes that transfer — `metadata.uid` on every emission, genesis omits `prev_event` rather than carrying a sentinel, fingerprint siblings for serialization honesty, the #1709 signature-bytes gap — plus five suggestions for the eventual class PR; and a worked sample (`docs/cosai-ws4-ocsf-mapping/trust-base-inventory-sample/`): three chained events for the reference bundle's demo agent, stdlib-only recomputable end to end (every digest has a named preimage; `build_sample.py --verify` recomputes fingerprints, chain linkage, and the divergences), demonstrating a benign divergence (declared toolset > enforced allowlist after an MCP `tools/list` refresh) and the Sleeper-Agents one (registry-declared adapter digest ≠ loaded-bytes digest, emitted before the adapter's first inference — admission control, then forensics). Docs only — no product impact.
 

docs/otel-2409-draft-comment.md

@@ -0,0 +1,81 @@
+# Draft response for open-telemetry/community#2409 — paste as Jeff
+
+**Context:** Hilmar Falkenberg (SAP, @hilmarf) incorporated our two OCSF
+observations into the Audit Logging spec draft
+([apeirora/opentelemetry-specification@578b930](https://github.com/apeirora/opentelemetry-specification/commit/578b930))
+and invited us to join the initiative as a supporter (2026-08-11 email /
+PR comment). Background on the group: SAP-led (sponsors SAP + Microsoft,
+filed by @mlenkeit Oct 2024), developed in the `apeirora` org — SAP's
+IPCEI-CIS EU sovereign-cloud program — after the OTel Governance Committee
+declined formal SIG status in Oct 2025; the PR thread remains the proposal
+venue. Full assessment in the 2026-08-11 session notes.
+
+**Posting notes:** paste the body below verbatim as a reply comment on
+[open-telemetry/community#2409](https://github.com/open-telemetry/community/pull/2409).
+Both artifact links are live on `main`. Points 1–3 map to gaps verified
+absent from 578b930 as of 2026-08-11 — none of it duplicates what Hilmar
+already incorporated.
+
+---
+
+Thanks @hilmarf — happy to join as a supporter, please add me. The corner I
+can usefully hold is the OCSF↔OTel intersection: we run the OCSF side of
+this in production (hash-chained, per-event-signed audit exports under the
+`record_integrity` profile that landed in OCSF 1.9 via
+ocsf/ocsf-schema#1661), and my interest is that the two specs end up
+mutually verifiable rather than parallel.
+
+I read through 578b930 — both additions are the right calls.
+`audit.sequence.stream_id` resolves the demultiplexing problem cleanly, and
+the `audit.integrity.signer` language that producer and collector signatures
+"MUST NOT be treated interchangeably" is exactly the discipline this needs:
+point-of-action attestation and custody attestation answer different
+questions, and we learned to keep them separate the slow way.
+
+A few notes from having shipped this shape, in roughly descending order of
+how much round-trip they might save you:
+
+1. **A chain pointer needs a resolvable record identifier, not only a
+   hash.** A predecessor hash proves linkage but can't *locate* the
+   predecessor across storage, sharding, or retention boundaries. OCSF's
+   merged shape ended up requiring every event to carry `metadata.uid` and
+   the previous-record pointer to reference it (`prev_event.uid`), with the
+   hash binding the reference to content. I'd recommend the data model
+   require a per-record id within the stream and have the chain pointer
+   carry both id and hash.
+
+2. **Define genesis explicitly: the first record of a stream omits the
+   previous-record pointer entirely — never a sentinel.** We shipped the
+   sentinel version once (a literal `"GENESIS"` string inside a hash-valued
+   field) and have it documented as an anti-pattern: a hash field whose
+   value isn't a hash breaks every schema-driven verifier. One sentence of
+   spec text here saves every implementer that round trip.
+
+3. **Signatures and chain hashes are only third-party-verifiable if the
+   record declares what bytes were hashed.** I'd recommend a required
+   companion attribute naming the canonicalization for
+   `audit.integrity.value` — RFC 8785/JCS, flat bytes, or a named producer
+   scheme. OCSF landed on an enum plus a free-text sibling precisely so
+   producers whose serialization isn't JCS can say so honestly instead of
+   misclaiming; without it, "verify the signature" quietly becomes "trust
+   the producer."
+
+4. **Offer: a written OCSF↔OTel crosswalk.** The mappings look
+   near-lossless from here — `audit.sequence.stream_id` ↔
+   `attestation.chain_uid`, the producer/collector signer split ↔ producer
+   signatures vs custody attestations with `authority_uid` naming the
+   attesting party, the chain pointer ↔ `prev_event`. If we keep that
+   mapping tight, one producer can emit both shapes (or transform between
+   them) without divergent integrity constructs. Happy to draft it as a doc
+   for the spec repo if useful.
+
+We can also contribute test vectors for the verification-procedures
+section: a production OCSF export (236-event chain, per-event ECDSA-P256
+signatures verifiable against a public JWKS, no secrets required) and a
+stdlib-only worked sample with fully recomputable fingerprints — both
+public:
+
+- https://github.com/levaj2000/ai-identity/tree/main/docs/cosai-ws4-ocsf-mapping/ocsf-log-reference-bundle
+- https://github.com/levaj2000/ai-identity/tree/main/docs/cosai-ws4-ocsf-mapping/trust-base-inventory-sample
+
+Looking forward to it.