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.