Liberty's Advanced Client Trusted Module

Last week, the Liberty Alliance announced the release of the initial draft of the Advanced Client Technologies (ACT) specification set. I mentioned it as well last week.

One component of the Advanced Client Technologies that may be less than obvious is the Trusted Module (TM). The TM should not be confused with the Trusted Platform Module (TPM) whose specifications have been released by the Trusted Computer Group -- the two modules do very different things, although I expect that some TM implementations will make use of a TPM to enable their trustedness.

The TM doesn't stand out so well since there is no "Trusted Module" specification in the specification set, although there is discussion about the TM in the Advanced Client Technologies Overview. That is, in part, because the TM isn't a service itself (although it does make use of other services such as the IdP service).

However, the TM is one of the more useful components included in the Advanced Client Technologies specs and was driven by a number of valuable (from a personal and a business sense) use cases which called for the following capabilities:

• The TM can act in the name of the (Identity Provider) IdP for SSO and Web Services transaction identity assertions.
• The TM can locally validate user credentials (username/password, smartcard, biometric, etc.) and assert the identity of the user based on the local validation (to the IdP and/or to relying parties (RPs)).
• The TM can perform these tasks when "offline" or otherwise disconnected from the IdP (sometimes out of a choice for privacy reasons).
• The solution must allow for, document, and support a model that does not inadvertently require the creation of a correlation handle for the user's identity across multiple providers. This requires interesting solutions when you take into account that an entity that is likely to be per-user will be participating in signed transactions.

Essentially in this model, the TM is a local beachhead for IdP delegated functionality. The reasons why an IdP might want to support this model include (in no special order, nor intended to be totally inclusive):

• Security - allowing verification of credentials locally, without the need for network transmission nor network storage of the credential verification data decreases the likelihood that such data will be stolen (especially an issue when considering biometric data given that the user typically can't change their biometric data).
• Load distribution - the identity related transactions are distributed out to end-user systems rather than having to rely on a central server for every transaction.
• Privacy - allowing the TM to perform SSO operations reduces the visibility of the IdP into exactly what the user did when since the TM can do so without involving the IdP (assuming, of course, that the IdP has allowed the TM to do so).
• Availability - the user is able to actively assert their identity, even when the IdP is not available (e.g. because of maintenance downtime, connectivity issues, or even remote site access).

All-in-all, this TM provides a substantial package of powerful technology that will improve the overall identity meta-system. I look forward to seeing some of this stuff hit the street.

Tags : identity / liberty / Liberty Alliance / Advanced Client / Trusted Module / delegation / TCG / TPM / TM / privacy