This document discusses the FIDO Alliance's approach to privacy in authentication. It outlines the history of privacy by design principles and how FIDO implemented them. Key points include that FIDO aims to keep user verification and biometric data local to the authenticator, prevents linkability between accounts, and allows de-registration at any time in accordance with privacy principles. The document also maps FIDO's approach to relevant regulatory requirements around privacy.

1. The FIDO Approach
to PrivacyHannes Tschofenig, ARM Limited
1

2. Privacy by Design History
2
• Ann Cavoukian, the former Information and Privacy
Commissioner of Ontario/Canada, coined the term
“Privacy by Design” back in the late 90’s.
• Idea was to take privacy into account already early in
the design process.
• Cavoukian went a step further and developed 7
principles.
• It took years to investigate the idea further and to
become familiar with privacy as an engineering
concept.

3. Privacy Principles
3
https://fidoalliance.org/wp-content/uploads/2014/12/FIDO_Alliance_Whitepaper_Privacy_Principles.pdf

4. 4
No 3rd Party in the Protocol
No Secrets generated on the Server side
Biometric Data (if used) Never Leaves Device
No Link-ability Between Services and Accounts
De-register at any time
No release of information without consent

5. FIDO & Privacy
AUTHENTICATOR
5
USER VERIFICATION FIDO AUTHENTICATION

6. Prepare0
STEP 1
FIDO
Authenticator
FIDO
Server
App Web
App
6
FIDO REGISTRATION

7. FIDO REGISTRATION
Prepare0
STEP 2
FIDO
Authenticator
FIDO
Server
App Web
App
7
TLS Channel
Establishment
1
No 3rd Party in the Protocol

8. FIDO REGISTRATION
Prepare0
STEP 2FIDO
Authenticator
FIDO
Server
App Web
App
8
Verify User & Generate New Key Pair
(Specific to Online Service Providers)
Legacy Auth.
+ Initiate Reg.
Reg. Request
+ Policy
1
2
3
No release of information without consent

9. FIDO REGISTRATION
Prepare0
STEP 3
FIDO
Authenticator
FIDO
Server
App Web
App
9
3
Legacy Auth.
+ Initiate Reg.
Reg. Request
[Policy]
1
2
Reg. Response4
Verify User & Generate New Key Pair
(Specific to Online Service Providers)
No Secrets generated on the Server side

10. 10
No Link-ability Between Accounts and Services
Website A
Website B
FIDO REGISTRATION
(On Multiple Sites)

11. FIDO REGISTRATION
Prepare0
STEP 4
FIDO
Authenticator
FIDO
Server
App Web
App
11
3
Verify User & Generate New Key Pair
(Specific to Online Service Providers)
Success 5
Legacy Auth.
+ Initiate Reg.
Reg. Request
+ Policy
1
2
Reg. Response4
Biometric Data (if used) Never Leaves Device

12. PERSONAL DATA
12
Application-specific Data
Depending on the service
(e.g., shipping address, credit card details)
User Verification Data
Biometric data
(e.g., fingerprint or voice template,
heart-rate variation data)
FIDO-related Data
Identifiers used by
the FIDO and protocols
(e.g., public key, key handle)
Data
Minimization,
Purpose
Limitation
and
protection
against
unauthorized
access
Outside the
scope of
FIDO

13. THE BUILDING BLOCKS
BROWSER/APP
FIDO USER DEVICE RELYING PARTY
WEB SERVER
FIDO AUTHENTICATOR
FIDO SERVER
FIDO CLIENT
ASM
TLS Server Key
Cryptographic
Authentication
Public
Keys DB
Authentication
Private Keys
Attestation
Private Keys
Authenticator
Metadata
& Attestation
Trust Store
FIDO UPDATE
13

14. ATTESTATION
14
… …SE
How is the key protected
(TPM, SE, TEE, …)?
What user gesture is
used?
14
Can I be tracked
using the
attestation
method?
AUTHENTICATOR
USER VERIFICATION FIDO AUTHENTICATION

15. ATTESTATION & METADATA
FIDO ServerFIDO
Authenticator
Metadata
Signed
Attestation
Object
Obtain meta-data
from
Metadata Service
or Other Sources
Understand
Authenticator
Characteristic
15

16. ATTESTATION & METADATA
16
• Basic Attestation
A set of authenticators (of the same model) share one
attestation certificate.
Injected at manufacturing time
• Privacy CA
Each authenticator has a unique “endorsement” key.
Authenticator generates an attestation key and requests an
attestation certificate from a Privacy CA (using the
endorsement key) at run-time.
• Direct Anonymous Attestation (DAA)
Each authenticator receives one set of DAA attestation
credentials.
Private key is unique to authenticator but unlinkable.

17. Mapping to Regulatory
Requirements
17
• FIDO privacy principles guided the work inside the FIDO
Alliance on technical specifications.
• Interoperability tests and certification programs verify
implementations.
• Regulation impacts those who deploy services.
• Intentionally, the FIDO principles are more detailed
versions of already existing regulatory requirements.
• Upcoming whitepaper explains the regulatory requirements
to FIDO-offered functionality.
• Offers mapping based on the European Data Protection
Directive (95/46/EC) and the Identity Ecosystem Steering
Group (IDESG) privacy principles.

18. Summary
18
• With the work in FIDO we have been trying to
exercise the privacy by design philosophy.
• Whitepaper explains the privacy principles. Those principles
have been taken into account during the work on the
technical specifications.
• Unique privacy characteristics:
• User verification happens locally at the Authenticator
• No centrally created or managed credentials.
• Reduced tracking capability.