Thanks for the clarification Tom,
In return: We run a Test Hub instance so that new members can explore functionality and get comfort with writing to the different sections of ORCID sandbox records. It's only after they've demonstrated familiarity with the system, that we let them loose on the production Hub, and thus the production ORCID registry.
For our non-Identity Federation members, we use ORCID as the first authentication mechanism for Hub admin roles based a read-limited call retrieving the record's email (and which we have instructed the user to make at least "trusted parties"). NB: the system we have in place already requires that email to be verified in the production Hub (calling on the production registry), but this is obviously relaxed in our Test environment (calling on the sandbox registry).
To be clear this change would have no effect on our production Hub, or for federated-identity members in our Test environment. For everyone else on Test, we'll now have to require them to create sandbox records that are validated with mailinator addresses - that's a new process and a little urksome, but not huge. For those member organisations where access to mailinator is blocked, we're kind of stumped.
The only hack I can think of is to get these admin users to attempt onboarding to Test, and when they're confronted with the "The Hub cannot verify your email address from your ORCID record." that they stop, and email us with their sandbox ORCID iD. This has the side effect of creating their user in the Hub's database, so that we can copy/paste the ORCID iD. They'll then be able to use the now Hub-known ORCID iD to log in. Obviously that's an inelegant cludge, and educating new to ORCID users to a substandard practise.
To paraphrase the reason given for this change, i.e., that the production registry is littered with misleading, if not outright false, email assertions which when public are both visible and being indexed for searching.
I agree that's undesirable but I guess I'm not sure why the solution is to effectively force unverified email's privacy to private, rather than read-limited; however, our real headache is that this change is affecting sandbox when the given reason is surely irrelevant there.
Thanks also for the pointer to Trello (and which I'll admit to always struggling to navigate). As a request, can I ask that anything that's hitting Launchpad and which is going to affect the behaviour or responses we can expect of the API, should get a post here.
Cheers,
Jason.