scitt-cose 0.0.1__tar.gz

scitt_cose-0.0.1/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

scitt_cose-0.0.1/NOTICE

@@ -0,0 +1,6 @@
+scitt-cose
+Copyright 2026 Action State Group, Inc.
+
+This product includes software developed by Action State Group, Inc.
+(https://actionstate.ai), published as neutral, profile-agnostic SCITT/COSE
+substrate for the community.

scitt_cose-0.0.1/PKG-INFO

@@ -0,0 +1,394 @@
+Metadata-Version: 2.4
+Name: scitt-cose
+Version: 0.0.1
+Summary: Generic, profile-agnostic IETF SCITT + COSE Receipts substrate for Python.
+Author: Action State Group
+License: Apache-2.0
+Project-URL: Homepage, https://github.com/action-state-group/scitt-cose
+Project-URL: Source, https://github.com/action-state-group/scitt-cose
+Project-URL: Issues, https://github.com/action-state-group/scitt-cose/issues
+Keywords: scitt,cose,cose-sign1,receipts,merkle,rfc9162,transparency
+Classifier: License :: OSI Approved :: Apache Software License
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Security :: Cryptography
+Requires-Python: >=3.9
+Description-Content-Type: text/markdown
+License-File: LICENSE
+License-File: NOTICE
+Requires-Dist: cbor2>=5.5
+Requires-Dist: cryptography>=42.0
+Provides-Extra: dev
+Requires-Dist: pytest>=7.0; extra == "dev"
+Requires-Dist: ruff>=0.4; extra == "dev"
+Requires-Dist: pycose>=1.1; extra == "dev"
+Provides-Extra: serve
+Requires-Dist: uvicorn[standard]>=0.27; extra == "serve"
+Dynamic: license-file
+
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+# scitt-cose
+
+A generic, profile-agnostic IETF **SCITT + COSE Receipts** substrate for Python:
+build/verify COSE_Sign1 **Signed Statements**, verify **Receipts** and RFC 9162
+**inclusion / consistency proofs**, with the **Merkle + receipt-signing
+primitives**.
+
+It is **NOT a transparency service** (operating a log — a hosted registration
+endpoint — is a separate concern), and it carries **NO application profile** —
+bring your own statement semantics. The only third-party dependencies anywhere
+in the package are [`cbor2`](https://pypi.org/project/cbor2/) and
+[`cryptography`](https://pypi.org/project/cryptography/), plus the standard
+library. COSE_Sign1 (RFC 9052) is implemented here from scratch — it does **not**
+use `python-cwt` or any other COSE library.
+
+> **Name note.** `scitt-cose` is the finalized package name, claimed on PyPI
+> and GitHub (`action-state-group/scitt-cose`) in the same pass.
+
+## What this does / does not do
+
+**Does:**
+
+- Verify a SCITT **Signed Statement** (`COSE_Sign1`) signature against a supplied
+  key — EdDSA and ES256 — and report its issuer / subject / content-type / alg.
+- Verify a **COSE Receipt** whose verifiable data structure is
+  **`RFC9162_SHA256`** (vds = 1, the tree algorithm registered by
+  draft-ietf-cose-merkle-tree-proofs): the RFC 9162 SHA-256 inclusion proof
+  *and* the log's signature over the reconstructed root — i.e. *"this statement
+  is provably in the log"* — **without trusting the log operator**. The vds value
+  is read from the protected header only and anything other than
+  `RFC9162_SHA256` is rejected, not silently accepted.
+- Provide the RFC 9162 **Merkle primitives** (root, inclusion, consistency) and a
+  `build_receipt` primitive.
+
+**Does NOT:**
+
+- **Operate a Transparency Service.** It never registers statements, issues
+  receipts, anchors, or stores anything. Running a log is a separate concern with
+  its own operational trust obligations.
+- **Validate any application profile's payload semantics.** The statement payload
+  is treated as **opaque bytes**. There is no agent-action-profile awareness —
+  that neutrality is deliberate, and is what makes this reusable by *anyone* in the
+  SCITT ecosystem.
+- **Depend on a COSE library for wire values.** `COSE_Sign1` is implemented from
+  scratch over `cbor2` + `cryptography`; code points are pinned to the IANA
+  registries, not to a library's enum.
+
+## Why this exists
+
+This is a **standalone, profile-opaque, cross-validated** generic SCITT/COSE
+verifier: it verifies *anyone's* SCITT Signed Statements and COSE Receipts, treats
+the payload as opaque bytes, and its conformance is checked against independent,
+external references (the published RFC 6962/9162 Merkle vectors, a third-party
+COSE library, and a separate Go implementation — see
+[Correctness & cross-implementation evidence](#correctness--cross-implementation-evidence)).
+
+It is intended to be useful as **neutral substrate**: the parts that exist today
+don't fit that gap cleanly — `python-cwt` is COSE-only (no SCITT/Receipts), and a
+transparency-service emulator is a server, not a verification library you depend
+on. So this is the small building block — a second, independent implementation
+you can verify against, with no profile baked in. (No primacy is claimed; the
+value is neutrality + verifiable conformance, not being "first".)
+
+An agent-action profile is **one** example consumer that builds its
+statement/claim semantics *on top of* this substrate — but nothing
+profile-specific lives here.
+
+## Provenance, neutrality & governance
+
+Three things an adopter should know up front:
+
+1. **Built by [Action State Group](https://actionstate.ai).** We built this for
+   our own SCITT use and publish it as community substrate under Apache-2.0.
+2. **Neutral by design.** No application profile, no vendor coupling,
+   payload-opaque. The package imports only `cbor2`, `cryptography`, and the
+   standard library — it does not import any Action State code, and a test
+   gate (`tests/test_iana_codepoints.py`) enforces that this stays true.
+3. **Foundation intent.** We intend to contribute this project to a neutral
+   open-source foundation so its governance does not rest with any single
+   vendor. Which foundation is deliberately not yet decided; until then it is
+   governed in the open under DCO + Apache-2.0 (see
+   [CONTRIBUTING.md](CONTRIBUTING.md)).
+
+## Scope
+
+In scope (library plumbing):
+
+- Build / parse / verify **Signed Statements** and **Transparent Statements**.
+- Verify **Receipts** + RFC 9162 **inclusion** and **consistency** proofs.
+- RFC 9162 SHA-256 **Merkle primitives** and the **receipt-signing** primitive
+  (`build_receipt`) — so you *can* mint receipts as a building block.
+
+Out of scope (documented, deliberately not built):
+
+- **Operating a transparency log / service.** A hosted registration endpoint,
+  log storage, monitoring, witnessing, gossip — none of that is here. The
+  primitives needed to build one (Merkle tree, receipt signing) **are** included.
+
+## Install
+
+```bash
+pip install cbor2 cryptography          # runtime deps
+# from a checkout (package root):
+pip install -e .
+```
+
+## Quick start
+
+```python
+from cryptography.hazmat.primitives.asymmetric import ed25519
+from cryptography.hazmat.primitives import serialization
+from scitt_cose import (
+    build_signed_statement, parse_signed_statement,
+    merkle_root, inclusion_proof, verify_inclusion,
+    consistency_proof, verify_consistency,
+    build_receipt, verify_receipt,
+    attach_receipts, extract_receipts,
+)
+
+# --- a key (caller supplies everything) ---
+sk = ed25519.Ed25519PrivateKey.generate()
+priv = sk.private_bytes(serialization.Encoding.PEM,
+                        serialization.PrivateFormat.PKCS8,
+                        serialization.NoEncryption())
+pub = sk.public_key().public_bytes(serialization.Encoding.PEM,
+                                    serialization.PublicFormat.SubjectPublicKeyInfo)
+
+# --- Signed Statement (generic; no profile) ---
+stmt = build_signed_statement(
+    b'{"hello":"world"}',
+    alg="EdDSA", private_key_pem=priv,
+    issuer="https://issuer.example",
+    subject="my-artifact",
+    content_type="application/json",
+    extra_cwt_claims={"my_claim": "x", 99: 1},  # str- or int-keyed
+)
+parsed = parse_signed_statement(stmt, public_key_pem=pub)
+assert parsed["signature_verified"] is True
+assert parsed["issuer"] == "https://issuer.example"
+
+# --- Merkle (RFC 9162 SHA-256; hex in/out) ---
+entries = [b"a".hex(), b"b".hex(), b"c".hex(), b"d".hex()]
+root = merkle_root(entries)
+path = inclusion_proof(entries, 2)
+assert verify_inclusion(entries[2], 2, len(entries), path, root)
+
+cproof = consistency_proof(entries, 2, 4)
+assert verify_consistency(merkle_root(entries[:2]), root, 2, 4, cproof)
+
+# --- Receipt (primitive) + verify ---
+receipt = build_receipt(
+    leaf_entry_hex=entries[2], leaf_index=2, tree_entries_hex=entries,
+    alg="EdDSA", log_private_key_pem=priv,     # here the "log" key is our key
+)
+res = verify_receipt(receipt, leaf_entry_hex=entries[2], log_public_key_pem=pub)
+assert res.ok and res.root == root
+
+# --- Transparent Statement = Signed Statement + Receipts ---
+transparent = attach_receipts(stmt, [receipt])
+assert extract_receipts(transparent) == [receipt]
+```
+
+## CLI
+
+```bash
+scitt-cose --statement stmt.cose --statement-pubkey issuer.pem
+scitt-cose --receipt receipt.cose --receipt-log-pubkey log.pem --leaf-entry-hex 61
+scitt-cose --statement stmt.cose --receipt receipt.cose \
+           --receipt-log-pubkey log.pem --leaf-entry-hex 61 --json
+```
+
+## Public API
+
+| Area | Functions / types |
+|---|---|
+| COSE_Sign1 | `sign_sign1`, `verify_sign1`, `Sign1`, `CoseError` |
+| Statements | `build_signed_statement`, `parse_signed_statement`, `attach_receipts`, `extract_receipts` |
+| Merkle | `leaf_hash`, `merkle_root`, `inclusion_proof`, `verify_inclusion`, `consistency_proof`, `verify_consistency` |
+| Receipts | `build_receipt`, `verify_receipt`, `ReceiptResult` |
+| Status | `DRAFT_TRACKING_NOTICE`, `DRAFT_SCITT_ARCHITECTURE`, `DRAFT_COSE_MERKLE_TREE_PROOFS`, `SUBSTRATE_RFCS` |
+
+### Algorithms
+
+`sign_sign1` / statements support `"EdDSA"` (code point −8) and `"ES256"`
+(−7). For ES256, COSE carries the signature as **raw `r || s`** (64 bytes), not
+DER; the conversion happens at the `cryptography` boundary. ML-DSA code points
+(RFC 9964) are *recognized* in the status notice but signing is **not**
+implemented here.
+
+### Why CWT Claims at label 15 (not 13)
+
+Signed-Statement CWT Claims are placed in the protected header at **label 15**,
+the "CWT Claims" header parameter registered by **RFC 9597 §2**. Label **13** is
+a different parameter (`kcwt`, RFC 9528) and is sometimes mistakenly used for the
+claims map; this library always reads and writes the claims at **15**.
+
+### Receipt vdp encoding (honest caveat)
+
+The Receipt's verifiable-data-proof shape tracks
+**draft-ietf-cose-merkle-tree-proofs-18**:
+
+- protected `1` = alg, protected `395` = vds (`1` = `RFC9162_SHA256`);
+- unprotected `396` = vdp map with key `-1` → array of inclusion-proof bstrs;
+- each inclusion-proof bstr = `cbor([tree_size, leaf_index, [audit_path bstrs]])`;
+- payload = the Merkle root (detached by default).
+
+`verify_receipt` reads **vds from the protected header only** (it is
+security-relevant and must be integrity-protected), reconstructs the root from
+the proof, and verifies the COSE_Sign1 over that root with the log key. Because
+the underlying documents are **drafts, not RFCs**, this exact CBOR shape is
+**validated by round-trip in this library's own tests**, not against a frozen
+RFC. Treat the wire shape as draft-tracking.
+
+## Draft-tracking / standards honesty
+
+This library tracks two IETF documents that are **Active Internet-Drafts (Work in
+Progress)** — they have been approved and are in the **RFC Editor Queue**, but are
+**NOT yet published RFCs** (status audited against the IETF Datatracker at ship
+date; re-verify at publish time, since RFC-Ed-Queue documents can be published at
+any point):
+
+- `draft-ietf-scitt-architecture-22` — *SCITT Architecture* (Datatracker:
+  Active Internet-Draft, RFC Ed Queue)
+- `draft-ietf-cose-merkle-tree-proofs-18` — *COSE Receipts / COSE Merkle Tree
+  Proofs* (Datatracker: Active Internet-Draft, RFC Ed Queue)
+
+**There is no RFC 9942.** No positive "RFC 9942" claim is made anywhere (enforced
+by a test that scans shipped source + docs).
+
+Published RFCs whose mechanisms this library implements / relies on (titles
+verified against the RFC Editor / IANA registries):
+
+- **RFC 9052** — *CBOR Object Signing and Encryption (COSE): Structures and
+  Process* (COSE_Sign1, Sig_structure).
+- **RFC 9053** — *COSE: Initial Algorithms* (EdDSA −8, ES256 −7).
+- **RFC 9162** — *Certificate Transparency Version 2* (SHA-256 Merkle tree;
+  inclusion and consistency proofs; reuses the RFC 6962 tree hash).
+- **RFC 9597** — *CBOR Web Token (CWT) Claims in COSE Headers* — the **CWT Claims**
+  header parameter at **label 15** (IANA COSE Header Parameters registry). Label
+  **13** is `kcwt` and **14** is `kccs`, both from **RFC 9528** (EDHOC) — *not* the
+  CWT Claims map; using 13 for claims is the python-cwt bug this library avoids.
+- **RFC 9964** — *ML-DSA for JOSE and COSE* (code points recognized; ML-DSA
+  signing not implemented here).
+
+## Independence
+
+`scitt_cose/` imports **only** `cbor2`, `cryptography`, and the standard library.
+It does **not** import `cwt` / `python-cwt`, `pycose`, or any consuming
+product/profile package. Verify:
+
+```bash
+grep -rnE 'import (cwt|pycose)\b' scitt_cose/   # → nothing
+```
+
+Two tests keep this true: the COSE-library import guard and the
+no-downstream-code neutrality gate (both in `tests/test_iana_codepoints.py`).
+
+## Correctness & cross-implementation evidence
+
+For a *community* verifier, "trust me, it's conformant" is worthless. The
+correctness story rests on agreement with things **outside this library**, not on
+self-consistency:
+
+- **Cross-language agreement (in CI).** An independent Go verifier
+  (the `scitt-cose-go-verify` directory, built on `veraison/go-cose` + `fxamacker/cbor`,
+  with a clean-room Merkle fold) verifies the statements *and receipts* this
+  library emits, agrees on the reconstructed Merkle root, and rejects tampered
+  inputs. CI runs it with `SCITT_REQUIRE_GO=1`, so the cross-check can never
+  silently skip. (`tests/test_crosslang_go.py`)
+- **The standard's own test vectors.** The Merkle code is checked against the
+  published RFC 6962 / RFC 9162 reference vectors (8-leaf root `5dc9da79…`, the
+  canonical inclusion/consistency proofs) — external values, not ours.
+  (`tests/test_rfc9162_vectors.py`)
+- **A third-party COSE library.** `pycose` (independent of us, and *not*
+  `python-cwt`) both verifies our statements and emits statements *we* verify —
+  so the round-trip isn't self-referential. (`tests/test_thirdparty_cose.py`)
+- **The COSE standard's own reference-signed vector.** We verify the canonical
+  COSE_Sign1 the COSE WG published (RFC 9052 §C.2.1, ES256, from the
+  `cose-wg/Examples` corpus) — anchoring the *signature* layer to the spec's
+  reference output, just as the RFC 6962 vectors anchor the Merkle layer.
+  (`tests/test_cose_wg_vectors.py`)
+- **A real Transparency-Service verifier.** A downstream consumer (the Action
+  State Authority verifier, built on a *different* COSE stack —
+  `python-cwt`) cross-verifies the same Signed Statements and the same
+  TS-issued Receipts and agrees on the reconstructed Merkle root. This exercises
+  the real register→issue→verify shape; the integration test lives in the
+  consuming repo (so this package stays standalone).
+- **IANA values, not library enums.** Every wire code point is asserted against
+  its registry/RFC number (CWT Claims **15**, not python-cwt's `13`).
+  (`tests/test_iana_codepoints.py`)
+- **Spec-driven negative suite.** The MUST-reject conditions — alg confusion,
+  critical-header (`crit`) handling, `vds` downgrade, wrong-leaf/wrong-log
+  receipts, Merkle edge cases, malformed CBOR — each have a test.
+  (`tests/test_negative_conformance.py`)
+
+> **Evaluated and not used: the SCITT API emulator.** The `scitt-community/`
+> `scitt-api-emulator` was considered as an ecosystem oracle and rejected: it is
+> archived/unmaintained (final "pre-archive" tag, Nov 2024) and emits the
+> *obsolete* pre-standard receipt format (`draft-birkholz-scitt-receipts` —
+> string labels `service_id`/`tree_alg`, not a COSE_Sign1 receipt, not the
+> `vds`=395 / `vdp`=396 RFC 9162 structure this library verifies); its statements
+> use `pycose`, already covered above. Pinning a non-conformant, drift-prone
+> implementation would be a *misleading* oracle, so the COSE WG spec vector is
+> used in its place.
+
+## Hosted verification — a standalone SCITT-only verifier
+
+`scitt_cose.hosted` is a **stateless, read-only** wrapper over the *same* verify
+functions, so you can offer verification without anyone installing anything — and
+without the submitter having to trust the operator with their data (nothing
+stored, nothing logged, payload-opaque; the receipt path needs only the leaf
+*digest*, never the payload). `tests/test_hosted_parity.py` asserts the hosted
+verdict equals the local verdict on a fixture set, including the ASGI path.
+
+**This is a SCITT-*only* verifier, and it is NOT a Transparency Service.** It
+verifies statements and receipts; it never registers, issues receipts, or
+anchors. Running a Transparency Service is a **separate** offering with its own
+operational trust obligations — deliberately out of scope here.
+
+Run it standalone (no other service involved):
+
+```bash
+# Zero extra deps — stdlib HTTP server:
+scitt-cose-serve                                  # 127.0.0.1:8080
+
+# Or under a production ASGI server (pip install "scitt-cose[serve]"):
+uvicorn scitt_cose.hosted:make_asgi_app --factory --host 0.0.0.0 --port 8080
+
+# Or containerized (Dockerfile ships with the package):
+docker build -t scitt-verifier . && docker run -p 8080:8080 scitt-verifier
+```
+
+```
+GET  /         -> capabilities (what it does / does not do)
+POST /verify   -> {valid, statement, receipt, reasons}   # JSON body, see below
+```
+
+`GET /` is content-negotiated: browsers (`Accept: text/html`) get a static
+landing **page that renders the verifier-vs-Transparency-Service boundary table
+on the page itself** — not buried in docs — while API clients get the same data
+as JSON (including a `boundary` field). Both are generated from the same
+constants (`scitt_cose.hosted.BOUNDARY_TABLE`), so page and API can't drift;
+`tests/test_hosted_page.py` pins the table's presence on both.
+
+It can also **ride along** inside an existing ASGI app via
+`app.mount("/scitt-verify", scitt_cose.hosted.make_asgi_app())` — same logic,
+shared deployment, still standalone code. The full design, submitter-safety
+constraints, and proposed deployment shape are in
+[`docs/hosted-verifier-design.md`](docs/hosted-verifier-design.md). The package
+is ready to run privately today; a **public** endpoint is a coordinated launch,
+not shipped reflexively.
+
+## Tests
+
+```bash
+python3 -m pytest -q                     # unit + conformance suite (package root)
+SCITT_REQUIRE_GO=1 python3 -m pytest -q  # also forces the Go cross-check
+python3 -m ruff check .
+```
+
+## License & contributing
+
+Apache-2.0 — see [LICENSE](LICENSE) and [NOTICE](NOTICE). Contributions are
+accepted under the Developer Certificate of Origin (sign your commits with
+`git commit -s`); scope rules and the standards-honesty gates are in
+[CONTRIBUTING.md](CONTRIBUTING.md).