skip to content

In RFC 8485, what does the vector `P1.Cc.Ac` claim, and what does its absent `M` component mean?

level: middleimportance: must knowfreq 42%

answer

  1. component, then one value character
  2. dots join, position carries nothing
  3. repeats mean AND, not override
  4. absent is not zero
  5. values mean what the framework says

basics

~20 s

It makes three component claims — a proofing value, a primary-credential-usage value and an assertion-presentation value — whose meanings come from the trust framework named alongside it. The missing M component is not a zero: no claim is made about credential management.

solid answer

~40 s

Read a vector component by component. Each component is a demarcator (`P`, `C`, `M` or `A`) followed by a single digit or lowercase letter, and components are joined with `.`. So `P1.Cc.Ac` carries a proofing claim, a primary-credential-usage claim and an assertion-presentation claim. Order is insignificant — `Ac.P1.Cc` is the same vector. A demarcator may appear more than once, and repeated components combine with logical AND, though the same component-and-value pair must not appear twice. What the values `1`, `c` and `c` actually mean is defined by the trust framework, so the string is only interpretable together with the trustmark that identifies that framework. And `M` being absent means the provider is claiming nothing about credential management — not the framework's lowest value.

code

json · 6 lines
json
{
  "iss": "https://idp.relief-partner.example",
  "sub": "a7f2c9d4",
  "vot": "P1.Cc.Ac",
  "vtm": "https://framework.example/consortium/v1"
}

go deeper

for a junior

Recall the shape: a capital letter, one value character, components joined by dots, and four possible letters. Knowing that a missing letter is a gap rather than a zero already puts you ahead.

for a middle

Parse a vector aloud component by component, then state what it does not claim. Explain why order is insignificant and why repeated components are ANDed rather than overriding.

for a senior

Show what you do with a gap: default-deny is your policy choice, not the vector's meaning, and you should be able to say which of your decisions each axis actually gates.

for a principal

The design question is how much per-axis detail your access policy can honestly consume before it collapses the vector back into one internal grade and loses what it was for.

## The grammar, one component at a time A **vector of trust** is a set of components serialised into one string. Each component is: 1. a **demarcator** — a single capital letter, one of `P` (identity proofing), `C` (primary credential usage), `M` (primary credential management) or `A` (assertion presentation); 2. followed by exactly one **value** — a single digit or a single lowercase letter. Components are separated by `.`. So `P1.Cc.Ac` is three components: `P` with value `1`, `C` with value `c`, `A` with value `c`. The value characters carry no arithmetic meaning of their own; `1` is not 'stronger than 0' and `c` is not 'better than b' unless the trust framework behind the vector says so. ## The four rules that trip people up | Rule | What it means in practice | |---|---| | **Order is insignificant** | `Ac.P1.Cc` and `P1.Cc.Ac` are the same vector. Never write a comparison that depends on position. | | **A component may repeat** | The same demarcator can appear more than once with different values, and the repeated components are combined with **logical AND** — the subject satisfies both. | | **No duplicate pairs** | The same component-and-value pair must not appear twice in one vector; repetition is for *different* values of the same axis. | | **Omission means no claim** | An absent demarcator is not a default, not a zero and not 'unknown but probably low'. It is the provider declining to make a claim on that axis. | The fourth rule is the one that does the most work in practice, and it is also the one candidates most often get backwards. ## Why 'no claim' is not the same as 'the lowest value' They differ in who is responsible. A low value is a **positive statement**: the provider looked, and reports a weak result. An absent component is a **refusal to state**: the provider is not standing behind anything on that axis, and the relying party must find the answer elsewhere or decide it does not need one. That distinction is exactly what a hastily assembled consortium needs. A relief partner that onboarded its field staff in a day can honestly assert a credential claim and an assertion claim while omitting proofing entirely, rather than inventing a proofing value it cannot defend. Your side then applies its own policy to the gap. Default-deny on an unclaimed axis is a perfectly reasonable policy — but it is *your* policy, not the meaning of the vector. ## Reading `P1.Cc.Ac` end to end Walking the example: - **`P1`** — a proofing claim exists, at the value the framework labels `1`. - **`Cc`** — a claim about the credential as used at authentication time, at value `c`. - **`Ac`** — a claim about how the assertion was presented, at value `c`. - **No `M`** — nothing is claimed about issuance, binding, replacement or revocation of that credential. So you know something about how the subject was proofed, something about what they present when they sign in, and something about how the statement reached you — and you know nothing about what happens when that credential is lost or must be revoked. If your decision turns on revocation, this vector does not support it, and no amount of re-reading the string will change that. ## The string alone is not the claim The values are defined by a trust framework, so a vector is processed together with the trustmark that names that framework; the vector is carried in the `vot` claim and the trustmark in `vtm`. Two providers can send the identical string and mean two different things. That is not a flaw in the notation — it is what makes the notation reusable across frameworks that grade differently — but it does mean that comparing raw strings from two partners is meaningless. ## The check to run on yourself Before acting on a vector, ask three questions in order: which axes are claimed, which framework defines these values, and which of the axes my decision actually depends on. If the third names an axis the first does not include, you are about to rely on something nobody asserted.

  • What does it mean when the same demarcator appears twice in one vector?
    The repeated components combine with logical AND: the subject is claimed to satisfy both values on that axis, not the greater of the two. The same component-and-value pair must not appear twice, so repetition is only ever used for different values of one axis.
  • If your policy needs a claim on an axis the partner omitted, what are your options?
    Three, and they are all yours to choose: refuse the login, admit the subject at a reduced level of access that does not depend on the missing axis, or obtain the fact another way — out-of-band evidence, or a second check you perform yourself. What you must not do is read the omission as a value.
  • Does `Ac.P1.Cc` need to be reordered before comparison?
    No, and reordering to compare is a sign the comparison itself is wrong. Order is insignificant, so a vector should be parsed into a set of components and evaluated as a set. String equality against a partner's vector is fragile for exactly this reason.

saying these in an interview costs you the question

  • Reads an absent component as the framework's lowest value
  • Compares two vectors by string equality across frameworks
  • Thinks component order changes what a vector claims
  • Treats a repeated demarcator as the later value overriding
  • Assumes value characters carry built-in numeric strength