Trust Framework System Rules - Business, Legal, Technical
Session Topic: Trust Framework System Rules (TH3F)
Convener: Dazza Greenwood (@dazzagreenwood)
Notes-taker(s): Eve Maler (@xmlgrrl) and Jamie Clark (@JamieXML)
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:
Resources under discussion are generally available at: http://civics.com/
What's the definition of a trust framework? Does it have boundary conditions? Is it a "club with rules"? The rules seem to have business, legal, and technical aspects. Could the boundaries be set dynamically? Perhaps, but it seems odd to include someone in the club without their knowing it.
Accounting for the regulatory aspects of trust frameworks is challenging. Better to just consider all "contractual" elements? Trust framework system rules are multilateral agreements. That set of contractual elements are not literally regulatory. Private parties get together and define a boundary for their "bubble".
Does such an agreement have to be legally enforceable? Are a bunch of tennis partners that expect each other to take turns buying the beer afterwards could be described as being (lightly) bound by a trust framework. But generally, what's at stake has high value in the aggregate, so enforcement -- whether legal or getting kicked out of the club -- is a part of the expectations.
For today's discussion, we're talking about explicit, written, agreements that involve business, legal (ideally enforceable), and technical elements. There are elements of verification, duties, and so on. Precedents: payment systems (e.g. ACH), supply chains (e.g. EDI), credit cards (e.g. VISA), and identity federations (e.g. InCommon)
People tend get lightly bounded when they visit a site through at least click-through ToS agreements or similar. Other ways of entering a trust framework are typically more tightly bounded. An important component of rules is exception rules, or "error trapping".
The Technical super-section of the sample Table of Contents starts with use cases, to capture the scope. The Legal super-section might include legal criteria for participation, so that (e.g.) for a insurance industry framework, shoe sellers wouldn't be eligible. Standardized liability statements aren't really available; they tend to be quite specific to the circumstances.
Dazza will soon publish his recent work on the insurance industry trust framework that he showed today. See other samples at: http://civics.com/idfederation-framework/
Trust frameworks have to emit pheromones that say "come play", so that they'll survive.
How do parties know what trust frameworks they should be joining? Right now, there are a bunch of efforts that aren't really ready to be joined yet. How to translate the credit card model to identity? OIX et al. are creating tools around this, but for right now, you'd probably know about them because they're idiosyncratic to your community. The trust mark aspect of the TOC shows a way that trust frameworks could be branded. This typically involves certification so that you can use the mark. Think of UL listing: http://www.ul.com/global/eng/pages/ In the future, maybe we'll see "OIX Listed" sites.
Cisco connects to 400 providers. It's painful to set each of these up. The use cases include both B2B and SaaS connections.
A lot of the TOC comes from or is inspired by the "PKI days". The supposed openness of those early projects actually added friction because people weren't sure if they were or should be considered within the boundaries. So the more bounded frameworks have worked better since. This is why business use cases are the starting point for filling out the TOC. There's an ROI for each potential member; some may choose not to join, or not to join now. The whole point of the multilateral agreement is scalability; this is a big part of the value.
Dazza is working with Jamie and OASIS to standardize this TOC approach. Operating rules/system rules are a persistent phenomenon. If you don't have rules like this, you basically can't "federate" (= operate under some set of rules).
Historically, forming the framework has been a matter for deep experts only, and it's had trouble scaling because the work product looks like it. :-) The current rules would "gag a yak" :-), and thus don't scale to the consumer market.
Typically it's "RPs" (parties who need to be assured that others' interests will sufficiently align with theirs) who get together and become the policymakers that create the rules. See: http://openidentityexchange.org/sites/default/files/the-open-identity-trust-framework-model-2010-03.pdf
Perhaps what we'll see is some successive approximation over time, a la open source licenses. Interoperability starts to become a well-known best practice.
What about the VRM fourth-party type of discussion? And what about other use cases that don't strictly use the IdP/RP/user triangle? Does the system rules model sale to n parties? Yes; you can define as many roles as you want. A party might be in more than one role, so you may have to consider interlocking duties.
"User-centric" frameworks are new, but Dazza had an opportunity to work on a research project that was related to veterans returning from war and using an Android app that behaviorally predicts PTSD etc. What do you with highly sensitive mobile, personal, and military data? The advice he got was to take the veteran's point of view in doing the system rules. This has a strong personal datastore aspect. Here's an example: http://civics.com/pd-tf-sysrules/
Some other trust frameworks Dazza has known and loved before: http://civics.com/trust-frameworks/
Dazza is starting to share some standard clauses between these projects and XACML and SOA system rules. These are shaping up to look a bit like the UMA Trust Model rules: http://kantarainitiative.org/confluence/display/uma/UMA+Trust+Model
Starting with the assumption that the individual owns their personal data and in full control of whom they share it with is often the best way to proceed. This is the operating assumption in healthcare records too.
Nailing down copyright licensing is a good backstop if other things go wrong, but the tactics need more work.
Join the OASIS TC discussion list and visit civics.com to continue the discussion! They're working on the TC charter proposal now, and is looking for proposers. They plan to launch in June.
