Scaling Interoperable

Trust through a

Trustmark Marketplace

Update to the

IDESG Plenary

Georgia Tech Research Institute

June 2014

This work was performed under the following financial assistance award 70NANB13H189 from the U.S. Department of Commerce, National Institute of Standards and Technology

Challenge #1: The “Inter-Federation Problem”

Critical Infrastructure

RP RP RP

IDP IDP AP

Health ISE

RP RP RP

IDP IDP AP

State ISE

RP RP RP

IDP IDP AP

FICAM

RP RP RP

IDP IDP AP

RP RP RP

IDP IDP AP

Challenge #2: All or Nothing Relationship

GFIPM

FICAM

SICAM

PIV-I

SBU/Intel COI

This is more than I need right now!

Prospective NIEF IDP or SP

Challenge #3: Evolving Requirements

Technical Interoperability

Technical Trust & Crypto

COI Attribute Vocabulary

Legal Agreement

Certificate Policy

Audit Policy

End-User Privacy Policy

Membership Lifecycle Policy

Bona Fides Policy

Early Adopter

Our Approach: Componentization and Machine Readability (“Trustmarks”)

ID Trust Framework B

ID Trust Framework A

NIST 800-63 LOA 3

ID Trust Framework C

FICAM SAML SSO

FIPPs OAuth OpenID FIPS 200

Scope of the NSTIC Trustmark Pilot

Trustmark Framework

Normative Trustmark Spec

Normative TD Spec

Normative TIP Spec

Trustmark Policy Template

Trustmark Agreement Template

NIEF Pilot Expanded Pilot

Concept Maturation

Trustmark Concept Presentation

Trustmark Pilot Concept Website

Outreach to IDESG

Outreach to NIEF Membership

Outreach to SICAM Stakeholders

Outreach to Other Stakeholders

Sample TDs, TIPs, and Trustmarks

Comm. Protocol TDs & Trustmarks

Identity LOA TDs & Trustmarks

End-User Privacy TDs & Trustmarks

Security Policy TDs & Trustmarks

Other TDs & Trustmarks

Sample TIPs for NIEF Community

Sample Tools

NIEF Trust Fabric Tools for

Trustmarks

Trustmark Assessment Tool

for Trustmark Providers

TD and TIP Authoring Tools

1 2 3 4

5 6

Issue Trustmarks to Current NIEF Members

Modify Tech Framework, Specs, TDs, TIPs, Policies, Agreements, and Tools as Needed

Identify Trustmark Use Cases

Issue Trustmarks to More IDPs, APs, and RPs via a New Trustmark Provider

Demonstrate Trustmark Use Cases in a Multiple-Trustmark-Provider Marketplace

• Trustmark Website

• https://trustmark.gtri.gatech.edu/

• Launched at January IDESG plenary meeting

• 19 pages, 7 articles, 25 artifacts so far

• Content on site lags behind latest work by 4-6 weeks

• ~500 users, ~900 sessions, ~3k page views since launch

• Subscribe to blog for notification of major site updates

• Briefings to multiple COIs

• NASCIO, Global, PM-ISE, NIEF, others

• IDESG Birds-of-a-Feather Sessions (January & April)

Progress Update: Concept Maturation and Outreach

Trustmark Defining

Organization

Stakeholder Community

Trustmark Definition

Is Represented By

Defines

Trustmark Recipient

Trustmark Relying Parties

Org. 1

Org. 2

End User

Trust Interop Profile

Trustmark A

Trustmark B

Trustmark C

Is Used By

Is Required By

Is Trusted By

Trustmark Provider

Is Required By

Issues

Refresher: The Trustmark Framework

Normative Specs Required

• Framework Artifacts Under Development

• Normative Specs

• Trustmark

• Trustmark Definition (TD)

• Trust Interoperability Profile (TIP)

• Policies and Agreements

• Sample/Template Trustmark Policy

• Sample/Template Trustmark Agreement

• NIEF Trust Fabric Usage Policy

• Trustmark Binding Guidance

• Addresses binding of trustmarks to service endpoints

• Facilitates trust-time and run-time trustmark-based decisions

• Target Completion Date: August 2014

Progress Update: Trustmark Framework Artifacts

• Componentized NIEF and FICAM trust frameworks

• Designed trustmarks for maximum reuse between them

• Developed ~57 trustmark definitions for NIEF Pilot

• Includes many that are broadly applicable to FICAM

• Developed “Notional List of Trustmarks”

• Includes components from NIEF, FICAM, CSDII, et al.

• Mapped to NSTIC guiding principles and derived reqs

• Seeking maximum reuse of trustmarks as applicable

• Abbreviated version is on trustmark website

Progress Update: Component Analysis & Trustmark Definitions

NIEF Trustmark Count 82

Trustmarks Needed for GTRI Pilot 63

FICAM Trustmark Count 41

NIEF/FICAM Trustmark Overlap Count 32

Trustmarks Related to Security & Resilience 52

Trustmarks Related to Privacy 21

Trustmarks Related to Interoperability 48

Trustmarks Related to Cost-Effectiveness & Ease of Use 7

Total Trustmarks Identified (so far) 107

Trustmark Analysis Stats

A Sample Trustmark Definition (Partial Screen Shots of Components)

• Trustmark Assessor Tool

• Web based software tool

• Facilitates the process of trustmark assessment

• Currently at “Version 1 Alpha”; ready for internal GTRI use

• Will be used for GTRI’s trustmark assessments

• Will be released as open source in 2015

• NIEF Trust Fabric Management Tools

• Trust Fabric Registry Mgr. – offers “a la carte” TF downloads

• Supports NIEF’s move from monolithic to a la carte trust fabric

• Trust Fabric Editor – for editing individual TF entities

• Each TF entity contains references to its trustmarks

• Managing many trustmarks per TF entity requires a software tool

Progress Update: Tool Development

Trustmark Assessment Tool Process Flow

Trustmark Assessment Tool

Database

Trustmark Assessment

Tool

FICAM LOA 2 Authn

Process TD

Trustmark Provider

Trustmark Recipient

Trustmark Definitions

1. Load TDs into Assessment Tool

2. Receive request for trustmark from Trustmark Recipient candidate

3. Perform assessment of Trustmark Recipient candidate

4. Store assessment artifacts / evidence in database

5. Issue trustmark to Trustmark Recipient

Sample Screen Shot from Trustmark Assessment Tool

NIEF Trustmark Issuance Process Flow

NIEF Trust Fabric

Registry

NIEF Trustmark Assessment Processes

Trustmark 1

Trustmark 2

Trustmark N

NIEF Trust Fabric Entry

Trustmark 1

Trustmark 2

Trustmark N

Signed by NIEF

NIEF Member Agency

(Trustmark Recipient)

Trustmark Assessment Tool

Trust Fabric Entry Editor

Trust Fabric Registry Manager Tool

NIEF Trustmark Usage Process Flow

NIEF Trust Fabric

Registry

Trustmark Relying Party

1. Query for trust fabric entries with required trustmarks, in accordance with local TIP

Trust Interoperability

Profile

2. Receive matching trust fabric entries

3. Install entries in local product

• Working towards a NIEF “Initial Operating Capability” (IOC) for trustmark issuance and use

• The Details:

• Requires initial Trustmark Framework (specs, policies, etc.)

• Requires initial trustmark assessment capability by NIEF

• Some NIEF IDPs and RPs will participate as trustmark recipients

• Will include: RISS, LA County, Texas DPS, et al.

• Objective: Use trustmarks to facilitate trust between live NIEF participants and system endpoints

• Expected IOC date: Sept 2014

Progress Update: Live Pilots that Use Trustmarks

• Demonstrate issuance of Trustmarks to IDPs/RPs wanting to participate in NIEF but not able to meet all NIEF monolithic requirements

• E.g., Pennsylvania JNET

• Demonstrate issuance of Trustmarks to IDPs/RPs for other LE federations besides NIEF

• E.g., MARIS, CONNECT Consortium

• Demonstrate acceptance of Trustmarks issued by a Trustmark Provider other than NIEF

• E.g., IJIS Institute

• Demonstrate that componentization of FICAM requirements within NIEF TFP can lead to incremental adoption of FICAM requirements over time

• E.g., RISS IDP FICAM gap analysis and incremental adoption roadmap

• Demonstrate issuance of Trustmarks to IDPs/RPs outside of LE community, and use in cross-COI data exchange scenarios

• E.g., Justice / Mental Health / Substance Abuse counselors in Alabama

• Demonstrate reuse of Trustmark Definitions across multiple TFPs and COIs

• E.g., CSDII and NIEF

Beyond the Initial Operating Capability: Objectives for the Next Phase of the Pilot

• We are not alone in thinking about trust framework componentization

• Internet2, AAMVA/CSDII, and others are also interested

• Trust frameworks can be componentized

• But how you componentize it matters

• Proper componentization requires comparison with other frameworks

• Reuse requires careful comparison

• Trustmarks can be helpful in the evolution of trust frameworks

• E.g., FICAM v1 versus FICAM v2 – What is the difference?

Some Lessons Learned So Far

• There is overlap between trust frameworks • E.g., technical specs

• E.g., privacy policy components

• Proper componentization can drive convergence and reuse • But improper componentization has little or no value

• Multiple TDs will exist for each category of requirements • E.g., “interoperability”, “privacy”, “security & resiliency”, etc.

• Necessary based on requirements of existing trust frameworks

• Normative specs are insufficient for achieving wide-scale trust and interoperability • Well-defined trustmark assessment processes are required to

drive convergence

• Otherwise, many trust framework details are subject to interpretation

Some Lessons Learned So Far (2)

• Not all specs are created equal; “good” specs have:

• Rigorously defined conformance criteria

• Little or no optionality

• “MAY”, “SHOULD”, “RECOMMENDED” considered harmful

• Appropriate limitation of scope

• “More is Less”

• A single conformance target

• Rigorously defined assessment criteria

Some Lessons Learned So Far (3)

• Q: “Do trustmarks apply to...?”

• A: “Yes.”

• (We have not yet encountered a concrete requirement to which a trustmark cannot be applied)

• Trustmark adoption will require bridging technologies

• Full implementation requires consideration of the “last mile”

• Separation of “trust time” and “run time” has clear implementation advantages

• E.g., binding of trustmarks to existing SAML service endpoints

• “Trustmark Preprocessing” is necessary for legacy products

• And as of today, w/r/t trustmarks, all products are legacy products

Some Lessons Learned So Far (4)

• Review the trustmark framework

• Is the framework structured properly?

• Who else should review it to help make this determination?

• Review the TDs developed through the pilot

• Do we have the right set of TDs?

• What TDs are missing?

• How well do existing TDs capture requirements from other existing trust frameworks in the ID Ecosystem?

• Facilitate participation by the “right” TDOs

• What group is best suited to maintain each TD over time?

• E.g., NIST, FICAM, industry groups and SDOs, etc.

• Identify specific additional trustmark demo scenarios

How IDESG Can Help

https://trustmark.gtri.gatech.edu

Learn More Here

High-Level Project Plan & Timeline

Q4 2013 Q1 2014 Q2 2014 Q3 2014 Q4 2014 Q1 2015 Q2 2015 Q3 2015

Refine Concept as Needed Develop Concept

Refine Framework as Needed

Refine TDs, Trustmarks, and TIPs as Needed

Develop Trustmark Framework

Develop TDs, Trustmarks, and TIPs

Develop and Refine Sample Trustmark Software Tools

Trustmark Pilot in NIEF

Expanded Trustmark Pilot

Community Outreach

Project Oversight & Reporting

Refine Use Cases & Scenarios as Needed Identify Trustmark Use

Cases & Scenarios

Outreach/Prep for Expanded Pilot

Cross-COI

Demos

• White Paper: “Trustmarks and Privacy”

• Written by GTRI pilot privacy team

(Antón, Blough, Reddick, Swire)

• Currently under review by NSTIC NPO

• Will circulate to IDESG Privacy Coordination Committee

• Goal is to get published in IEEE Security & Privacy

• Privacy Policy Component Analysis

• Developing a “Notional List” of privacy components

• Goal is to identify reusable “atomic” privacy concepts

• Will circulate with NSTIC NPO and IDESG when ready

Progress Update: Trustmark Privacy Analysis

Trustmark Crosswalk with NSTIC Principles and Derived Requirements