skip to content

In RFC 8485, which four separate things does a vector of trust grade about a partner's 'verified' user?

level: juniorimportance: should knowfreq 30%

answer

  1. one word hides several separate facts
  2. proofing is not credential strength
  3. how it is managed, how it travelled
  4. four capital demarcators in one string
  5. axes, not stages of one pipeline

basics

~20 s

RFC 8485 grades four independent things rather than one score: how the person was identity-proofed (P), how strong the primary credential is in use (C), how that credential is managed over its life (M), and how the assertion reached you (A).

solid answer

~40 s

A vector of trust replaces a single overall grade with up to four component claims, each written as a demarcator plus one value. `P` grades identity proofing — what was done to establish that a real person is who they say they are. `C` grades the primary credential as it is used at authentication time. `M` grades how that credential is managed across its life: issuance, binding, replacement, revocation. `A` grades how the assertion about all of this was presented to you. They are independent axes, not stages of one process, so a subject can be strongly credentialed and deliberately not proofed at all — which is exactly the case RFC 8485 uses to argue that collapsing the four into one number destroys the information a relying party needs.

go deeper

for a junior

Recall that assurance is graded on several separate axes, and that identity proofing, credential strength, credential management and how the assertion travelled are four different questions.

for a middle

Explain each demarcator in your own words and give a case where two axes disagree, such as a strong credential on an account nobody proofed. Say what an absent component means.

for a senior

Show that you use the axes operationally: which axis actually gates which of your decisions, and what you do when a partner claims nothing on the one you care about most.

for a principal

The tradeoff is how much of the four-axis detail your own policy can consume. A policy that collapses everything back to one internal grade throws away the distinction the vector was created to preserve.

## Why one word is not enough When a partner organisation tells you a user is **verified**, that single word is standing in for several unrelated facts. Did someone check identity documents against a living person, or did the account appear from a self-service form? Is the credential presented at sign-in something an attacker can phish and replay, or something bound to hardware the user holds? Was that credential handed over in a controlled way and can it be revoked promptly? And did the statement reach you over a channel you can actually check? Each of those is answered by a different team, with different evidence, and they move independently. **RFC 8485** — *Vectors of Trust* — exists because compressing them into one scalar loses precisely the distinctions that matter. Its own worked case is a subject who is strongly credentialed and deliberately **not** proofed: a pseudonymous account with a hardware-bound credential. A single score has no honest place to put that subject; a vector does. ## The four component demarcators A vector is a set of components. Each component is a **demarcator** — one of four capital letters — followed by a single value. | Demarcator | What it grades | The question it answers | |---|---|---| | `P` | Identity proofing | What was done to tie this account to a real-world person? | | `C` | Primary credential usage | How strong is the credential actually presented at authentication? | | `M` | Primary credential management | How is that credential issued, bound, replaced and revoked over its life? | | `A` | Assertion presentation | How did the statement about this subject reach the relying party? | The components are written together, separated by `.`, giving a compact string such as `P1.Cc.Ac`. That example asserts something about proofing, something about the credential in use, and something about how the assertion was presented — and says **nothing at all** about credential management, because no `M` component is present. ## They are axes, not a pipeline The most common misreading is to treat the four as four steps that happen in order, so that a high value on one implies something about the others. They do not work that way: - A well-proofed person can hold a weak credential, because proofing happened once at enrolment and the credential was chosen later. - A very strong credential can sit on an account nobody ever proofed, which is the pseudonymous case above. - Excellent credential management — prompt revocation, controlled issuance — says nothing about how the resulting assertion travelled to you. - A perfectly presented assertion can carry a claim about a weakly proofed subject. Good carriage does not upgrade the content. A component that is **absent** from the vector is not a zero and not a default: it means **no claim is being made on that axis**. That is a deliberate feature, and it is what lets a partner be honest under time pressure rather than overstating. ## Where the other vocabulary fits The same four-way decomposition, in a different shape, is what **NIST Special Publication SP 800-63-3** is organised around: it splits assurance into three families — an identity-proofing family (IAL), an authenticator family (AAL) and a federation-assertion family (FAL) — instead of one overall grade. If a partner quotes a grade from that guideline and another sends you a vector, you are receiving claims on comparable axes, but expressed in two different vocabularies, and neither translates into the other by arithmetic. ## What the four components never tell you A vector grades how strongly an identity was established, credentialed and asserted. It does not say what the subject may **do**: entitlements, roles and resource permissions are a separate decision your own system makes after it has decided how much to believe the identity. It also carries no meaning on its own — the values are defined by a published trust framework, and a vector arriving without a pointer to that framework cannot be processed. Both of those are the next things to learn after the decomposition itself. For a consortium standing up shared access in a hurry, the practical payoff is this: partners can say *exactly* how much they are claiming, on each axis separately, on the day they join — including 'nothing' on the axes they have not had time to do.

  • Where does an authenticator's resistance to phishing show up in a vector of trust?
    On the credential axes, not the proofing one. How strong the credential is at the moment it is used is a `C` claim; whether it was issued, bound and revoked under control is an `M` claim. The ceremony that makes a particular authenticator phishing-resistant is not described by the vector — the vector only grades the result on those two axes.
  • Does a vector of trust say anything about what the user is allowed to do?
    No. It grades how strongly the identity was proofed, credentialed and asserted. Entitlements are a separate decision the relying party makes afterwards, using its own policy. A strong vector on a subject with no role in your system still buys that subject nothing.
  • Can a partner send a vector with only one component in it?
    Yes. A vector is a set of components, and a partner may include only those it is prepared to stand behind. The axes it leaves out are simply unclaimed, which is more useful than a fabricated value — and it tells you which questions you still have to answer some other way.

saying these in an interview costs you the question

  • Treats 'verified' as one yes-or-no fact about a user
  • Assumes a strong credential implies the person was proofed
  • Reads the four components as ordered stages of enrolment
  • Thinks an absent component means the lowest value
  • Says the vector also tells you what the user may access