Registration Services

Registration is straightforward. You can integrate it into your own applications and create the core experience yourself so it is seamlessly integrated into your application.

To register an individual only needs to

• choose their own username which we call a MydexID
• provide an email address
• create a password

See example of a registration form:

As part of the registration process we also set up the individual's Personal Data Store (PDS), which is their own vault for their personal information they chose to collect and store. As part of the set up they asked to create a Private Key.

The Private Key is something only they will know, it is how they access the PDS itself and control who can send or collect data from.

Unlike the password for their MydexID, Mydex cannot reset or recover the private key as it is only known to the individual.

Validation of the MydexID and other attributes 🔗︎ click to copy

When using your own registration form to register a new MydexID and PDS per our documentation, our Identity Services Platform will check the supplied payloads for registering a MydexID, to ensure it meets 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 email address is not empty and not already in use
4. That the password is not empty and not the same as the MydexID
5. That the password is 8 characters or longer
6. That the MydexID is alphanumeric in nature.

We recommend that your application also perform its own validation of items 1 through 6 before proceeding to submit the request to our API to process the registration.

Don't forget that your POST payload must also contain other attributes not-specific to the member, such as your API key, Connection NID, Connection Token Hash and return_to URL, as per the documentation in the link above.

Mydex will then redirect the member to the Identity Services app to create their Private Key. This form is not part of your own app, but is processed directly at Mydex.

The Private Key form will validate:

1. That the private key is not empty and not the same as the MydexID
2. That the private key is not the same as the password
3. That the private key is not less than 8 characters and not longer than 128 characters
4. That the terms of service have been accepted.

Assuming that all validation passes, the member will be registered, their PDS created, and the member's browser will be redirected back to your return_to URL.

Delegating the registration process off to Mydex via OpenIDConnect 🔗︎ click to copy

Should you wish to avoid handling (or your app is unable to handle) the registration step in your application, delegating the registration process off to Mydex is possible (and highly recommended) by using the OpenIDConnect protocol. Please visit our instructions for getting started with OIDC.

Beginning a standard OIDC flow, with a query parameter action=register appended to the auth URL, will result in a redirect from your application to a registration form on our OIDC platform, and your app need never process the MydexID, password or email address in a form 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).

Theming of the form to present a consistent experience with your app is possible (contact us to discuss further).

Next steps after registration 🔗︎ click to copy

That's it for registration of a MydexID. Should you wish to interact with the new member's 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.

Should you wish to allow the member to log in to your app with their MydexID and password in future, you will need to use either OIDC or SAML protocols to allow the member to authenticate.

See an example of a data sharing agreement presented to the individual to approve:

As soon as they approve this they are returned to your own application journey so they can continue as an authenticated user connected to your service.

If the individual already has a MydexID, They will simply login and approve the data sharing agreement for the first time they connect to your service.