[OJS] Require ORCID iDs to be authenticated (prevent manual entry)

[davidjb]

Describe the problem you would like to solve
At present, OJS allows users to copy/paste or manually enter their ORCID iDs into their profiles, and allows manual entry into articles for publication. The ORCID Brand Guidelines mentions this isn't allowed:

Organizations should obtain and display authenticated iDs. Do not allow users to copy or type in their ORCID iD, [...]

At present, manual entry is only possible when the orcidProfile plugin isn't enabled (as described by #6959); when the plugin is enabled, the fields are replaced with buttons that trigger the ORCID Oauth process.

Describe the solution you'd like
Perhaps the first step is to discuss directly with ORCID. The ORCID guidelines suggest the solution would be that the Oauth process (provided by the OJS orcidProfile plugin) becomes the standard way to authorise ORCID iDs, with the current current core ORCID iD text input fields being removed (e.g. when the plugin isn't enabled).

A side issue is that articles/publications with previously manually-entered ORCID iDs still display these as on an article when the orcidProfile plugin gets enabled. The article in the dashboard is aware the ORCID iD isn't authenticated (the plugin's UI asks to email the author(s) to connect their ORCID records) - but is still displayed on the public page.

Who is asking for this feature?
Journal Editors (currently manually entering ORCID iDs), and organisational ORCID support staff

Additional information
N/A

[NateWr]

@asmecher, @withanage I think we've had some conversations about this but I can't remember whether we made a decision.

[asmecher]

I'll defer to @withanage, who is in closer contact with the ORCiD folks, but I think it might be sensible to review OJS's behaviour generally when the plugin is disabled. The ORCID profile plugin has become quite mainstream now, and I think those who want ORCID integration at all can be expected to use it. For example, I think it's a defensible decision to fetch/display ORCIDs on the reader front end even without the plugin, as I don't want to entangle the ORICID plugin too much with theme plugin concerns -- but if we decide to get rid of the fields (or make them read-only) when the ORCID plugin is disabled that's OK with me.

[withanage]

Hi @davidjb ,

Thank you for your comments!

We have had some previous discussions this issue with orcid.org.
As you already described the a proper way to handle orcid IDs is to hold only authenticated Orcid IDs in OJS.

For current versions, we can agree of dropping the field, but still older OJS versions may hold manually entered orcid IDs, which may be tricky in upgrade processes. Automatically dropping orcid id's in an upgrade process maybe a very critical decision for us cause the users will not be very happy in what some may define as "data loss", if we do not import that data or import and do not display the orcid ids.

Therefore I have an alternative suggestion for you which we can discuss with community and the oricd.org

Currently in the front end, we are displaying the "green button of an orcid", if the user has a oricd id ( eventhough manually entered) .

1. we can display the green icon, strictly when we have an authenticated icon in the system.

---

In a conversation with @NateWr yesterday, he gave the following suggestions, which we can think of longer term resolving the problem you describe.

His idea was to move the orcid ID management in a separate management panel which is similar to handling DOI registrations e.g. in the crossref plug-in.
Then immediately you would see unauthenticated IDs for a submission and we can give journal managers the possibility to either ask the authors or co-authors to authenticate or simply remove the orcid ids.

An additional idea was that we let pre-publication checks for Orcid IDs, if the journal is configured to have only authenticated IDs, which can be intergrated via the plugin.

@ajnyga @sheilarabun @alexxxmendonca your suggestions on this will be very valuable!

[NateWr]

There is a mockup of how ORCID could help journals authorize old unauthorized ORCIDs in this proposal for a deposit/distribution tracking UI for OJS: #5980

Then immediately you would see unauthenticated IDs for a submission and we can give journal managers the possibility to either ask the authors or co-authors to authenticate or simply remove the orcid ids.

I especially like having an option to remove the remaining unauthorized ORCIDs. I think that we could include something like this in, for example, a 3.4 version of OJS, with a warning that unauthorized ORCIDs are not allowed. Eventually we could consider removing them in an upgrade script -- or perhaps migrating the data to a new property for unauthorized ORCIDs which would remove it from deposits or public display but not destroy the data completely.

[ajnyga]

Hi! My opinion is that we definitely should not allow any manual entries of ORCIDs, because it is against the design of ORCID. That means removing the free text field for ORCID's.

We should also consider the import functionality in OJS. At the moment you can import also ORCID data and this is in my opinion the same as allowing manual entries of ORCIDs.

The new management idea sounds good 👍

I like Nate's ideas of how to remove the unauthorized ORCIDs over time 👍

[davidjb]

Just echoing all of @ajnyga's comments 👍

In my situation, I've currently got a multi-journal installation where some journals are looking at official ORCID integration and others aren't. Because the OJS install uses federated single-sign on (Shibboleth), this means that one journal someone contributes to may authorise ORCID iDs and another may allow manual entry (e.g. have the ability to edit their ORCID iD in a text box at the site-level or on a different journal) -- having this all be consistent (e.g. what's described above) would solve this issue.

The ability to manage and see authorised/unauthorised ORCID iDs (like what @NateWr, @withanage and #5980 describe) would be fantastic and a huge win for journal managers. At present, the visibility isn't there (beyond looking at published articles) and trying to retrospectively link ORCID iDs means an un-publish/edit contributor/re-publish cycle for all articles and all contributors on each article -- a long and complicated process.

In short, this sounds amazing - thanks for the consideration 👍

[alexxxmendonca]

My opinion is that we definitely should not allow any manual entries of ORCIDs, because it is against the design of ORCID. That means removing the free text field for ORCID's.

I second this.

[amandastevens]

I further noticed that when the plugin is not enabled and an author manually enters their ORCID ID into their user profile, it does not appear on a published article page. But when an editor manually enters an ORCID ID into a contributor record in the metadata of an article, it does appear on the published article page and links to the ORCID profile. I think having these fields available and working in unpredictable ways can be confusing for editors.

[asmecher]

@amandastevens, I think the solution for this is going to be to fully integrate ORCID support directly into OJS/OMP/OPS rather than having operate as a plugin. This will allow us to make consistent decisions without having to consider both plugin-enabled and plugin-disabled modes of operation.

[asmecher]

Scheduling against 3.5.0; with that release, ORCiD will be integrated into the core application and the requested change will be implemented implicitly. (@ewhanson, FYI.)

[bozana]

Hi @ewhanson, I think this issue can be closed, right?

[ewhanson]

Hi @bozana, yes, it's been completed as of #9771.