Two issuers, two answers, one person. Who decides?

Every verifiable credential architecture answers the question of who may issue an attestation. None of them answers what a verifier should do when two issuers it trusts assert incompatible things about the same human. That gap is where people get stuck, and it is about to get much wider.

The credentialing file that says two things

Picture a hospital credentialing office on a Tuesday. A physician is being onboarded. Two records sit in front of the coordinator. The hospital's own credentialing file, populated at hire and maintained since, records the physician as board certified in their specialty. The certifying board's status feed, fetched this morning, records the certification as lapsed.

Both records are internally consistent. Both come from a source the hospital has decided to trust, or it would not be fetching them. Neither is a forgery, neither is corrupted, and if both were cryptographically signed verifiable credentials, both signatures would verify perfectly. The coordinator has two valid attestations and a decision to make that no policy document actually covers.

What happens next is the interesting part. In most organisations the coordinator opens an exception ticket. The ticket sits in a queue. Someone emails the board, or calls the physician, or checks a third source to break the tie. Days pass, sometimes weeks. Meanwhile the physician is not seeing patients, the department is short, and nobody involved would describe what is happening as an identity problem. They would describe it as paperwork.

It is an identity problem. Specifically, it is the one that verifiable credential architectures have not addressed, and it does not go away when the credentials become cryptographic. It gets worse, because now both sides of the disagreement carry a signature that says they are authoritative.

What does an attestation conflict actually look like?

The hospital case is the tidy version. The messy versions are more common.

An employer's human resources system says an employee is active. The identity provider says the account was deprovisioned three weeks ago. Both are signed statements from systems the organisation operates, and they disagree because the offboarding workflow ran in one and stalled in the other. We covered where those artefacts scatter in They left in March, their access did not.

A bank's verification vendor reports an address as confirmed. The utility bill on file shows a different one. Neither is lying. The vendor confirmed the address against a data source that is eighteen months stale, and the customer moved.

A professional licensing register in one state shows a licence active. A national practitioner database shows a disciplinary action in another. Both are correct in their own frame. The question of which one governs the decision in front of you is a governance question wearing a data costume.

And then the category that affects the largest number of people and receives the least attention: a person's name is recorded differently across two government issued documents, and no adjudication rule exists at all.

Why is conflict the normal condition rather than an edge case?

Because the systems were designed around a template of a human life, and a very large fraction of human lives do not match the template.

Consider what happens to names. Many people change their surname at marriage, and the records that predate the change do not automatically update, so a decade of employment history, professional certifications and academic credentials sit under one name while current government documents carry another. In Spanish naming conventions a person carries two surnames, and systems built for one frequently truncate, reorder or drop one of them, producing a mismatch that looks like a discrepancy and is not. Names transliterated between scripts have no single canonical romanisation, so the same Arabic, Cyrillic or Chinese name will legitimately appear in several spellings across documents issued in different countries and different decades. Some people have a single name and no surname at all, which is entirely normal in parts of Indonesia and South Asia, and which many identity systems simply cannot represent.

Consider dates of birth. Refugees and displaced people are frequently assigned a default date of birth, commonly the first of January, when documentation is unavailable at registration. That date is then recorded as fact in one system and contradicted by a different assigned default, or by an actual document recovered later, in another.

None of these are errors. They are the accurate recording of a life that does not fit a form. When a verifier treats disagreement as evidence of fraud, it fails hardest on married women, on immigrants, on refugees, and on anyone whose naming culture differs from the one the schema assumed. That is not a marginal population and treating them as an exception queue is not an acceptable design.

This is why the framing matters. If conflict is an anomaly, you handle it with an escalation path and move on. If conflict is the normal condition of identity data at scale, then the absence of a resolution mechanism is a hole in the architecture, and the exception queue is where you have hidden it.

Why don't verifiable credential standards cover this?

Because they were solving the previous problem, and they solved it well.

The W3C Verifiable Credentials data model gives you a way to express a signed claim about a subject, from an issuer, with a proof anyone can check. Status list mechanisms let an issuer publish revocation without the verifier phoning home, which we walked through in the licence was revoked in March and the credential still verifies. Trust frameworks such as those developed in the Trust Over IP community, and the trusted list machinery in the European eIDAS framework, answer the question of which issuers a verifier should accept.

Every one of those addresses the relationship between one issuer and one verifier about one credential. None of them addresses arbitration between two accepted issuers. The specifications tell you how to determine that an attestation is authentic and that its issuer is recognised. They fall silent at exactly the moment when two authentic attestations from two recognised issuers say different things.

There is prior art worth knowing about, and it comes from an older world. X.509 certificate policy and policy mapping wrestled with something structurally similar: how one certification authority's assertions relate to another's when trust is bridged between hierarchies. It produced machinery that was famously difficult to use, which is instructive rather than discouraging. Nobody should want to repeat that design. But the problem it was reaching for is the problem here.

The reason this gets worse from here

Issuers are multiplying. European digital identity wallets are bringing new government issuers into circulation. State issued mobile driving licences sit alongside federal documents in the United States. Enterprises are running their own credential pilots. Every new issuer is a new opportunity for two authoritative sources to disagree, and the combinatorics are not kind: conflicts scale with pairs of issuers, not with issuers.

At the same time, the entity doing the verifying is increasingly software with no escalation path. A human coordinator who gets two answers opens a ticket. An automated verification step, or an agent completing a workflow, takes whichever answer its code path reached first and proceeds. That failure is silent, and it is the one that produces the wrong outcome for the wrong person without anyone noticing.

What are the four ways to resolve a conflict, and when is each right?

There are four available strategies. Each is correct sometimes and catastrophic elsewhere, and the current state of practice is that most systems use one of them for everything.

Issuer precedence: rank the sources

Declare that some issuers outrank others for particular attributes. The certifying board outranks the hospital's internal file on certification status. The licensing register outranks an employer's record on licence validity. This is usually the right answer when one issuer is definitively the source of the fact and the other holds a derived copy.

The problem is that precedence requires governance, and the governance mostly does not exist in machine readable form. It lives in a policy document, or in the head of a coordinator who has done the job for eleven years. Two organisations verifying the same physician may rank the same two issuers differently and reach opposite conclusions, both defensibly.

Recency: the newest observation wins

Take the most recently issued attestation. This is intuitive, cheap, and frequently correct, because most conflicts are not really disagreements. They are the same fact observed at two different times, which is the subject of Every identity record is a photograph of a moving thing. A licence that shows active in a record from January and suspended in a record from June is not a contradiction, it is a timeline.

Recency fails badly when the newer attestation comes from a less authoritative source. An employer record updated this morning does not override a licensing board record from last quarter, because the employer is not the source of that fact. Applied blindly, recency lets any issuer overwrite any other by the simple expedient of publishing more often, which is also an attack.

Subject assertion: ask the person

Ask the human. They almost always know. The physician knows whether they recertified. The employee knows whether they still work there. The person whose name is spelled two ways knows which document is current, and has known the whole time, and has probably explained it to eleven different institutions already.

This is how conflicts get resolved in the physical world, and digital systems almost never permit it, for a reason that deserves to be stated fairly: the subject has an interest in the outcome. A person whose licence was suspended has every incentive to assert that the record showing it active is the current one. Self assertion cannot be authoritative for adversarial attributes.

But most conflicts are not adversarial. They are clerical. Refusing subject input across the board, to guard against the minority of cases where the subject might lie, is why the exception queue exists and why it moves at the speed it does. The design question is not whether to permit subject assertion but for which attributes, and with what accountability attached.

Abstention: decline to decide

The verifier concludes it cannot resolve the conflict and escalates rather than guessing. This is the least discussed strategy and frequently the correct one, particularly for adversarial attributes and for anything where being wrong is expensive.

Abstention has a bad reputation because it looks like failure. It is not. A verifier that fails closed and routes to a human has behaved correctly. A verifier that silently picks the more permissive of two conflicting attestations, because that code path had no else branch, has behaved incorrectly and produced no signal that it did so. The second is far more common and far more dangerous, and it is the mechanism by which an attacker who can engineer a conflict gets the answer they want.

Which strategy fits which conflict?

The row that most systems get wrong is the last one. If your verifier resolves ties by taking whichever attestation is more permissive, or whichever arrived first, then anyone who can introduce a second attestation can steer the outcome. That is not a hypothetical attack so much as an inevitable one, once conflicts are common enough that nobody investigates them.

What would a machine readable conflict policy look like?

The contribution this post wants to make is that these rules are expressible, and that expressing them is a legitimate target for standards work rather than a matter for each organisation's tribal knowledge.

A policy needs four things: which issuers are authoritative for which attributes and in what rank order, how fresh an attestation must be to count, what to do when ranks are equal, and whether the resolution itself gets recorded.

{
  "policy_id": "clinical-privileging-v3",
  "attribute": "board_certification_status",
  "issuer_authority": [
    { "issuer": "did:example:certifying-board", "rank": 1, "role": "definitive" },
    { "issuer": "did:example:hospital-hr",      "rank": 2, "role": "derived"    }
  ],
  "freshness": { "max_age_days": 30, "on_stale": "refetch" },
  "on_conflict": {
    "different_rank": "prefer_higher_rank",
    "same_rank":      "escalate",
    "unresolved":     "request_subject_tiebreak"
  },
  "record_resolution": true
}

And the verifier walk that applies it. Note that there is no branch in which the code silently picks one and continues.

a, b = fetch_attestations(subject, "board_certification_status")

if a.value == b.value:
    return a.value                          # no conflict

policy = load_policy("clinical-privileging-v3")
stale  = [x for x in (a, b) if age(x) > policy.freshness.max_age_days]
if stale:
    a, b = refetch(stale)                   # a conflict is often just decay

ra, rb = policy.rank(a.issuer), policy.rank(b.issuer)

if ra != rb:
    outcome = higher_ranked(a, b)           # definitive beats derived
elif policy.on_conflict.same_rank == "escalate":
    outcome = escalate(a, b)                # do not guess
else:
    outcome = request_subject_tiebreak(subject, [a, b])

emit_resolution_receipt(outcome, inputs=[a, b], policy=policy.policy_id)
return outcome.value

The last line before the return is the part that does not exist anywhere today. A resolution receipt records that a conflict occurred, which attestations were in play, which policy was applied, what the outcome was, and if a human broke the tie, that they did so and when. It turns an invisible judgement call into an auditable event.

Consider what that gives you over time. Today, nobody can answer the question "how often does this issuer turn out to have been stale?" because the resolutions are not recorded. With receipts, issuer reliability becomes measurable from evidence rather than assumed from reputation. That is a genuinely useful dataset, and the right thing to score with it is issuers. Never people.

Isn't this just the freshness problem again?

Frequently, yes, and separating the two cases is most of the work.

A large share of what presents as disagreement is one source observing a fact at one time and another source observing it later, which is decay rather than contradiction. Refetching both attestations before doing anything else, as the code above does, resolves a meaningful fraction of conflicts for free and should be the first step in any implementation.

What is left after that is real disagreement: two sources looking at the same moment and reporting different things. That residue is smaller and much harder, and it is where issuer authority and subject assertion earn their place. The mistake is treating the whole population as the hard case, which is expensive, or treating it all as the easy case, which is wrong.

Where Manav sits, honestly

Modestly, and it is worth being precise about how modestly.

Manav's receipts carry the issuer, the scope, and the time, and verify offline against a published key without contacting anyone. That makes a conflict legible: you can see exactly which party asserted what, when, and under what scope, rather than comparing two opaque database rows whose provenance is a matter of institutional memory.

Legibility is a precondition for resolution. It is not resolution. Manav does not adjudicate between issuers and should not, because that adjudication is a governance decision belonging to the organisations and frameworks that accept those issuers, not to an infrastructure vendor.

The one piece of the puzzle that does sit naturally here is the human tie break. When a policy reaches the point of asking the person which record is current, that answer should be a signature from an enrolled device rather than a checkbox in a form, so that the assertion is attributable, non repudiable and carried forward with the resolution. A formal conflict resolution policy language is not something Manav has shipped. This post proposes one and would rather see it standardised in the open than owned by anyone, including us.

Honest limits

Subject assertion cannot be authoritative for adversarial attributes. Asking someone whether their own suspension is current invites the obvious answer. Subject tie break belongs to clerical conflicts, not to disciplinary ones, and any policy that fails to make that distinction is worse than no policy.

Coercion is real. A signature says the person asserted something, not that they wanted to. In domains where coercion is plausible, a signed tie break is not sufficient on its own.

Precedence requires governance nobody has agreed. The policy file above is easy to write and hard to fill in correctly, because deciding that one issuer outranks another for a given attribute is a governance act. Standards work can supply the vocabulary. It cannot supply the agreement.

Recording resolutions has a privacy cost. A resolution receipt discloses that a conflict existed about a specific person, which is information that did not previously exist in durable form. That is a real tradeoff and should be scoped deliberately rather than logged everywhere by default.

Some conflicts are not resolvable by any mechanism. When two institutions genuinely disagree about a contested fact, the answer is a human process with a right of reply, not a better algorithm. Systems that pretend otherwise produce confident wrong answers.

What to do this week

1. Find your exception queue. Every credentialing, onboarding or verification process has one. Measure how many items in it are source conflicts rather than missing data, which most teams have never separated.
2. Write down your precedence rules for your top five attributes. If nobody can state them, that is the finding, and it means your system is currently resolving conflicts by accident.
3. Audit for silent resolution. Search your verification code for branches that compare two sources and pick one without logging that a discrepancy occurred. These are usually easy to find and unsettling to count.
4. Add freshness to your attestations. Store when each was observed, not just its value, so you can tell decay from disagreement.
5. Give the person a channel. Identify which of your conflict types are clerical, and build a path where the human can assert which record is current and be believed.
6. Check whether your automated paths can escalate at all. If an agent or a batch job hits a conflict at three in the morning, find out what it currently does. The answer is often that it picks one.

If you want to see how a signed, scoped, timestamped attestation differs from a database row in practice, the verification demo shows the offline check, and the developer documentation covers the receipt structure that makes issuer, scope and time explicit.

Frequently asked questions

What should a verifier do when two valid credentials about the same person conflict? Apply a published rule on issuer authority and freshness first, refetching stale attestations because many conflicts are just decay. If ranks are equal or the rule is inconclusive, escalate rather than guessing, and for clerical conflicts ask the person to sign which record is current. Record how the conflict was resolved.

What is an authoritative source in identity governance? It is the system designated as the origin of truth for a given attribute, as distinct from systems holding derived copies. The concept is widely used and rarely written down in machine readable form, which is why two organisations can rank the same pair of sources differently and both consider themselves correct.

How do trust registries handle issuer disagreement? They mostly do not. Trust frameworks including the eIDAS trusted lists and Trust Over IP registry work establish which issuers are recognised for which credential types. That answers whether to accept an attestation, not which of two accepted attestations governs when they conflict.

Is most recent wins a safe default? No. It is right for timing conflicts where both sources are equally authoritative, and wrong whenever the newer attestation comes from a less authoritative source. Applied blindly it lets any issuer override any other by publishing more frequently, which is also how an attacker would use it.

Can you let people resolve conflicts about their own records? For clerical conflicts, yes, and refusing to is why exception queues are slow. For adversarial attributes such as disciplinary status or licence suspension, no, because the subject has an interest in the outcome. The policy has to distinguish the two rather than applying one rule to both.

Doesn't adding more issuers improve trust? Not by itself. Adding issuers adds attestations, and attestations that disagree add disagreement. Without a resolution mechanism, more issuers means more conflicts, more exception volume, and more opportunities for a verifier to silently pick the convenient answer.

Why record how a conflict was resolved? Because it converts an invisible judgement into an auditable event, and because over time it lets you measure which issuers turn out to have been stale. Nobody can answer that question today, since resolutions are not written down anywhere.

Sources

1. World Wide Web Consortium, Verifiable Credentials Data Model, including issuer metadata and status mechanisms: w3.org/TR/vc-data-model-2.0
2. Trust Over IP Foundation, trust registry protocol and governance framework specifications: trustoverip.org
3. European Commission, eIDAS regulation and the European Digital Identity framework, including trusted lists: digital-strategy.ec.europa.eu
4. National Institute of Standards and Technology, SP 800-63A Digital Identity Guidelines on identity proofing and evidence sources: pages.nist.gov/800-63-3
5. Internet Engineering Task Force, RFC 5280 on X.509 certificate policies and policy mapping, as prior art in bridging trust between hierarchies: datatracker.ietf.org/doc/html/rfc5280
6. National Committee for Quality Assurance, credentialing standards and verification source requirements: ncqa.org

Adding issuers does not add trust. It adds disagreement, and the trust layer of the next decade is not more attestations but a verifiable way to settle them.