[Feedback] KYA-OS 1.0: human-facing delegation verification and natural-person principals

## Summary

I'm an independent engineer in Japan. I read the KYA-OS 1.0 spec (MCP binding), built an
independent verifier against it, and confirmed interop with the reference implementation.
This issue reports two structural gaps I hit — both concerning the case where **the relying
party is a human** — plus three smaller technical points.

Artifacts (MIT, no affiliation, nothing to sell):

- Verifier (runs entirely in the browser): https://izurutoys.github.io/dare-no-dairi/
- Source + notes: https://github.com/IzuruToys/dare-no-dairi
- Japanese-language explainer of KYA-OS (first one I could find):
https://zenn.dev/izurutoys/articles/dare-no-dairi-kya-os

Interop check: credentials issued by `@kya-os/mcp` v1.11.0 `DelegationCredentialIssuer`
verify green in my implementation, and tampering flips them red — i.e. JCS canonicalization
and `Ed25519Signature2020` handling agree byte-for-byte with the reference implementation.

## Gap 1: No human-facing verification surface

Verification in the spec is machine-to-machine (detached JWS, DID resolution, chain
validation). The only human-facing surface is the consent flow (`authorizationUrl`, §9.2),
which lets a human **grant** authority — not **verify** a delegation presented to them.

This matters because a growing class of interactions puts a human on the relying-party side:
gig workers receiving tasks commissioned by agents (RentAHuman, MeatLayer and similar
marketplaces launched in 2026), merchant staff, call recipients. The power-of-attorney
metaphor the spec uses is precisely a document meant to be *shown to a person*.

The spec already recognizes the danger of unspecified human-facing surfaces: §11.1 lists
consent-URL substitution as a phishing threat. The same class applies to delegation display —
if rendering is unspecified, every implementer invents their own "who delegated what" screen,
and attackers can invent theirs too.

**Suggestion for v1.x — a Human Verification Profile defining:**

1. A normative minimum display set for rendering a delegation to a human: responsible party,
effective scope (including CRISP budget/temporal bounds), revocation status, chain summary.
2. A canonical interaction pattern: short URL / QR resolving to a rendering served by a
verifier **the recipient chooses**, never by the presenting agent.
3. Three-state results. My implementation renders 🟢 verified / 🔴 failed / ⚪ **could not
verify**, and keeps the third distinct. Concretely: a credential with no `credentialStatus`
is a delegation with *no revocation mechanism at all* — that is a material fact for a human
deciding whether to act, and collapsing it into "valid" hides it.

I've implemented one interpretation of the above and am happy to contribute it as a starting
draft if the WG finds this direction useful.

## Gap 2: No path for a natural-person principal

§4.1 profiles `did:key` for "ephemeral agents, development, testing" and `did:web` for
"production servers, organizational identity". I could not find a recommended binding for a
natural-person Responsible Party who controls no web origin — yet that is the common case in
consumer delegation.

Two questions:

1. Is `did:web` on a controlled subdomain (e.g. GitHub Pages) an intended binding for
individuals? If so, guidance on the trust semantics of shared-origin subdomains would help
verifiers, which otherwise have to treat `did:web:someone.github.io` as equivalent to a
dedicated domain.
2. §4.5's key-locality rule ("no other party generates, holds, escrows … an agent's secret
key") is stated for agent keys. Does the WG intend an analogous rule for *principal* keys?
Non-technical principals realistically need platform custody (passkeys, secure enclaves),
and explicit guidance would prevent divergent conformance interpretations.

## Smaller points

3. **Delegation depth asymmetry.** The Entity Card profile bounds chains at
`MAX_DELEGATION_DEPTH = 10` (§6.10); the base profile states no limit (§6.4). Unbounded
chains are a verification-cost DoS vector, and the asymmetry complicates cross-profile
expectations. (Related: #37.) Consider a normative cap, or explicit verifier-discretion
language, in the base profile.

4. **Downgrade path (§11.7).** The residual risk "a non-compliant client may omit KYA-OS
headers entirely" could be tightened with conformance-suite items: verifiers claiming L2+
MUST be configurable to reject unidentified invocations for designated scopes, and client
conformance MUST include the §9.3 step-2 challenge-proof check before following
`authorizationUrl`.

5. **Profile discrimination.** The base credential profile and the Entity Card profile
(VC 2.0 + ZCAP-LD) do not coexist in one deployment. How should a verifier receiving a
delegation determine which profile governs interpretation? An explicit profile identifier
(or registry) would prevent ecosystem bifurcation.

## Interop notes

While implementing I recorded the places where the spec doesn't uniquely determine an
implementation (canonicalization target, `proofValue` encoding, chain transport, status-list
verification). They're written up here in case they're useful for a conformance suite:
https://github.com/IzuruToys/dare-no-dairi/blob/main/FORMAT-NOTES.md

Two concrete divergences I noticed between spec text and the reference implementation:

- The reference verifier accepts `proof.proofValue || proof.jws || proof.signatureValue`;
the spec text only shows `proofValue`.
- The reference verifier does not enforce a `proof.type` string; I chose to treat anything
other than `Ed25519Signature2020` as "cannot verify" rather than valid.

Happy to turn any of the above into PRs if that's more useful than an issue.