Technologies and Tokens Used
in the Identity Ecosystem
  Bryan Ichikawa
  Senior Manager
  Deloitte & Touche LLP
  Myisha Frazier-McElveen
  Manager
  Deloitte & Touche LLP
Agenda
 The Identity Ecosystem
 Levels of Assurance
 Technology Types
 Step-up Authentication
 Use Cases
 Conclusion
The Identity Ecosystem - Overview
The Identity Ecosystem contains of multiple stakeholders
representing different user groups and different policy
and technical needs
  Risk-based approach toward
identity yields a mixed
environment aggregated by
common interests.
  Communities of Interest (COI)
can vary in needs from requiring
very little to very high confidence
in the asserted identity.
  COIs can cross typical market
segmentation (e.g., commercial
vs. public sector).
  Transactions can cross COI
assuming common risk profile.
Levels of Assurance – What does this mean
for a Relying party
Relying Parties (RP) need understand the implications of a
false positive authentication given their specific business
process
Level 1 – Little or no confidence in
the asserted identity’s validity
Level 2 – Some confidence in the
asserted identity’s validity
Level 3 – High confidence in the
asserted identity’s validity
Level 4 – Very high confidence in
the asserted identity’s validity
– OMB M-04-04, E-Authentication Guidance for Federal Agencies.
Levels of Assurance – Technology
Types
Variety of token types and identity proofing requirements
allow for customization of deployment based on RP and
customer requirements.
Level 1 – Password or PIN
Level 2* – Memorized Secret Token
(Password or PIN), Pre-Registered
Knowledge (favorite color), Look-up
Secret Tokens (grid card), Out of Band
Tokens (text message), and Single
Factor One-Time Password (OTP)
Devices (hardware OTP generator)
Level 3* – Multi-factor requirement.
Software crypto allowed
Level 4* – Hard crypto tokens with FIPS
140-2 L2 (physical security at L3)
validated
* – Identity Proofing Requirement
– NIST SP 800-63
Step-up Authentication
RPs need to balance competing needs: technology,
policy, and implementation realities.
  Compensating Controls
  Outside of System
  Example – Requiring additional identification prior to issuance
of a service to verify the identity of the user.
  Within System
  Example – Secondary approval prior to completion of a
transaction.
 Step up Authentication
  Why would they be used
  Example – Additional credentials requested prior to completion of a
transaction.
Use Case - OpenID
  OpenID is an open source community and a legal
entity
  Provides simplicity and control of shared
information by end users
  Provides relying party authentication capabilities,
accepting third party credentials
  OpenID is an example of a Level 1 credential
Use Case – Consumer Step-up
  Public access to web site requires no assurance, for
individuals or the site.
  Access to an individual’s account requires a level of
assurance from both the individual and the site.
  Customer enters user id
  Bank replies with authentication graphic and
(previously supplied) user phrase
  Customer replies with password
  Large Value transaction requires additional factor
(OTP)
Use Case – Consumer Step-up
Bank’s mutual authentication
sent after user id is entered
Account password entered after
both parties are authenticated
Use Case – Consumer Step-up
********
Use Case – National Strategy for
Trusted Identities in Cyberspace
(NSTIC) Pilots
  Round 1 saw five pilots with varying objectives
  Strong focus on Trust Frameworks
  Common challenges with lack of:
  Consistent policies
  Consistent procedures
  Common levels of assurance (LOA) risk mitigation
strategies
  Harmonized standards
  Equivalency of token types
  Tremendous learning and movement of the concepts
that are the Identity Ecosystem
Conclusion
 There is an increasing recognition for the need of
strong(er) credentials
 Individuals and organizations understand the
convenience associated with utilizing credentials
issued by different entities
 Understanding for different LOA is growing
 There is not a “one size fits all” approach
 There exists a wide range of token technologies,
both in-use and planned, that will enable stronger
authentication across LOAs
Bryan Ichikawa
Myisha Frasier-McElveen
[email protected]
[email protected]
 Smart Card Alliance
 191 Clarksville Rd. · Princeton Junction, NJ 08550 · (800) 556-6828
 www.smartcardalliance.org
This presentation contains general information only and Deloitte is not, by means of this presentation, rendering accounting,
business, financial, investment, legal, tax, or other professional advice or services. This presentation is not a substitute for such
professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before
making any decision or taking any action that may affect your business, you should consult a qualified professional advisor.
Deloitte shall not be responsible for any loss sustained by any person who relies on this presentation
.
About Deloitte
Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of
member firms, each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed
description of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see www.deloitte.com/us/about
for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest
clients under the rules and regulations of public accounting.