Android and iOS

Binding evidence to JSON and Protobuf requests

Designing client, server, framework and policy layers together.

Protection architecture1 min readEditorial methods

Evidence must remain bound to the same business data regardless of request format. Representation differences can cause clients and servers to calculate different digests.

Evaluation approach

Define field order, number representation, defaults and unknown-field behavior. Serialization stability is part of the protocol.

Application example

Use test vectors to confirm that mobile and server implementations generate identical verification inputs from the same payment fields.

Limits and considerations

Ad hoc JSON concatenation or assuming identical serializer output across versions is risky.

Serialization is a security contract

Equivalent data can have different byte representations. Define the fields and canonical encoding used for hashing or signing. A deterministic serializer setting should not be assumed to resolve every version and language difference.

Include empty fields, unknown fields and number formats in test vectors. The server derives the expected digest from its business data rather than blindly accepting the client's claimed coverage.

Checks and decisions

  • Define canonical representation
  • Test boundary values
  • Carry schema versions

Before validating cryptography, establish exactly which data is being verified.

Sources

The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.