Policy Framework

From IIW
Jump to: navigation, search

Privacy Framework

Session: (TH2L & 3L)

Conference: [1] November 2-4, Mountain View, Complete Notes Page

Convener: Jeff Stollman

Notes-taker(s): Jeff Stollman

Discussion notes:

Attendees: Joni Brennan, Jay Unger, Peter Capek, Alan Zhao, Max Beman

One effective way of creating an identity ecosystem that provides both trust and privacy is through a Trust Framework. The Kantara Initiative has created one of the first trust frameworks which has been certified by the US Federal Government through the Identity, Credential, & Access Management committee (ICAM). Kantara is now garnering support for the development of a Privacy Framework that will document auditable Service Assessment Criteria (SACs) that will allow for the certification of the personal information handling practices of Identity Providers and Relying Parties. The session sought to solicit both ideas and ongoing participants in the Privacy Framework development effort.


Background In the traditional three-party internet transaction model, there are Subjects, Identity Providers (IdPs) and Relying Parties (RPs). To create trust among all three parties, a Trust Framework establishes a three-legged stool that provides (1) Assurance, (2) Protection, and (3) Control.

Assurance is the trust a Relying Party can have in the ability of the Identity Provider to accurately represent the Subject when the Identity Provider assigns an ID to the Subject.

Protection is the ability of the Subject to trust that his personal information is being handled “as advertised” by both the IdP and the RP.

Control is the ability of the Subject to correct errors in the information about him/her as well as the ability specify when and how this information is disseminated. [NOTE: In our discussion we also noted that a fourth part is likely to exist for many transactions: the attribute provider. But we did not digress into this area, reserving it for future discussion.]

The US National Institute of Standards and Technology (NIST) has defined a hierarchy four Levels of Assurance and prescribed information proofing practices necessary to provide increasing levels of assurance for transactions that require them. At Level 1, an identity can be self-asserted for simple transactions such as managing one's Facebook account. Additional assurance is typically required for higher value transactions that might involve the transfer of money or confidential information.

The Kantara Initiative has already created an Identity Assurance Framework (IAF). This Framework describes auditable Service Assessment Criteria (SACs) that can be used to vet an Identity Provider's ability to provide identities at different Levels of Assurance. The IAF establishes these broad rules and also includes profiles that allow for variations as needed to address unique requirements that exist for different trust frameworks (typically defined by either national jurisdiction or industry sector). A profile has been created for the US government's ICAM program. The IAF provides an RP with the necessary level of trust to conduct business at various Levels of Assurance.

Privacy Framework. The next step needed in this process is to create a Privacy Framework that afford Subjects the trust they need in how their personal information will be treated to induce them to use the Trust Framework.

In the session we discussed various issues regarding a Privacy Framework. For example, we discussed whether it is practical to establish Levels of Protection in the same way the the Identity Assurance Framework establishes Levels of Assurance. We also discussed the viability of combining Levels of Control with Levels of Assurance, but the group's initial inclination was to keep these separate.

Next Steps. One of the goals of the discussion was to enlist ongoing contributors to the creation of the Privacy Framework. Several of the participants recognized the criticality and high visibility of this effort and were enthusiastic to participate. Participation will begin via one-hour, bi-weekly telecons to be held every other Thursday at 08:00 Pacific Time to gather the team and layout the work streams.

Others interested in participating or with questions about the effort should contact Jeff Stollman (stollman.j at gmail.com).


Thank you. Jeff