What’s your street cred?

Identity and access management is a tricky business.  You have OAuth, OpenSocial and other products from IBM Tivoli, RSA and so forth that clarify and dismay some users and decision makers.  The OAuth and such of the world are great for basic authorization and authentication.  But when you have financial, health and other client sensitive requirements these MAY not cut the CISO sniff-test.  Enter the big boys: Tivoli, RSA/ClearTrust, Verizion Identity and Access Management.  But as reported today in Mashable – the folks at Open Identity Exchange, Verizon and Google have introduced a national trust identity management scheme.

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

The concept is taking a bit of the best of everything and make a national trust ID system without getting the government involved in it.  Verizon has one of the best remote-managed ID and Auth management systems out there. Ok, back to the concept;  here are the active ingredients:

1. The user
2. A “relying party” website that needs to get a trustworthy street address for a user, for example to see if that business has some historical records associated with the user at that address
3. An “attribute provider” that has verified the user’s street address of the user, and is trusted by the RP to assert that address
4. The user’s main “identity provider” that they most frequently use to login to websites

The enroll process is like this:  you would create one account, go to the attribute provider (AP) and then through the OAuth flow it would verify you via a street address and when you get a postcard from the AP you would then re-login and verify your street ID with the code on the card and the ID and address are connected (though the registration Db wouldn’t actually have your address – just verification of the trust association).  Then you head to a site (RP) and when you log on, it will ask you which address you would like to use and when the address is verified consent is given and the RP will get the trusted token and the user will be logged in.  Pretty slick.

Pretty slick with the exception of that as with any federated identity management system you can only trust the ‘trusted source’ so much.  The same issue comes up with SAML and other federated auth schemes – you are trusting someone elses security to allow access to YOUR data/website/etc.  In a non-purist standpoint, this seems good enough for most applications.  But when you deal with HIPAA and other sensitive data, this doesn’t cut it.  That is why as great as identity standardization is, it will be a bit before this is wrapped into the greater enterprise.  It will also show up on requirement docs “Login through Facebook/OpenSocial” – and I will always walk them through the auth transaction field trip showing them glaring security gaps and then one can decide if the risks outweigh perceived benefits.  OAuth and other open authentication schemes are always attractive because of the the perceived low cost – compared to RSA/Tivoli options but as this internet world becomes more blurred – even with ‘standards’ – having your own trusted security plan and solution is going to tend to win more often than not.