[avatar user=”willsimpson” size=”thumbnail” align=”left” /]
Privacy and individual control are founding principles of ORCID, and remain a point of focus with both ORCID Members and researchers alike. We continually work to improve the clarity, completeness, and robustness of our privacy policy. As the ORCID Registry grows (not only the number of actual records, but the volume of integrations and assertions associated with them), we are better able to learn about how the registry is used and continually adjust our approach to stay ahead of the latest in data protection practices.
Each year our policy and practices are reviewed against assessment criteria of the EU-U.S. and Swiss-U.S. Privacy Shield Verification Program. TRUSTe has provided a letter of attestation again this year. Here’s what’s new in our privacy policy this year:
Affiliation end dates
As you are probably aware, the ORCID record contains a section for affiliations, including the record holder’s employment at an organization.
.png)
If the record holder’s employer is an ORCID member, that organization may post employment affiliation directly to that record if they are granted permission by the record holder to do so. Not only is this convenient and time-saving for the record holder, but by asserting current employment, the member organization builds upon the usefulness of the record by increasing the interoperability of the data.
However, if the record holder revokes permission that was originally granted to post the affiliation before the end of their employment, the member will be unable to update the end date. Therefore, it looks as if the record holder is still employed by the organization when in fact they are not.
Even though this sequence of events is rare in practice, that it is possible at all erodes trust in the assertions, and therefore their usefulness to end users.
So, we have updated the privacy policy to allow member organizations to update data that they added to your record, even if the permission has been revoked. There are still technical details for us to work out, and we’ll be working on the user interface to make sure ORCID record holders are informed and able to make the right choices for them.
Single Sign On
Last year we launched our implementation of OpenID Connect, which opened the door to integrators using ORCID as a sign in mechanism to their systems, using the same standards and software used to implement sign in with Google, Twitter, and other social media platforms.
When you use sign on with social media, it is normal for your email address to be passed to the system you are signing into. However, most ORCID users have their email address set to ‘only me’ visibility. This means that we can’t pass it to the system that you are signing in to.
The OpenID Connect standard does not require email address to be released, but this is a case where common practice diverges wildly from the specification. Many tools and systems expect the email address to be there and fail if it is not. Yes, integrators should be able to use the ORCID iD instead of email as an identifier, but in practice they do not. This has led to some highly undesirable behavior, such as integrators asking users to make their email address public so that they can use sign in with ORCID.
So, we updated the privacy policy to allow the user to grant permission to release their email address to a specific organization, even if it is marked as ‘only me’. We have not implemented this feature yet, but when we do we’ll always ask the user for explicit permission to release the email address in this way.
Other changes
There were some other changes to the policy for clarification and completeness.
- We added mailing lists to the list of systems covered by the policy (throughout the policy)
- Clarified the meaning of corporate reorganization (section 6.5)
- Stated reason for keeping cryptographic hash of email address after record deactivation (section 7.0)
If you have any questions or concerns about ORCID’s privacy policy or these changes, please let us know.
