Anil John
 
 

Proprietary Attribute Validation (Remote Identity Proofing) APIs

 Share  Print  Email

Specialization in the identity service industry has given us component identity services; a good thing. In a typical integration with a Credential Service Provider (CSP) or a Token Manager (TM) the point of integration is often a profile of a protocol, such as SAML, to minimize interoperability issues. This blog post looks at the current status of attribute validation (remote identity proofing) APIs where proprietary is the name of the game.

A relying party will sometimes choose to keep in-house the binding between the token and the identity, and out-source the identity management function to an identity manager. In such a case, the RP will ask for self-asserted information from an individual, and outsource the verification and validation of that information to an Identity Manager (i.e. a “remote identity proofing service”).

The challenge in this world is that everyone from specialists like Socure and Trulioo, who focus on social identity verification, to the big guys like Equifax, Experian, Lexis-Nexis and others have proprietary APIs they use for integrating with RPs. This requires one-off integrations when an RP is using multiple Identity Managers, or when it wants to move from an existing vendor to a new one.

At the same time, if you speak with these folks, you quickly realize that their value proposition is not at the protocol level but in the payload they offer. The analytics they offer on top of their aggregated data is what they see as their unique selling point. So it has always been a point of curiosity to me that there has not been more of a movement to standardize the APIs/Interfaces they provide.

Given that they often need to partner with multiple token managers to provide a full CSP solution, and with industry Trust Frameworks seeking clarity around division of labor between token managers and identity managers, my hope is that this is an area these folks will come together on standardization at the protocol level and compete at the data/payload level.

RELATED INFO



This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.

Topic(s):
By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post.
Meet me over on Mastodon to join the conversation!

I am a public interest technologist. I help organizations and leaders make digital services secure and trustworthy.
Learn more »