Open ID in Government

© 2011 Karthik Ethirajan, all rights reserved
Open Identity Solutions for the
Open Government Initiative
Karthik Ethirajan
November 2011

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

3
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

4
Agenda
a) ICAM LOA 1 Trust Framework
b) NIST Levels of Assurance
c) Privacy Principles
d) Government Benefits
7. NIH Use Case

5
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

6
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

7
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

8
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

9
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

10
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

11
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

12
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

13
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

14
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

15
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

16
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

17
OpenID Process Flow

18
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

19
IMI Process Flow

20
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

21
SAML Process Flow

22
Agenda
a) IdP Certification Process
b) Kantara Service Assessment Criteria
c) OIX Assessment Package
d) Approved Certification Houses
7. NIH Use Case

23
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

24
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.

25
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.

26
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

27
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

28
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

29
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

30
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

31
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

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

33
Identity Provider Login Screen
Relying Party (NCBI) redirects user to Identity Provider (Google or PayPal) login
screen
NIH Use Case
PayPal LoginGoogle Login
Links to Privacy Policy
and User Agreement

34
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

35
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

36
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

More Related Content

What's hot

Viewers also liked

Similar to Open ID in Government

More from Karthik Ethirajan

Open ID in Government