TAS3 Architecture is rather complex so we need to analyze the runtime cost of implementing it. The cost can be divided in six categories
Connection overhead, including TCP handshake and TLS handshake. The latter involves one public key operation on both sides, unless TLS connection cache hit is achieved. Except for the cache hit case, connection overhead is mostly unavoidable given TAS3 Architecture's division of components. Sometimes co-locating several components in same host may allow use of localhost connection to avoid handshake overhead. The TLS overhead may be avoidable in localhost and secure internal network cases. The TCP overhead is very sensitive to latency: usually a precondition for a connection is to resolve a domain name: this means one round trip latency cost. Then actual threeway TCP handshake needs to be performed, causing three round trip latencies. Finally TLS handshake causes at least one more round trip. Therefore the time cost of a connection tends to be minimum of 5 round trip latencies. Higher the latency, more time it takes to process a call and more simultaneous calls are needed to keep up the same through put.
Communication overhead: this consists of compression, encryption (symmetric stream cipher), and transfer of the actual data. Mostly unavoidable. As communication cost and stream cipher tend to be neglible compared to TCP + TLS handshake and digital signatures, we will not consider communication cost in our calculations.
Digital signature overhead: usually at least one public key operation is involved on each side. Often responder side needs to verify several digital signatures: one for the message and one for each token or credential it receives. The signature overhead is mostly unavoidable, though some caching and session techniques may reduce it in case of often repeated actions.
XML overhead: the arcane and poorly designed features, such as namespaces and canonicalization, of XML cause significant processing overhead (not to mention bugs). In some Java implementations of digital signature processing the XML formatting consumes as much CPU as the public key operation. Even in the best of breed implementations XML formatting has significant cost, usually about 20% of the cost of a public key operation. XML cost could be eliminated by choosing a more rational data format.
Authorization cost. Evaluation of rule set will depend heavily on the particular ruleset and its implementation technology. Some rulesets are know to take exponential time to evaluate. Authorization cost is exclusively borne by the PDP components. While a PDP may incur additional cost in validating credentials, this is not taken in account here (but can be accounted as digital signature overhead).
Payload cost. This is the cost of running the actual application and is unavoidable. Since we are trying to measure the overhead cost of TAS3 Architecture, the payload is assumed to be free.
In cost calculations we will use units with overall cost computed as show in following table:
Table 3:Units of cost computation and their RSA equivalence
| Unit | RSA Eq. | Definition |
|---|---|---|
| T | 1.5 | One TLS connection establishment. Not entirely RSA comparable as latency component is involved. |
| t | 0.5 | One TLS connection establishment, with connection cache hit (avoids public key operation) |
| S | 1 | One digital signature generation or validation |
| X | 1 | One XML document parse or canonicalization |
| Z | 0.5 | One ruleset evaluation. |
The cost is unevenly divided among the entities in the TAS3 trust network, but the division depends heavily on whether caching can be utilized. If the usage pattern is isolated single operations, the IdP, discovery, and credential issuance tend to become hotspots because these functions are relied on by many other players in the network. For single operations the TLS cache misses will penalize the system overall.
If the usage pattern is repeat operations, then the bottleneck tends to shift towards responder processing: credentials can be cached, but they still need to be validated every time (some checksum based validation cache may be feasible, but has not been explored yet).
Overall bottlenecks in both cases include audit bus logging, local audit trail (especially if digitally signed), and authorization. In this analysis audit bus is assumed to work by exchanging digitally signed SOAP messages and each exchange to be authorized separately.
To explore the cost we will consider two scenarios.