Infrastructure » CN REST

So yes, this will affect our production logins. We currently set the user's DN based on the content of the sub claim, which so far has remained the http://orcid.org/xxxx-xxxx-xxxx-xxxx format. Because we are planning on creating equivalent identities for the https a bare ORCID string versions of these identities, this is probably a good time to make this change as well. We currently set the prefix in portal.properties to vary between the sandbox and production ORCID services. Changing to use the iss claim concatenated with the sub claim is overall a minimal change.

That said, timing is everything. We'll need to know when this change is available on https://sandbox.orcid.org so we can test it out, and then will need to know the precise date and time of the https://orcid.org production switchover so we can upgrade the portal at the same time to avoid authentication downtime. I'll chime in on the email list so Tom is aware that this affects our production service.

I'll make the changes and work with Jing and Dave to get it into the next release. We might want to have the tagged portal package ready and just wait until ORCID is ready for their switch.

Here's a copy of my response to Tom Demeranville at orcid.org:

Begin forwarded message:

From: Christopher Jones <cjones@nceas.ucsb.edu>
Subject: Re: [ORCID API] OpenID 'sub' change schduled for May 16th
Date: April 19, 2018 at 4:52:12 PM MDT
To: "Demeranville, Tom" <t.demeranville@orcid.org>
Cc: ORCID API Users <orcid-api-users@googlegroups.com>

Hi Tom,

Thanks for the note, and for the timing.  This change will definitely affect our 
authentication service in the DataONE network, and so we’d like to request two things:

1) Having the switch be done in the sandbox.orcid.org environment at least two weeks 
before the production switch.  That will allow us to change our code and test it 
in the sandbox beforehand.

2) Identify the exact time that the production switch will occur on May 16th.  
This will allow us to  coordinate our switch at the same time to avoid downtime 
as much as possible.  We can let our community know that there will be a slight 
downtime during a defined window, and that they’ll need to authenticate again.

Thanks very much,
Chris

I'm working on a fix for this, and am thinking about handling the scenario where they don't provide time in their sandbox environment for testing, but just make the switch on the 16th. I haven't heard back at all, so it'll be good to be prepared either way. Dave, it might be helpful for you to respond as well at the google group to try to bump this a bit.