Review request: cross-language verification of an experimental signed admission profile using RFC 8785 JCS

[bglassy]

I’m looking for technical criticism of a narrow experimental interoperability profile from the PlaceAuth / Spatial Policy Protocol (SPP) project.

The question is not whether SPP should become a standard.

The question is:

Can an independent implementation reproduce and safely verify this signed admission artifact contract without relying on the Python reference implementation?

The experiment grew out of a need to represent a machine’s admission state for a governed physical place in a form that can be independently verified across implementations.

The current experimental profile covers:

• RFC 8785 JSON Canonicalization Scheme (JCS)
• Ed25519 signatures
• AdmissionProfile payload binding
• subject binding
• place / space / derived-scope binding
• issuance and expiration time
• exact restriction identity for DEGRADED operation
• deterministic verification outcomes
• explicit canonicalization-profile versioning

The current profile identifier is:

rfc8785-jcs-v1-experimental

It is explicitly experimental and non-normative. SPP 0.1 remains unchanged.

Cross-language work

The profile has been implemented or independently verified in:

• Python
• Node.js
• Rust

All three implementations agree on 10 committed golden vectors.

A deterministic adversarial corpus currently contains 35 cases, with zero unexplained cross-language disagreements.

Two disagreements were found during the work and corrected before this review request:

1. Python originally accepted raw integer -0 because its JSON parser converted it to integer 0 before validation.

2. Python originally allowed values such as 1e20 because its JavaScript-safe-integer check applied only to Python int values, not mathematically integral floats.

The resulting experimental numeric contract is now:

• finite numbers only
• negative zero rejected
• mathematically integral values outside ±(2^53 - 1) rejected
• safe integral exponent representations such as 1e3 accepted
• valid finite non-integral numbers retained
• no silent coercion of unsafe numeric values

Raw parsing and canonicalization are intentionally treated as separate security boundaries.

Other relevant rules include:

• duplicate decoded JSON keys are rejected
• no implicit Unicode normalization
• timestamps use exact UTC-second form:
  YYYY-MM-DDTHH:MM:SSZ
• equivalent offsets or fractional-second representations are not accepted
• canonicalization profile identifiers are signature-bound
• an older signed artifact must not be silently reinterpreted under a newer profile

Signed envelope

The experimental signed metadata covers:

• issuer_id
• algorithm
• envelope_type
• envelope_version
• canonicalization_profile
• subject_id
• place
• space
• scope
• issued_at
• expires_at
• signed_payload_digest

The AdmissionProfile itself is bound through signed_payload_digest.

Ed25519 is the only algorithm tested for this profile.

DEGRADED restrictions

A DEGRADED admission state can contain exact operating restrictions.

The current experiment treats restriction identity strictly:

• exact restriction string
• SHA-256 restriction digest
• no trimming
• no case folding
• no fuzzy matching
• no Unicode normalization
• whitespace-only restrictions are invalid

An acknowledgement must correspond to the exact restriction being relied upon.

This is intended to prevent a generic “supports degraded mode” flag from being treated as evidence that a downstream adapter understands the actual restriction.

The acknowledgement proves recognition/configuration mapping only. It does not prove that the physical robot actually enforced the restriction.

What I would especially like reviewers to attack

1. Canonicalization / parser ambiguity

Are there JSON, Unicode, numeric, duplicate-key, timestamp, or encoding cases that could cause two otherwise conforming implementations to verify different bytes?

2. Signature binding

Is anything security-relevant missing from the signed metadata?

Is anything signed that should not be?

Could an attacker substitute adjacent unsigned state while retaining a valid signature?

3. Subject and spatial scope binding

Are the subject / place / space / scope semantics sufficient to prevent an artifact from being accepted in the wrong context?

The current model allows same-context reuse until expiry or revocation. It does not claim to prevent all replay.

4. Numeric rules

Is restricting mathematically integral values to the JavaScript safe-integer range a reasonable interoperability rule for this profile?

Are there important RFC 8785 edge cases the current experiment may still mishandle?

5. DEGRADED restriction acknowledgement

Is exact restriction identity a useful safety boundary?

Is the current acknowledgement/mapping model unnecessarily complicated?

Is there a simpler mechanism with equivalent fail-closed behavior?

6. Failure taxonomy

The current language-neutral categories are:

• malformed
• unsupported_profile
• invalid_signature
• untrusted_issuer
• subject_mismatch
• scope_mismatch
• expired
• invalid_time
• binding_mismatch

Implementations do not need identical internal exception types.

Is this division useful, incomplete, or misleading?

7. Trust and lifecycle boundary

The profile deliberately does not attempt to define a complete PKI or issuer federation model.

Is that separation clean, or does the signed-artifact layer currently assume too much about trust lifecycle?

Supporting material:

Technical peer-review entry point:
https://github.com/placeauth/spatial-policy-protocol/blob/main/docs/review/README.md

Experimental admission-trust interoperability profile:
https://github.com/placeauth/spatial-policy-protocol/blob/experiment/admission-trust-profile-draft/docs/experimental/admission-trust-interoperability-profile.md

JCS canonicalization experiment:
https://github.com/placeauth/spatial-policy-protocol/tree/experiment/jcs-canonicalization-profile

Rust interoperability experiment:
https://github.com/placeauth/spatial-policy-protocol/tree/experiment/jcs-rust-verifier

P0 trust-pipeline experiment:
https://github.com/placeauth/spatial-policy-protocol/tree/experiment/p0-trust-pipeline

What I am NOT asking reviewers to evaluate here:

• whether SPP should become a formal standard
• production PKI design
• issuer federation
• remote discovery
• Open-RMF planner architecture
• robot physical-enforcement guarantees
• commercialization
• patentability
• normative SPP 0.2 language

This is specifically a request to review the experimental wire/canonicalization/signature/binding contract.

The most useful feedback would be:

• a concrete interoperability ambiguity
• a parser or canonicalization attack
• a missing signed field
• a replay or substitution problem
• an unsafe trust assumption
• unnecessary complexity
• a test vector that should exist but currently does not
• an existing standard/profile that solves this problem more cleanly

Even a small reproducible counterexample would be extremely valuable.