Why must an RFC 8485 `vot` vector travel with its `vtm` trustmark, and what does that trustmark point at?

## What the specification defines, and what it deliberately does not **RFC 8485** gives you the notation: four component demarcators, a single value character each, joined with `.`. What it does not give you is a value dictionary. There is no universal definition of `P1`, and that is on purpose — proofing practice differs so much between a bank, a research federation and a relief consortium that a single global scale would either be useless or be ignored. The meaning therefore lives in a **trust framework**: a published document that says, for the parties who have agreed to it, what each component value requires. A vector interpreted outside its framework is not a weaker claim; it is not a claim at all. ## The two claims, and the binding between them | Claim | Carries | What the relying party does with it | |---|---|---| | `vot` | The vector itself, e.g. `P1.Cc.Ac` | Parses it into components and values | | `vtm` | An HTTPS URL — the **trustmark** | Identifies which framework defines those values | The two are useless apart. `vot` without `vtm` is a string of letters with no dictionary. `vtm` without `vot` is a dictionary with nothing to look up. This is why RFC 8485 requires the vector to be communicated bound to its trustmark, and why a relying party's parser should reject the pair as incomplete rather than guessing a default framework — guessing a framework is how a partner's weakest grade silently becomes your strongest. ## What is at the end of that URL The trustmark URL resolves to a **human-readable** definition of the framework: what proofing evidence value `1` demands, what makes a credential qualify at value `c`, what counts as an acceptable assertion presentation. It is documentation for the people writing the mapping, not a machine-parseable schema, and that matters for how you operate it: - Someone on your side has to **read** it once, per framework, and encode the result in your own policy. - The URL is best treated as an **identifier** for the framework — a stable key you match against your policy table — rather than something fetched on every login. - If a partner changes the URL, you have a new framework as far as your policy is concerned, and it needs reading again before anything is admitted under it. ## The name collision you must not walk into The word *trust mark* appears twice in federation work, meaning two unrelated things: 1. an **RFC 8485 trustmark** — the HTTPS URL described above, pointing at a prose trust-framework document, carried in `vtm`; 2. an **OpenID Federation Trust Mark** — a signed JWT carrying `trust_mark_type` and issued about an entity by a trust mark issuer. One is a link to a document that defines vocabulary; the other is a cryptographically signed statement about a party. They are not two views of one mechanism, and nothing about verifying the second tells you anything about the first. Say which one you mean, every single time — in a design review, that ambiguity costs an hour. ## In the consortium, concretely Twelve relief organisations stand up shared access in two days. Three of them already belong to an existing sector framework and assert its trustmark; two have written their own one-page framework overnight and publish it at their own URL; the rest assert nothing on most axes. Your side ends up with a short list of trustmark URLs you have read and encoded, and a default-deny for any trustmark you have not. That list, not the vector strings, is the asset. Vectors arrive and change constantly; the set of frameworks you have actually read grows slowly, and it is the thing an auditor will ask you about afterwards. ## The failure to recognise The characteristic production failure here is not a rejected login — it is an **accepted** one. A relying party that treats the vector as self-describing, or that hard-codes a single framework because the first partner used it, will happily admit a second partner's `P1` under the first partner's definition. Nothing errors, nothing logs, and the assurance policy is quietly not being enforced. The guard is mechanical: no recognised trustmark, no interpretation.