# 6.13.4.7 What the appendix carries

The appendix is the witness followed by the second part, with an optional text field after them. The text field is optional, so a protocol that needs to carry a context should decide whether it travels in the appendix or in the domain separation string of the larger set.

## What it asks

Define the appendix layout your protocol carries, including whether the optional text field is present, and keep it stable across versions. Record the decision, because a verifier that assumes no text field will fail when one appears.

## What the amendment does

Inserts 6.13.4.7.

## Who it binds

The protocol owner and the API owner.

## Evidence an auditor samples

- The appendix layout in the interface specification (interface specification)
- The parser test, with and without the text field (test suite)
- The versioning note, stating whether the layout can change (design note)

## The test you can run

Send an appendix with a text field to a verifier that expects none. If it fails with an unhandled error rather than a clean rejection, the parser is not bounded.

## Common failures

- The optional field is used for data that belongs in the signed message.
- The parser reads past the end of the appendix.

## How to close it

An optional field in a security structure is a versioning problem. Decide whether it is present, say so in the contract, and bound the parser so that a future sender cannot turn a data field into a denial of service.

## Source

ISO/IEC 14888-3:2018/FDAM 1:2026(en), draft, 6.13.4.7. Read on 21 October 2026. Our wording, not the instrument's.
https://www.iso.org/standard/89517.html

Not legal advice; does not certify.