Discuss implications of using Mathigon or IBM Quantum login methods

[eddybrando]

Related to #2207
Related to #1972

[eddybrando]

We scheduled a dev team meeting to discuss this yesterday, as pointed out by @vabarbosa in https://github.com/Qiskit/qiskit.org/issues/2207#issuecomment-948960150.

[Tansito]

From our last conversation with the IQX team the login process is very connected with the iqx-api right now. Furthermore it seems that there are some business use cases to take into account before being able to register users from qiskit.org.

One approach could be to start the refactorization with challenges and take of advantage from it to continue with the login process. For this case we manage our login so we are going to need to think a way to connect our users with the iqx-api.

Another approach could be to find a solution between register our users in iqx (trying to solve those business use cases and so on) and manage our data by ourselves.

The idea will be to clarify what implications mean to go with one or another solutions in the next meeting with the IQX team.

[Tansito]

With the purpose to support accounts in qiskit.org in the meeting with IQX we could clarify the next scenarios:

Scenario 1

We could say that this is the simplest scenario. We use the IQX API to register our users through the desired provider supported by IQX. With the redirectTo after the login we redirect our users to our platform and we add our additional information to the IQX user.

PROS:

• the workflow is done, we are only going to need to take into account the particularities from the IQX users (like mandatory parameters: institution, terms of services acceptance...)

CONS:

• we don't have users. The users are from IQX and we depend on them to manage them.
• the workflow is a bit trickier because at the end it's like we are adding a patch to an incomplete user.
• we are going to need to manage the user requirements from IQX (like the mandatory parameters)

Scenario 2

Near to our desired scenario. Here we manage our users and we use IQX only to run the circuits from qiskit.org. The current problem is that IQX doesn't support an easy way to link external users to use its platform. The workflow here would be something like a user is created in qiskit.org and if the user wants to run a circuit will need to enter in the IQX platform, create an account, obtain the IQX token and save it in qiskit.org.

PROS:

• here we manage all our users data and all the user creation workflow.
• the workflow would be a bit safer because the contexts are not dependant.
• it's true that there is a manual step in the middle to run circuits but could be automatised in the future (we could be near to scenario 3).

CONS:

• the entire workflow would be a bit manual initially.

Scenario 3

The ideal scenario but difficult to achieve right now. Similar to the scenario 2 but the idea would be that the link of the user between qiskit.org and IQX would be fully automatised through some kind of end-point. Impossible by now from IQX but we could try to be near to it creating the user and handling the IQX token from our side.

Last notes to take into account

• These scenarios would be independent of the login plugin from Mathigon, that it's not being studied in this meeting.
• The source of the data is the most important thing. Moving forward from Scenario 2 to Scenario 3 could be easy to handle in the future because we are the managers of the data. The same doesn't apply to the Scenario 1.

[eddybrando]

Thanks a lot for the detailed explanation @Tansito.

We will be moving forward with the approach described in the scenario 2 and revisit scenario 3 in the future if we can automate the IQX account link.

Can you confirm, @va?

Anything else to add? Otherwise I'll lock this discussion for now.

[vabarbosa]

@eddybrando thank you. i am good. feel free to lock the discussion. thanks again @Tansito