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

Digital Identity Landscape for Vancouver IAM Meetup 2017 12-19

  • 1.
    Digital Identity DISCUSSION ATTHE 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  (notblockchain – 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 primarygoal 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 primarygoal 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 DigitalIdentity 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 DigitalIdentity 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 DigitalIdentity 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 DigitalIdentity 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  Increasethe ‘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 DigitalIdentity 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  Increasethe ‘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 DigitalIdentity 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 doesa 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  Fastevolution 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 evolutionof 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  “DecentralizedIdentifiers (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 KeySystems  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  AndrewHughes, 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