Digital IdentityDISCUSSION AT THE VANCOUVER IAM MEETUP 2017-12-19
[email protected] @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-timepassword (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-timepassword (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-timepassword (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