Summary

  • Revision 02 of Identity Verification Methods Values, dated 2 October 2026, says that an ivm value means the named identity-verification method succeeded. It also says the claim supplies neither the evidence nor the details of how that method was used.
  • The proposed vocabulary can improve interoperability, but it cannot by itself establish provider quality, source authority, procedure equivalence, freshness, assurance level, legal sufficiency or the application decision that followed.

Compression is useful until a short code begins to borrow authority from everything it leaves out. That is the governance boundary exposed by draft-skyfire-oauth-id-verification-02.

The draft proposes ivm, a JSON array of case-sensitive strings. Its initial vocabulary includes database verification using an unspecified number of consumer-reporting sources, one source or multiple sources; digital and physical identity-document verification; secondary documents; in-person verification; and a live video interview. A relying system can receive a compact account of which method families succeeded.

Revision 02 adds the sentence that should govern every use of that account. Presence of a value indicates that the method succeeded. The claim does not provide evidence or details of how the method was used. The document points deployments needing that depth toward OpenID Identity Assurance or Vectors of Trust, either alongside ivm or separately.

That caveat is not a defect in the vocabulary. It defines the vocabulary's proper job. A method identifier can stop two systems from inventing different strings for the same broad technique. It can make logs searchable, policy rules portable and assertions smaller. It cannot carry the complete proofing case without becoming a different data structure.

Consider dbv1 and dbvm. One says that one consumer-reporting data source was used; the other says multiple sources were used. The labels do not name those sources, show whether they are independent, identify the records queried, preserve their dates, reveal conflicts, disclose the match threshold or say which attributes agreed. Counting sources is not the same as establishing their authority or diversity.

The document values have similar internal variation. phy can cover a real-time capture of a driver's licence or passport page, but the label does not say which document version, issuing jurisdiction, capture device, anti-tampering check or biometric comparison was used. dig does not say which digital-credential trust framework governed the presentation. vid names a live interview, not its liveness control, operator, script, recording policy or exception handling. inp does not identify the site, reviewer or supervised equipment.

Even the word “succeeded” is local to a procedure. It tells the recipient that the issuer reached its success state. It does not disclose the success threshold, demonstrate that two issuers share one threshold, or prove that the asserted real-world identity is correct. A signed JWT can authenticate who made the statement and protect it against undetected alteration. It cannot recover facts that the statement never contained.

The proposed IANA structure should be read with the same precision. Revision 02 asks for an ivm JWT claim and a new Identity Verification Methods registry. It proposes Expert Review, three weeks of mailing-list review and criteria such as avoiding duplication, serving general use, reflecting actual use and having a clear description. Those controls improve namespace quality. They do not accredit providers, certify implementations or assign a universal assurance score.

The active IANA registries remain the authority for actual allocations. A table printed in an individual Internet-Draft is proposed initial content, not proof that IANA already created the registry. The frozen Datatracker record has no stream, intended standards level or standards level. Association with the OAuth area and its discussion venue does not turn it into an adopted Working Group document or an RFC.

The analogy to amr is instructive. RFC 8176 standardised authentication-method reference values, while warning that policies tied directly to particular methods can become brittle as attacks and deployments evolve. Method names help report what happened. A broader authentication context can express the policy class a service required. Identity proofing needs the same distinction between the mechanism label and the assurance contract under which it was accepted.

OpenID Identity Assurance shows what richer transport looks like. It can separate the trust framework, assurance level and process; overall verification time; a reference to the verification case; evidence objects; and individual check details such as method, organisation, event identifier and completion time. RFC 8485 likewise says vector values are meaningful within a specific trust framework that the relying party must understand.

NIST SP 800-63A-4 adds another useful decomposition. It separates identity resolution, evidence collection and strength, validation and verification. A code saying “physical document” or “video” crosses only one semantic coordinate. It says nothing by itself about the evidence strength, the authoritative or credible source used for validation, or the binding of the applicant to the evidence.

The operational answer is not to reject compact claims. It is to stop them from becoming evidence-shaped shadows. Preserve an evidence receipt beside the token: exact vocabulary version; issuer and trust framework; subject and transaction binding; method values; provider and policy version; immutable evidence reference; source and jurisdiction; validation and verification checks; liveness or human-review result; timestamps; assurance classification; exceptions; local decision; and application outcome.

That list is editorial operating guidance, not draft text. Its purpose is reconciliation. When a provider changes a threshold, a database refreshes, a document expires, a jurisdiction changes its rule or an auditor asks what happened, the organisation can reconstruct the decision without pretending the three-letter code contained a case file.

Heng Lu's Minimum Initial Specification supports the boundary: standardise the smallest vocabulary needed for voluntary interoperability, then preserve local responsibility for consequential decisions. Running-Code Primacy asks which checks actually executed, not which label a token carried. Reality Layers prevents a registry term, an issuer assertion, an evidence record, an assurance judgment and a final action from collapsing into one status.

ivm can therefore be valuable precisely because it is small. The condition is intellectual and operational honesty. Let the label name the method. Make the evidence prove the case. Make the relying party own the consequence.

Sources