Relying Party Assurance IOP Insurance Etc…

Session Topic: Relying Party Assurance

Wednesday 1D

Convener: Ben Wilson

Notes-taker(s): Ben Wilson

Not all identity solutions are created equal and trust frameworks vary from community to community. A free web mail or social network account has a low threshold to obtain.

The value of an identity credential/solution depends on factors such as the number and quality of associated claims and subject attributes and the overall security of the solution. As a generalized illustration, a credential maintained using a stronger password policy is more valuable to a third party than one with a week one.

Vetting process to issue credential, what proof goes into it. How do we elevate low assurance credentials to higher levels? One way is to go back to the local communities where face-to-face interactions occur and interject human involvement in the creation / upgrading of these identities.

The market for identity solutions is comprised of multiple submarkets of identity tokens, attributes, and claims. A credential issuer able to assert claims of “country of residence” and “age over 13” might augment its credential by acquiring additional claims from a third party. That relationship will require a contract or other legal memorandum setting forth the strength of the assertion, liability, etc. Embedded in such relationship will be enforcement mechanisms to help ensure the accuracy of the claims made.

Information sharing can be limited by scope, subject matter, permitted use, etc. For example, the claim/attribute provider could say, “I provide this information with the express restriction that it be used only for the patient’s health and secured in accordance with HIPAA/HITECH.”

The claim/attribute provider might say, “I take no liability” or “I back each assertion with maximum liability of $1.” This is where insurance backing might come in. For information security or contractual liability reasons (insurance-backed warranty), each solution provider (and each contracting partner, relying party, business, consumer/subject) might want to ensure that the total potential liability is covered. Insurance companies have the best experience in the area of evaluating these types of risks. Trust frameworks need to also be aware of and/or educated about contractual liabilities and risks.

One postulate of economics is that markets operate more efficiently when there is better information available for all parties involved. “Information” includes each party’s

understanding of the rules and risks of the market and the products involved. A relying party (service/resource provider) in the market for an identity-attribute solution needs to know what each service provides.

The relying party / service provider / attribute consumer might only need to purchase the solution once. After that, it has a relationship with the subject, and a trust relationship can build upon that initial enrollment. If a third party identity credential is used, then if the credential is compromised or if required by token management processes, the solution might need to be consulted again for re-enrollment.

Inter-Framework Relationships

Each trust framework evolves with its own social contexts, underlying assumptions, frames of reference, liability rules, contracts, enforcement mechanisms, etc. These will all need reconciliation. The federated credential market needs common rules for levels of assurance and

A cross-framework legal model requires a common vocabulary and frames of reference. The legal document will likely contain certain boilerplate that both sides can agree upon relatively easily. The difficult work will be in creating a framework-to-framework comparison/cross-walk/gap analysis. One side may be asked to change parts of its model / policy / rules for better interoperability. Equivalencies will have to be agreed upon by both sides. Cross-trust between 2 frameworks requires at least 4 trust decisions—(1) does TFa trust identities/attributes/claims asserted in TFb; (2) does TFb trust identities/ attributes/claims asserted TFa?; (3) does TFa trust the permitted uses of information within TFb?; and (4) does TFb trust the permitted uses of information within TFa?

Some frameworks are likely to be inherently incompatible.

Work going on in Refeds and OIX might be helpful and/or important.