Federated identity brokers (plenty in the market) generally require that the "relying party" and consequently the "principal"/user trust them with sensitive information. The implementation of federated login generally involves the service provider directing the user to select from a preset list of identity providers. Combining these modes of operation you end up with a situation where user privacy and security are both compromised, not a good look for what is meant to be a security solution.
Beyond these immediate concerns, the actual specifications on which these identity broker services are based are generally more convoluted than they need to be. OAuth and OpenID are two of the more established standards, unfortunately these standards suffer from tunnel vision, ie they are so focused on the problem of user identity as it relates to login flows that they fail to consider simpler, better and more general approaches to solving the problem.
User identity authentication as it relates to login flows is really just a very specific case of the more general problem of trust establishment for information furnished by users on the internet.
The natural approach to this general problem of trust establishment is to break up the problem into component parts:
The lighter touch approach is for relying parties to decide for themselves what information they'll accept and from whom, ie I won't accept health information from your bank but I'll accept financial information. Over time some pseudo-standard is likely to emerge as consensus forms around these matters.
Our protocol incorporates the use of Asymmetric signatures that makes it easy for relying parties to enforce attribute source restrictions.
Over time we plan on incorporating auditing of trust providers to at least ascertain that their systems are suitable to serve as trusted sources. For instance if an employer has an HR system where a user can change their name, dob and such information without any additional due diligence on the part of the employer then such as system can't be used as a source of trusted information.
The second component of automated processing is deriving meaning from parsed information, this is perhaps where a standard repository of attribute meaning would be most helpful. A universal meaning-retrieval repo has so far been elusive, many initiatives have come and gone so for the most part it remains an open problem.
We have decided so far to create a data dictionary API to facilitate meaning extraction, though our preference would be to be able to just leverage a standard dictionary such as schema.org.
This post is not meant to start a flame war so I hope no one approaches it as such. I welcome feedback and critic.
Beyond these immediate concerns, the actual specifications on which these identity broker services are based are generally more convoluted than they need to be. OAuth and OpenID are two of the more established standards, unfortunately these standards suffer from tunnel vision, ie they are so focused on the problem of user identity as it relates to login flows that they fail to consider simpler, better and more general approaches to solving the problem.
User identity authentication as it relates to login flows is really just a very specific case of the more general problem of trust establishment for information furnished by users on the internet.
The natural approach to this general problem of trust establishment is to break up the problem into component parts:
- Who can provide trust.
- How do you ensure automated processing of the transmitted trust.
- How do you facilitate the transmission of trust in a manner that compromises neither the security nor the privacy of the user.
Who can provide trust
The heavy handed approach to this problem is to create some elaborate standards based process for deciding which trust entities can provide various types of information. There is obviously merit (mainly regulations) to the heavy handed approach, however this seems like a recipe for complexity that ultimately does not justify its value.The lighter touch approach is for relying parties to decide for themselves what information they'll accept and from whom, ie I won't accept health information from your bank but I'll accept financial information. Over time some pseudo-standard is likely to emerge as consensus forms around these matters.
Our protocol incorporates the use of Asymmetric signatures that makes it easy for relying parties to enforce attribute source restrictions.
Over time we plan on incorporating auditing of trust providers to at least ascertain that their systems are suitable to serve as trusted sources. For instance if an employer has an HR system where a user can change their name, dob and such information without any additional due diligence on the part of the employer then such as system can't be used as a source of trusted information.
How do you ensure automated processing of the transmitted trust.
This is straight forward. First, settle on a data format, we've settled on JSON (and maybe XML). JSON/XML support parsing schemas so that handles the first part of automated processing. Our API support transmission of such schemas.The second component of automated processing is deriving meaning from parsed information, this is perhaps where a standard repository of attribute meaning would be most helpful. A universal meaning-retrieval repo has so far been elusive, many initiatives have come and gone so for the most part it remains an open problem.
We have decided so far to create a data dictionary API to facilitate meaning extraction, though our preference would be to be able to just leverage a standard dictionary such as schema.org.
How do you facilitate the transmission of trust in a manner that compromises neither the security nor the privacy of the user.
This is another problem with a straight forward solution that seems to have eluded current standards. Don't reinvent the wheel, the internet already has a robust solution to address this issue, it is called Transport Layer Security (TLS). Our API is modeled after TLS with the API playing the role of a somewhat trusted man-in-the-middle. Details of our this works is all documented here: https://www.cipheredtrust.com/doc/This post is not meant to start a flame war so I hope no one approaches it as such. I welcome feedback and critic.
Comments
Post a Comment