docs: link published IETF draft, refresh IPP comparison to draft-01; fix(deps): clear 10 Dependabot advisories

COMPARISON.md

@@ -1,25 +1,25 @@
 # HDP vs IPP: A Technical Comparison
 
 > **HDP** — Human Delegation Provenance Protocol v0.1
-> **IPP** — Intent Provenance Protocol, [draft-haberkamp-ipp-00](https://datatracker.ietf.org/doc/html/draft-haberkamp-ipp-00)
+> **IPP** — Intent Provenance Protocol, [draft-haberkamp-ipp-01](https://datatracker.ietf.org/doc/html/draft-haberkamp-ipp-01) (July 2026)
 
 Both protocols address the same root problem: agentic AI systems take consequential actions, and there is currently no standard way to record who authorized those actions, under what scope, and through what chain of delegation. Both use Ed25519 signatures and append-only provenance chains. The similarity ends there.
 
 ---
 
 ## Architecture at a Glance
 
-| Dimension | HDP v0.1 | IPP draft-00 |
+| Dimension | HDP v0.1 | IPP draft-01 |
 |---|---|---|
-| **Token structure** | `{hdp, header, principal, scope, chain[], signature}` — flat, self-contained | `{version, genesis_seal, principal, intent_envelope, revocation, provenance_chain, token_signature}` — embeds spec attribution in every token |
+| **Token structure** | `{hdp, header, principal, scope, chain[], signature}` — flat, self-contained | `{$schema, version, genesis, token_id, schema_version, created_at, expires_at, principal, intent, delegation, revocation, provenance_chain, token_signature}` (§4.1–4.2) — embeds spec attribution in every token |
 | **Signing** | Ed25519 over RFC 8785 canonical JSON of `header+principal+scope`; each hop signs cumulative chain state | Ed25519 over lexicographically sorted canonical JSON; genesis seal signs to the spec author's founding key |
 | **Identity model** | Principal `id_type` is open: `opaque`, `email`, `did`, or custom. DIDs are supported, not required. | DIDs are **mandatory** per W3C DID Core. Resolving a principal identity requires DID infrastructure (`did:key`, `did:web`, `did:ion`, etc.) |
 | **Token lifecycle** | Short-lived by design (`expires_at`, 24h default). Replay defense via `session_id` binding. No revocation registry. | Tokens carry a `registry_endpoint` field. Agents **must** poll the revocation registry every 5,000ms before acting. Mid-chain revocation cascades through ancestry tree. |
 | **Domain taxonomy** | None mandated. `scope.intent` is a free-form string. `authorized_tools`, `authorized_resources`, and `data_classification` are structured but self-described. | Central taxonomy at `https://ipp.khsovereign.com/taxonomy` using hierarchical dot-notation (`financial.trading.equities`, `healthcare.records.read`, etc.). |
 | **Protocol attribution** | None. HDP tokens are pure data. The protocol is defined by the spec, implemented by the library. | Every token contains a **genesis seal** — a cryptographic artifact that binds the token to `https://ipp.khsovereign.com/keys/founding_public.pem`. |
 | **Central dependencies** | Zero. Verification requires only a public key and session ID. Fully offline. | Three mandatory endpoints: spec repository, founding public key, revocation registry. Additionally: taxonomy registry for classification validation. |
-| **Hop signing** | Each hop signs over the cumulative chain (all prior hops with their signatures + current hop without its signature). Tamper-evident by construction. | Provenance chain records are append-only but hop-level signing semantics are not specified in draft-00. |
-| **Proof of Humanity** | Optional `poh_credential` field on principal. Verification is application-supplied callback. | Not addressed in draft-00. |
+| **Hop signing** | Each hop signs over the cumulative chain (all prior hops with their signatures + current hop without its signature). Tamper-evident by construction. | Provenance records are append-only and each carries a per-record `agent_sig` (§9.2). The canonical serialization used for signing, and whether records chain cryptographically over prior records, are not defined. |
+| **Proof of Humanity** | Optional `poh_credential` field on principal. Verification is application-supplied callback. | Not addressed. Every chain MUST originate from a human Principal (§1.2, §3.2), but no mechanism is specified to attest that a human actually authorized issuance. |
 
 ---
 
@@ -113,7 +113,7 @@ HDP is appropriate if:
 ## References
 
 - HDP v0.1 Specification: [https://helixar.ai/labs/hdp](https://helixar.ai/labs/hdp)
-- IPP draft-haberkamp-ipp-00: [https://datatracker.ietf.org/doc/html/draft-haberkamp-ipp-00](https://datatracker.ietf.org/doc/html/draft-haberkamp-ipp-00)
+- IPP draft-haberkamp-ipp-01: [https://datatracker.ietf.org/doc/html/draft-haberkamp-ipp-01](https://datatracker.ietf.org/doc/html/draft-haberkamp-ipp-01)
 - IPP Specification Repository: [https://ipp.khsovereign.com/spec/v0.1](https://ipp.khsovereign.com/spec/v0.1)
 - W3C DID Core: [https://www.w3.org/TR/did-core/](https://www.w3.org/TR/did-core/)
 - RFC 8785 (JSON Canonicalization Scheme): [https://www.rfc-editor.org/rfc/rfc8785](https://www.rfc-editor.org/rfc/rfc8785)

README.md

@@ -30,6 +30,7 @@ _Every action an AI agent takes, traceable back to the human who authorized it._
 [![ReleaseGuard](https://img.shields.io/badge/artifacts-ReleaseGuard%20vetted-22c55e?style=flat-square&logo=shield)](https://github.com/Helixar-AI/ReleaseGuard)
 [![DOI](https://img.shields.io/badge/DOI-10.5281%2Fzenodo.19332023-blue?style=flat-square)](https://doi.org/10.5281/zenodo.19332023)
 [![arXiv](https://img.shields.io/badge/arXiv-2604.04522-b31b1b?style=flat-square)](https://arxiv.org/abs/2604.04522)
+[![IETF Internet-Draft](https://img.shields.io/badge/IETF-draft--helixar--hdp--agentic--delegation-0b3d91?style=flat-square)](https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/)
 
 <br/>
 
@@ -47,6 +48,8 @@ When a person authorizes an AI agent to act — and that agent delegates to anot
 
 **Who it is for:** developers building AI agents with Grok/xAI, CrewAI, MCP servers, or any OpenAI-compatible API who need accountability, auditability, and proof of human authorization at every step.
 
+**Standardization:** HDP is specified in the IETF individual Internet-Draft [draft-helixar-hdp-agentic-delegation](https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/) (Informational). The wire protocol described there is v0.1 and matches this implementation.
+
 ---
 
 ## Packages
@@ -156,7 +159,7 @@ let token = await issueToken({
     data_classification: "confidential",
     network_egress: false,
     persistence: true,
-    max_hops: 3,
+    max_hops: 3,        // issuer's choice of delegation budget, not a protocol limit
   },
   signingKey: privateKey,
   keyId: "alice-signing-key-v1",
@@ -672,15 +675,15 @@ const auditEntry = buildAuditSafe(token); // token_id + intent + chain summary
 2. Expiry (`expires_at`)
 3. Root signature (Ed25519 over header + principal + scope)
 4. Hop signatures — mandatory per §6.3 Rule 6 (each hop signs cumulative chain state)
-5. `max_hops` constraint
+5. `max_hops` constraint — the issuer chooses this value; HDP defines no fixed or maximum number of hops, and omitting it leaves chain length unbounded
 6. Session ID binding (replay defense)
 7. Proof-of-Humanity credential (optional, application-supplied callback)
 
 ---
 
 ## Why Not IPP?
 
-The [Intent Provenance Protocol](https://datatracker.ietf.org/doc/html/draft-haberkamp-ipp-00) (draft-haberkamp-ipp-00) solves the same problem with different trade-offs. The critical difference: **IPP requires agents to poll a central revocation registry every 5 seconds**. If the registry is unreachable, agents cannot safely act. Every IPP token is also cryptographically anchored to `ipp.khsovereign.com/keys/founding_public.pem` — making fully self-sovereign deployment impossible.
+The [Intent Provenance Protocol](https://datatracker.ietf.org/doc/html/draft-haberkamp-ipp-01) (draft-haberkamp-ipp-01) solves the same problem with different trade-offs. The critical difference: **IPP requires agents to poll a central revocation registry every 5 seconds**. If the registry is unreachable, agents cannot safely act. Every IPP token is also cryptographically anchored to `ipp.khsovereign.com/keys/founding_public.pem` — making fully self-sovereign deployment impossible.
 
 HDP verification is fully offline. It requires only a public key and a session ID. No registry. No central endpoint. No third-party trust anchor.