With the new OpenID Connect for Identity Assurance standard out in draft there is only one puzzle piece remaining to fit to fully realize distributed identity management: an electronically verifiable trust registry of Identity Providers. And the Kantara Initiative is poised to provide it.
To fully realize dynamic interoperability a user new to a digital realm – a website, an API, a phone app – needs to be able to present their identity and credentials and be registered and admitted on the spot.
We are almost there.
First, to the well-known Oauth and OIDC dance, we add the OAuth Dynamic Registration protocol (required support it for was dropped from the final CURES Act ONC API rule.)
Dynamic registration does a couple of things. First, it spackles a crack in mobile API access security (many APIs today issue refresh tokens to non-confidential mobile clients, which is prohibidibidado in OAuth 2.0.)
But second, and germane to our discussion here, Dynamic Registration standardized the API and process for an app’s initial registration at an API developer portal.
There are many advocates of some kind of list of trusted applications, and an application certification process. As I sketched out in ‘Trusted Applications: An Interoperability Parable’, I am more of the laissez-faire school: the onus in on the API to protect itself from bad agents, and, as for the apps, caveat emptor, Consumer.
With OAuth and OIDC, the user’s identity information is provided by the OpenID Connect Provider (OP) to the website, app or API the user is attempting to register for – the ‘Relying Party’ or ‘RP’.
The new Identity Assurance specification lets the RP get both metadata about the quality of the identity presented – whether it has been proofed to the NIST 63.3 IAL2 standard for example – and also additional identity attributes such as place of birth that the RP may use to do their own identity assurance – their re-assurance.
The remaining problem to be solved – the last piece of the puzzle – is this: how does the Relying Party know that the OP, the Identity Provider, the IdP, is trustworthy, that their claims of IAL2 quality proofing, for example, should be believed?
Right now the Relying Party must establish that trust discretely, and manually, for each OP with which they want to federate identity.
The Kantara Initiative is almost there. The Kantara ‘Trust Mark’ is a kind of Good Housekeeping seal of approval granted to Identity Providers that speaks to their quality of identity proofing and authentication. Getting a Trust Mark requires passing a stringent audit by a trained and certified auditor. Kantara has a well-designed and effective vetting process.
If the OP provided the Relying Party with a token identifying the OP that could be verified against the trust registry, then the entire registration process could be done dynamically with no pre-arrangement.
Give the large number of Identity Providers we have in the US – this is not Estonia, which has more of a Highlander approach (‘There Can Be Only One!’ : ) – a national IdP here is decades away here – this dynamic validation of the quality of our IdPs is on the critical path to establishing broad identity federation to support Interoperability.
I hope that Kantara is already on this trail and I simply haven’t found the spoor yet.
Stay tuned.
Health IT Architect 