Delegating ORCID Tokens

This is the final blog posting arising from the ORCID Delegation workshop held on the 10th October at Jisc in London (with representatives from Oxford, Imperial, Leeds, LSE, ORCID and Jisc). The previous blogs (Delegating ORCID Tokens – background, Revoking ORCID tokens) covered other incidental outcomes, so I will now get to the main topic – the fact that institutional ORCID users needed to explicitly grant access to third party suppliers in addition to their own institution. This behaviour has a number of undesirable side effects (repeating myself somewhat):

• Communicating this to users can be difficult since they are not always aware of these third parties
• Getting consistent takeup across multiple systems can be difficult (user loses interest) which makes downstream integration more awkward than necessary
• Institution has little visibility of these third party interactions – which can cause problems when suppliers are dropped or other issues arise
• The only way currently round this is to let a supplier use the institutional key – which however then grants them *ALL* the rights can access that the institution has

ORCID uses the OAuth(2) mechanism for authentication and authorization. OAuth already provides the functionality that will allow an institution to generate secondary tokens for third parties and subsequently revoke them:

• When an ORCID owner authorises institutional access, the institution receives two digital tokens:
  • The access token acts as a “key” that is used to access ORCID data via the ORCID API
  • The refresh token can be used to request additional tokens via the OAuth API
• There are two primary ways that the refresh token can be used:
  • To request a new access token when it nears expiry, invalidating the current access token – this has been discussed in the previous posting on revocation
  • To request an additional access token which may have reduced permissions and/or differing expiry, which leaves the current access token intact
• Multiple additional tokens can be requested
• Additional tokens can be invalidated in a similar way to regular access tokens

Obviously, this additional token mechanism is exactly what is required to allow delegated access to third parties. The issue is that there is no standard mechanism for a third party to know that they should go to an institution to get a token instead of ORCID themselves, nor is there a standard way for an institution to deliver that that token securely. There are several approaches to solving this issue:

• ORCID keeps track of additional tokens requested and who they are intended for, and issues them when requested.
  • ORCID will need API enhancements to allow institutions to indicate which tokens are for which supplier (and for a supplier to indicate which institution’s token they require)
  • These enhancements are likely to be ORCID specific rather than vanilla OAuth2 so existing code libraries will not exist
  • Institutions will need to implement and use this API, which may involve rather more information release than is desirable
  • Supplier will need to implement and use this API
  • It is unclear how a person with multiple institutional affiliations might be handled without adding significant complexity
  • Short lived tokens would require a three-way interaction between supplier, institution and ORCID – this will be complex and is unlikely to scale effectively
• Institutions provide an endpoint which the third party always contacts when it needs an access token.
  • This could be implemented as an OAuth2 proxy type of service, which could forward token requests to ORCID on behalf of the institution if an additional token does not already exist, or return an institutional token if the institution in question was not interested in delegation. If developed as a standardised packaged software appliance suitable for running on virtual or cloud infrastructures this could be deployed at an institutional level with minimal effort.
  • Institutions could automatically request and issue short lived tokens relatively easily
  • Institutions retain control over third part interactions
  • Institutions would need a secure (SSL, VPN etc.) network channel to the supplier. This is quite likely to exist already, in practice
• A third party could maintain a shared proxy-type service for use by multiple organisation
  • This would add another party that needs to be trusted into the interaction, adding effectively a second level of delegation.
  • Cost saving against a locally deployed appliance (as described above) may be minimal when the additional complexity of management is taken into account

Ideally, to make the system robust and workable, ORCID owners should have a verified institutional affiliation (or more than one if necessary) attached to their account so that a third party supplier knows who to contact for a delegation token (either directly or via ORCID). Otherwise, another mechanism would need to be found to indicate which institutions can issue tokens for a particular ORCID owners, which would be somewhat redundant. This relationship would also need to be deasserted promptly when the relationship ends. Any of these approaches will require some investment of effort by both ORCID and member institutions for development and ongoing maintenance. The key questions for the community are thus:

1. Primarily, whether there is sufficient interest and desire for a solution to the delegation problem for such an investment to be worthwhile
2. Secondarily, which route is the preferred one. On initial analysis on the day of the workshop, the feeling of the group was that an institutional proxy appliance seemed to be the most attractive option.

As a footnote, Will Simpson of ORCID noted during the meeting that using additional tokens internally for different systems within the institution was also a valid use case in that it allowed ORCID to separate requests from different sources in their logs. This greatly simplifies troubleshooting problems with interactions with multiple institutional systems.

This posting originally appeared on the UK ORCID Consortium blog.