I'm in the Federation, Policy & Trust Management session. The participants are:

• Moderator: Jim Hurley, VP, Aberdeen
• Khaja Ahmed, Chief Security Architect, Microsoft
• Michael Barrett, VP Internet Strategy, American Express
• Tim Moses, Sr. Director Advanced Security Technology, Entrust

I apologize that I've not kept careful track of who said what in the following. There's some general discussion of policies and trust. Access policies should be:

• Accessible to people and businesses in native languages
• Portable from business strategy through IT operations
• Consistent from human readable to digital instruction and across time and location invariant
• Reliable
• Trusted

Policy is the set of actions that a party is required to take. Trust if confidence that a policy is being followed. For example, in authentication, the policy details the authentication mechanism and parameter values. The trust comes from the identification and authorization procedure and refresh requirements. In a different scenario, the policy might tell to what uses the data may be put, how long it can be retained, entities that may have access, etc and the trust is based on certification.

There are some important questions about policy in a federated space:

• Who sets policy? First-party, third-party, bilateral?
• How is the policy represented? Human readable, machine readable, both?
• At what stage is the policy set? Deploy-time, run-time?
• How flexible is the policy? Take it or leave it, adaptable?

The bad news is that traditional approaches for managing policy and trust are inflexible, slow, and costly. The worse news is that federation makes this worse. This sets the stage for requirements for policies that are machine readability, consistent, support late binding, adaptable, and function in a heterogeneous environment.

A community of trust has four components:

• Governance (operating rules, roles and responsibilities, and legal validity)
• Operations (people and the procedures they follow)
• Technology (software and hardware)
• Viable economic model

A village is a community of trust. Trustworthiness is based on reputation. Strangers have no trust, but over time this changes. eBay is a good example of this kind of trust system. MSN Messenger has provided a community for traders where people rely on the MSN messenger ID being inviolate. Email works very similarly--people trust email addresses and an email address conveys some sense of trust to people who have interacted with it for some time. Villages have a low governance burden. The community manages the trust and it works effectively across national boundaries. Risk management is done by each individual judging the risk/reward for a particular transaction.

Some ideas for reputation system:

• Better formalized reputation system or 'gossip' mechanism in cloud-based systems
• Services that allow a hybrid model (reputation plus authority assertions (village elder)
• Rich, intuitive, "falling off a log" easy desktop tools for credential and attribute management.

Liability flow between companies affects trust. A liability flow occurs when a service provider can sue an identity provider for damages related to problems associated with an identity. False positives occur when someone has access to an account they have no rights to, an automated attack occurs and fools the system into granting an identity that doesn't belong to the attacker, or social engineering attacks. Another problem is authentication strength. Its very difficult to compare two authentication schemes and determine which is stronger (how UID is chosen, how passwords are chosen, how passwords are aged, etc.)

What to do? Ignore the risk--probably not a good idea. Accept the risk--viable and often done. Joining a prep-existing network that's worked some of these problems out--PingID is providing such a network. Utilize the Liberty Alliance Business Guidelines that explore these issues in detail and work out solutions.