Liability for ldps, APs, RPs... Continued

From IIW

Issue/Topic: Liability for Idps, APs, RPs… Continued (F1D)

Conference: IIW-East September 9-10, 2010 in Washington DC Complete Set of Notes

Convener: Brian Kelly <>

Notes-taker(s): Myisha Frazier-McElveen <>

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:

We grabbed a larger room this morning to continue our discussion on liability and financial models for IdPs and RPs. We were fortunate to have a number of lawyers joining the conversation as we all learned about how to get to the root of solving the liability issue. Scott David (K+L Gates) took us all through a whirlwind applied law lesson that was very helpful in giving this mixed audience a new way of thinking about the real legal problems.

Session Highlights

  • The American Bar Association (ABA) has started a workgroup that is addressing Liability issues (Led by Tom Smedinghoff)
    • Scott David wrote a draft document to help define how to think about the duties of the various parties (IdP, RP, User, 4th party–AP) in the identity ecosystem so that we can accomplish the goal:
    • Curb discretion to make the entire system more reliable and more interoperable.

(“program people” to act in the best way that benefits everyone in the system.)

    • The biggest risks are on the edge of the system. E.g. Credit Card companies put a $50 liability on the consumers on the edges.
    • Tools & Rules: It’s a 50/50 split to have a successful system.
  • ABA draft materials
    • Similar to the terms sheet but a three way agreements
      • The agreements are not bi-lateral but rather multi party in nature.
    • Find the low hanging fruit of duties to standardize in a legal spec. Defining the duties of each party in the system is the key place to start.
      • Level Of Assurance (LoA) – Based on NIST SP 800-63 and OMB M-04-04 (1-4)
      • Level Of Protection (LoP) – Third party data theft (e.g. leaky pipes) – Protection of data (e.g. HIPAA)
        • Where this falls on the four parties is TBD
        • Identifying duties associated with preventing third parties from getting access to the data is currently being defined.
        • Data duty: transfer of data, holding of data
      • Level Of Control (LoC) – Provides protection for 1st party unauthorized use.
      • Use fair information practice principles (FIPPs)
  • There are different sets of duties for different trust communities.
  • Source of duties: Law, Contracts
  • Start with background law and work to achieve contract law.
  • The Trust Frameworks fill in the gaps from the duties identified from the legal spec.
    • Creating the legal spec floor upon which trust frameworks can build based on specific requirements of each trust framework.
    • Attribute Providers would fall under the scope of the trust frameworks as part of the gaps from the duties.
  • The goal is to curb human discretion to increase reliability and interoperability.
  • Other terms: causation, duty, breach, damage

Notes from earlier in the session

  • NSTIC references that liability needs to be addressed potentially utilizing insurance to mitigate the liability issue – but doesn’t go any further than that (today).
  • Is the FDIC Model for liability applicable to identity?
    • Would Trust Framework Providers put the money into the identity FDIC
    • Utilizing this model includes and underlying assumption that there is government regulation over the identity space (as what is done in the financial space).
    • This model may not be able to deal with redress for end user
      • If the IDP goes down (like with a bank) how do you deal with the end users loss
      • Model may be good for catastrophic system failure but not good for individual end user re-dress
  • Issues that could arise
    • Data breach
    • ID provider hands out misleading attributes
    • ID Theft
    • Liability of a relying party transferring information outside the transaction
    • RP reveals information to the wrong end user.
  • Claimed ID Portability
    • What happens if an IDP goes down:
      • How portable are those identities?
      • Or should they even be portable?
  • In order to address liability, we need to examine each entity in the transaction and understand their drivers.
  • Liability – a duty that’s breached, with causation and damage.
    • What do we want these systems to do?
    • What do we want to have happen?
    • Identify the duty
    • How was the duty breached?
    • Who caused it?
    • What are the damages?
    • Liability is the end result.
  • Are there other models that would work?
    • E.g. No Fault Auto Insurance