Some more ORCID Hub questions/feedback

[Andrea Schweer]

Hi,

here are some more questions / comments about the NZ ORCID Hub. They're a mix of my own observations and those of others here at Waikato University.

Validity of verified employment information

• We're worried about the following scenario: An employee grants write permissions to the ORCID Hub. We use it to push employment info to their ORCID record. They revoke permissions, whether on purpose or by accident. Some time after that, they leave our institution. We now have no way to update the employment info with an end date, making it look like the person is still employed with us. This appears to be a pretty fundamental issue with verified affiliation data. Is there some way (eg via webhooks or the like) to ensure we get a chance to end date (or delete) not-yet-end-dated employment info when permissions are revoked?
  

Hub admin accounts

• Can only one person be the technical contact? Would it be possible to assign a fall-back contact in case the main contact is away etc?
  
• What about organisation admins - the FAQ mention that this role exists, but how is this configured and by whom? Any chance this can come through Tuakiri via an AD group or the like so we can maintain role membership at UoW rather than inside the Hub?
  

Integration

• What is the roadmap for supporting automated integration? We'd need at the very least web services to provide functionality similar to what's available via the "ORCID iDs of researchers at your institution" and "Upload Researcher Info" pages. Access to the tokens (rather than the Hub replicating functionality available through the ORCID API) may be useful too, though see the Symplectic Elements discussion for concerns around how that fits with the OAuth philosophy.
  

Access to the Hub

• How is determined who can authenticate to the hub via Tuakiri? Eg currently UoW alumni can authenticate as their account remains open indefinitely. How would that be locked down, would it mean having to lock down access to all of Tuakiri? Or could there be some sort of role identification thing inside the Hub that only lets through certain groups, eg affiliation types?

UX

• The U Canterbury feedback shared by Anton and Stuart covered much of what we had collected here at Waikato Uni.
  
• I find the "Home" button particularly confusing since it shows the log-in buttons even when I'm logged in.
• Are there any plans for letting organisations skin/theme the Hub for their users? We're a little worried about asking our users to go through the Hub, then Tuakiri, then the UoW IdP, then ORCID and back to the Hub, all with different / non corporate looking user interfaces (as noted by the Canterbury folks too). Some way for us to deep link to somewhere in the Hub that removes some choices from the end user might also be nice -- eg if we put a link somewhere in our intranet, we already know that everyone clicking on that link should log in via Tuakiri not ORCID, and should pick UoW as their Tuakiri organisation.

cheers,
Andrea

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

[Anton Angelo]

Kia ora koutou,

 

I have one REALLY messy approach to the zombie record thing.

 

Set the Job Title to “Magnificent Job Title – last updated mmmm yyyy”

 

Then at least it obvious that it’s not an end date, but if it gets really stale it might draw attention that it could be incorrect data.  It would mean updating it occasionally.

 

aa

--
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/3ced81d3-135f-6981-840d-7cc7ddad7eb4%40waikato.ac.nz.

[Jason Gush]

Good good questions/comment.  I'll be responding inline:

On Friday, 15 September 2017 12:07:05 UTC+12, Andrea Schweer wrote:

Hi,

here are some more questions / comments about the NZ ORCID Hub. They're a mix of my own observations and those of others here at Waikato University.

Validity of verified employment information

• We're worried about the following scenario: An employee grants write permissions to the ORCID Hub. We use it to push employment info to their ORCID record. They revoke permissions, whether on purpose or by accident. Some time after that, they leave our institution. We now have no way to update the employment info with an end date, making it look like the person is still employed with us. This appears to be a pretty fundamental issue with verified affiliation data. Is there some way (eg via webhooks or the like) to ensure we get a chance to end date (or delete) not-yet-end-dated employment info when permissions are revoked?
  

Yes. That's a real, although I suspect low risk scenario.  I'd also suspect solutions would create more problems for well-behaved users than is worth it, e.g., should the records of genuine long-serving staff be treated as suspicious because the record is unchanged over many years?

Anton's suggesting is feasible, but unlikely to please the folk who are looking to ORCID being an auto-generated professional CV with verification.

It is possible to check for the expiration/revocation of an access token, and given the primacy of the ORCID record belonging to the individual it may be more appropriate to just ask for permission to update when/if you're aware a token has been revoked.

 

Hub admin accounts

• Can only one person be the technical contact? Would it be possible to assign a fall-back contact in case the main contact is away etc?
  

Sorry, ORCID are very clear only one person can be the technical contact at any time.  However as far as the Hub's concerned, a Main Contact emailing us with a change will get the new individual a Tech Contact invite to the Hub and an update to the contact list that ORCID uses.  That switch over is usually completed in 1-2 working days.

• What about organisation admins - the FAQ mention that this role exists, but how is this configured and by whom?

The Organisation Admin role was created on request.  It's configured so it has all the functions of the Technical Contact in the Hub, with the exception of the views/tasks to do with the API credentials.  The "by whom" part is by a Tech Contact or Main Contact or another Org Admin asks or...@royalsociety.org.nz to invite someone as an Organisation Admin.  They go through the same onboarding process as the Technical Contact, but unlike Tech Contacts, you can have as many Org Admins as are found useful.  

• Any chance this can come through Tuakiri via an AD group or the like so we can maintain role membership at UoW rather than inside the Hub?
  

Are you proposing specifying an eduPersonEntitlement? If so then in principle, yes but a definite word will need to wait on Rad's return on where this fits.

Can they be a joint/shared user?  If that's what the organisation wants then yes we'll send the invitation to whatever email address the Technical Contact instructs; however as we've recently started logging/reporting "created by" and "updated by",  I'd prefer the Hub users remained identifiable.

 

Integration

• What is the roadmap for supporting automated integration? We'd need at the very least web services to provide functionality similar to what's available via the "ORCID iDs of researchers at your institution" and "Upload Researcher Info" pages. Access to the tokens (rather than the Hub replicating functionality available through the ORCID API) may be useful too, though see the Symplectic Elements discussion for concerns around how that fits with the OAuth philosophy.
  

The roadmap is well defined up until the next major milestone after the current features of ORICD authentication and rich affiliation, i.e., Hub-written funding items.  

We've a bunch of potential directions after that: Hub-written works; alternative authentication such as AD; and yes a Hub API for the functions mentioned.  However, for organisations with the wherewithal to interact with a Hub API, my suspicion is that they'd be better off getting and using Hub-mediated tokens directly.

We've another 9 months more development time, and I'm looking for a steer on where to set future priorities from the IT Advisory Group and indeed the community.  If there's no overt preferences expressed, you can expect to see either a survey or a call to a town hall zoom session once we're towards the end of the "write funding" push (i.e., in the next two months all being well).

• Access to the Hub
  

• How is determined who can authenticate to the hub via Tuakiri? Eg currently UoW alumni can authenticate as their account remains open indefinitely. How would that be locked down, would it mean having to lock down access to all of Tuakiri? Or could there be some sort of role identification thing inside the Hub that only lets through certain groups, eg affiliation types?

Anyone with Tuakiri credentials can log into the Hub, but what happens from there is controlled by what eduPersonAffiliation <http://wiki.aaf.edu.au/tech-info/attributes/edupersonaffiliation> they present with.

The Hub's rules are currently if the eduPersonAffiliation attribute contains "faculty" or "staff" then an employment affiliation is written; if it contains "student" an education affiliation is written; and if it loops through the attribute without finding either a warning is given:

"The ORCID Hub was not able to automatically write an affiliation with {user.organisation}, as the nature of the affiliation with your organisation does not appear to include either Employment or Education.

Please contact your Organisation Administrator(s) if you believe this is an error."

In development/testing, we were also giving education affiliations to those with "alum" as the meaning is "Alumnus/alumna (graduate)"; however, it turned out that many orgs aren't using it in exactly this way.

UX

• The U Canterbury feedback shared by Anton and Stuart covered much of what we had collected here at Waikato Uni.
  
• I find the "Home" button particularly confusing since it shows the log-in buttons even when I'm logged in.

That's "improved" in the next Hub iteration; hopefully this will be on test by/before the next sprint showcase on Thursday. 

• Are there any plans for letting organisations skin/theme the Hub for their users? We're a little worried about asking our users to go through the Hub, then Tuakiri, then the UoW IdP, then ORCID and back to the Hub, all with different / non corporate looking user interfaces (as noted by the Canterbury folks too).

There's a couple of things that interact here.

Although there's no plans for the Hub to be skinable, there are a few current and possible future workarounds.

At the nuclear end, the Hub is open so it would be possible to run your own instance skinned however you like if that's definitely what you're after. 

Lower down the scale:

• Some way for us to deep link to somewhere in the Hub that removes some choices from the end user might also be nice -- eg if we put a link somewhere in our intranet, we already know that everyone clicking on that link should log in via Tuakiri not ORCID, and should pick UoW as their Tuakiri organisation.

 

Currently, for the Tuakiri-mediated login the best I can offer is that you offer the link of https://orcidhub.org.nz/Tuakiri/login instead of https://orcidhub.org.nz.  This will silently redirect the user directly to the Tuakiri Directory Service to select their Home Organisation and saving them at least 2 clicks.

In the longer term, the dev team have a meeting arranged and scheduled by the good auspices of Sat Mandri (Tuakiri/REANNZ) with eTV's developer.  It would be good to see how they go about directing to the correct IdP from an email address on a log in to http://www.etv.org.nz/.  That's still not exactly user friendly as it requires the entry of the email to detect the correct IdP, but then the user to enter it again on their IdP.  However if it turns out to be simple, we can look to creating a url for each Tuakiri member which would result in a Tuakiri sign in at their IdP that drops them authenticated into the Hub to give their permission at ORCID and saving the user another click.

Finally, if you're after organisation branding in your message you may prefer to use the Non-Tuakiri invite flow instead.  This has the advantage of requiring fewer user-interactions, i.e., 

1. The User clicks on a link in a branded email which sends them to ORCID (requesting Hub-mediated permission).
   
2. The user enters their ORCID credentials and clicks "Sign into ORCID"
   
3. The user (with their new two-step permission flow) Click "Authorize"

They're then dropped into the Hub at their profile page being told "Success" and that no further action is needed.  NB on test that email is currently themed as per the Hub's Tech Contact invites.  

Although the Hub is by its design principles "not a content-management system", the Society has offered to help organisations craft an email template for their organisation's invitations to use.

If there's an appetite for this (and the willingness to provide the necessary authorised assets), let us know with a mock of what you'd like it to look like and we'll see what can be done in the next few sprints.

I should also point out that the Non-Tuakiri flow does give some of our more identity-minded folk mild conniption.  While it's the only option for those without an IdP, is simpler for the user, and has the potential to immediately result in the richest affiliation record that ORCID can take; on the other hand, it's delivered to anyone with the ability to receive/intercept the email.  Unlike the non-Tuakiri org Technical Contact/Organisation Admins, it's not feasible to confirm that the ORCID record has a verified email address before writing the affiliation.