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.
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.
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.
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)