Allow users to specify their ORCID and/or ISNI ID in their user account

[pdurbin]

From a meeting with @mcrosas @scolapasta and @pdurbin we should allow users to specify their ORCID and/or ISNI ID for their user account at sign up or later when editing their account.

This is for user accounts, not datasets, per https://docs.google.com/a/harvard.edu/document/d/1bZjEsejCaw1U6zNkER7iaZbysmXRKmonp9tKLUn-4LI/edit?usp=sharing

See also #829.

[scolapasta]

Is this for built in users or also shibboleth? currently, I don't believe we allow users to add any extra info (yes, including usernames) for shibboleth )or other external).

[pdurbin]

Is this for built in users or also shibboleth?

All users should be treated equally.

[eaquigley]

Since 4.0 is now coming out towards the end of March and I am already rethinking the Logging In process, I would like to add this field in to the registration form.

[posixeleni]

@eaquigley would this field also be pre-populated in the Dataset form like we do for the author name? This would save the user a lot of time having to re-enter the same information twice (or multiple times if they have many datasets).

[eaquigley]

@posixeleni yes ma'am, anything from the user sign up that relates to dataset metadata needs to be pre-populated.

[pdurbin]

If we're going to revisit the registration form, can we please make it so all users can have their "Affiliation" and "Position" stored in the database? (Or simply remove affiliation and position altogether?) If we need a separate ticket to revisit the builtin user table (where affiliation and position are stored) vs. the authenticateduser table, that's fine. To fix #945 and #457 and #965 the authenticated user table should probably have separate firstName and lastName columns.

Obviously, all users should be able to specify their ORCID or other ID, not just builtin users.

[suenjedt]

An update from the meeting:

• There is a preference from the ORCID side to start with Oauth and Phase 2
• However, there are examples, e.g. by ANDS where Phase I equivalent widgets are built http://developers.ands.org.au/widgets/orcid_widget/.
• Discussion shows preference to start with Phase 1 as planned, with suggestions for ORCID records (similar to ANDS integration)

---

quick update: I asked our colleagues at ANDS, who could not give me any additional information in regards to their ORCID widget that we looked into during our ORCID meeting. The other tool that was mentioned has not been implemented yet. More details (e.g. code) to follow from my CERN colleagues.

---

My summary from the meeting and follow up conversations: there are different models for implementations (e.g. publisher's manuscript submission systems, repositories or community portals such as ADS). ORCID prefers an Oauth integration for most, or all. However, it seems feasible to start with our planned Phase 1 and I, personally, dont see why we should not move as planned. Phase 1 is already an enhancement to the current state and Phase 2 requires more discussion and thus would happen much further down the road.

You are of course welcome to revise my summary.

[However, what is probably needed, is a conversation about Oauth as well, non?]

[pdurbin]

I've listed OAuth as an interest of the Dataverse Auth Community Group: https://docs.google.com/document/d/1xbWkj_OIk13gKe7jleNXVvakZErvHLA8JRBvLz8Fe8Q/edit?usp=sharing

[pdurbin]

what are the technical details for allowing shibboleth users to add in their ORCID?

From an email I sent last summer:

Eventually, we may be able to get ORCID IDs from Shibboleth in the form of a SAML assertion of an "eduPersonOrcid" attribute per the (unfinalized) spec linked from https://spaces.internet2.edu/display/macedir/ORCID+and+other+researcher+IDs

This was mentioned yesterday in the IT Summit talk "Enabling Cross-University Collaboration with Harvard IAM: TIER, InCommon, and Grouper"

[pdurbin]

This issue is highly related to #3338 which is currently under development.

[djbrooke]

I'm going to close this in favor of #3338.

[djbrooke]

Talked with @scolapasta, got some more info, reopening. Oops.

#3338 deals with logging in with / converting an account to use ORCID. This issue deals with maintaining an ORCID association for non-ORCID accounts AND using an ORCID throughout the application.

If this is worked on as part of #3338, we'll revisit closing/combining.

[djbrooke]

This is out of scope for #3338 and will live on a separate issue.

[pdurbin]

Out of scope for #3507 too.

[pdurbin]

Today I stubbed out a getOrcidId method on AuthenticatedUser in ca33857 but it's only for users who log in via ORCID.

[pdurbin]

I'm closing this until we decide to start working on it.