NPE Claims Should Use Binary Format Instead of JSON

[arkavo-com]

Issue

Currently, NPE (Non-Person Entity) claims are transmitted as JSON in HTTP requests to authnz-rs. This is inconsistent with the NanoTDF binary format used elsewhere in the architecture.

Current State

arkavo-edge → authnz-rs (authentication): JSON

{
  "platform_code": "macos-arm64",
  "platform_state": "Trusted",
  "device_id": "...",
  "app_version": "0.38.2"
}

authnz-rs → arkavo-edge (response): NTDF binary token (Z85 encoded)

Authorization: NTDF <z85-encoded-binary-token>

Proposal

NPE claims should be serialized as binary (matching NanoTDF format) and Z85 encoded for transport, rather than using JSON.

Benefits:

1. Consistency with NanoTDF binary format
2. Smaller payload size
3. Unified serialization approach
4. Better alignment with RATS attestation evidence formats

Impact

• authnz-rs API changes (breaking)
• arkavo-edge client changes
• Update NTDF token specification
• Migration path for existing deployments

Related Work

• NTDF token specification: ntdf-token/draft-arkavo-ntdf-token-00.md
• NanoTDF implementation: opentdf-rs
• arkavo-edge implementation: Issue #309

[arkavo-com]

TL;DR

Use Protocol Buffers (proto3) for the NTDF payload with deterministic (canonical) encoding required.
Do not compress JSON for the token payload (it’s small; compression adds CPU and often increases size).
Avoid FlatBuffers/Cap’n Proto for this use-case—zero-copy isn’t the bottleneck, and cross-lang signing/canonicalization is trickier.

---

•	“The NTDF token payload MUST be encoded using Protocol Buffers (proto3) with deterministic serialization. Implementations MUST sort repeated scopes and attrs as defined prior to encoding. Map fields are forbidden in the token payload. Producers MUST NOT include human-readable strings in the token; all identifiers and attributes MUST be numeric codes.”
•	“Compression is not used for the token payload. Large or verbose data MUST be referenced out-of-band or placed in an optional extension field outside the HTTP header path.”