Symplectic Elements & the Hub

[Anton Angelo]

Kia ora koutou,

We, at Canterbury, have recently adopted Symplectic Elements, and one of its many benefits has been to point researchers towards registering with ORCID.  Has anyone had any thoughts about how to put the hub into the workflow through elements?  

Nā mihi,

Anton.

[Jason Gush]

Kia ora Anton, 

Good question. I know that The University of Auckland has a similar query/interest.

Now, I'm effectively a complete novice when it comes to Elements... so although I know that the tokens that Elements gets from researchers on linking a record are /read-limited, I have no idea how simple/difficult it is to import/export ORCID iD/access token pairs into/from Elements.

If that is possible, and there's a desire; then from the Hub to Elements is worth looking at.  The Hub is now collecting tokens with the default scope a combined "/read-limited" and "/update/activities".  Those tokens should both work with Elements (although in it's current state that integration wouldn't be taking advantage of the "/update/activities" permission in each token), and provide at least one less interface that your researchers have to navigate.  We'd likely look to working with Elements users for secure ways of transmitting those pairs.  

From Elements to the Hub is less likely to be useful, at least at present.  The main purpose of the Hub is the ability to write to records with tokens having "/update/activities" scopes, and Elements doesn't currently request them.

If I've made an error or misunderstood anywhere, I hope someone with knowledge of Elements can correct me.

Noho ora mai

Jason.

[Andrea Schweer]

Hi all,

I hope it's ok to revive an old conversation. I asked Symplectic about the idea of re-using Hub tokens for Elements (for those reading along who have access to the Symplectic support site, the conversation is at https://support.symplectic.co.uk/support/discussions/topics/6000035504 -- I'm not comfortable re-posting things that aren't my own words in full here). Their response was basically that from their point of view, the OAuth philosophy means that a user grants access to an application and that re-using tokens across applications would probably break OAuth trust promises. They're also concerned that ORCID may block such applications from using the API for the same reason. They do indicate that they're open to further discussion on this.

My response to this was:

The way the Hub has been marketed here, rather than focusing on the term "application" they are asking ORCID users to grant permission to the organisation, which is represented by the Hub but could be represented by other applications. I can see how that may go against the OAuth philosophy, but at the same time if we promise our academics that we'll push a verified employment record to their ORCID profile and read publications from their ORCID profile, at the end of the day I'm not sure they're worried / want to know whether this is Elements and the Hub today, or potentially some different publications management system and/or local HR-to-ORCID integration in a few years.

I should have added, the client id / secret would actually be a technical barrier here too wouldn't it? Ie it's not enough to copy/paste an access token to a different application, the request also needs to use the same client id / secret.

Jason, have you had any conversations with ORCID around re-use of permissions between applications at the same organisation? Is this something you'd be willing to bring up with them? From conversations with Library / Research Office folks here at Waikato University, we think from a UX point of view it'd be better not to have to ask for ORCID permissions for multiple applications. But of course we also want to do the right thing in terms of honouring the trust promises / sticking to the "the ORCID user owns their profile" philosophy.

cheers,
Andrea

--
You received this message because you are subscribed to the Google Groups "nz-orcid-hub" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nz-orcid-hub-...@aucklanduni.ac.nz.
To post to this group, send email to nz-orci...@aucklanduni.ac.nz.
To view this discussion on the web, visit https://groups.google.com/a/aucklanduni.ac.nz/d/msgid/nz-orcid-hub-gg/8ad415ca-d261-4689-850b-f90c6f6917a5%40aucklanduni.ac.nz.

-- 
Dr Andrea Schweer
Lead Software Developer, ITS Information Systems
The University of Waikato, Hamilton, New Zealand
+64-7-837 9120

[Jason Gush]

Hi Andrea, 

Good to see you here, and imho no thread is too old to revive when there's still live issues to discuss. :)

Re: Elements and token reuse. That seems to be an old interpretation to me and rather, I suspect that ORCID would encourage this kind of reuse.  Sorry I can't be entirely clear what their issue is as that link is behind a Symplectic support login.

Those of you with a keen eye will have noted that since we started development in Feb, ORCID have reversed their request to us asking that we identify the Hub apps as "Hub apps".  That's why we changed the auto-population in the API credentials request form from being named "NZ ORCID Hub for" the organisation name, to being just the organisation name (ORCID support began stripping the "NZ ORCID Hub for" in any case) .

> I should have added, the client id / secret would actually be a technical barrier here too wouldn't it? Ie it's not enough to copy/paste an access token to a different application, the request also needs to use the same client id / secret.

That's not quite true.  The client id and client secret (and redirect URI) are needed to get the access token, but once you have it and the ORCID iD that granted it the id/secret aren't referred to again.

As a consequence there's be no technical barrier for a Sympletic app, or indeed any app specifically including cURL, using a Hub-mediated "/read-limited+/activities/update" token to read trusted-party information, and in my opinion no additional privacy concerns.

When we were in the position of branding the interactions from these Apps with "NZ ORCID Hub...", I'll admit that I was uncomfortable with the reuse of tokens for other purposes.  Now that the Apps show it's the organisation that is requesting permission, and the actions of the tokens gained will be shown to have come from the organisation, my concerns have evaporated.  As noted it's in our future plans to explore ways of securely sharing the tokens with you.

We're fortunate to have an ORCID delegation here next week for ARMS, and I'll be happy to ask them for a verdict on this very matter.

BTW it's a requirement of the ORCID's new checklist for vendor systems that we allow this, i.e.,.

• Your system must offer a way for your clients to export the stored ORCID iDs and token exchange data (access tokens, refresh tokens, scopes, scope expiry). If your system also writes data, then it must also include the relevant put codes with data exports. 

https://members.orcid.org/api/workflow/vendor-systems

We're very clear that the tokens belong to the organisations, and if you ask for them we'll give them to you.

The last thing I'll note tho is a reiteration: ORCID's security is geared around ensuring the identity of the App together with making the user aware of the source of a token request and explaining the scope requested.  Given their power and utility, once the ORCID iD/token pair is obtained, the burden of securing them lies with the system(s) these tokens pass through (i.e. the Hub and whatever system is on the receiving end at the institution).

Best wishes,

Jason

[Andrea Schweer]

Hi Jason,

thanks for your response -- and yes please on checking in with the ORCID folks for a verdict. I'll pass a summary of your response back to Symplectic; they have indicated that they're open for further discussion on the matter and I'm sure the extra information you've linked to will be of interest to them. From what you're saying, ORCID have changed their position on this and I imagine it's entirely possible that Symplectic aren't aware of the changes. So an "official" answer from ORCID would be really helpful.

cheers,
Andrea

To view this discussion on the web, visit https://groups.google.com/a/aucklanduni.ac.nz/d/msgid/nz-orcid-hub-gg/a87f131f-ac48-4ecf-baa2-053575a6e02a%40aucklanduni.ac.nz.