skip to content

Two partners each assert `P1` under their own trust frameworks — why can you not compare those claims, and what do you build instead?

level: seniorimportance: must knowfreq 38%

answer

  1. matching strings, different practice
  2. no ordering, no nesting
  3. translate, never compare
  4. keyed by framework, not by value
  5. unknown framework, default deny

basics

~20 s

Component values are defined per trust framework and carry no ordinal or subsumptive meaning, so identical strings from two frameworks are not comparable. Build a mapping table per framework, keyed by its trustmark, that translates each partner's claims into your own policy decisions.

solid answer

~50 s

A vector value is a label inside one framework, not a magnitude on a shared scale. RFC 8485 is explicit that a relying party must not assume component values are **ordinal** — that a higher character means more — or **subsumptive** — that a stronger value implies everything a weaker one would have claimed. So two partners' `P1` claims can describe entirely different proofing practice, and comparing them arithmetically is meaningless. What works is a mapping table: one row set per trust framework, keyed by the trustmark URL, written once by somebody who read that framework's document, translating each value into what *your* policy will let it do. Unknown trustmark, no mapping, default-deny. The same applies to a partner quoting grades from a published guideline rather than a vector: that is another framework, mapped the same way.

go deeper

for a junior

Recall that the same vector string from two organisations can mean two different things, and that the framework named alongside it is what decides.

for a middle

Explain what 'not ordinal' and 'not subsumptive' each rule out, and why that leaves enumeration and mapping as the only honest operations on component values.

for a senior

Describe the artefact and the failure it prevents: a mapping table keyed by trustmark, explicit no-claim rows, default-deny for unread frameworks, and the silent cross-framework accept you are guarding against.

for a principal

The real decision is how many frameworks the organisation will ever accept, since each one is a document somebody re-reads on every revision — and who owns that table when the emergency is over.

## Why the obvious comparison is wrong A relying party receiving `P1` from two partners is holding two strings that happen to match. What the value `1` requires — what evidence was examined, by whom, against what — is defined by each partner's **trust framework**, and nothing obliges two frameworks to agree. One may require an in-person check against a government document; another may mean a colleague vouched for the person by telephone. RFC 8485 states the constraint directly: the relying party **must not assume ordinal or subsumptive properties** of component values. - **Not ordinal** — you may not conclude that `2` is stronger than `1`, or `c` stronger than `b`, unless the framework itself says so. - **Not subsumptive** — a stronger value does not automatically include everything a weaker one would have claimed; there is no guarantee the framework's values nest. Together these remove every shortcut. There is no arithmetic, no maximum, no 'at least' operator, and no cross-framework normalisation that the notation supports. ## What you build instead A **per-framework mapping table**, keyed by the trustmark URL, and read once by a human. | Column | Contents | |---|---| | Trustmark | The framework's HTTPS URL, matched exactly, used as the key | | Component + value | e.g. this framework's proofing value `1` | | What it permits here | The decision in *your* vocabulary: which operations this claim is sufficient for | | Reviewed | Who read the framework document, and when | Three properties make it work: 1. **It is keyed by framework, not by value.** The same string under a different trustmark is a different row, which is what stops the silent cross-framework accept. 2. **It has an explicit 'no claim' row per axis.** Since an omitted component means no claim, your table must say what you do about that — and default-deny on the axes that gate real operations is a defensible answer. 3. **It has a default-deny for unknown trustmarks.** A framework nobody has read cannot be mapped, and mapping it optimistically is the failure mode that matters. ## The other vocabulary on the table Not every partner will speak in vectors. Some will quote a grade from a published guideline: **NIST Special Publication SP 800-63-3** organises assurance into three families — identity assurance (IAL), authenticator assurance (AAL) and federation assurance (FAL) — rather than a single overall grade, which is the same insight the four-component vector expresses in a different shape. That does not make the two interchangeable. A guideline grade is another framework's vocabulary, and it gets another block of rows in the same table. Resist the temptation to write a translation function between the two schemes: you would be inventing equivalences neither document states, and the invention would be invisible to everyone reviewing the result later. ## The consortium case Twelve organisations, forty-eight hours, no time to agree a common framework — and no need to. Each partner asserts under whatever framework it already has, or under a one-page framework it publishes for the emergency. Your side does three things: 1. Reads each framework document once and writes the rows. 2. Decides, per operation, which rows are sufficient — a shelter roster read and a controlled-supply release do not need the same claim. 3. Denies by default anything asserting under a trustmark not in the table, while keeping a path to admit those subjects at whatever access requires no assurance claim. What this buys is the ability to say afterwards, precisely, what each admitted login was worth — which is the question that arrives after the emergency, not during it. ## The failure this prevents The characteristic failure is not a rejection. It is a **silent accept**: a relying party that hard-codes the first partner's framework, or normalises every partner into one internal numeric grade, will admit a second partner's `P1` under the first partner's definition. No error is raised and no log line is unusual. The only defence is structural — interpretation happens through the table, and the table is keyed by trustmark. ## What to say in an interview Name the constraint (values are framework-relative, not ordinal, not subsumptive), name the artefact (a per-framework mapping table keyed by trustmark, with explicit no-claim and unknown-framework rows), and name the failure it prevents (a silent cross-framework accept). Then say who owns the table, because the honest answer is that somebody has to re-read a framework document every time a partner revises it, and that ongoing cost is the real argument for keeping the number of accepted frameworks small.

  • What does 'must not assume subsumptive properties' rule out that 'not ordinal' does not?
    Ordinality is about ranking: you may not decide `2` beats `1`. Subsumption is about containment: even if a framework does rank its values, a higher one does not automatically satisfy every requirement the lower one would have satisfied. A policy written as 'anything at least this strong' relies on both assumptions at once.
  • A partner asserts a grade from a published guideline rather than a vector. Does that change the approach?
    No. It is another framework with another vocabulary, so it gets its own rows in the same mapping table, keyed the same way. What you must not do is write a translation between the guideline's families and the vector components — no document states those equivalences, and inventing them buries a judgement call in code.
  • How do you keep the mapping table honest as partners change their frameworks?
    Treat a changed framework identifier as a new framework: no rows, therefore default-deny, until somebody reads the revision. Record who reviewed each framework and when, and keep the accepted set small — the maintenance cost is per framework, and it is paid forever, not at onboarding.
  • Is it ever safe to collapse all partners into one internal assurance grade?
    Only if the collapse is the *output* of the mapping table rather than a substitute for it. Mapping each framework's claims into your own internal vocabulary is exactly the right design; normalising incoming vectors into one number before the framework is identified is the failure mode.

saying these in an interview costs you the question

  • Compares component values numerically across two frameworks
  • Assumes a higher value subsumes everything a lower one claims
  • Normalises every partner into one internal grade on receipt
  • Writes a translation between vectors and a guideline's families
  • Admits a subject asserting under an unread trust framework