registry: add MachineMandate as second profile entry (owner fields pending Tyche confirmation)

[StevenMih]

Adds MachineMandate (Tyche Institute) as the second registry profile (AAC is #1). ASG staged the entry from public documentation; the digest-context fields are marked [OWNER TO CONFIRM] and were not inferred — they need the owner's authoritative values before merge.

Staged row: Name machine-mandate (registrant's suggestion) · Reference tyche-institute/machine-mandate@524e6a3 · Status provisional (no published vector set at the pinned commit).

@tyche-dev — please confirm or correct these four (push to the branch, or state them here and I'll update):

Preferred artifact type name — machine-mandate is our suggestion; confirm or substitute.
Canonicalization algorithm — which CPB-registered algorithm (jcs-n, cde-n, or a new entry) applies to MachineMandate payloads (AEP tokens, EAR results, run credentials, mint records)?
Field set + exclusion set — which top-level fields are in the canonical form, and which (if any) are excluded for the derived identifier?
Representation — assumed lowercase hex (64-char SHA-256); confirm.

Status stays provisional until a two-sided (positive + negative) MachineMandate vector set is supplied — and per the registry policy, any profile-specific vectors ride the same mutation-probe discipline as the CPB core suite. Supply the fields + vectors and it promotes straight to owner-confirmed. We won't merge until your values land, so the entry is genuinely owner-authored.

[StevenMih]

@tyche-dev - please review

[tyche-dev]

Owner input on the four fields, derived from the machine-mandate repo with pins and evidence. Two naming decisions are flagged [ANTON TO CONFIRM] below — I will finalize those in a follow-up on this thread; everything else here is repo-derived fact.

Ground truth for everything below: tyche-institute/machine-mandate @ 524e6a3 (your pin; deps/jcs.py is byte-identical at the semantic freeze commits e440286d — artifact v1.0 — and e4bc763 — preimage freeze).

1. Artifact type name. machine-mandate is consistent with the credential's own type identifier: vct = https://vocab.tyche.institute/vct/machine-mandate (deps/mandate.py:25,82; also credential_claims.vct in interop/run-credential-mint-record.json). [ANTON TO CONFIRM — final naming acceptance.]

2. Canonicalization algorithm — none of the registered entries fits; a new entry is needed. deps/jcs.py:12-14 is exactly json.dumps(obj, sort_keys=True, separators=(",",":"), ensure_ascii=False).encode("utf-8"). There is no null/empty-member removal pass: jcs({"a": None, "b": [], "c": {}, "d": 1}) yields {"a":null,"b":[],"c":{},"d":1} (executed, not inferred). jcs-n removes those members bottom-up before serialization, so the two algorithms diverge on any payload containing a null/empty member — declaring jcs-n would misstate the construction. cde-n is CBOR-side and reserved. Registration text for the new entry: RFC 8785 subset — sorted keys, no insignificant whitespace, UTF-8, no member removal; numbers restricted to integers (ES6 number formatting per RFC 8785 §3.2.2 is explicitly not implemented, deps/jcs.py:3-6); key sorting is by code point (diverges from RFC 8785 UTF-16 ordering only for non-BMP keys). The frozen composition payloads happen to sit in the jcs-n-compatible intersection (no nulls, no numbers), but the registry field governs all payloads, so the entry must be honest. [ANTON TO CONFIRM — name for the new algorithm entry.]

3. Field set / exclusion set. Two constructions, and note the derived identifier is not a JCS field-set rule at all:

• Credential derived identifier (the CPB-relevant one for this artifact type): preimage = the exact issuer-signed JWT component bytes of the SD-JWT — the first ~-separated component as transmitted ("option (a)", confirmed on the three-owner review thread; interop/run-credential-mint-record.json → credential_preimage.rule; interop/mint_run_credential.py docstring). Field set = every issuer-signed claim exactly as serialized in the JWS component (signature-protected bytes, no re-canonicalization). Exclusion set = everything after the first ~: salted disclosures and the KB-JWT, i.e. all presentation-variant material — the digest is invariant across presentations. Frozen instance: 1190 bytes, no trailing newline, SHA-256 5df4d32df57650f27b6a65df041b708de80d69c0ca82a1044334f5e2edef5ce2, re-derived byte-exact from interop/run-credential-preimage.jwt at the pin. Contrast with agent-action-capsule: the identifier is external to the document rather than embedded-then-excluded.
• Bound action digest (the action_hash claim inside the credential): field set = {action_id, outcome}, closed; exclusion set = empty (src/scope_enforce.py:59-62). Frozen instance: 91 canonical bytes → sha256:a89fbd2bd6f95cdb1ec27b6c7253770ff2a22220937cf065f6e45ef67b37e299, matching shared_synthetic_action.mandate_side in interop/composition-input-manifest-v0.5.json. (A demo profile in src/agent_demo.py:19-20 hashes {tool, amount_eur, to} — same H, different field set; the composition-seam freeze is {action_id, outcome}.)

4. Representation. Lowercase hex, two forms: claim-embedded hashes carry a sha256: prefix (deps/jcs.py:17-18,21-22); the derived identifier is bare 64-char lowercase hex, validated [0-9a-f]{64} with no prefix (credential_preimage in the mint record; manifest v0.5 pins the no-prefix rule explicitly). Registry Representation field should read: bare 64-char lowercase hex; sha256: prefix appears only in in-document claims.

Corrections to the staged entry:

• The editor note's "produced by SPIRE-attested workloads" is wrong — SPIRE appears nowhere in the repo. The attestation root is an emulated software TPM (swtpm) appraised RATS/Veraison-style (README "Honest scope").
• machine-mandate/v1 is not a string that exists in the repo; the type identifier is the vct URI.
• Question 2's payload list conflates neighbors: AEP tokens and EAR results are not MachineMandate payloads. The EAR is a RATS artifact consumed at gate L2; the AEP is referenced by hash (aep_receipt_hash). The artifact type covers the SD-JWT credential (plus the action-object digest context above).
• "No published vector set found at pinned commit" — the positive side does exist at the pin and reproduces: the manifest publishes the action's canonical bytes in hex with the expected digest, and the preimage file digests to the frozen value. What's missing is the negative side, so provisional stands, for the corrected reason.

Vectors. A two-sided set is generatable from the repo now. Positives: the two frozen derivations above, plus key-order-permutation invariance and a non-ASCII case. Negatives (MUST-FAIL): a null-member payload where jcs-n's member removal produces a different digest (the probe that discriminates the new algorithm from jcs-n), a float-bearing payload (rejected — no ES6 number formatting), trailing-newline-appended preimage, prefixed-vs-bare digest comparison, uppercase hex. Happy to run them under the same mutation-probe discipline as the CPB core suite; delivery timing is ours to confirm.

[tyche-dev]

Owner confirmation on the two names I left open above.

1. Artifact type name — confirmed: machine-mandate. It matches the credential's own type identifier (vct = https://vocab.tyche.institute/vct/machine-mandate), so the registry string and the wire format agree. "MachineMandate" stays the prose/brand spelling.

2. Canonicalization algorithm — new entry, proposed name jcs-s ("JCS subset"). It cannot be jcs-n: deps/jcs.py performs no null/empty-member removal, which jcs-n mandates, so the two algorithms diverge on any payload carrying such a member.

Registration text as I would state it — the algorithm, not the name, is the part I am asserting as owner:

jcs-s — RFC 8785 subset. Object members serialized in ascending key order by Unicode code point; no insignificant whitespace; UTF-8 encoding; no member removal (null, empty array and empty object members are retained and serialized); numbers restricted to integers, since ES6 number formatting per RFC 8785 §3.2.2 is not implemented. Digest: SHA-256. Representation: lowercase hex.

Two divergences from full RFC 8785 are deliberate and stated so implementers are not surprised: the integer restriction, and code-point rather than UTF-16 code-unit key ordering (these differ only for non-BMP keys, which the format does not use).

The name is a proposal, not a requirement — if the registry prefers a different token, take any name you like as long as the semantics above travel with it and it is not jcs-n. Everything else in my earlier comment (field set, exclusion set, representation, the corrections to the staged entry) stands unchanged, and I am happy to supply the two-sided vector set once the entry name is fixed.

[tyche-dev]

Two-sided vector set delivered — the promotion condition for the entry.

Branch feat/cpb-registry-vectors-v0.1 on tyche-institute/machine-mandate, commit 640f2a668cfc4a357f9b34ecb0add5faf8bbdda1; vectors/cpb-registry/machine-mandate-vectors-v0.1.json (SHA-256 06572fccb7afa3eda4c68604221a83476faac8f8509b7165724553d58384d816) with a self-verifying generator (gen_vectors.py --verify recomputes everything from deps/jcs.py, so vectors cannot drift from the code).

Positive: the two frozen derivations — credential derived identifier (1190-byte issuer-signed component → bare hex 5df4d32d…5ce2) and the {action_id, outcome} action digest (91 canonical bytes → sha256:a89fbd2b…7e299) — plus key-order-invariance and UTF-8 probes. Both reproduce byte-exactly against interop/composition-input-manifest-v0.5.json.

Negative: the member-removal discriminator ({"a":null,"b":[],"c":{},"d":1} — a jcs-n-style removal pass yields a different digest and MUST fail), float rejection, trailing-newline byte-exactness on the preimage, bare-vs-sha256: representation confusion, uppercase-hex rejection.

The set names the algorithm jcs-s pending the naming decision above; if the registry picks another token, only that string changes. Once the name is fixed, this closes the provisional → owner-confirmed gap from my side.

[StevenMih]

@tyche-dev — thank you. This is exactly the owner-authored material the entry needed, and the four corrections are accepted without argument.

Corrections taken. The SPIRE line was ours and it was wrong — removed. machine-mandate/v1 removed; the vct URI is the type identifier. Question 2's payload list conflated neighbours; corrected to the SD-JWT credential plus the action-object digest context, with the EAR noted as a RATS artifact consumed at the gate and the AEP as a hash reference, not payloads of this type. And the "no published vector set at the pinned commit" line was wrong on the positive side; the status reason is corrected to negative side absent, which your v0.1 set now closes.

One process note on ourselves: that editor note asserted a fact about your architecture instead of quoting it or marking it [OWNER TO CONFIRM]. That is precisely what this repo's own rule forbids — "CPB editors MUST NOT fill in an owner's digest-context parameters on their behalf" — and the same discipline should have applied to the descriptive prose. We have tightened it.

Artifact type name: accepted as machine-mandate. Agreeing with the credential's own vct is the right basis — the registry string and the wire format should not diverge.

The blocker is CPB, not your entry. Your field-set answer surfaced a defect in our Artifact Type Registry template. The template carries a single Digest Context per entry — one algorithm, one exclusion set, one representation. machine-mandate has two: the credential derived identifier (preimage = the issuer-signed JWS component as transmitted, excluding all post-~ presentation material) and the bound action digest over {action_id, outcome}. Only the second is a field-set rule, and only the second uses a JSON canonicalization at all. If we merged the row today, the Digest Context cell would describe the inner action digest while purporting to describe the artifact identifier — permanently, since entries are immutable.

Worse, and more interesting: we have no registered algorithm for what your identifier actually does, which is nothing — the preimage is the exact signed octets as transmitted. Re-canonicalizing there would be an error, not a redundancy: the signature is what makes those bytes authoritative, so the signature's own byte boundary IS the canonicalization. That is not special pleading for SD-JWT. The provisional verifiable-agent-conversation entry (draft-birkholz-verifiable-agent-conversations) is stuck on the same point from the COSE side — content-hash over "the payload bytes" with no normalization specified, because a COSE_Sign1 already fixed them.

So two CPB changes, both of which we now consider blocking for promotion:

An as-transmitted (identity) entry in the Canonicalization Algorithm Registry. Its Digest Context has no field set and no exclusion set, so it must instead state a byte-boundary selector — "the first ~-separated component as transmitted"; "the COSE_Sign1 payload bytes." Without the selector such an entry says nothing.
Multi-context Artifact Type rows: N digest contexts per entry, each carrying a purpose label, so a type with an identifier rule and an inner action-digest rule can state both instead of picking one.

On the algorithm name. Take the substance as yours; we would only push on one word. "Subset" asserts the property that is false here: code-point key ordering diverges from RFC 8785 §3.2.3's UTF-16 code-unit ordering for non-BMP keys rather than restricting it, so jcs-s output is not always valid JCS output. An implementer who reads "JCS subset" will reasonably assume substitutability, and the entry is immutable. We would rather a token with no JCS lineage — json-sk-cp (sorted keys, code point) or anything you prefer — with your registration text travelling unchanged. This is genuinely your call on everything except the substitutability implication.

The other half of that: for "Specification Required" to mean anything, the algorithm text needs to live somewhere citable. Our proposal is CPB §11.1, owner-authored, credited to you, rather than a normative reference to a repository. Your paragraph is already the right text; we would move it, not rewrite it.

One substantive point on the algorithm itself, offered as review rather than objection — the integer bound. Your text restricts numbers to integers because ES6 number formatting is not implemented. We hit the adjacent problem and it needs stating explicitly: an integer whose magnitude exceeds 2^53−1 does not round-trip through an ECMAScript-Number-based reader, so two conforming implementations can derive different digests from the same bytes even with floats already excluded. Our canonicalizers reject it as a typed error rather than serialize it, and the AAC suite ships a MUST-FAIL vector (neg-unsafe-integer-in-digest-field) for exactly that boundary. If the frozen payloads never carry a large integer, the registration text still governs future ones — the same argument you made for null members against jcs-n. Suggest adding the bound and a matching negative vector; happy to contribute the vector if useful.

Relatedly, we sort object members by UTF-16 code units in both implementations (encode("utf-16-be") in Python, utf16.Encode in Go) specifically to hold RFC 8785 ordering, which is what makes the code-point divergence above visible to us rather than theoretical.

Vectors. We will reproduce your v0.1 set independently — pin 640f2a668cfc4a357f9b34ecb0add5faf8bbdda1, file SHA-256 06572fccb7afa3eda4c68604221a83476faac8f8509b7165724553d58384d816 — against our own implementation and post the result on this thread rather than taking delivery on trust. Independent byte agreement is the point of the exercise; accepting a vector set unrun would defeat it. The member-removal discriminator is the one we most want to run, since it is the probe that distinguishes the two algorithms.

Status. The entry stays in spec/cpb-provisional-registry.md for now, and we want to be precise about why: it is provisional for a CPB reason, not an owner reason. You have confirmed every field asked of you and supplied a two-sided set under the mutation-probe discipline. What is missing is on our side — the identity algorithm entry and the multi-context row template. Both are queued for the next CPB revision; we will open them as separate PRs so they can be reviewed on their own merits, and link them here. Once they land, this entry promotes to owner-confirmed with no further work from you beyond the name token.

[tyche-dev]

Agreed on both. Take json-sk-cp for the registry token — you're right that "subset" wrongly implies JCS-substitutability, and the non-BMP code-point/UTF-16 ordering divergence is exactly why. Registration text stands as written.

On the integer bound: yes, add the 2^53−1 ceiling and a matching MUST-FAIL vector — please do contribute neg-unsafe-integer-in-digest-field; it's the same argument I made for null members.

I'll align the paper's naming and tighten the agreement-set claim to name the non-BMP divergence before it goes out.

[tyche-dev]

Owner confirmation, consolidated against the current record:

1. Artifact type: machine-mandate is confirmed. It matches https://vocab.tyche.institute/vct/machine-mandate.
2. Credential-derived identifier context: purpose identifier; algorithm as-transmitted; byte-boundary selector = the issuer-signed JWS component of the SD-JWT, i.e. the first ~-separated component exactly as transmitted, with all presentation-variant material after the first ~ outside the pre-image; representation = bare 64-character lowercase hex.
3. Bound-action digest context: semantic purpose = binding the credential to the closed action object {action_id, outcome}; algorithm = json-sk-cp as agreed on this thread; exclusion set empty; representation = sha256: plus 64-character lowercase hex when carried as the in-document action_hash claim. Please use the final purpose-label token chosen in C1b/C1c: Artifact Type Registry accepts N digest contexts, each with a purpose label #9 for this binding purpose rather than silently calling it equivalence if that vocabulary remains under correction.
4. Two-sided vectors: controlling public coordinate is now tyche-institute/machine-mandate, branch feat/cpb-registry-vectors-v0.1, commit 5605783a (the algorithm-scoped correction supersedes the earlier branch tip). The vector file SHA-256 remains 06572fccb7afa3eda4c68604221a83476faac8f8509b7165724553d58384d816.

The substantive owner fields are therefore confirmed. The present PR diff still contains the original placeholders and stale architecture prose, so this is not approval of head 5d973664f390cad22359a4a0f10480cad29a76d9. Please update/rebase the row after #8 and #9 land, then return the exact head for final owner review and independent vector reproduction.

[StevenMih]

Independent reproduction of the v0.1 vector set, run against pin 640f2a668cfc4a357f9b34ecb0add5faf8bbdda1 / file SHA-256 06572fccb7afa3eda4c68604221a83476faac8f8509b7165724553d58384d816 — confirmed the file bytes match that pin before computing anything.

Used a second implementation for the JCS-path values: a from-scratch Node.js canonicalizer built from your registration text (not from deps/jcs.py), plus raw-byte shasum/hashlib for the credential-derived identifier per your as-transmitted construction (no re-canonicalization, as you specified).

All 9 vectors reproduced byte-for-byte on our side: the two positive derivations, the key-order and non-ASCII probes, and all five negatives. For the negatives we went a step further and built condition-removed mutants to confirm each one actually discriminates rather than just pattern-matching: the member-removal mutant reproduces your wrong_digest_prefixed_jcs_n exactly, the no-integer-check mutant silently serializes the float instead of rejecting, and the representation/case-folding mutants both wrongly accept where the strict form correctly rejects. Nothing to correct on your side — this closes our independent-reproduction condition for promotion.

[StevenMih]

@tyche-dev as I opened this PR for your MachineMandate, need you to merge :) please go for it if you're good

[tyche-dev]

Not ready to merge from the owner side yet. The independent reproduction result is good and closes that condition, but PR #4 itself is still at exact head 5d97366 with the original single commit. Its diff still contains the owner placeholders, stale architecture prose, and the old source coordinate that I explicitly did not approve on 9 August. Also, the two schema dependencies identified on this thread—#8 (as-transmitted) and #9 (multi-context rows/purpose label)—are both still open. Please land #8 and #9, then update/rebase PR #4 to the consolidated owner-confirmed fields and current vector coordinate, and return the new exact head. I will do the bounded final review against that head and merge if it matches. The vector reproduction alone does not make the current stale head mergeable.

[tyche-dev]

Both schema dependencies are now on main: #8 merged (bd00718, as-transmitted registered with the mandatory byte-boundary-selector rule) and #19 merged (7881c0c, -01 restack + multi-context rows + typed-ref purpose selector). Nothing further blocks on our side.

Per my 11 Aug condition, please now update/rebase this PR to the consolidated owner-confirmed fields (9 Aug comment) in the current registry shape — one machine-mandate entry, two digest contexts:

• identifier — profile version N/A; algorithm as-transmitted; byte-boundary selector: the issuer-signed JWS component of the SD-JWT (RFC 7515 §7.1 compact serialization; the first ~-separated component exactly as transmitted), everything after the first ~ outside the pre-image; representation bare 64-char lowercase hex.
• equivalence — the published §13.2 definition fits this binding, so equivalence it is (closing my point 3): algorithm json-sk-cp; field set {action_id, outcome}, closed; exclusion set none; domain separation none; representation sha256: + 64-char lowercase hex as the in-document action_hash claim.
• Vectors: tyche-institute/machine-mandate branch feat/cpb-registry-vectors-v0.1, commit 5605783a, file SHA-256 06572fccb7afa3eda4c68604221a83476faac8f8509b7165724553d58384d816 as per the thread — your 11 Aug independent reproduction stands.
• Drop the stale architecture prose flagged 1 Aug (SPIRE claim, machine-mandate/v1 string, conflated payload list).

Note json-sk-cp still needs its own Canonicalization Algorithm Registry row in the same diff (registration text in my 1 Aug comment, name agreed on-thread) — an artifact-type row may not cite an unregistered algorithm.

Return the new exact head and I'll do the bounded final review and merge.

[StevenMih]

@tyche-dev — rebased onto current main (59461cf, which now includes both #8 and #19) and rewrote the entry per your 13 Aug comment.

New exact head: 96a30e27dc3f6c489e54f441c9b5434913d7938b

What changed, one commit on top of the rebase:

1. One machine-mandate entry, two digest contexts, in the normative CPB -01 Artifact Type Registry (§13.2):
   • identifier — as-transmitted; byte-boundary selector = the issuer-signed JWS component of the SD-JWT (RFC 7515 §7.1 compact serialization; the first ~-separated component exactly as transmitted), everything after the first ~ outside the pre-image; bare 64-char lowercase hex.
   • equivalence — json-sk-cp; field set {action_id, outcome}, closed; exclusion set none; domain separation none; sha256: + 64-char lowercase hex, as the in-document action_hash claim.
2. json-sk-cp registered as its own Canonicalization Algorithm Registry row (renumbered to §13.1 under the -01 restack), registration text moved verbatim from your 1 Aug 19:11 comment — only the name token changed (jcs-s → json-sk-cp, per your 4 Aug agreement), text otherwise unchanged. Added the agreed 2^53−1 integer ceiling as a separate trailing sentence, not folded into your text.
3. Vector coordinate updated to commit 5605783a (supersedes 640f2a6); file SHA-256 unchanged (06572fccb7afa3eda4c68604221a83476faac8f8509b7165724553d58384d816).
4. Dropped the four stale prose items: the SPIRE claim, the machine-mandate/v1 string, and the conflated AEP/EAR payload list (all confirmed removed repo-wide, not just reworded).
5. REGISTRY.md mirrors both registry changes; spec/cpb-provisional-registry.md's provisional block is replaced with a pointer to the graduated normative entry.

CI is green on this head (build/check/dco/neutrality/test 3.11+3.12, gh pr checks). .xml/.txt regenerated from the .md source via kramdown-rfc + xml2rfc.

Still owed and not on this head: the neg-unsafe-integer-in-digest-field MUST-FAIL vector for the 2^53−1 boundary — flagging as a fast-follow rather than folding it in under time pressure, since a vector we add needs the same mutant-flip discipline as the rest of this suite and that's real implementation work (a json-sk-cp reference construction plus a new checker category), not a quick addition.

Ready for your bounded final review against 96a30e2.