An overview of new and existing approaches for Digital Identity including enterprise and customer identity. New blockchain-oriented techniques and where they fit into the IAM landscape.

1. Digital Identity
DISCUSSION AT THE VANCOUVER IAM MEETUP 2017-12-19
ANDREWHUGHES3000@GMAIL.COM @IDIMANDREW
Digital Identity Landscape for Vancouver IAM Meetup by Andrew Hughes is licensed under
a Creative Commons Attribution 4.0 International License.

2. Today’s Topic
 (not blockchain – sorry!)
 What does the IAM/IDM landscape look like?
 Where do new approaches and technologies fit?
 What’s exciting (to me, at least) and evolving to attack long-standing
problems?
2

3. What Organizational Contexts?
 Context is everything
 Identification, authentication, authorization are all relative to a population, a
relationship set, a resource set, authorities, etc.
 A) Internal operations
 Employees, contractors, students, business units, …
 B) External partners
 Vendors, commercial partners, back-office services, supply chain, …
 C) External clients
 Customers, shoppers, social networks, offline-ish, devices/things, …
3

4. What other (non-org) contexts?
 Peer-to-peer (P2P)
 ‘Circle of Trust’ / ‘Web of Trust’
 User Centric
 Anonymous
 Profiling / cookie tracking / marketing segmentation
 Segregated domain (walled gardens, in-game communities)
 Self-Sovereign
 Non-Person Entity, Autonomous agents
4

5. What’s the primary goal of IDM?
 Convert an ‘unknown’ entity into a ‘known’ entity,
then do interesting stuff
 Login / Authenticate to a system
 Physical/logical credentials, authorization/access control, …
 Manage a customer (service) account & deliver services
 Personalize, add info, keep records, …
 Increase the ‘known-ness’ of the entity – increase ‘proof’ of identity
 Get attributes, assertions, evidence from sources to substantiate
 Register, enroll, step-up/’trust elevate’
5

6. What’s the primary goal of IDM?
 Convert an ‘unknown’ entity into a ‘known’ entity,
then do interesting stuff
 Login / Authenticate to a system
 Physical/logical credentials, authorization/access control, …
 Manage a customer (service) account & deliver services
 Could be: hire person, pay them, do productive work, manage, …
 Increase the ‘known-ness’ of the entity – increase ‘proof’ of identity
 Get attributes, assertions, evidence from sources to substantiate
 Register, enroll, step-up/’trust elevate’
6

7. A Simplistic Digital Identity Matrix
Internal External - Partner External - Client
‘Login’
1 4 7
Service Account
2 5 8
ID Verification &
’Entity Binding’ 3 6 9
7

8. A Simplistic Digital Identity Matrix
Internal Notes Tech Standards
1: ‘Login’
• Managed
environment
• Known actors
• Employment
contracts
• Policy is
enforceable
• Active Directory
• LDAP
• Virtual directory
• Privileged account
management
• Multi-factor
authentication
• Federated
authentication
• IDaaS &
Directories
• Lots of them
2: Service Account
3: ID Verification &
‘Entity Binding’
• Hiring process,
background
checks, payroll
• Onboarding
processes
• Long relationship
8

9. A Simplistic Digital Identity Matrix
External - Partner Notes Tech Standards
4: ‘Login’
• Known actors
• Commercial
contracts
• T&C enforceable
• Active Directory
• LDAP
• Virtual directory
• Privileged account
management
• Multi-factor
authentication
• Federated
authentication
• IDaaS &
Directories
• Lots of them5: Service Account
6: ID Verification &
‘Entity Binding’
• Contract specified
• Onboarding
processes
• Prior relationships
9

10. A Simplistic Digital Identity Matrix
External - Client Notes Tech Standards
7: ‘Login’
• Outside the
security domain
• Previously-
unknown actors
• T&C iffy
• Uncontrolled user
behaviour & tech
• Username-
password
• One-time
password (SW|HW)
• SW|HW ‘crypto’
tokens
• PKIs
• Biometric-enabled
devices
• Device
fingerprinting
• Decentralized
Identifiers
• NIST SP 800-63
• ISO 24760
• ISO 29003
• ISO 29115
• OASIS SAML
• IETF OAUTH, JWT,
JOSE, SCIM
• OIDF OpenID
Connect
• FIDO U2F & UAF &
CTAP
• W3C Verifiable
Claims, WebAuthn
• OpenBadges
8: Service Account
9: ID Verification &
‘Entity Binding’
• Self-asserted
evidence
• KBA/KBV (ugh)
• ID Resolution
companies
• Remote attribute
assertions
10

11. Old approaches
 Increase the ‘known-ness’ of the entity – increase ‘proof’ of identity
 Get attributes, assertions, evidence from sources to substantiate
 Old approaches
 Gather ID Evidence at registration only
 Use ‘paper’ credentials as a primary source of evidence
 Weak connection (binding process) between person and issued authentication credential
 Use public, hacked, or guessable data to feed KBA/KBV and (in)security questions
 Rely on service counter staff to be better than machines and fake ID
11

12. A Simplistic Digital Identity Matrix
External - Client Notes Tech Standards
7: ‘Login’
• Outside the
security domain
• Previously-
unknown actors
• T&C iffy
• Uncontrolled user
behaviour & tech
• Username-
password
• One-time
password (SW|HW)
• SW|HW ‘crypto’
tokens
• PKIs
• Biometric-enabled
devices
• Device
fingerprinting
• Decentralized
Identifiers
• NIST SP 800-63 v3
• ISO 24760
• ISO 29003
• ISO 29115
• OASIS SAML
• IETF OAUTH, JWT,
JOSE, SCIM
• OIDF OpenID
Connect
• FIDO U2F & UAF &
CTAP
• W3C Verifiable
Claims, WebAuthn
• OpenBadges
8: Service Account
9: ID Verification &
‘Entity Binding’
• Self-asserted
evidence
• KBA/KBV (ugh)
• ID Resolution
companies
• Remote attribute
assertions
12
Old ways: How to connect/bind
the ‘entity’ to the ‘electronic
record’

13. New techniques
 Increase the ‘known-ness’ of the entity – increase ‘proof’ of identity
 Get attributes, assertions, evidence from sources to substantiate
 New techniques
 Attribute collection and verification over time
 Accept assertions from a large number of authorities and sources
 Risk-based and relationship-based confidence
 Use ‘non-memory’ human indicators to confirm presence and the specific individual
(device fingerprints, behavioural analysis, human gestures)
 Optimize for user experience (passwordless systems, hardware/mobile authenticators,
intrude thoughtfully, better account recovery)
 Don’t trust the humans to spot the fake credentials
13

14. A Simplistic Digital Identity Matrix
External - Client Notes Tech Standards
7: ‘Login’
• Outside the
security domain
• Previously-
unknown actors
• T&C iffy
• Uncontrolled user
behaviour & tech
• Username-
password
• One-time
password (SW|HW)
• SW|HW ‘crypto’
tokens
• PKIs
• Biometric-enabled
devices
• Device
fingerprinting
• Decentralized
Identifiers
• NIST SP 800-63 v3
• ISO 24760
• ISO 29003
• ISO 29115
• OASIS SAML
• IETF OAUTH, JWT,
JOSE, SCIM
• OIDF OpenID
Connect
• FIDO U2F & UAF &
CTAP
• W3C Verifiable
Claims, WebAuthn
• OpenBadges
8: Service Account
9: ID Verification &
‘Entity Binding’
• Self-asserted
evidence
• KBA/KBV (ugh)
• ID Resolution
companies
• Remote attribute
assertions
14
New ways to triangulate on the
‘entity’ and build confidence
over time

15. Problems?
 How does a service provider figure out all the authorities, data sources and
verifiers that pertain to an entity?
 How does a service provider know if data about an entity is ‘good’ or reliable?
 How does an entity keep track of where it’s authorities, data sources and
verifiers are?
 How does an entity shield themselves from correlation and usage profiling?
 Who keeps the private keys private?
 Does anyone actually care who the real person really and truly is? Or is taking
their word for it good enough most of the time?
In other words: should IDM systems be very concerned with identification? Or
mostly authentication and verification? 
15

16. Attribute Data
 Fast evolution of approaches and technologies
 Data is a toxic compound!
 How to decentralize or distribute data to lower risk and overhead?
 Move to a claims-based approach
 Be an originator and authority for the smallest possible data set
 See Open Badges, Blockcerts, Verifiable Claims
16

17. Verifiable Claims
 https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-
fall2017/blob/master/topics-and-advance-readings/verifiable-claims-
primer.md
 Key points
 Issuer does not know when or to whom the Holder presents the claim
 Strategy is to use a browser ‘polyfill’ and the Web Payments pattern to
encourage vendors to build it in
17

18. Blockcerts, Open Badges
 “Learning Machine collaborated with the MIT Media Lab to develop
Blockcerts, an open standard for issuing and verifying credentials on a
blockchain.”
 “The aim behind Blockcerts is to give recipients ownership of their official
records so that they are freed from ongoing dependency on issuing
institutions—or any centralized authority—to verify their own credentials
and achievements.”
 “Blockcerts, a blockchain-based credentialing standard, is architected from
many of the same values that drove the development of Open Badges:
interoperability, portability, and verifiability.”
 https://medium.com/learning-machine-blog/the-time-for-self-sovereign-
identity-is-now-222aab97041b
18

19. Identifiers
 Fast evolution of approaches and technologies
 Turns out that identifiers are (still) the keys to the systems
 Universal identifiers are not great for online connected systems (e.g. email
address or SIN)
 Per-domain identifiers do not readily cross namespace boundaries
 People do not deal with kazillions of identifiers very well
 Public registries and DLT approaches are evolving to enable namespace
discovery and traversal
 See Decentralized Identifiers, Blockstack/Onename
19

20. Decentralized Identifiers
 “Decentralized Identifiers (DIDs) are a new type of identifier intended for
verifiable digital identity that is "self-sovereign", i.e., fully under the control
of an entity and not dependent on a centralized registry, identity provider,
or certificate authority. DIDs resolve to DID Documents. Which typically
contains at least three things. 1) a set of mechanisms that may be used to
authenticate as as a particular DID (e.g. public keys, pseudonymous
biometric templates, etc.). 2) a set of authorization information that
outlines which entities may modify the DID Document. 3) a set of service
endpoints, which may be used to initiate trusted interactions with the
entity.”
 Decentralized ID Foundation:
https://medium.com/decentralized-identity/the-rising-tide-of-
decentralized-identity-2e163e4ec663
20

21. Decentralized Public Key Systems
 This is still the big unsolved issue – how to generate, distribute, manage
and secure key pairs
 Will ‘blockchain wallets’ save the day?
 Will someone develop self-healing key management systems?
 Will a new type of entity arise to do the ‘binding’ of entity to keys better than
Certificate Authorities have done?
 Who will invent ‘keyless’ security systems that take responsibility for
private keys away from the humans?
21

22. Entity Binding & Assurance
 Precise determination of the actual, authentic, ‘real person’ entity is
overrated in most cases
 In particular when it is front-loaded into registration
 This approach tends to grow big data sets that need to be maintained
 Long-lasting services or infrequent accesses defeat the utility of front-loaded
resolution
 Risk-based authentication, delayed identification, real-time techniques, trust
elevation are being used to increase assurance over time that the entity is
correctly identified when needed and to the degree needed
22

23. About me
 Andrew Hughes, CISSP, CISM
 Founder, ITIM Consulting Corp.
 ~ 25 years in IM/IT consulting
 ~ 14 years @ Sierra Systems Victoria; ~ 5 years Independent Analyst
 Working on: digital identity & personal data consortia, international standards,
trust frameworks, peering into the future of digital people and evolving
systems of systems
 KantaraInitiative.org Leadership Council Chair; Chair of Consent & Information
Sharing WG; Secretary/Instigator of the new Consent Management Solutions WG
 Past Plenary Vice-Chair, US NSTIC ID Ecosystem Steering Committee
 Current delegate to ISO as a Canadian Expert for SC 27 WG 5 (Identity and Privacy);
co-rapporteur for 2 Study Periods, tracking 3-4 standards
 I learn about, research and explore new and interesting Digital Identity stuff
that will emerge in 3 to 5 years’ time.
23