Registration Services

If your application is capable of operating as an OpenIDConnect (OIDC) Relying Party (RP), it can help a citizen register a MydexID and a PDS. To do this, have your application initiate an OIDC auth flow with our OIDC server using an extra argument in the flow to present the Mydex Registration Form instead of the Login form. The member is then returned to your app to complete First Time Connection (if applicable).

Using the OIDC approach means you completely offload processing or validation of any credentials whatsoever. It is also a fast, streamlined experience for the member, because they can create their Personal Data Store's Private Key in the same form, as well as set up Multi-Factor Authentication devices if they wish.

Below is the flow diagram showing how registration via OIDC works. In this diagram, the 'Mydex LaCa' is the Login and Consent App, where a member is taken to either register or login with their credentials.

Loading the registration form 🔗︎ click to copy

By initiating an OpenIDConnect authentication flow with the custom query parameter action=register appended to the auth URL, will make the Mydex LaCa render a registration form instead of a login form, as shown below.

If you are collecting an e-mail address from your members in your application as a step prior to initiating the registration flow to Mydex's OIDC, you may also append the query parameter email, for example you@example.com. This will pre-fill the email fields in the registration form to save time for the member filling out their registration details. Note that if the e-mail address is already in use in our system, the member will still need to enter a different e-mail address in order to register.

This means your app need never process the MydexID, password or email address in a form hosted on your application at all. Processing registration in this way also carries the benefit of automatically establishing an OIDC session (the member is considered 'logged in' once they return to your app - you won't have to invoke a login flow after registration).

Mydex's registration form will enforce the following conditions:

1. That all the required parameters provided by the member are present (mydexid, email, password)
2. That the MydexID is not empty and not already in use
3. That the MydexID is alphanumeric in nature
4. That the MydexID is not made up exclusively of numbers
5. That the MydexID is a minimum of 3 characters and no more than 60 characters in length
6. That the email address is not empty and not already in use
7. That the password is not empty and not the same as the MydexID
8. That the password is 8 characters or longer.
9. That the private key is not empty and not the same as the MydexID
10. That the private key is not the same as the password
11. That the private key is not less than 8 characters and not longer than 128 characters
12. That the terms of service have been accepted.

Theming the registration form 🔗︎ click to copy

Theming of the registration (and login) forms to present a consistent experience with your own application's style guide is possible. Mydex hosts the assets for that theme in the LaCa. It is the responsibility of the Subscriber to provide the assets to Mydex. Please contact us to discuss further if you'd like to explore this option.

Sample application to perform registration 🔗︎ click to copy

To view a sample Python Flask application that uses OpenIDConnect with the Mydex Sandbox, please click here to see our Developer API Example git repository. If you uncomment the "action": "register" in the request's parameters in the python script, it will load the registration form instead of the login form.

Next steps after registration 🔗︎ click to copy

That's it for registration of a MydexID. To login and logout with a MydexID, please see the authentication documentation.

Should you wish to interact with the newly-registered member's Personal Data Store (PDS) using your Dedicated Connection, you can then initiate the First Time Connection journey, upon which the newly-registered member will be taken to the Data Sharing Agreement page to approve the connection of their PDS to your application.

As soon as they approve the Data Sharing Agreement, they are returned to your own application journey so they can continue as an authenticated user connected to your service, and your application also receives a POST payload from the PDX API containing special cryptographic information for reading or writing to the member's PDS.