digital identity landscape for vancouver iam meetup 2017 12-19

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.

https://creativecommons.org/choose/idimmusings.org

http://creativecommons.org/licenses/by/4.0/



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, …



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


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


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


• Contract specified• Onboarding

processes• Prior relationships

9


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


• Self-asserted evidence

• KBA/KBV (ugh)• ID Resolution

companies• Remote attribute

assertions

10

Old approaches



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






behaviour & tech





devices• Device


Identifiers

• NIST SP 800-63 v3• ISO 24760• ISO 29003• ISO 29115• OASIS SAML• IETF OAUTH, JWT,





8: Service Account





assertions

12

Old ways: How to connect/bind the ‘entity’ to the ‘electronic

record’

New techniques



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






behaviour & tech





devices• Device


Identifiers

• NIST SP 800-63 v3• ISO 24760• ISO 29003• ISO 29115• OASIS SAML• IETF OAUTH, JWT,





8: Service Account





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

Technology