Identifier Crosswalk: DOI, ORCID, ROR & CRIS

An identifier crosswalk — the mapping that lets one metadata scheme’s identifier for a person, output, or organisation be resolved to another scheme’s identifier for the same entity — is a familiar concept once you’ve seen it defined. What’s less often shown is what it looks like as data: which field, in which record, carries which identifier, who puts it there, and where the linkage actually breaks in day-to-day research administration. This guide is that practical, systems-level companion. It assumes you already know what a DOI, an ORCID iD, and a ROR ID each are on their own — if not, start with those Dictionary entries or the cluster overview at Persistent Identifiers & Research Information Systems, which introduces all four identifiers (DOI, ORCID, ROR, and RAiD) and frames the crosswalk problem at a conceptual level. Here, the focus is the mechanics: real metadata fields, real systems, and the specific points where the chain most often fails.

The four identifiers, and what each one is attached to

Before looking at how they connect, it helps to be precise about what each identifier actually identifies — crosswalk failures very often trace back to conflating these:

DOI identifies an output — an article, dataset, preprint, or similar — and is standardised as ISO 26324:2012. Registration agencies include Crossref (mainly journal literature) and DataCite (mainly data, software, and other non-article outputs).
ORCID iD identifies a person — a specific researcher, not a name string, which is precisely the ambiguity it exists to remove.
ROR ID identifies an organisation — a university, funder, hospital, or research institute — as a single, unambiguous record rather than however many variant name-strings that institution has been entered as (“UC Berkeley,” “University of California, Berkeley,” “Berkeley, Univ. of CA,” and so on).
RAiD identifies a research activity or project itself (ISO 23527:2022) — distinct from any single output, person, or organisation involved in it.

A crosswalk, in practice, is what lets a system holding one of these — say, a DOI — walk outward to the others: from the output to its authors (ORCID), from those authors to their institutions (ROR), and potentially to the project that produced it (RAiD). None of that walking happens automatically just because all four identifiers exist. It happens only where a specific metadata field, populated at a specific step in the deposit workflow, actually carries the link.

How a DOI record actually carries the crosswalk

The clearest way to see this is to look at what a real Crossref or DataCite metadata record contains, field by field, rather than treating “the DOI record” as a black box.

Contributor identity: ORCID in the deposit record

When a publisher deposits a DOI with Crossref, each author is represented as a person_name element. That element can carry an <ORCID> child element — but critically, that element carries an authenticated attribute, and the value of that attribute matters a great deal:

<person_name sequence="first" contributor_role="author">
  <given_name>Jane</given_name>
  <surname>Researcher</surname>
  <ORCID authenticated="true">https://orcid.org/0000-0002-4011-3590</ORCID>
</person_name>

authenticated="true" means the author actually signed in to ORCID during the submission process and granted the publisher permission to assert that iD — a verified link. An ORCID iD present in a Crossref record without that attribute (or with it set to false) is publisher-asserted only: someone typed a string that looks like an ORCID iD into a form field, with no confirmation the researcher themselves attached it. Both forms are technically “an ORCID iD in the metadata,” but only the authenticated form is a crosswalk a downstream system should trust without independent verification. DataCite’s schema achieves the same linkage differently: a Creator or Contributor’s nameIdentifier property can carry an ORCID iD (identified by nameIdentifierScheme), alongside comparable identifiers such as ISNI.

Once an authenticated ORCID iD is present, Crossref’s auto-update mechanism can add the newly registered DOI-linked work to that researcher’s ORCID record automatically — but only if the researcher has separately granted Crossref permission as a trusted organisation on their ORCID account. Two separate consents have to both be true (the ORCID iD attached at deposit, and auto-update permission granted) before the DOI-to-ORCID link becomes visible on the researcher’s own record without them manually adding the work themselves.

Affiliation and funder identity: ROR in the deposit record

Crossref added native ROR ID support to its metadata schema and APIs in January 2022 (schema version 5.3.0), extending the existing affiliation element so it can carry a typed institution_id:

<institution>
  <institution_name>Example University</institution_name>
  <institution_id type="ror">https://ror.org/0abcdef12</institution_id>
</institution>

This is what actually links an author’s DOI-record affiliation to their institution’s ROR record, rather than to a free-text institution name that a downstream system has to try to match against a known list. The same mechanism extends to funding: Crossref and ROR announced in September 2023 that the Crossref Open Funder Registry (the older “Funder ID” scheme) is transitioning into ROR, so a funder can now be identified in deposit metadata by ROR ID directly rather than by a separate Funder ID. The two schemes coexist during the transition — existing Funder IDs continue to resolve — but new deposits are increasingly using ROR IDs for funders as well as for author affiliations. DataCite’s schema carries the equivalent linkage via its funderIdentifier property, which likewise accepts a ROR ID.

A related, genuinely CASRAI-relevant piece of the same deposit record: Crossref schema 5.5 (proposed 2023, generally available 2024) added native support for CRediT contributor roles inside the same person_name element that carries the ORCID iD — so a single deposit can express not just who contributed, but what they did, tied to the same authenticated identity. See CASRAI’s own Crossref schema 5.5 & CRediT implementation guide for the full XML structure.

Seeing the crosswalk assembled: DataCite Commons and the PID Graph

Individual metadata fields are the raw material; a few real, live systems assemble them into a traversable graph. DataCite Commons, built on work from the EU-funded FREYA project, exposes a “PID Graph” — a queryable network of connections between DOIs, ORCID iDs, and ROR IDs, accessible via a GraphQL API. Querying an ORCID iD there can surface the DataCite DOIs connected to it and, through those, the ROR-identified organisations named as affiliations or funders — a concrete, inspectable example of the crosswalk working as intended, built entirely from the metadata fields described above (it draws its DataCite/ROR data comprehensively but only a partial slice of ORCID and Crossref metadata, since neither of those organisations exposes their full graph through the same API).

How a CRIS resolves and cross-references these identifiers

An institutional CRIS (current research information system) sits on the other side of this same linkage, from the institution’s perspective rather than the publication registry’s. Structurally, most CRIS platforms model research information around a small set of core entities — broadly aligned with the CERIF data model that euroCRIS maintains: a person record, an organisational unit, a project, and a research output — plus the relationships between them.

The practical work of “resolving and cross-referencing” happens where each of those internal entities is anchored to an external persistent identifier rather than left as free text:

A CRIS person record stores the individual’s ORCID iD as an external identifier, and can use ORCID’s API (with the researcher’s read-permission grant) to pull in works, employment, and education directly rather than requiring manual entry.
A CRIS affiliation or organisational-unit record stores a ROR ID, which lets the institution’s own sub-units (departments, centres, hospitals within a university system) be mapped consistently against the same external organisation graph everyone else — funders, publishers, other institutions — is also using.
A CRIS research output record is populated from the DOI record itself, typically by querying the Crossref or DataCite REST API for a given DOI and importing the structured metadata (title, contributors, funder, affiliations, related identifiers) rather than re-keying it — the same ORCID and ROR fields described above are what make that import populate correctly linked person and organisation records instead of orphaned text strings.

Harvesting and interoperability between systems — a national aggregator pulling records from many institutional repositories, for example — commonly runs over OAI-PMH, with OpenAIRE Guidelines specifying how CERIF-aligned metadata, including these same PID fields, should be exposed for that harvesting to work consistently across systems built by different vendors.

Why this matters for research administration

None of the above is abstract systems architecture for its own sake. A research office that can rely on the crosswalk being correct gets three concrete things it otherwise has to do by hand:

Accurate output attribution without manual reconciliation. When a DOI record’s ORCID and ROR fields are correctly and authentically populated, an institution’s CRIS can automatically attribute a new publication to the right researcher and the right department the moment it’s registered — instead of a research office staff member periodically searching Crossref or Google Scholar by name and trying to match ambiguous author strings to people on staff.
Reliable funder and grant reporting. Where a funder’s ROR ID (or legacy Funder ID) is present on the output’s DOI record, that output can be programmatically tied back to the award that produced it — supporting compliance reporting without a manual audit trail assembled from award numbers copied out of acknowledgment sections.
Defensible research assessment exercises. National and institutional research-assessment processes that aggregate outputs by researcher and by unit depend on exactly this linkage being correct at scale; a broken or missing crosswalk for even a modest fraction of outputs means either manual correction under time pressure or an incomplete return.

The RDA DMP Common Standard, which DMPTool and DMPonline implement for machine-actionable data management plans, is built around the same expectation — ORCID, ROR, and CRediT identifiers are how a maDMP stays interoperable with an institution’s CRIS/RIM system rather than existing as an isolated document. See CASRAI’s NIH vs. NSF data management plans guide for where the machine-actionable DMP angle is covered in more depth.

Common failure points

The crosswalk breaks in a small number of predictable, specific ways — worth knowing precisely, since each has a different practical fix:

An ORCID iD is unclaimed or never linked. A researcher may have an ORCID iD but never add it at manuscript submission, or a publisher’s form may accept a typed string without the researcher signing in to confirm it (an unauthenticated <ORCID> element, as above). Either way, the DOI record either has no ORCID at all or has one a downstream system can’t fully trust without separate verification.
Auto-update permission was never granted. Even with a correctly authenticated ORCID iD on the DOI record, Crossref’s auto-update won’t add the work to the researcher’s ORCID record unless that researcher has separately granted Crossref (or the specific publisher) trusted-organisation permission on their ORCID account. The two consents are independent; missing either one leaves the work off the ORCID record until someone adds it manually.
Affiliation metadata is missing a ROR ID entirely. ROR support in Crossref metadata is comparatively recent (January 2022) and adoption is still uneven across publishers and journals — Crossref’s own 2026 public data file reported ROR identifiers for organisations up roughly 250% year-over-year, real growth, but growth of that scale from a low base also signals how far from universal ROR-tagged affiliation still is. A DOI record with an author’s name and a free-text institution string, but no institution_id type="ror", forces a CRIS or reporting system back onto name-matching — the exact ambiguity ROR exists to remove.
Funder identification is split across two schemes mid-transition. With the Crossref Funder Registry (Funder ID) and ROR coexisting during their announced merger, a DOI record may carry a legacy Funder ID, a ROR ID, both, or neither for the same funder, depending on when and by whom it was deposited — a reporting system that only checks one of the two fields can silently miss funder-linked outputs that used the other.
Name-matching is used as a fallback where a PID is missing, and it fails silently. Whenever any of the above gaps exist, the practical fallback is matching on name strings — author name, institution name, funder name — which is exactly the ambiguity these identifiers were built to remove, and which produces both false matches (two researchers who share a name) and missed matches (the same researcher’s name spelled or ordered differently across records) without any error being raised.

A practical checklist for research administrators

Confirm your institution’s ORCID integration is actually enabled where researchers submit manuscripts, and that it requests authenticated ORCID sign-in at submission, not a free-text ORCID field.
Confirm your institution’s ROR ID is correctly used — and communicated to researchers and co-authors — wherever a submission system asks for institutional affiliation, rather than relying on whatever free-text variant of the institution’s name a given author happens to type.
Where your CRIS supports it, enable automated metadata import from Crossref/DataCite by DOI rather than manual re-entry of new publications — this only works as well as the source record’s ORCID/ROR fields, which is the actual reason to care about the deposit-side details above, not an abstract standards preference.
When reconciling funder-linked outputs for a reporting cycle, check both legacy Funder ID and ROR ID fields until the Crossref/ROR funder-registry transition is further along.
Treat an unauthenticated ORCID iD or a name-only affiliation on an incoming record as a flag for manual review, not as equivalent in reliability to an authenticated, ROR-tagged record.

Frequently asked questions

Does having an ORCID iD, a ROR ID, and a DOI automatically mean they’re linked?

No. Each identifier can exist independently of the others. The link only exists where a specific metadata field — the authenticated <ORCID> element on a Crossref contributor, the institution_id type="ror" on an affiliation, the nameIdentifier/funderIdentifier on a DataCite record — is actually populated at deposit. Existence of all three identifiers is necessary but not sufficient for the crosswalk to work.

Who is responsible for making sure a DOI record carries the correct ORCID and ROR links?

In practice it’s shared and easy to lose track of: the individual author, who has to sign in to ORCID and confirm their affiliation at submission; the publisher or repository, whose submission system has to request an authenticated ORCID iD and a ROR-backed affiliation field rather than free text; and the researcher again, who has to separately grant auto-update permission for the record to flow through to their own ORCID profile without manual intervention.

What’s the difference between “authenticated” and just “present” on an ORCID iD in metadata?

An authenticated ORCID iD means the researcher signed in to ORCID during submission and confirmed it themselves. A present-but-unauthenticated ORCID iD means someone (often the corresponding author, on a co-author’s behalf, or an editorial system pulling from a prior record) typed the string in without that confirmation step. Both look identical as plain text; only the authenticated attribute in the underlying Crossref record distinguishes them, and only the authenticated form should be treated as a verified crosswalk link without independent checking.

Does this crosswalk work the same way for datasets and software as it does for articles?

The mechanism is equivalent but runs through DataCite rather than Crossref for most non-article outputs: DataCite’s Creator/Contributor nameIdentifier property carries ORCID iDs, and its funderIdentifier/affiliation identifiers carry ROR IDs, in the same structural role Crossref’s fields play for journal literature. Whether a given repository actually populates those fields at deposit is a separate, repository-specific question — the schema supporting it is not the same thing as every deposit using it.

Is RAiD part of this same crosswalk?

Conceptually yes — a RAiD identifies the project or activity that produced a given output, and in principle links back to the same authors (ORCID) and institutions (ROR) as any output the project produced. In practice, RAiD adoption in deposit metadata is far less mature than ORCID or ROR support in Crossref/DataCite records, so treat project-level linkage via RAiD as an emerging piece of the crosswalk rather than one you can assume is already populated the way author- and affiliation-level linkage often is.

Identifier Crosswalk: Connecting DOI, ORCID, ROR, and Institutional IDs in Practice