A Periodic Table of Trust Elements – Building Real Trust Frameworks from the Bottom Up

Session Topic: A Periodic Table of Trust Elements - Building Real Trust Frameworks from the Bottom Up

Tuesday 2D

Convener: Ken J K

Notes-taker(s): William Lowe

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

Basic overview: this session highlighted the lessons learned by InCommon during their 10 year plus experience operating a federation of autonomous IdP’s and SP’s. Based on this experience, Ken formulated a periodical table that identified common considerations for those interested in creating and operating their own federation.

Goal: start a conversation that could help create a standard framework for creating and operating a federation of autonomous industry participants.

Goal: determine a framework for the creation of federations that enables 'fire retardant federation operators'. (i.e. make it as simple as possible to create and operate a federation in order to reduce common mistakes)

Terminology: Trust frameworks or marks are bad terminology because they're often misconstrued. But, based on experience, we understand trust elements that can be used, in concert, to create frameworks and marks.

Background: InCommon runs a full mesh federation, as opposed to a hub-and-spoke federation, meaning each federation participant manages it’s own Identity Provider (IdP).

InCommon Federation projected to include 20,000 IdP’s within the next few years.

Federations consist of tools and rules. Rules can be subject to legal enforcement based on privacy laws within the federations region.

There are federation operators and federation participants. Federation operators need to set the federation schema.

National Information Exchange Model (NIEM) is the largest federation in world. For a list of Shibboleth Federations, scroll to the bottom of: http://en.wikipedia.org/wiki/Shibboleth_(Internet2)

Referring to the periodic table diagram presented:

• Rows of the table reflect layers of scale in the ecosystem
• Rows include federation operators elements, operator to member elements, member to member elements, attribute authority elements, end user elements.

Federation operators need to set rules for: eligibility, termination dispute resolution, identity vetting.

Other possible considerations for federation operators: audit applications for minimal attribute disclosure, compliance with European privacy laws, etc.

End user privacy still needs work. Added tools for individual control of managing privacy is on the horizon. InCommon hopes that in 2 years all institutions in the federation will provide their users tools for better management of PII.

Why? Because nobody really understands exactly what "downstream" dissemination of user data means. Where does it go? More importantly, what can you do with my data?

Some technical considerations...

Schema needs unique bindings. For example, kids need binding to parent and teachers.

If you asked if somebody is a student, do you assert that the individual is a student because InCommon said so? No. Each institution validates their own people.

What about correlation? Non correlatable identifiers are best option for ensuring anonymity.

Signed assertions. Syntax is normative. Rough semantics for commonality of meaning.

• Attributes are provided by the gateway.
• How do we set a standard for federation creation regardless of industry?
• Biggest change for federations from industry to industry is schema. Single most non generalizable aspect.

Dynamic metadata requires commonality of policy.

Why federations? Federations normalize us for behavior, which is the only way to achieve scale.

Possible next steps:

• Step1: Find new elements in the wetware.
• Step2: Find complementary trust marks to create comprehensive trust framework