Users not properly authenticated with ORCID?

Context: OJS 3.3.0-14 ; OrcidPlugin v1.1.3.6

Before proceeding with the ORCID API key change from Public to Member (ORCID plugin : changing from public to member API key), I have questions regarding ORCID entries that are not authenticated for users and authors. I encountered several entries in my database with this problem (i.e. unauthenticated ORCID id).

  1. Users
    When a user registers in OJS for the first time via the “Create or connect your ORCID id” button in the Register page, they must grant, on the ORCID side, authorization to the OJS website for specific access to their ORCID record (either “Get your ORCID iD” for the public API key or “Add/update research activities” for the member API key). This process also fetches some information from their ORCID profile, such as their name, country and ORCID id (within the user details section). The OJS website is then listed as a trusted party in the user’s ORCID profile.

However, it appears that this initial authorization process is not sufficient for registering the scope and token information in the database. To properly register this information in the database, the user must log in to their OJS account, go to their Public profile, and click “Create or connect your ORCID iD.” They must then grant access via the exact same ORCID windows/content that they used the first time. If I’m not wrong, only in this way are the scope and token information registered in the OJS database.

This has caused confusion, as I have seen many users with an ORCID iD in the database (e.g. setting_name = orcid; setting_value = “https://orcid.org/0000-0002-1825-0097”), but without any scope and token information. As a result, the editor must request proper ORCID authentication (again) when the user submits their next article.

Is this normal/intended? If so, what is the rationale behind this behavior?

  1. Authors
    I have also observed many author entries in OJS where the ORCID iD was simply entered manually in the OJS form (section “user details” I guess) but has not been registered/authenticated against their ORCID profile. Hence, instead of displaying “ORCID record access granted with scope /authenticate, valid until [date]” or “ORCID record access granted with scope /activities/update, valid until [date]” within the contributor metadata section, it displays “ORCID iD not authenticated! Please request authentication from the contributor.”

Even if the ORCID ID for an author was not properly authenticated, publishing was made and the ORCID logo (and ORCID url + iD) would still appear alongside the author’s name on the main web page for the article. This can give the impression that the ORCID is well authenticated when, in fact, it is not.

The recent fix (pkp/orcidProfile#119 Detected unauthenticated ORCiDs by withanage · Pull Request #255 · pkp/orcidProfile · GitHub) seems to be able to prevent that by ensuring/enforcing appropriate authentication before publication. But ORCID logo/iD are still displayed in the public interface for previous non authenticated authors. I guess I will have to clear those entries manually in the Database since, if I understand correctly, editors cannot request ORCID authentication from authors/contributors of already published articles. Is that correct?

Thank you for your help.

@Dulip_Withanage: are you able to speak to this?

Hi @Marie-Helene .

  1. I will test this and come-back to you, if I can repdroduce this.

I guess I will have to clear those entries manually in the Database since, if I understand correctly, editors cannot request ORCID authentication from authors/contributors of already published articles. Is that correct?

You can click the “unpublish” once and then ask the the authors to add ORCiDs and “re-publish” it, although it is not generally recommended due to effects such as DOI registration when the article gets published. The correct way would be to create a new publication version, ask the ORCiDs and publish it new.

Hi @Dulip_Withanage

Thank you for taking a closer look at issue #1.

Regarding the unpublish/re-publish approach (issue #2), I am hesitant to pursue it for the reasons you mentioned. Additionally, I prefer not to suspend the online distribution nor do I wish to put article back online after a waiting period (waiting for the authors of publications that were already published to authenticate their ORCID; Some might not respond at all). I think the best solution would be to create a version as you suggested, but at the moment we do not use the versioning feature and hence don’t master all aspects.

I also understand that the latest version of the plugin prevents publishing if ORCIDs are not properly authenticated. This is a positive development, as it ensures that such cases will not occur in the future. Only the previous cases remain to be managed.

Hi @Dulip_Withanage, were you able to reproduce the 1 @Marie-Helene point ?
We could have at least 1 user that could be in that situation.
@Marie-Helene, can you share the query you used to check users with orcid but without scope and token information?

Regarding the fix, how publication is prevented? When problems are detected and publication is stopped, what have to be done to finalize the publication, e.g. if the author does not confirm? The orcid has to be deleted?

Best regards
Stefano

Hi @bolelligallevi,

These are the queries that did work for me:

Testing for users with orcid value but no proper authentication:

Select 
u_s.user_id, u_s.setting_value
from user_settings as u_s
where u_s.setting_value like '%https://orcid.org%'
and u_s.setting_name like '%orcid%'
 and
 (
 	-- this is the normal behavior I guess, where orcidAccessScope lines are added only when ORCID authentication is done. We want to test the subquery for FALSE, hence indicating no lines 
 	(not exists (select * from user_settings as u_s1 where u_s1.setting_name LIKE 'orcidAccessScope' and u_s1.user_id = u_s.user_id))
 	OR
 	-- not sure an orcidAccessScope without a value (i.e. NULL) might be registered but just in case :
 	(exists (select * from user_settings as u_s2 where u_s2.setting_name LIKE 'orcidAccessScope' and u_s2.setting_value IS NULL and u_s2.user_id = u_s.user_id))
)

Testing for authors with orcid value but no proper authentication:

Select 
a_s.author_id, a_s.setting_name, a_s.setting_value
from author_settings as a_s
where a_s.setting_value like '%https://orcid.org%'
and a_s.setting_name like '%orcid%'
 and
 (
 	-- this is the normal behavior I guess, where orcidAccessScope lines are added only when ORCID authentication is done. We want to test the subquery for FALSE, hence indicating no lines 
 	(not exists (select * from author_settings as a_s1 where a_s1.setting_name LIKE 'orcidAccessScope' and a_s1.author_id = a_s.author_id))
 	OR
 	-- not sure an orcidAccessScope without a value (NULL) might be registered but just in case :
 	(exists (select * from author_settings as a_s2 where a_s2.setting_name LIKE 'orcidAccessScope' and a_s2.setting_value IS NULL and a_s2.author_id = a_s.author_id))
)

By contrast, this should give you authors with proper ORCID authentication, and the type of permission given (authenticate or activities/update or else (?))

Select 
a_s.author_id, a_s.setting_name, a_s.setting_value, (select a_s2.setting_value from author_settings as a_s2 where a_s2.setting_name LIKE 'orcidAccessScope' and a_s2.setting_value IS NOT NULL and a_s2.author_id = a_s.author_id) as type
from author_settings as a_s
where a_s.setting_value like '%https://orcid.org%'
and a_s.setting_name like '%orcid%'
having type IS NOT NULL

Following the implementation of the latest fix, the editor will receive a warning during publication and will be prevented from proceeding any further. Based on my understanding, the editor may choose to either request ORCID authentication from the authors/contributors via email (and await their response) or remove the ORCID information.

I hope this information proves helpful to you!

Marie-Hélène

Thanks @Marie-Helene for giving the background information!

For your original question

I have added the pull request and it will be released with OJS 3.3.0-15, which
comes soon

Thank you @Dulip_Withanage ! By any chance, did you have time to look into issue #1?

@Marie-Helene I have looked into your use-case 1 , unfortunately in the plugin level, it is not possible to get the validated token, beforehand as the form only has the orcid id pre-defined. We have to validate it again in the profile

Thank you @Dulip_Withanage for checking this out. I find this situation very annoying. I’m afraid that this situation where the user thinks they have authenticated their ORCID by going through the registration page, but in fact they haven’t, is likely to happen to all journals that have enabled the ORCID plugin and should definitely be fixed, don’t you think? Perhaps this could be done through a message to the user that authentication should be completed via their profile or other means? I would like to hear from other users on this.

We agree with @Marie-Helen: this can be a problem for our platform and it should be fixed. Best regards
Rossella

1 Like

@Marie-Helene
I see your suggestion as valid, I will implment the message mechanism and most probably a forwarding to the user profile, if possible

Excellent! I look forward to seeing this implemented.

@Marie-Helene
I am looking into the plugin and may be is it not better, that we do not allow the users to login via orcid email address, because only thing they get is their name and email address in the process.

hi @Dulip_Withanage could you explain better what you mean? thanks

@Marie-Helene

I removed the orcid registration from the plugin and the version is published in 1.1.3.8 to stop the non-complete validation.

@rossella.filadoro
There is no benifit in getting the oricid id without a proper validation passing until the published stage in OJS, therefore I removed the functionality completely.

Thanks @Dulip_Withanage , I tried the updated plugin.
If there is an author unauthenticated, the error message is “Unauthenticated ORCiDs for contributors detected” and it is not possible to publish the article unless the autor authenticates or you disable Orcid plugin. If the article has many authors it becomes quite difficult to resolve the problem quickly. Is it possible to have the list of the unauthenticated authors in the error message?

1 Like

@Marie-Helene @Dulip_Withanage Hi Dulip, Dear Dulip, I am sorry, but it seems that the current solution (blocking the publication of the article until the author has authenticated himself) is not going well because it achieves the opposite effect: our editorial teams are disabling the Orcid plugin in order to have immediate publication.
I’m afraid we need to think of an alternative solution, such as going back to immediate publication and providing in the meantime a function or automatic notification that lists authors with orcid problems to the journal manager (who will then be able to contact the author explaining what they have to do to make it work). Thanks

Dear all,

We are facing the same issue over here. One of our journals started a project to add XMLs to the final compositions of articles from previously published issues. When unpublishing the articles, the editorial team is encountering issues with republishing due to ORCID. It would be important to have a solution for this without having to remove the author’s ORCID or disable the plugin.

Best regards,

1 Like

Hi all,

As a trusted service provider, orcid.org would like us to ensure that, we publish only authenticated orcid profile, so having authenticated orcids is important from a non-technical perspective.

I can take the validation away, but that would mean, that we do not adhere to the guidelines setup by orcid.org

Currently, JMs disabling the plugin as a workaround to avoid the rules, I think this has to be corrected soon in newer OJS versions.

Therefore I would recommend asking the co-authors to properly authenticate, if possible.

If you really want to pubish, without orcid profiles, then it would be better not to have unauthenticated orcid ids in your articles.

I can consult, orcid.org about this issue, but I suspect, they would recommend the same.