open id in government

© 2011 Karthik Ethirajan, all rights reserved

Open Identity Solutions for the

Open Government Initiative Karthik Ethirajan November 2011

© 2011 Karthik Ethirajan, all rights reserved 2

Agenda

1. Executive Overview

2. ICAM Trust Framework

3. The Open Government Initiative

4. Government Approved Technology Schemes

5. ICAM Certification Process

6. Recommended Approach for IdM Provider

7. NIH Use Case


Executive Overview

Government is buying into the vision of IDM ICAM Trust Framework was drafted by public-private partnership to help government adopt

commercially available IDM solutions

ICAM defines the stakeholders and establishes processes for evaluating new technologies. It also ties together NIST guidelines for e-Authentication and privacy principles from industry Trust Models

The Open Government initiative issues a new mandate Federal CIO office stipulates a 3-year period to implement federated identity for federal agency

websites requiring the lowest Assurance Level (LOA 1)

The initial set of technologies, identity providers and certifications houses have been approved

Government includes industry standard technology options ICAM approved technology options are OpenID, SAML and IMI

A federal profile has been created for each technology to serve the particular requirements of ICAM

The foundations for Open Identity will oversee certification Many founding members of Open Identity industry standards are the drivers behind ICAM

ICAM provides IdM provider a clear channel to break into Government space Furthers IdM provider’s goal to be a major player in federated identity

IdM provider and ICAM policies are well aligned

Does not require major technology upgrades to become ICAM certified


Agenda



a) ICAM LOA 1 Trust Framework

b) NIST Levels of Assurance

c) Privacy Principles

d) Government Benefits





7. NIH Use Case


Adoption of Privacy Principles

Opt in, notification, tracking, minimalism, others

Adoption of Assurance Levels

Allows government to adopt assurance levels stipulated by NIST (e-Authentication Guidelines, pub. SP 800-63)

Adoption of Open Identity

ICAM LOA 1 Trust Framework

ICAM Trust Framework

The government adopts a trust framework to evaluate Open Identity standards and providers, and implement them in agency websites

GSA ICAM

OIX Kantara

Google Equifax PayPal

NIH NLM LOC

Allows government to adopt industry standards and COTS technology schemes

Fosters public-private partnership

More information at IDManagement.gov

http://idmanagement.gov/


NIST Levels of Assurance


NIST has defined 4 Levels of Assurance (LOA) in providing technical guidance to federal agencies wishing to adopt federated identity. Level 4 is the most stringent and Level 1 is the least.

Allowed Token Types LOA 1 LOA 2 LOA 3 LOA 4

Passwords & PINs

Soft crypto token

OTP device

Hard crypto token

Potential Impact to Agency Resulting from Authentication Errors

LOA 1 LOA 2 LOA 3 LOA 4

Inconvenience, distress or damage to standing or reputation

Low Mod Mod High

Financial loss or agency liability Low Mod Mod High

Harm to agency programs or public interest

NA Low Mod High

Unauthorized release of personal information

NA Low Mod High

Personal Safety NA NA Low Mod/High

Civil or criminal violations NA Low Mod High

NIST technical requirements cover areas such as:

• Identity Proofing

• Registration

• Tokens

• Authentication Protocols


Privacy Principles


The ICAM Trust Framework encompasses the following privacy principles

Privacy Principles Description

Opt In Identity Provider (IdP) must provide end users attribute-level consent before transmitting user data to Relying Party (RP)

Minimalism IdP must transmit only those attributes that are explicitly requested by RP application or Federal Profile

Activity Tracking IdP cannot disclose user activities on RP websites to third party or use the information for any purpose other than federated authentication

Adequate Notice IdP must provide end users adequate notice regarding federated authentication. It should be incorporated into the Opt In process.

Non Compulsory Federated access must be supplemented by an alternative access that does not require sharing of PII with commercial IdP

Termination In the even an IdP ceases to provide service, the IdP shall continue to protect any sensitive data including PII


Government Benefits

Identity Federation saves cost Maintaining a separate identity and access

management solutions is expensive

Customer service support needs and costs increase

Simplifies user access & drives traffic Value proposition of IDM for consolidation of

user accounts is well understood

Better data sharing between websites Improved interoperability across multiple

government agency websites

Secure access & protection of user data Certification process ensures adequate

protection for websites requiring different levels of assurance

User data is securely held by one identity provider

A small business of 500 employees spends approximately $110,000 per year on password management. That’s $220 per user per year. Source: RSA working paper CLHC WP 2004

One federal agency with 44,000 users discovered over 700,000 user accounts, with the average user having 16 individual accounts. Source: U.S. Government survey, December 2007

Use of single sign-on technologies can reduce annual sign-in time by 50 hours/user/year. Source: The Burton Group, August 2004

Implementation of strong credentials across the Department of Defense resulted in a 46% reduction in intrusions. Source: Lt Gen Charles Croom , August 2007


By leveraging Open Identity standards in agency websites, government can realize several benefits including cost savings, wider adoption and improved security


Agenda




a) The New Government Mandate

b) Government Agencies Included in the Mandate

c) ICAM Approved Identity Ecosystem

d) Approval Details for Providers & Technologies

e) Timeline for Site Upgrade




7. NIH Use Case


Government Agencies Included in the Mandate

The OMB is planning to communicate the memorandum from the Federal CIO to government agencies and has several meetings scheduled

The Open Government Initiative


The New Government Mandate


Government is mandating the use of federated credentials Federal CIO has mandated in a memorandum on Oct 6, 2011 that all government

agencies start accepting federated identity from well-known providers

The initial players in the government ecosystem approved ICAM has approved a number of technologies, identity providers and certification

houses for the federal agencies to choose from to comply with the mandate

Implementation guidelines for federal agency websites Agencies have 3 years to complete upgrading their LOA 1 websites to accept

externally-issued identity credentials as per ICAM Trust Framework

Upgrade of higher assurance level websites are optional

Possible Penalty for non-compliance Government may withhold funding to agencies if they fail to comply with the

mandate from OMB

Pilot project with NIH show cases cost-savings NIH started accepting federated identity starting June 2010

Estimated cost-savings of $2.98 million across 50 NIH websites from 2011-15


ICAM Approved Identity Ecosystem

Trust Framework Providers

Identity Providers

Identity Schemes

Certification Process

~ 9 months

1. Kantara Initiative 2. Open Identity Exchange (OIX) 3. InCommon Federation

1. Identity Management Interoperability (IMI)

2. OpenID 3. SAML

1. Google 2. PayPal 3. Equifax 4. VeriSign 5. Wave Systems

Trust Framework Providers are the certification houses approved by government to certify a federated identity provider

Identity Schemes are technologies approved to deliver a federated identity to a government website

Identity Providers enable federated digital identity for users, including authentication, authorization and data attribution


ICAM approved an initial set of providers and technologies for the federal agencies to choose from in order to comply with the government mandate


Approval Details for Providers & Technologies

Trust Framework

Provider

Level of Assurance

Approval Status

Kantara Initiative

Levels 1, 2, and non-PKI 3

Approved

Open ID Exchange (OIX)

Level 1 Provisional

InCommon Federation

Level 1, 2 Provisional

Identity Provider Identity Scheme Level of Assurance

Equifax IMI 1.0 Level 1

Google OpenID 2.0 Level 1

Paypal OpenID 2.0 Level 1

Paypal IMI 1.0 Level 1

Verisign OpenID 2.0 Level 1

Wave Systems OpenID 2.0 Level 1

Note: OIX anticipated to receive certification for Levels 1,2, non –PKI 3 in fall of 2011.


Identity Scheme

Federal Profile

Level of Assurance

OpenID 2.0 Level 1

SAML 2.0 Web Browser SSO

Levels 1, 2, non-PKI 3, 4

IMI 1.0 Levels 1, 2, non-PKI 3


Timeline for Site Upgrade

90 Days 3 Years

Trust framework providers are approved

Government agencies have 90 days to plan to incorporate federated identity

Government agencies are to begin the project

Government agencies complete the project

Assurance Level 1 websites of government agencies can now start accepting federated credentials

Credentials with Higher levels of assurance will also be accepted

Agency’s own identity credentials might also be accepted

Federal agencies have 3 years to complete upgrading their LOA 1 websites to start accepting externally-issued identity credentials as per ICAM Trust Framework



Agenda





a) OpenID 2.0 Profile

b) IMI 1.0 Profile

c) SAML 2.0 Web Browser SSO Profile

5. Government Approved Certification Process


7. NIH Use Case


ICAM OpenID 2.0 Profile

Profile based on OpenID 2.0

Requires SSL/TLS on all endpoints

Requires Directed Identity Approach

Requires pair-wise unique pseudonymous identifiers (e.g. ip)

Requires short-lived association handles

OpenID Specification

Open Source roots

OpenID Foundation serves as steward and provides necessary infrastructure

Used/supported by JanRain, SixApart, Google, Yahoo, Facebook, AOL, MySpace, Novell, Sun, etc.

1 billion+ OpenID-enabled accounts

40,000+ web sites support OpenID

Federal Profile

Government Approved Technology Schemes


OpenID Process Flow



ICAM IMI 1.0 Profile

Profile of Identity Metasystem Interoperability Document 1.0 (IMI)

Requires encryption of PII (SSL/TLS used on all endpoints)

Requires use of optional Private Personal Identifier(PPID)

Managed cards only (from approved ID Providers)

SAML 1.1 assertion tokens only

IMI Specification

Analogous to the cards you carry in wallet

Open Source & industry standards

Supported by Azigo, CA, Equifax, Google, Intel, Microsoft, Novell, Oracle, Paypal, etc.

Built into MS Vista; option for XP

Earlier stage of adoption than OpenID

Approved for Levels of Assurance 1-3; possibly 4

Federal Profile



IMI Process Flow



ICAM SAML 2.0 Profile

Requires E-Gov (conformance) Profile

SSL v3 /TLS 1.1 or higher MUST be used to protect all endpoints

IdPs and RPs must use FIPS 140 validated crypto modules and algorithms for XML signing and encryption.

IdPs must digitally sign entire SAML assertions.

LOA 2 or higher requires encryption of SAML assertions using XML encryption.

SAML Specification

OASIS SAML 2.0

Based on E-Gov conformance Profile developed through Liberty Alliance (now Kantara)

Broad COTS support

Approved for Levels of Assurance 1-3

Has been used by government before

Federal Profile



SAML Process Flow



Agenda






a) IdP Certification Process

b) Kantara Service Assessment Criteria

c) OIX Assessment Package

d) Approved Certification Houses


7. NIH Use Case


IdP Certification Process

Membership in Trust Framework Provider

Network

•Provides legally binding obligation for IdP to adhere to TFP policies and TF specifications.

•Also requires short approvals process including verification of business information.

House Assessment and Certification

Process

•Based on criteria specified in Trust Framework (TFPAP & ICAM Profile).

•Provides assurance that IdP conforms to basic security and interoperability measures established by IACM.

Publishing of Metadata in

Certification House & ICAM Registries

• Federal Websites are updated regularly with whitelist of ICAM approved IdPs.

•Commercial partners will look to TFP approved IdP list for guidance.

http://openidentityexchange.org/sites/default/files/oix-us-icam-loa1-tfp-assessment-package-November%2008%202011%20V2.pdf

Becoming an accredited IdP for the ICAM initiative is a three step process involving assessment of business and technical capacity. In addition, annual reviews are necessary to ensure compliance and continued approved status.

ICAM Certification Process


Kantara Service Assessment Criteria for LOA 1

Items related to Organizational Maturity

Common Organizational SAC

1. Enterprise and Service Maturity

2. Notices and User Information (T&C and Privacy Policy)

Identity Proofing SAC

1. Policy - unique identity for given service, distinction within IdPs community.

2. Identity Verification - accept self assertion of ID.

3. Remote Public Verification – requires email or phone number.

4. Secondary Verification - request additional measures to deal with anomalous circumstances (e.g. change of address).

Credential Management SAC

1. Part A - Credential Operating Environment

1. Security Controls

2. Storage of Long Term Secrets

2. Part B - Credential Issuing

1. Identity Proofing

2. Credential Creation

Details Identity Proofing Services

Establish Conformity for Credential Lifecycle Mgt.

The SAC establishes a baseline for organizational conformity, identity proofing services, security, and credential strength and management services.



OIX Assessment Package for LOA 1

Organizational Due Diligence of OIX Members

Organizational Maturity

1. Enterprise and Service Maturity

2. Notices and User Information (T&C and Privacy Policy)

Privacy Requirements

1. Opt-in

2. Minimalism

3. Activity Tracking

4. Adequate Notice

5. Non Compulsory

6. Termination

US ICAM Trust Criteria

1. Registration and Issuance

2. Tokens

3. Token and Credential Management

4. Authentication Process

5. Assertions

Privacy Requirements for OIX Members

Conformance to ICAM Security, Credential and Authentication Requirements

The TFP Assessment Package establishes a baseline for organizational conformity, identity proofing services, security, and credential strength and management services.



Approved Certification Houses

InCommon: Approvals Process 1. Submission of domain for approval (must be .edu) 2. InCommon Domain verification

1. Determination of Ownership (ip vs institution) 2. Creation of CNAME record by Institution 3. Verification that CNAME redirects correctly to incommon.org 4. CNAME stored in InCommon CM.

Kantara: Approvals Process 1. Secretariat

1. Checks Application for Completeness 2. Admin (fees paid, Applicant PoC, etc)

2. Approvals Review Board 1. Chairman - Review App Materials 2. Determine evaluation plan with other board members 3. Distribution and evaluation of application package 4. Notify Applicant of anticipated time for decision (typically less than 1 month)

OIX: Approvals Process 1. Assessor: qualified for Trust Framework 2. Assessments: Applicant prepares evidence that it meets 3. trust framework providers requirements at specific level of assurance and or level of

protection. 1. Selects Listed Assessor and negotiates pricing and other terms. 2. Undergoes assessment

4. Registering Listings – After successful assessment, provider submits membership listing form and is subsequently published in the OIX listing service. Approved: LOA 1

Approved: LOA 1,2,3

Approved: LOA 1,2



Agenda







a) IdM Benefits

b) IdM Differentiation as an Identity Provider

c) Steps to Becoming an Open Identity Provider for the Government

7. NIH Use Case


IdM Provider Benefits

Thought Leadership IdM will be perceived as a leader in Federated Identity Management with a

high level of Trust among the likes of Google, VeriSign, PayPal and Equifax

Marketing Benefits IdM logo/login will be displayed on hundreds of government agency websites

further augmenting the trust brand image of IdM

Realizing Open Identity Synergies IdM’s consideration to launch OpenID in commercial space is strengthened by

this new government mandate

The new releases of Open Identity standards (e.g., OpenID Connect and SAML 2.0) will further drive their adoption with both government and commercial entities

Open Identity standards are supported by aggregators such as Gigya and Janrain

Reach beyond Government The government encourages adoption of its Identity Trust Framework by

general online commerce giving IdM an advantage when such non-government websites start following the mandate as well

Recommended Approach for IdM


IdM Differentiation as an Identity Provider

IdM can provide basic IDM functionality plus share verified fields & provide VAS to federal agency websites. The ability to automatically log in on a mobile may further differentiate IdM from other identity providers.

Mobile Login

IdM can offer many value-added services to agencies and consumers including, • Identity verification • Strong authentication • Payments

IdM brand is trusted by millions of consumers, providing a level of assurance unmatched by other IDM providers

IdM subscribers can be automatically logged in to websites using IdM login by virtue of possessing the handset

IdM is a highly differentiated IDM provider to the Government

Trusted Brand

Value-added Services


http://www.google.com/imgres?imgurl=http://www.sellmystuff.com.au/wp-content/uploads/2011/04/selling-online.jpg&imgrefurl=http://www.sellmystuff.com.au/&usg=__Oa0SCMExR_Ql87tvp9ld7wrQm6A=&h=284&w=584&sz=37&hl=en&start=8&zoom=1&tbnid=jhK5m4vSi9s2gM:&tbnh=66&tbnw=135&ei=tuCETp_KNMzgsQKa1Jm6Dw&prev=/search?q=selling+online&um=1&hl=en&sa=N&rls=com.microsoft:*&tbm=isch&um=1&itbs=1

http://www.google.com/imgres?imgurl=http://www.contentsecurity.com.au/images/strong-authentication.jpg&imgrefurl=http://www.contentsecurity.com.au/solutions.php&usg=__ba9u9gKeqZdqxZ_VnU7-Ao2hRLI=&h=146&w=304&sz=16&hl=en&start=11&zoom=1&tbnid=N0HYDdq3L3MbiM:&tbnh=56&tbnw=116&ei=KlKPTrPfMI6NsAKNpKXCAQ&prev=/search?q=strong+authentication&um=1&hl=en&sa=N&rls=com.microsoft:*&tbm=isch&um=1&itbs=1


Steps to Becoming an Open Identity

Provider for the Government

1. Choose ID

2. Choose Technology

3. Choose Certification House

Select Access ID to be used with ICAM Trust Framework, extending its reach beyond Gigya and other commercial websites

Start certification process with SAML in 1Q12 Once OpenID is established for IdM, start

certification process for OpenID immediately

Use OIX to get ICAM certification for LOA 1 and negotiate pricing

Kantara works closely with OIX and is an alternative option

Start discussions for getting LOA 1,2, 3 & 4 certified

ICAM provides IdM a clear channel to break into Government space

Access ID


http://www.google.com/imgres?um=1&hl=en&sa=N&rls=com.microsoft:en-us&biw=1366&bih=663&tbm=isch&tbnid=xQYm0MXj6h_NKM:&imgrefurl=http://lists.oasis-open.org/archives/security-services/200810/msg00043.html&docid=QahekxxILgoseM&imgurl=http://www.oasis-open.org/committees/download.php/29723/draft-saml-logo-03.png&w=1641&h=529&ei=HJq5TvPfMqLCsQLEn5HCCA&zoom=1

//upload.wikimedia.org/wikipedia/en/c/c8/OpenID_logo.svg


Agenda






6. Recommended Approach for IdM

7. NIH Use Case

a) NCBI Login Screen

b) Identity Provider Login Screen

c) User Data Consent Screen

d) User Name Association Screen

e) User Landing Page


NCBI Login Screen NCBI is a NIH web property. It accepts both NCBI login and federated login credentials.

Federated Login

NIH Use Case


Identity Provider Login Screen Relying Party (NCBI) redirects user to Identity Provider (Google or PayPal) login screen

NIH Use Case

PayPal Login Google Login

Links to Privacy Policy and User Agreement


User Data Consent Screen Identity Provider asks for user consent to allow login process to continue and transfer user data to the relying party

NIH Use Case


PayPal notifies user that their email and name will not

be transmitted

Gmail notifies user that their email address will be transmitted

Janrain is the aggregator PayPal is using

Permission for creating offline token


User Name Association Screen Once logged in, Relying Party prompts user to associate email address (if transmitted) with user name, enter a new user name or link with a NCBI account

NIH Use Case


Dynamic verification of availability of username


User Landing Page User landing page shows profile data after first login, and shows preference settings for subsequent logins

NIH Use Case

Welcome Screen for

Subsequent Logins First Time Login

open id in government

Documents