Surfaced during the v0.1.0 review (PR #2). Spec clarity work.
§4 lists ClientHello and ServerHello fields but never states a resolution rule for the negotiation. Specifically:
- Profiles:
ServerHello.profiles_accepted description says "The Guardian selects from the client's profiles_supported based on its own capabilities and policy requirements." Is this the intersection, a Guardian-chosen subset, or Guardian-augmented (Guardian adds profiles the client didn't claim)? §4 says a Guardian MAY refuse a session if the client doesn't declare a policy-required profile, but how, and with what error code?
- Methods: ServerHello says
methods_evaluated is a "subset" of the client's methods_implemented. Can the Guardian list a method NOT in methods_implemented?
- Signatures: ServerHello declares supported algorithms, but ClientHello has no signature-algorithms field. The Observed Agent has no negotiated set to pick from when it goes to sign a request.
The failure mode: two conformant implementations cannot agree on the active capability set after handshake. Vendor A treats profiles as intersection. Vendor B returns Guardian-required profiles the client must support or fail-closed. Vendor C treats profiles_accepted as a strict subset of client-declared. Different outcomes for the same handshake, different sessions either run or refuse, no SDK can write portable session setup.
Proposed direction:
- §4 normative table: for each field pair, name the resolution operation (intersection, Guardian-selects-from-client, Guardian-required-or-refuse)
- ClientHello should carry a
signature_algorithms_supported field so the Observed Agent has a negotiated set
- Refusal cases should be wired to the error code registry (separate issue)
Why deferred from v0.1.0: real ambiguity but smaller blast radius than the precedence issues in the main PR review. Could land in the same disposition-semantics follow-up PR.
References: specification.md §4, handshake.json
Surfaced during the v0.1.0 review (PR #2). Spec clarity work.
§4 lists ClientHello and ServerHello fields but never states a resolution rule for the negotiation. Specifically:
ServerHello.profiles_accepteddescription says "The Guardian selects from the client'sprofiles_supportedbased on its own capabilities and policy requirements." Is this the intersection, a Guardian-chosen subset, or Guardian-augmented (Guardian adds profiles the client didn't claim)? §4 says a Guardian MAY refuse a session if the client doesn't declare a policy-required profile, but how, and with what error code?methods_evaluatedis a "subset" of the client'smethods_implemented. Can the Guardian list a method NOT inmethods_implemented?The failure mode: two conformant implementations cannot agree on the active capability set after handshake. Vendor A treats profiles as intersection. Vendor B returns Guardian-required profiles the client must support or fail-closed. Vendor C treats
profiles_acceptedas a strict subset of client-declared. Different outcomes for the same handshake, different sessions either run or refuse, no SDK can write portable session setup.Proposed direction:
signature_algorithms_supportedfield so the Observed Agent has a negotiated setWhy deferred from v0.1.0: real ambiguity but smaller blast radius than the precedence issues in the main PR review. Could land in the same disposition-semantics follow-up PR.
References:
specification.md§4,handshake.json