skip to content

In RFC 8485, how does a relying party's `vtr` claim request state which vectors of trust it will accept?

level: middleimportance: nice to knowfreq 18%

answer

  1. an array, not a single string
  2. two levels of logic, not one
  3. inside is all, across is any
  4. no ordering means no threshold
  5. a request, not a guarantee

basics

~20 s

vtr is a claim request whose value is a JSON array of vector strings. Components inside one string are ANDed — all must hold — while the entries across the array are ORed, so satisfying any single listed vector satisfies the request.

solid answer

~40 s

The relying party expresses its requirement as a `vtr` claim request: a JSON array, each element a vector string. Read it as two levels of logic. Within one element the components combine with **logical AND** — the subject must satisfy every component in that vector. Across the array the elements combine with **logical OR** — any one of them being satisfied is enough. That structure lets you say 'strong proofing plus a strong credential, *or*, failing that, this weaker combination' in one request. What comes back is a `vot` the provider is actually willing to assert, with its `vtm`; `vtr` states what would be acceptable, and the relying party still evaluates the returned vector against its own policy.

code

json · 6 lines
json
{
  "vtr": [
    "P1.Cc.Ac",
    "Cc.Ac"
  ]
}

go deeper

for a junior

Recall that the relying party can state what it will accept, and that it does so as a list of whole vectors rather than a single minimum grade.

for a middle

Get the two levels of logic the right way round: all components inside one entry, any one entry across the array. Explain why there is no threshold form.

for a senior

Show the operational half: different operations warrant different requests, and your code must handle a returned vector that satisfies nothing you listed without pretending otherwise.

for a principal

Decide how many distinct acceptance lists your estate can maintain. Every operation-specific request is a policy statement somebody must revisit when a partner's framework changes.

## Asking, rather than assuming Accepting whatever assurance a partner happens to send is a reasonable default only until you have an operation that genuinely needs a stronger claim. RFC 8485 gives the relying party a way to say in advance what it would accept: the **`vtr` claim request**. Its value is a **JSON array of strings**, and each string is an ordinary vector in the notation you already know — components of one demarcator plus one value, joined with `.`. ## Two levels of logic, and they differ This is the whole question, and it is the part people invert: | Level | Combination | Reading | |---|---|---| | Components **within** one array element | **AND** | every component in that vector must hold | | Elements **across** the array | **OR** | satisfying any one of them satisfies the request | So an array of two vectors is not 'both of these'. It is a preference list of acceptable shapes: *this* combination, or *that* one. Getting it backwards produces a request no provider can ever satisfy, and the symptom is an authentication that keeps coming back with less than you asked for while the logs show nothing wrong. ## Why a list rather than a threshold The obvious alternative — 'anything at or above this level' — cannot be expressed, and deliberately so. Component values have no built-in ordering, so there is no 'above'. A list of acceptable vectors is the only honest way to express a requirement in a notation where values are framework-defined labels rather than magnitudes. It also forces the relying party to have actually thought about which combinations it will take, instead of hiding that decision behind a comparison operator. ## What comes back, and what does not The response carries a `vot` — the vector the provider is prepared to assert about this subject — together with its `vtm` trustmark. Several things are worth being precise about: - The provider answers with what it **can** assert, which may be less than any entry in your list. A request is not a guarantee. - The returned vector may omit axes you listed. An omitted component is still **no claim**, exactly as in any other vector. - The evaluation is then **yours**: parse the returned vector, look up its framework by trustmark, and decide whether it satisfies at least one entry of what you asked for. - A returned vector that satisfies nothing you listed is not an error condition in the protocol sense. It is an answer, and your policy decides what to do with it — refuse, admit with reduced access, or seek the missing evidence another way. ## In the consortium The relief consortium's case-management system holds two classes of operation: reading a shelter roster, and releasing controlled medical supplies. Those deserve different requests. For the roster, the relying party lists a permissive set of acceptable vectors, including entries that make no proofing claim at all, because field volunteers were onboarded in hours. For the release operation it lists only entries that include a proofing component and a strong credential component. That is the practical value of the array: one relying party, two operations, two different `vtr` requests, and neither of them pretends that a single global threshold exists. ## The mistakes to avoid Three recur: 1. **Inverting the logic** — treating the array as a conjunction, which yields an unsatisfiable request. 2. **Treating the request as binding** — writing code that assumes the returned `vot` is one of the listed strings, which breaks the first time a provider asserts less. 3. **Comparing across frameworks** — listing vectors in your framework's vocabulary and matching them against a partner asserting under theirs. Your list is only meaningful against the framework its values came from, so the trustmark check happens before any matching at all.

  • In the example array, what does the second entry `Cc.Ac` accept that the first does not?
    An assertion that makes no identity-proofing claim at all. The first entry requires a proofing component alongside the credential and assertion components; the second lists only the latter two, so a subject whose proofing was never claimed can still satisfy the request. That is a deliberate policy choice, written down where it can be reviewed.
  • What should a relying party do when the returned `vot` matches none of the listed vectors?
    Apply its own policy. Nothing was violated: the provider asserted what it could. The sensible outcomes are to refuse, to admit with access that does not depend on the missing axis, or to obtain the evidence out of band. Silently proceeding as if the request had been met is the one unacceptable option.
  • Why can a `vtr` request not simply say 'at least this level'?
    Because component values are framework-defined labels with no ordinal meaning — there is no 'at least' to evaluate. Enumerating the acceptable vectors is the only way to state the requirement without assuming an ordering the notation does not have.

saying these in an interview costs you the question

  • Reads the array as requiring every listed vector
  • Treats a vtr entry as a guarantee the provider will assert it
  • Expects the returned vector to be one of the listed strings
  • Thinks the request can express 'this level or higher'
  • Matches listed vectors without checking the returned trustmark