Requirements a solution must meet
We believe that any solution must attempt to meet the following seven requirements:
- A single solution for situations where this problem manifests.
- A lightweight RESTful application level protocol (run on top of HTTP).
- Should not require a new cryptographic protocol; it takes forever to build trust.
- No new types of credentials to get and manage.
- Place as little trust in the user/browser as possible, and ensure there are no changes required to the browser.
- Do not use user authentication as a proxy for B2B authentication.
- Plan for scale, the web apps in mashups might be serving millions of users. Cannot repeat expensive PKI operations each time.
Let us now elaborate our perspective on the requirements any solution to this problem must meet. We believe that the following requirements are critical to the solution:
- Solve it once! We believe that we should solve this problem once at the fabric level, and not in a piecemeal fashion for the various situations in which the absence of a fundamental solution manifests as a problem. This is not a cross-domain XHR, OpenAJAX, OAuth, OpenID, SAML, etc. problem, it is a fundamental Internet security component that is missing in action!
- Solve it at the application level. It will be tempting to find a way to stitch together two TCP level SSL pipes from the browser to the two Web Apps. In fact the solution we have devised can work at the socket level and this can be achieved. However, as applications migrate into clouds where their ‘server address’ will become increasingly irrelevant, we feel the problem should be best solved at the application level.
- Do not trust the browser or the user, or require changes to the browser. It might seem that it is fairly obvious that Web App 2 cannot take the word of the browser on which application directed it to Web App 2. We do not claim this is always avoidable, but minimizing the trust in the user is essential. Further, solutions which require changes to the browser we believe should be avoided as they cannot be used in the near term. The solution has to support existing browsers.
- Don’t use user authentication as a proxy for server authentication. Let us say a man walks into a business, claims he is a lawyer, and shows the business a power of attorney purportedly signed by you. The business will verify your signature of course, but even if it is satisfied you signed it, it is almost inconceivable that the business will allow the man to transact business on your behalf without authenticating him. Take another example: you order your bank to move a certain amount of money to your brokerage. Sure, the bank will authenticate you, but when the money actually moves, the bank and the brokerage will perform B2B authentication (or use a trusted 3rd Party). They will certainly not take your word for who is at the other end of the connection. In the brick and mortar world, almost every business-to-business transaction implicitly or explicitly requires mutual authentication of the businesses, not just the client on behalf of whom the transaction happens. There is little reason to believe that if the transactions are conducted electronically, that end-user authentication (using an easily compromised user ID and password!) will substitute for businesses verifying the identity of the counterparty business. Early emerging mashups tend to fall into this trap and often suggest substituting user-to-business authentication, for business-to-business authentication. We believe they do so because of the absence of this “missing security function”. Rather than “make do” in this fashion, we believe we need to fix the underlying problem.
- No new crypto protocols! We believe that the only good crypto protocol is an old crypto protocol that has stood the test of time. While it is easy to invent a new protocol to solve this problem, it is far better to solve it with a protocol that everyone knows and trusts. For instance, one can imagine starting with XML Digital Signature and XML Encryption and building a protocol that solves our problem, but it will take years before we can build confidence in such a protocol. This is simply a function of how cryptography works; it took several years for instance for all the wrinkles to be worked out in SSL.
- No new trust infrastructures! Perhaps the hardest part of any solution would be to distribute trustworthy credentials to applications. This is a problem of business processes, trust, insurance, indemnity, etc., and it is infinitely preferable to use an existing infrastructure.
- Plan for scale. Finally, we believe that the solution should have built in it the ability to anticipate that in many practical situations the same two web apps will need to repeatedly authenticate each other, but through different users, and have its performance optimized for that situation.