Why (Identity, Privacy, Turst) Frameworks are Failing

Session Topic:Why Frameworks Are Failing

Convener:Jeff Stollman

Notes-taker(s): Jeff Stollman

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Jeff posited that ALL past and current framework efforts – be they identity, privacy, or trust frameworks – have failed to gain traction because they have not identified the fundamental requirements.

The hypothesis presented is that we need to articulate a trust framework meta- model. Identity frameworks and privacy frameworks are merely subsets of this larger meta-model. It was further asserted that the trust framework meta-model describes a “system-of-systems” problem. As such, component sub-systems, such as identity and privacy, cannot be expected to address the entire problem space. Furthermore, as a system-of-systems problem, it is necessary to first articulate the structure of the overall trust framework in order to specify system-of-systems requirements that apply to all component systems.

For example, you can design a space shuttle by itself and come up with a clever design. But the shuttle can’t fulfill its mission without other major systems: command center, launch pad, launch vehicle, etc. If the launch vehicle doesn’t have the thrust to lift the shuttle into orbit, the project will fail. If the launch pad can’t withstand the heat or weight of the launch vehicle, the project will fail. It is necessary to specify the overall requirements and the “interface” trade-offs. Should the launch vehicle be bigger or the shuttle lighter? She the launch pad be stronger of the launch vehicle less demanding?

It was further asserted that most current frameworks have assumed a technical solution before they developed requirements. Accordingly, they never really developed fundamental requirements.

Regarding the trust framework meta-model, Jeff claims that it is not something to be created, it is something to be revealed. The meta-model already exists and is characterized by our behavior. We use it every day – however unconsciously—in making decisions whether or not to engage in a transaction (both live and online). The mission is to articulate the various trust elements that comprise the trust framework.

For example, if Alice seeks to purchase a widget from Bob online, she may need to trust

• that Bob is the authentic Bob that she has chosen to purchase from

• that Bob has access to the widget that she wants

• that Bob will deliver the widget to her once she provides her credit card information

• that her credit card company will approve her transaction

• that her credit card company will be online to approve her transaction promptly

• that her transaction information is not being monitored by unwanted spyware on her device

• that her network connection is secure

• that Bob’s network connection is secure

• that her ISP is not monitoring her transaction data

• that Bob’s ISP is not monitoring her transaction data

• that Bob will treat her personal information according to the terms or his Terms of Service and Privacy policies

• etc.

Similarly, Bob will have his own set of trust elements that need to be satisfied - as will all of the other parties to the transaction: the ISPs, regulators, appropriate legal systems for the jurisdictions involved in the transaction, etc.

Once defined, the meta-model provides several useful capabilities:

1. It allows us to map frameworks to it to determine how complete they are in addressing all of the trust elements needed for a comprehensive trust model.

2. It can serve as test criteria to determine whether specified Service Assessment Criteria effectively address the trust elements determined to be “in scope” by the framework developers.

3. It can be used to define boundaries of the various subsystems (e.g., identity, privacy, notification) of a trust framework and identify any gaps between them.

Rainer Hörbe has begun documenting the various roles involved in the full range of transactions. He has also taken a stab at identifying the various trust relationships among the parties. (See http://cmmls.portalverbund.at) This site also includes some work Rainer has begun to develop sample test criteria to assess whether a framework effectively addresses the requirements of the meta-model.

Jeff has begun identifying the trust elements that comprise these trust relationships.

Trust Framework Categorization v1.xls

A first pass is included in this spreadsheet:

Some definitions are included in slides 3-9 of the attached presentation.

Elements of a Trust Framework v2.ppt

Scott David is establishing an OIX risk wiki web site. This site is not yet available.