Where Have All the Trust Frameworks Gone?

Where have all the Trust Frameworks gone?

Wednesday 8H

Convener(s): Don Thibeau, Andrew Hughes, Bjorn Hjelm

Notes-taker(s): Karyl Fowler (Transmute) & Thomas Berry

Tags for the session - technology discussed/ideas considered:

Trust frameworks, multi-party contracts, relying parties, spectrum of verification

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

1. Notes received from Karyl Flower:

• Primary Use Case explored: Project Verify: telcos (Verizon, TMobile, AT&T, etc.) are considering entering a trust framework with each other.
  • Starting Hypothesis: this type of agreement can only be done with a trust framework
• Starting point for discussion: What is the burning business problem “trust frameworks” solve?
  • Answer: Businesses should implement trust frameworks because they:
    • Are more scalable, multiparty agreements
    • Risk Mitigation
    • Cost (reduction/efficiency/etc.)
    • Brand: Market Differentiator, unlocks new business models/opportunities/unique services, reduces time to market
• Today we have 3 ways to do business/interact:
  • 1 – bilateral contracts
    • most used today but not scalable
  • 2 – Loosely coupled SLAs
    • good when companies want to agree to keep operating at the “status quo” without bilateral/formalized contracts
    • Don’t clearly assign liabilities
  • 3 - Trust Frameworks
    • Multiparty agreements/contracts that specify:
      • Technical standards [compatibility/interoperability]
      • Legal responsibilities and liabilities
        • “we can’t operate efficiently without clear liabilities”
      • Level of performance commitment and accountability
        • Including what can and cannot be done (for example how data can and cannot be used)
      • Risk-based [in most cases]
        • Where do you want the risk?
      • Way more scalable
• In order to enter/establish and implement a trust framework:
  • Companies “must agree on trust attributes, including measures of security, performance guarantees, etc.
    • Includes defining the criteria for what everyone should expect these attributes to be, on what level and how to enforce or certify compliance [with a third party or self-certify as an alternative]
  • Companies also must identify relying parties [like banks in the case of the telco use case]
    • Determine a way to standardize criteria here too
    • Relying parties benefit/are more likely to engage just knowing that a trust framework is in place
• “Trust but Verify” conundrum:
  • “sales talk” often is not or cannot be held accountable for assertions, so how do we reduce the risk that they are not lying (ex telco commits to one level of performance, but sales reps are communicating something else, etc.)
• Auditors ARE attesters:
  • Hey take the risk of public verification of XYZ (e.g. companies complying with a standard or trust framework)
  • They don’t dictate how companies comply – just verify what you are complying with and whether you are compliant
    • Some trust frameworks can help companies standardize how they are complying, like Kantara Trust Framework makes NIST assessment criteria more tangible
• ASSERTION RISK:
  • Companies take this risk in claiming compliance “referential trust”; an auditor verifies this claim
  • Quality assurance is the result
• There are only 7 “web of trust” auditors globally
• Whether a 3rd party [like an auditor] is required to interpret our contract and attest to compliance after signing depends on the levels of risk involved
  • For example, if I require all of my cloud vendors be ISO 2701 compliant, I can check myself [perhaps in the ISO registry] to verify whether they are ISO certified
• Project Verify Trust Framework (TF):

Spectrum of “Trust but Verify”:

• Relying Parties (like banks) want to know that telcos are all complying with the same thing; often RPs dictate acceptable certifications
• Relying Parties (RPs) get these unique things from a trust framework:
  • Risk reduction
  • Unique Services
  • Reduced time to mkt/market defense [depends on other variables too]
  • Reduced costs
• Trust Frameworks can enable/allow for greater participation
• Trust Frameworks can be proof points
• Purchasers have ultimate power to dictate requirements
• Regulations can be [and often are] part of trust frameworks
• Law:
  • Private Law: contracts [live within public]
  • Public Law: regulations
  • Mere compliance with the law isn’t a trust framework

• Group point of debate: what is the longevity of trust frameworks?

****************** *********************** *********************

2. Notes received from Thomas Berry:

Business Trust Framework is trying to solve

If one wants to federate or interoperate with a diverse class of partners

• bi-lateral contract
  • Everyone understands them and uses them every day
• loosely coupled SLA
  • No need for contractual relationship, but provides an understanding/relationship-framework
• trust framework
  • Contractual; multi-party contract
  • Sum of two parts
    • Technical requirements of inter operation
    • Legal responsibilities
      • What are the standards each party must be compatible
      • What are the legal requirements for the business relationship
    • Commentary:
      • Not purely legal

What do you expect the trust attributes to be (that can be used for auditing)?

Examples

• Sovereign foundation is going to have self-assertion to demonstrate compliance
• CA Browser uses a framework for compliance

Is there a way to define the role and expectation in a common way to address security and privacy of data/users in the various sectors a relying party (RP) would operate.

Needs to describe to other relying parties the standards that you intend to meet.

Trust Framework is needed to foster a two-way trust

TF should address what you’re entrusting the party with (accountability of the trust relationship)

Trust, but verify

• Self-certification is an oxymoron; lowest level of risk mitigation
  • Sales talk isn’t necessarily beholden to accountability
• Trusted party needs to take a public statement of compliance
  • Attestation is needed to verify the party is meeting obligations/expectations
• What is the value of the interoperability; auditors are not needed on every aspect
• Trust Framework must have an accreditation program if level of assurance established by trust is necessary to support the trust.

Within the TF here’s what I expect to do and here are the rules

• Instead, just send out the requirements
• Attestation comes in that the requirements map to the parties processes and compliances
• Assessment criteria can be common

Use Case

| |

Shape - - - - - -

| T-mobile | | VZN |

ShapeShape - - -| | - - - 

Verify TF| | |  | BANK (RP) |

||

ShapeShape - - - | | - - - 

| ATT | | Sprint |

Shape - - - - - -

| |

The parties may be operating outside the framework

Trust Framework: Multi-Party Contract

- Trust Framework is contractual [private law that lives within public law]

What are the technical requirements to be a member of the “TF club”?

• all parties agree to be audited for trust-worthiness by independent audit
• Internal auditors are required to meet certain standards
  • Internal auditors can be held liable for not meeting those standards

TF 

• risk mitigation
• $$
• Brand reliability/Market differentiator

RP

• Risk reduction
• Unique services/data coverage
  • Ability to ubiquitously trust in service players
• Time to market
• Cost

Any contract must be legally conforming

• compliance to the law
• Private, public, and regulatory
• The contract will be lawful

Relying Party Compliance/Governance should drive utilization of trust framework