Mydex CIC describes how they are leveraging the design of OpenIDConnect to deliver more complex journeys with the Person at the centre of a data exchange, and what they envisage to come next.

# Introduction

In the previous post in this series, we introduced the Mydex Safe, Secure Cloud’s Identity as a Service platform, and how it has evolved over the years to adopt certain protocols - most significantly, OpenIDConnect and OAuth2.0.

In this concluding chapter, we talk about how we are taking OpenIDConnect further to deliver more complex journeys, and how the standard is continuing to evolve and adapt to changing needs in a modern internet age.

# Beyond login: delivering more complex journeys via OpenIDConnect

As we started to make more and more use of OpenIDConnect, we realised that its ethos is identical to that of Mydex’s own mission: the person is at the centre of an exchange of information.

In addition, Mydex has been growing rapidly as a platform. We run not only our own web applications in our infrastructure estate (a.k.a as a ‘First Party’), but also support integrations by third parties, who might be building their own web applications, which Mydex has no access to.

We don’t want those applications to be able to store attributes about the member in our Identity platform. This is the same as the Personal Data Exchange platform: for a Subscriber to read or write to a member’s PDS, that member must have granted consent for that to occur.

This led us to ponder how to allow web applications to invoke certain journeys in order to read or set attributes about a member only with the member being actively present. We realised that this is exactly what OpenIDConnect is all about!

The challenge then became: how to ’tap into’ the OpenIDConnect flow to tell the Identity Platform that we wish to perform a certain action that is ‘beyond’ merely authenticating the member, but which should only occur because that member has just demonstrated authentication (proof of ownership of credentials)?

The simplest solution, once again, was through a feature provided by Hydra. The ‘request URL’ that begins the OIDC journey can have query parameters appended to it in such a way that they are ‘parseable’ by the Login and Consent app once the member’s browser arrives there.

Mydex is using this technique to drive new journeys on our platform, including:

• Support for mapping a ScotAccount entity to a MydexID entity, as the Scottish Government seeks to make more use of the ScotAccount platform (which is, itself, also an OpenIDConnect service). This will ensure that Scottish citizens can login to Mydex-based services using their ScotAccount, and those services will understand which PDS to use, if necessary, to interact with that person’s data
• Multi Factor Authentication - a recent rollout to our Identity Services stack, allowing members to strengthen the security of their account. MFA device details are stored in the member’s own PDS, with support for different methods and a full audit trail of usage.
• ‘Anonymous Identifiers’ - part of our effort to introduce an anonymised entity ID that allows services to interact with a member without needing to know their MydexID, including the ability to contact the member without knowing their contact details or preferred contact method.

Each of these journeys, because it requires an OIDC flow, depends on the member being present and actively engaged, yet is also an automated process that doesn’t require extra effort from the member to complete. In some cases, if they are already authenticated due to an earlier session, they don’t even see anything at all.

But crucially, we don’t want a third party app being able to tell our Identity Service platform what ScotAccount entity should map to what MydexID - what if that app gets hacked, and attempts to perform an account takeover with either an arbitrary ScotAccount or an arbitrary MydexID?

The beauty of driving the mapping journey via OpenIDConnect is that:

• only the member can invoke that change by being present as part of the OIDC journey
• the change itself is performed entirely within the Mydex IDaaS platform, and not directly from the 3rd party application.

# Future areas of interest for Mydex, Identity and OIDC

As you can see, the more we take advantage of the principles of OpenIDConnect and OAuth2.0, the more possibilities seem to emerge.

We are lucky in some way to have predated OpenIDConnect in our mission, as it has made it easier to identify the similarities in our goals and approaches, and help us see where we may be able to leverage this maturing standard to replace older techniques used up til now in our platform.

Here are some examples of areas of interest that we are considering for the future.

## Use of claims as data sharing agreement and dynamic consent

Mydex’s Data Sharing Agreement between the Member and the Subscriber is built on foundations that match in principle with the idea of Consent in OpenIDConnect.

We have learned that the Data Sharing Agreement, a contract between the member and the subscriber that is crucial to ensuring the member maintains control over this process, also represents a common ‘friction’ point for less technically-minded members trying to use the platform.

The consent model in Mydex is currently custom and is deeply integrated into the encryption of the Personal Data Store itself, but we see opportunities to drive some of the data sharing agreement process through the use of claims and consent flows in OpenIDConnect. If nothing else, this may allow us to remove a lot of custom code, shrinking our attack surface and simplifying the platform, which is also good for security.

## Use of OAuth2.0 credentials as the Dedicated Connection Key

The Dedicated Connection Key or Dedicated Connection Token used by subscribers today, is largely an authorisation measure to drive the Data Sharing Agreement journey. There may be ways we could potentially replace or drop the Dedicated Connection Key, by using the OAuth2.0 credentials already starting to be used by the Subscribers for accessing the API in the first place.

## Federated identity (Self-Issued identity provider), distributed identifiers and mobile

As modern usage of the internet continues to evolve into a mobile-first environment, new challenges emerge in terms of making it easy to integrate mobile native applications into web journeys.

Mydex is closely watching and sometimes offering feedback into ambitious new RFCs being developed by the OpenID Foundation, such as Self-Issued OpenID provider.

Another area of interest is the W3C’s Decentralised Identifiers specification.

Efforts such as these are built from the belief that centralisation of service represents a position of privilege from which control can be exercised over the information flowing through that service. This can be antagonistic towards an individual’s right to remain in control about who gets to see or make use of their information, as well as the individual’s rights to see how that information is being used.

These projects and efforts often align with Mydex’s mission to help keep the person at the centre of the data exchange when it comes to personal data.